The post about Unity I wrote yesterday was the longest one I’ve published so far, and even then I feel like I left out about a hundred things. One of the most important ones I wanted to talk about was complexity.
When I first moved away from Game Maker in 2018, I really couldn’t imagine actually writing my own games without using a premade engine. I mean, Game Maker is a massive tool that’s been developed for decades, and the source must have thousands of lines of code, right?
Well, yes. But you don’t need to recreate Game Maker. You can make a lot happen with something called MVP; Minimum Viable Product. Let’s look at a practical example.
Super Mario Bros.. Released in 1985, for the Nintendo Entertainment System. Somehow I doubt it ran on Unity.
Let’s start with the most important part: the stuff that moves around and does things.
Now, I’ve looked at SMB1’s engine code, and it actually kind of sucks, so I’ll instead focus on a high-level version of a system that matches what SMB1 has, but doesn’t recreate it one to one. Remember, I want to encourage you to get something made yourself, in your own chosen language and framework, instead of getting stuck looking at hex and memory address behaviour.
We can define an object as something that’s interactable, and can change its state. This locks out stuff like the background bushes, clouds, mountains and also the ground (since it remains constant). However, this means that something like brick blocks and question mark blocks are objects.
In its simplest form, an object base would have a few parameters that every object in the game have: X and Y coordinates, current object state, and whether the object is active or not.
Most of the objects in SMB1 are either very boxy or actually just boxes, so for collision we’ll simply use an axis-aligned bounding box.
How you make the object do, you know, object things, probably depends on what language you’re using. In C I’d use some sort of overcomplicated function pointer array to point to object state functions. In more modern (and reasonable) languages like C#, Java and even C++ you’d probably just inherit the class and make the language figure out what to do with the object.
As for actually managing the objects, well that’s quite simple. The camera in SMB1 moves to the right, and never backtracks, so in essence you just have to worry about objects that appear from the right side of the screen. If you spawn objects only as they’d appear on the screen, and despawn them as soon as they disappear off the left side of the screen, you can easily get away with just a fixed-size array of say, 32 indices, and a for loop to update the active objects.
My very first game was quite literally just this. It’s as basic as it gets, and it totally works!
Generally speaking, one of the most frustrating parts in game development are level creation tools. Without a level, you don’t really have a game, and if your tools suck ass and level creation is a pain, your game won’t turn out so good. As of writing this, I’ve spent about 3 months writing a pretty comprehensive level editor for Radium. However, your first game (super mario) won’t be as complicated. We’ll use something tangible as an example again!
Let’s look at world 1-4, the first Bowser castle. At first glance it looks rather complicated, there’s floor, a ceiling, both change height at several points, there’s pits, all sorts of traps. It looks like a cohesive place.
But remember, video games are all smoke and mirrors. Ultimately all of this is just numbers in memory.
With that in mind, if you stare at the stage for a while, you might start noticing some strange details. Ignoring all enemies and simply looking at the ground, you might notice that the level never features any overlapping geometry. Bricks and question mark blocks may occasionally form platforms, but as far as the ground and ceiling goes, there are never any overhangs, tunnels, multi-layered passthroughs… it’s simply all solid blocks.
SMB1 constructs its worlds by defining a floor and ceiling height. The level itself is constructed by placing markers along the stage that change the floor and ceiling height from that point onward. If the floor is 0 grid units high, it’s a bottomless pit. Therefore, if you simply wanted to make a clone of the world generator and Mario’s player controller, the collision detection would at its simplest be whether or not Mario’s feet are below the ground level. For walls, you can scan the stage forward by Mario’s width and see if the ground level changes at all. If it does, you can check if it’s again higher than Mario’s feet level.
Thus, we have a level creation toolset that doesn’t even require tiles. It might not be suitable for a WYSIWYG approach to level design (for that I’d recommend Tiled or similar), but for a starting position you can quite literally just hardcode a list of ceiling/floor height change instructions separated by N amounts of tiles. Level design without an editor.
That’s not all I could talk about, but I already feel like this is a lot to swallow. Stuff like sprite batching, tile rendering, texture atlases etc. are all topics you'll probably encounter sooner or later. I'd really love to go on about stuff like this, but I'm trying to avoid writing a book.
My hopes with this post are to showcase that making games outside of the carefully curated toolsets of modern engines isn’t always as difficult as you’d imagine. The likes of Unity and Unreal have made us believe that game engines are gigantic, unscalable mountains of code. In truth, a game engine is simply something that runs a game.
When I started my engine journey in 2018, I hadn't really realized this. I jumped to MonoGame because I thought custom engines were rad, but I didn’t really know how to actually make an engine, let along a game in one. It didn’t take long to figure just how many corners you can cut to just make something work in the most basic of senses. For every challenge, you have infinite solutions, far beyond the templatized ones provided to you by online Unity tutorials.
I made the source code for my first ever custom game open when I finished the game. It was written in about 2 weeks, and during the production I learned MonoGame, C# and engine design philosophies, all for the first time in my life. You can take a gander at it here and witness it in all its hacky glory. Despite that, it’s a game that you can play.
I’ve also opened up the questions page on my Tumblr, so maybe I can assist with some issues you may have when starting out. I hope I’ve at least inspired you to give a shot for outside the box thinking. The game you want to make may be a lot simpler than you initially imagined.
Happy carefree programming!
blakekathryn
annaxmalina
areudirty
pixelskylines
vaporwave
andulkaphoto