If you’re still not in the loop, I’ve also got a shiny new trailer to go along with the occasion!

A huge thank you to everyone who played and left feedback on the beta! Many of the improvements since February would likely not have happened without you. While I’m sad I wasn’t able to get to everyone’s feedback (especially for more recent respondents), you’ve all given me a lot to think about for the full game.

While there’s still a ton that could be improved with this demo, I’ve committed to not letting the “good enough” be the enemy of the “totally shippable bro”. With that said, and even if I’ll probably still be working on this demo for weeks to come, this is nevertheless a version I’m truly proud of and ready to share far and wide.

And speaking of the full game, I can finally confirm that we’ll be launching a Kickstarter to help fund it on April 28th! If you enjoyed the demo and want to see the full project realized, keep an eye out for that and tell your friends! Really. We’re still pretty underground, so sharing the demo around is liable to have a big impact.

You can check out the pre-launch page here: https://www.kickstarter.com/projects/massimog/diorama-break

While this version of the demo is fully playable from start to finish, some polish, balance tweaks, and quality of life features are still forthcoming (particularly audio improvements). Once these planned changes and player feedback has been implemented, a full demo release is planned for Steam sometime in March!

Look forward to it!

The City

I was pleasantly surprised that I was able to get to my hotel from the airport in just under an hour using Seattle’s light rail system. Coverage and frequency could be better, but the trains and stations felt pleasant and clean by North American standards. I get the sense that this system has spent what little resources it’s been given into hitting a decent standard for travelers (specifically, those staying in the city proper), which makes sense.

As is typical in NA though, things rapidly deteriorate once you get away from the city center. I went to a wrap party held at a venue about 40 minutes away, thankfully was still able to get there by train but the 15 minute walk between the station and the restaurant was along a gigantic stroad and has got to be one of the creepiest I’ve ever taken.

Google maps also lied to me about when the trains would stop running, which was fun to discover after having walked back to the station at 1AM…

The architecture was somewhat more interesting than average, though nothing breathtaking or too out of the norm for NA. Density in the city center felt like the densest parts of my home city Montreal, but over a noticeably wider area. Good, but it didn’t really blow me away like New York did. Roads were an interesting mix of very wide (three car lanes + bus lane) and quite narrow (enough to cross in two strides; I felt safe ignoring the traffic light).

The People

One thing I always notice visiting America is how willing total strangers on the street are to randomly say things to you or even strike up a conversation. It’s a surprising fact, since as much as people like to say Canada isn’t all that different I’ve almost never had that happen here. I’d say I’m somewhat indifferent to this over my usual status quo, it can be a fun diversion but sometimes you don’t really have the energy for it. Related to this, though this seems like more of a west coast thing: the front-facing service workers I met almost all either projected a sense that they wanted to kill me or that they are utterly jazzed to be talking to me1. Both vibes are somewhat uncomfortable, but likely just because I’m used to a more “genial yet straightforward and curt” attitude.

Another thing that stood out: in discussions, I was struck by how desperate people2 seemed to maintain social harmony, or, more accurately, a mutual sense that no one was offended or hurt by anything done or said by anyone3. The most notable example was when mentioning to a group that I did not drink alcohol, all three people I was talking to visibly sprang to offer me a laundry list of reasons why that was completely fine in their eyes. When I asked them why they and others seemed to do things like that, one put forth the idea that it was due to people wanting to foster unity despite the area’s cosmopolitanism. Coming from a fairly cosmopolitan city myself, this explanation seemed lacking, though maybe it’s just a skill issue on our part. The same person claimed it was a mixed blessing though, since in his experience many would act familiar to the point where it seemed they wanted to pursue friendship, yet cancel plans and refuse to ever follow up later.

The Food

Was ok. The state of American takeout food always feels perfectly congruent with the litany of health crises the country is experiencing4. I did have some nice thai food, and the hotel I was staying at had okay-ish vegan pizza next door. Tried some salty ice cream; novel, but not something I’m likely to do again. I’ll admit I did not have the time or money to try anything top rated, so don’t take this as criticism of the best Seattle has to offer.

The Expo

I wish I could say the actual experience of exhibiting was fun, but the build wasn’t exactly finished when we were due to start5, so the first three days ended up very stressful and very sleepless (advice to my past self: don’t underestimate how long it will take to complete the demo by more than half, you fool, you moron6). The last two days were fortunately less stressful thanks to a more stable build, but as usual for these sorts of events, marred by exhaustion. I didn’t even get to try Kirby Air Riders7…

We were also only two (huge, huge thanks to Rowan, one of the artists on the game, for flying down and helping out), which is pushing it; three feels like the minimum needed to not have someone crippled by exhaustion on the last day (again, huge, huge thanks to Rowan). Important advice: get shoes optimized for standing. I brought two pairs, my normal shoes for the trip and a pair of Hokas for the actual expo. Sit down frequently, especially if you’re in pain; don’t try to push through it. Rest properly at the end of every day.

Still, through it all, it was an incredible relief to see the very (dare I say it, overwhelmingly) positive reaction to the game. With how many unorthodox choices I made in the writing and game design, it was immensely gratifying to me to have people praise them directly, and the rest of the team were all stoked to receive so many compliments on the game’s visuals and music. And all this despite how much content was missing from the demo we showed8! I can’t wait to put the completed demo out and show you guys what we can really pull off.

And beyond just compliments, it’s nice to have finally created something that people cared enough about to give, uh, constructive feedback on (some of it valuable, even!). We even got recommended some games to learn from (hadn’t heard of Phantom Brigade, but I’ll definitely be stealing tastefully adopting some UI ideas from that game).

Everything went smoothly with the event staff and organizers, no complaints there. Though I’ll say, it must feel vaguely infantilizing for the attendees to have the enforcers form a human wall at the end of every day and sweep through the convention like a wave, bright flashing lights and all. I got the sense though that this was more a teambulding exercise for the staff rather than something deemed strictly necessary.

Also had some great booth neighbours; was pleasant to talk to an out-of-province Canadian dev about the various things, especially the programs and services available to them, both public and private.

Wrap-up

With everything over and done with, it’s important to recover properly. For that and no other reason, I’ll be taking the next couple days to rest, then it’s back to the grind. Enjoy Silksong everyone!

Subscribe now

Waow! Wondering where this will go? Maybe, uuuuuuuuh… subscribe?

Subscribe now

Me and my team are working as fast as we can to finish up a proper demo within the next couple months (as the ship that is my personal funds buckles and collapses beneath us); I’ll definitely have more to share here then (or earlier, if I feel like it). And as the project progresses, I’ll aim to post regular updates about whatever it is we’ve been working on lately, if it turns out there’s an audience for it.

In the meantime though, why not join the new discord or wishlist the game on steam? Who knows, maybe you’ll find some more info about the project there…

If you just can’t wait to play it though, we’re planning to have the first half of the planned demo playable at PAX West in just under a month! Come check us out in the Arch Expo Hall.

In a sense, I think this Stokes guy is right. Capabilities are improving at tremendous speed, anyone like me expecting AI to get to the point where it can conquer the world (or, more optimistically, all jobs) should naturally expect to see it master software development sometime before then. But the point of contention here is whether current AI systems can even provide significant productivity gains to programmers working on meaningful, complex systems and… ha… haha… yeah, I’m very much on Blow’s side on that one.

But, y’know, anyone can just toss that opinion out there. Fortunately for me though, it doesn’t seem like many skilled programmers that hold the “current AI is incompetent” view have actually bothered to substantiate their point (at least, with an article like this). I feel like, when I see these sorts of disputes, a lot of people are missing context.Everyone agrees the AI isn’t perfect, but what exactly is the AI failing at and why does it seem to matter so much more to some people? As someone who has tried AI out in multiple contexts, I thought it would be valuable to give the “strongest” tools a fair shot and closely scrutinize and critique the actual outputs. Who knows, maybe I’ll get a benchmark named after me1.

The Task

The task is simple, and so are the rules:

• I have recently added a simple camera shake feature to the game I’m working on. This was done without any AI assistance. Based on the edit history of the relevant files, this took me about 30 minutes.

• I will branch off from just before I added the feature, then use an AI tool to recreate it. My goal will not be to necessarily perfectly replicate my implementation, but to prompt the AI and make edits until it’s version of the feature is basically functional. I will then critique the code it provided throughout this process.

• If the AI tool and I cannot achieve basic functionality (from when I start typing the first prompt for the AI), I will critique what work it was able to do inside of 30 minutes.

Frankly, I’m throwing the AI a bit of a softball here. The problem is not too difficult, we’re not doing any major overhauls to the program’s structure, we’re not adding a feature that touches multiple systems, and most of the structure is already in place, no need to add any entirely new systems. This is partly to keep this test easy to run, partly to keep things short and understandable for beginners, and partly as an additional sneaky test for the AI: can it recognize that there’s no need to overcomplicate things?

My implementation

Before we give the AI a shot, let’s take a look at my existing implementation to get an idea of where our standards are at.

As mentioned, the goal was to create a camera shake system. Specifically, I wanted a function I could call which:

• Takes a duration (in frames) and a force (in pixels) and shakes the camera that much, for that long.

• Calling the function multiple times should create an additive effect, so multiple sources of camera shake can add up to create a stronger overall effect.

• I’d also like the ability to limit the shake to only the x or y axis.

Before I started, the camera was mainly controlled by the stage system, and its final position primarily depended on three global vector2 variables:

• stage.target_camera_pos: Primarily meant to be messed around with by entities in the stage. After setting this value, the camera’s center position will (later in the frame, when the camera updates) be moved to this value. At the moment, the camera will always snap instantly to this position, but in the future I may have it move more smoothly/gradually towards it.

• stage.camera_pos: The camera’s actual position in the stage. If you imagine the camera’s view as a rectangle, this position would be in the top left.

• camera.pos: When the game draws anything, this value is applied such that the camera system works as intended. This value is extremely volatile and is mainly intended to be a cached value that can be quickly accessed and used in drawing functions without needing to cast or modify the value. When changing drawing contexts (such as when drawing to a separate texture), a new camera position is pushed onto a stack, and is popped off said stack when returning to the previous drawing context. Whenever the stack changes, this value is updated to reflect the top value of the stack. Also corresponds to the camera’s top-left position. stage.camera_pos gets pushed onto the base of the stack when the current stage begins rendering.

Here’s what the stage system update (which was basically just camera code) looked like:

In summary:

• If the camera is tracking a specific entity, set the target position accordingly.

• Set stage.camera_pos based on stage.target_camera_pos

• Clamp stage.camera_pos to the stage bounds.

camera.pos is then set via the provided function in the stage rendering code, right before it starts drawing stuff:

Alright, with all that preamble out of the way, let’s look at the changes made. Since I was finally adding per-frame camera-related behavior that arguably wasn’t also closely tied to the stage system, I first decided to move all the camera code in the stage system to a camera-specific update function:

That left _stage_system_update empty, but I decided to keep it around in case I want to add anything non-camera related to it later.

The simplest form of camera shake essentially just involves adding some random value to the camera’s “unshaken” position every frame. With that in mind, and since _camera_system_update is intended to be the “end point” for any camera changes in a frame (i.e. any special camera behaviors I add in the future will either be called inside the function or before it), I decided to implement camera shake by modifying stage.camera_pos after we’ve set it in _camera_system_update. Since I wanted the camera to be able to shake slightly outside the room bounds, I decided to add the shaking code after we clamp stage.camera_pos.

But I still needed some values to refer to in order to determine how much shaking to apply. Since we want shaking to be able come from different sources, which could shake things for different lengths of time and with different strength, I decided the best way to proceed was to have a pool of shake “requests” that can be added to or removed from2.

Each shake request stores a how long it should keep on going for, as well as a force value. The force is stored as a vector2, allowing me to apply different amounts to the x and y axis.

Exposing this to the “user” (me) in the form of the originally specified function is trivial:

With all that out of the way, applying the actual shake is simple:

• Loop through all the requests, adding up their force, updating their timers and removing them when they run out. The order of the requests doesn’t matter, so we can use an O(1) time unordered remove.

• Once you have the total force, for both the x and y axis:

  • Clamp the force to avoid edge cases where its unnoticeable or overwhelming

  • Apply some randomness to make the camera shake feel more varied

  • Add or subtract (at random) the force value to the camera position

And voila! Now all that was left to do was test and see if it works. The easiest thing to do was just to throw something at the top of the player’s update loop, so that’s what I did:

Waow!

Here are some combined calls. With this code, the camera shake should increase significantly for 10 frames (1/6th of a second) whenever I click (I also made Pro flinch for effect):

Here’s vertical shake only:

Tubular!

And all in just about 30 changed lines!

Now let’s see how the AI handles it.

The AI’s implementation

While I have tried Claude Code in the past, for maximum fairness, I wrote the previous sections before running this test, and won’t be making any major edits to them after conducting the test.

You’ve been able to ask AI chatbots to spit out code for you for quite a while now, but more recently firms have begun offering “agentic” AI coding tools which can take a look at entire codebases and intelligently make changes. I’m not interested in comparing a bunch of different tools, so let’s just go with the best, which right now is…

Claude Code!

Setting things up wasn’t too tough, now let’s jump right in. You’ve already seen the initial prompt earlier:

And here’s the first edit it came up with:

Impressive! The core idea is there, with only a little overcomplication compared to my implementation. Let’s see if we can correct that:

Nice.

It also remembers to init the data structure:

Here’s the main implementation:

Not bad. Here are the issues though:

• The extra camera_shake functions are a nice touch, but given that Odin makes it easy to provide a Vec2 or a scalar to camera_shake, ultimately unnecessary.

• It’s keeping a separate global variable for the shake offset. I didn’t catch that earlier; as you know, it’s unnecessary.

• It doesn’t bother using odin’s special loop syntax, making the loop definition a teensy bit harder to parse than it needs to be.

• It uses an ordered_remove to get rid of expired “shake instances”, wasting time unnecessarily. Surprising, since it’s still looping through the instances in reverse.

• It correctly applies a bit of randomness to the shake, but this is done in an overly wordy way. It also gets the random function’s name wrong (should be random_f). The exact way randomness is applied is also not quite the same as what I’m doing, but that’s not super important and it does result in less calls to the RNG for now. Since this is something I plan to refine later even in my own implementation, I’ll leave it like this for now.

• It doesn’t clamp the shake, but given that I never asked it to do this I’ll give it a pass for now and come back to that later.

Let’s give it feedback on the major problems and see where it goes with it:

Still a bit more verbose than I’d like, but let’s move on.

Its plan is revealed! This comes before the clamp though, so let’s fix that, as well as the unnecessary global while we’re at it:

Cool.

It then tries to see if the code compiles, but I tell it that I have my own build pipeline and it should just add some test code and let me run it:

Good enough. Testing in-game, it all builds and works fine (Claude has a strange idea of “gentle”, but whatever).

Oh, let’s not forget:

Wow, that’s a bit much. Whatever though, also good enough.

How’d it do?

Frankly, pretty good! Claude was definitely off the mark at times, but with some scrutiny and feedback, it managed to get pretty close to our “ideal” implementation. Sure, its syntax is a little more verbose than necessary, and its architecture is a little less clean (still pretty well segmented though, nothing I’d consider egregiously wrong). Still, verbosity is a real cost, Claude sometimes taking a dozen lines to express what I can cleanly express in 1-2 can add up to serious problems in terms of readability and maintainability. I can always go clean it up, but man, that’s gonna add more time, let’s check and see how long Claude and I were at it-

Oh. 50 minutes, huh? So much for 5x productivity gains…

In the end, I think this test isn’t going to satisfy either side of the debate very much. Those who believe in the current power of the tools are gonna feel like I spent too long studying and nitpicking every last detail of the AI’s implementation, squandering any productivity gains. The skeptics, on the other hand, will likely see this task as trivial, and not really proving anything about serious capabilities3. I think a more serious version of this would involve running the same process on the implementation of a large and complex system that took multiple days to complete and touched many different parts of the codebase (and didn’t have as straightforward of an implementation strategy). But that would be far more difficult to fit into a short, accessible post like this one, and I have better things to do4!!

Still, for any confused onlookers willing to really study the details shown here (I do it all for you, my lovelies), I think this exercise will offer you some insight into the current power of these tools. At least until the next big capabilities leap in 6 months completely obsoletes this post.

<<Introduction | <Previous post

Oof, been a while hasn’t it? It’s January now and I wrote the previous two posts I just uploaded alongside this one back in August, didn’t quite have time to put the finishing touches on them before work on Antonblast went crazy, so they languished in my drafts for a bit. Oh yeah, Antonblast, that came out! I’d be surprised of anyone reading this hasn’t seen it already, but in case you didn’t read the first post in this series, my frustrations working in Game Maker on that project was what set me down this path of making my own engine in the first place. And my opinion hasn’t exactly turned around, getting that game ready for a Switch release was a nightmare all on its own (one I might write a bit about in a future post). But anyway, it’s time to put an end to this series, because guess what?

I did it!! Woo!!!

That’s right! As of… uh… roughly September-ish, I finally completed my engine! And just in time too, ‘cause its first game has officially been in full development since December, just as planned! That’s been a real timesink, lemme tell ya, but I felt bad not having finished this series, so before my life is entirely consumed by that project, I’ll run through all the little stuff I missed:

Fonts and text rendering

Frankly, there’s a lot more to this topic than I could write about in 100 posts or that I even know, so I’ll just cover how I handled things for my own purposes.

When building a text rendering system, you might be tempted, as I was, to just load font (.ttf) files alongside your other assets, then use a library like SDL ttf to read those files and render out your fonts whenever you need to draw text. This was unfortunately a misstep that cost me a few days to fix, because doing things this way is slow. Every time I wanted to draw a new character at a given size, the library would have to generate a texture for that single character using the .ttf file data, which I had to send to the GPU whenever I wanted to draw that single character (see the post on sprites to learn why this isn’t great). While most libraries will do some caching to help alleviate this, it will still cause unacceptable lag spikes that one doesn’t have a ton of control over (one frame in testing that had to draw a paragraph of text for the first time all at once took 40 whole milliseconds to render, disgusting).

So, what’s the alternative? While there are definitely ways to make using .ttf files at runtime faster, if you know ahead of time what fonts you’ll need and what size you’ll need them at, it’s better to just cut out the middle man and pre-generate some font texture pages! Just like sprite texture pages, these are large images that have all the characters of a font rendered onto them and packed tightly together, along with an index file that records where each individual character is located in that image. Rather than including the .ttf file in the final game assets, the build process simply reads those .ttf files, generates these pages, only includes them in the actual game. When rendering text, I can then copy the image data from these textures, and just like sprite pages these have the advantage of being able to batch multiple character draws together before having to send new data to the GPU.

In order to make this process possible, each .ttf font should have some kind of attached config data that specifies how it gets converted to a font page (I use little .json files stored in the same folder). This data should look something like this:

• Ranges: Specifies which characters I want to actually have on the font page using unicode ranges. Most games won’t really need to display e.g. the ugaritic alphabet, so it’s useful to be able to narrow down the characters I need, to save on texture space. The ranges in the example above correspond to the Japanese hiragana and katakana syllabaries (I’ve made it so my system always exports the basic latin characters no matter what). If you’re confused as to why the numbers at the links don’t match what’s written in the example, that’s because unicode indices (‘code points’) are usually written in hexadecimal. If you convert the numbers into decimal, you’ll see that they match up with the ones I’ve written.

• Sizes: What sizes of the font I want to export. Since I can’t read the .ttf file on the fly, the texture data I’m rendering in-game is static, unchanging, so each different size needs to be pre-rendered separately.

• Page: Which page to put the font data on. If multiple fonts are often used together, they can be packed together on the same page to make rendering them more efficient.

Collision

This is more of a per-game thing, but I’ll cover a quick solution for collision that can work in a lot of situations.

The basic operation of a collision system is checking whether two shapes are overlapping. In the simplest case, two rectangles (call them A and B), this is done by checking 4 things:

• If the x position of the left edge of A less than (i.e. to the left of) the x position of the right edge of B

• If the x position of the right edge of A more than the x position of the left edge of B

• If the y position of the top edge of A is less than (i.e. above) the bottom edge of B

• If the y position of the bottom edge of A is more than the y position of the top edge of B

If all 4 of these things are true, it means the rectangles are overlapping (think about it carefully).

While checking this can be quick, often things get dicey once there are a lot of rectangles to check. Say I’m a rectangle (maybe I’m attached to a player) in a stage with 100 other rectangles (maybe they’re attached to walls, or enemies). To know if I’m overlapping with any of them, I need to check those 4 conditions 100 times! And I might need to do that several times in one frame (for example, if I’m moving, say, 8 pixels this frame, then every pixel I move I need to check all 100 rectangles again to know if I’ve hit a wall and need to stop. In the worst case, that’s 800 checks). And if any of the other rectangles want to do similar collision checking, they have to go through all the others too! 100 rectangles that want to collide with each other means 10000 collision checks!

Ok, calling them ‘rectangles’ is a bit weird, they’re usually called ‘colliders’, since they don’t necessarily have to be rectangles, so I’ll switch to that, but keep in mind that no matter what we’re just checking if two shapes overlap.

Anyway, there are several paths to optimization here, but a simple and easy one is to just narrow down the number of colliders we need to check. If a tiny collider is on one end of a large stage, I know for sure it’s not going to be colliding with another tiny collider all the way on the other end. Knowing this, I can split the stage up into “partitions”, which each has a list of the colliders it contains1. Whenever a rectangle is created or moved, I check if it moved out of a partition or into a new one and register or deregister it with that partition. Then, when doing collision checks with a rectangle, I first check which partitions that collider overlaps, and then only check for collisions with colliders registered to those partitions. If done properly, this cuts down massively on the number of collision checks that need to be done in one frame, great success!

So what about non-rectangle shapes? Different pairs of common shapes will have different “fast” ways of checking overlap, but rectangles are basically always fastest to check, so usually colliders will keep track of their shape as well as a ‘bounding box’, i.e. a rectangle that perfectly encloses the shape. Since most things aren’t overlapping most of the time, when checking for overlap between one or more non-rectangles, overlap between bounding boxes will be checked first, then the more expensive check will be done if and only if the bounding boxes overlap (since we can infer that the enclosed shapes aren’t overlapping if their bounds aren’t). This saves on doing a bunch of expensive checks. But what are those checks?? To be honest, for my purposes rectangles work 90% of the time, so I didn’t bother implementing any other common shapes. The other 10% is covered by “precise” collisions, i.e. irregular shapes, usually ones that conform to the exact shape of a sprite. To check these, I basically brute force it: for every “solid” pixel in shape A, I check if its position matches any solid pixel in shape B. This can be quite expensive, but it will happily handle any weird shape you can draw to a grid, and these sorts of collisions are so rare that it’s not usually a big deal. And if it ever does get to be a problem in a specific case, I can always just devise a more optimal solution for that specific case.

Shaders

Ugh, another topic that people can and have written whole textbooks about. Frankly, I’m not an expert on this, but basically the GPU’s shader is the program it runs which determines how it actually renders out texture data. Custom shaders can be used to produce all sorts of creative visual effects (as well as leverage the GPUs parallelism to do certain kinds of computations), but they’re always written in their own quirky languages due to said parallelism, and are limited in their ability to communicate with your main program.

Initially, these gave me a bit of trouble, since SDL2’s basic rendering backend, which handles making a lot of the more complicated calls to a graphics library such as OpenGL (which is what is ultimately making the CPU talk to the GPU), did not support shaders out of the box. Since I didn’t have the time to properly learn OpenGL and outright replace SDL’s functionality here I was in a bit of a bind. However, I figured out, through a lot of stressful research and trial-and-error, that by forcing SDL to use OpenGL as the rendering backend for its basic renderer you can make some simple calls to OpenGL to set a custom shader before calling SDL’s rendering functions, and the shader will work correctly. Nowhere on the internet is this explained explicitly, so, uh, you heard it here first folks!2

Anyway, once all that was figured out, the rest was just a question of writing some shaders and adding them to the asset system. The sorts of shaders I want to use are few and fairly short, so I can get away with just packing the shader code (i.e. the text of the program, written OpenGL’s shader language, GLSL) in with the rest of my assets, then calling OpenGL when the game starts to compile that code into usable instructions that can be passed on to the GPU when needed.

Again, really not an expert here, I couldn’t yet tell you how half the crazy stuff people do with shaders is done, but getting started using shaders for applying simple effects to 2D textures is not that bad at all.

Each GLSL shader is split into two parts:

• The vertex shader, which is only really relevant for 3D because it’s used to mess around with a 3D shape’s vertices, and so in my case will basically always look the same and not do much. If I wanted to deform the rectangle my texture was being drawn to this might be relevant, but usually I don’t.

• The fragment shader, which is used to mess around with pixel data by changing the position and value of colors on a texture. You can think the actual function written in it as being run on a single point of the texture (the GPU will run it on as many points as needed to construct each pixel of the final output). This is where the magic happens, by passing in a texture here, sampling it, modifying the sampled color, then passing it on, we can create all sorts of neat effects.3

And that pretty much covers it! If you want to get started with these yourself, I’d recommend looking up examples online, but here’s an example of a shader I wrote that creates a simple wavy effect and pulses the texture red:

Serialization

You can think of ‘serialization’ as just a fancy synonym for “saving and loading (usually to a file)”, or, in a dry, useless, technical sense, “converting data into a stream of bytes for transmission or storage”. But it’s worth dissecting the term to understand what it really means: data in computer programs is, underneath it all, just a long string of ones and zeroes. But some of those ones and zeroes are treated as references to other bits of that long string. If I have 100 enemies in my game that all look the same, I don’t want to copy the texture data used to represent those enemies 100 times, what a waste! So instead, in each of the little data structures that hold each enemy’s information like position and speed, I keep a small little number that shows you exactly where to find that enemy’s texture data in some central place in memory. When the rendering system comes along to render that enemy, rather than reading the texture data to pass to the GPU directly from the enemy’s data itself, it follows that little address and gets it from the central place. This is all well and good, but now let’s say I want to save all of that enemy’s information to a file, so that I can load it up later. I tuck all the little numbers in the enemy’s little data structure into a little binary file and back it up to the cloud.

Flash forward 70 years. I am old. Too old. My only remaining shot at joy in life is to see that little enemy again. I pull the enemy’s file down from the hypercloud. Tell me dear reader, using only that file, will I be able to draw that enemy again…? No! Sure, I’ll know where that enemy was and how fast it was going, those are just numbers, stored safely in the file. But that little address that showed me where to get the texture data? It points to nothing. The RAM that held that texture data turned to ash long ago. Despair overtakes me, I will never see my enemy again.

This is what it really means for data to be “serializable” or not. If you can reconstruct all the relevant information a block of data is meant to represent by reading through that block alone, a.k.a. that serial string of ones and zeroes, then we can say that any data that can be turned into such a block is serializable. Conversely, data that isn’t serializable is data which points to outside information using addresses whose validity won’t outlive the data itself. Note that there’s a bit of fuzziness here. If I had loaded the enemy file right after saving it, without closing the program, the address pointing to the texture would still have worked (assuming the program didn’t move the texture data somewhere else for whatever reason). If I never intend to keep enemy files around for longer than the lifetime of the program, then I will always know how to interpret the texture address properly, and the enemy data is, in a limited sense, serializable.

Anyway, as you may have guessed, serialization comes into play when saving and loading the player’s progress, as well as when editing data that will get turned into loadable asset files such as stages or cutscenes. The exact details of how one goes about serializing this sort of data radically depends on the details of a specific game, but it’s important to think about how your data is laid out and to be able to quickly recognize what can and can’t be easily serialized.

Stages

A stage system is something that is genuinely so game-dependent that it’s tough to describe in detail. But broadly speaking, stage systems will look something like this:

• Stage data is saved to a file in a format your engine can interpret (i.e. deserialize).

• These files are edited using and external editor such as Tiled or LDTk, or in-engine using a custom-built level editor. On my current project, I built an editor that can edit entities and a few other things like image and tileset layers directly. When saving, the editor reads only the relevent information from the game state and serializes it to a stage file.

• When loading a stage, existing entities and other non-persistent stage elements are cleared, and new ones are created using information from the stage file.

Particles

Gonna be honest, haven’t gotten around to actually building this yet as of writing this. But in principle, this is just a very efficient sprite system that sacrifices versatility and control over individual sprites in order to quickly be able to draw a huge amount of sprites at once. The difference is related to sorts of considerations that come up in Data-oriented design, something I touched on in the post on entities. Basically, the plan when building a particle system is to pack all the information your particles will need in order to be rendered (stuff like position, speed, spin, and texture information) as conservatively as possible into one dense array (it’s worth looking up other particle systems to get an idea of the kind of variables they use to create effects). You can then churn through this data very quickly, updating and rendering each particle without needing to retrieve data from elsewhere.

Other tips and tricks

• A debug console you can call up at anytime is an invaluable tool, and worth building. At its simplest this is just a textbox where you can type in predefined commands which will call custom functions, but adding features yourself such as a history, autocomplete, command arguments, and a visible output is not as daunting as you might think. I use the dear imgui library to build in-engine development tools like this, and it’s quite pleasant to work with.

• Similarly, learning how to set up and use a profiler is not that hard and is indispensable when it comes to evaluating your code’s performance, and for a language manually managed memory like ODIN it’s immensely useful for making sure your program isn’t leaking memory (i.e. requesting memory without properly cleaning it up when its done, an error which will eventually balloon your program’s RAM consumption and crash it). I recommend Tracy, ODIN bindings can be found here.

• Tilesets should just be a small extension to the existing sprite system. Define a structure that “wraps” a sprite with a additional information such as tile size and padding. You can then build functionality that takes that structure as well as a given “tile index” and draws the relevant part of the sprite, i.e. the tile at the given index.

• Regularly testing your engine on platforms you plan to support is a good way to catch bugs early and ensure you aren’t swamped tracking down errors in code you wrote months ago when it’s finally time to publish. Personally, I have not been keeping up with this, and am therefore screwed.

• When working in ODIN and using a dynamically linked library, remember to include the library file with your final executable (.dll files on windows). Unlike a pure ODIN package, ODIN bindings just tell your program how to call a library, but if you don’t include the library itself alongside your .exe your program will fail when it tries to call the library and finds nothing. This does not apply to statically linked libraries (.lib on windows), which will be built into your .exe when compiling.

• Slightly related to the above point, you can take advantage of .dlls to reload the majority of your engine’s code while it’s running, giving you the ability to change functionality without needing to close and reopen your program, which can help a lot with iterative testing. The exact details of this are too technical to cover in this series, but I’d recommend checking out this repository for details.

Grand Conclusion

And there you have it! Thanks a lot for reading, to those who have or are planning to build their own engine I hope this helped make it all seem more approachable, looking back over those 6-ish months of work, it really does seem like modern languages like ODIN have made learning and doing proper low-level game development more accessible than ever before, even on a tight schedule like mine. And for those non-programmers this series is ostensibly aimed at, I hope this demystified a lot of what goes on under the hood of your favorite games and gave you a richer understanding of the medium.

And for those who are maybe on the fence about jumping into this kind of development, I really hope this gave you the push you needed to give it a shot. While I wouldn’t recommend it to a complete beginner, it’s clear to me now that building an engine like this isn’t the crazy multi-year ordeal some make it out to be, and that it should be a natural step on every game programmer’s journey. Especially for those developing 2D commercial projects, having to deal with a third-party engine can end up being far more trouble in the long run, and building your own foundation in a data-oriented way will result in a happier development experience and better software for your players. And best part is, you can do stuff like this:

Onto the next thing

Alright, I’m off to have my life entirely consumed by that project. See you soon!

Subscribe now

<<Introduction | <Previous post

<<Introduction | <Previous post | Next Post>

just use FMOD lol

<<Introduction | <Previous post | Next Post>

<<Introduction | <Previous post | Next post>

Input. Seems simple, right? Press the A button, make the marketable character jump. Easy peasy. But what if I want to press the spacebar instead? What about the right trigger? What if I only want to use one hand? What if I wanted to press the a button now, but I did it one tenth of a second ago? Everything’s falling apart. The intern has drizzled conditional input checks all over the player object. You’re using variables from 5 different files, half of which you don’t remember making. You’re tracking input buffers in the player’s state logic. Nightmare. Nightmare! NIGHTMARE!!

Like many software development tasks, building a proper input system is an exercise in abstraction. The goal is to translate signals from a controller into actions in the game, but problems arise when thinking of this as a 1:1 relationship. Instead, it’s often simpler in the long run to construct multiple abstraction layers which store information and mappings and serve to translate concise, high level requests (e.g. did the player make a “jump” input?) into questions of the lower level hardware (e.g. did the 3rd face button on the gamepad connected to OS port 2 go from unpressed to pressed within the last 10 frames?).

Now, the exact construction of these layers is going to vary significantly based on your preferences, needs, and what your framework/engine can already provide for you, but I’ll describe the system I use, which is fairly generalizable. It involves roughly 4 layers:

• The framework layer

• The abstracted hardware layer

• The mapping layer

• The verb layer

The framework layer

Premade engines like Game Maker or Godot will usually get you most of the second layer out of the box, sometimes more, but if you’re just using a framework like SDL then this is the only part that will already be done for you. In my case, SDL handles two things for me:

• Allows me to retrieve the complete input state of the keyboard or mouse at any given point in time as a big chunk of data.

• Triggers events when a gamepad is connected/disconnected, which provide a pointer that can be used to retrieve infromation about the state of that specific gamepad later on.

The abstracted hardware layer

The goal of this layer is to read the input states obtained from the previous layer and allow us to easily ask, for any given device, whether one of its keys/buttons1 was pressed, released, or is being held. Also to retrieve the current value of unique stuff like analog stick axes or mouse position. I call it the “abstracted hardware” layer because, while we’re still thinking of physical devices at this point, I’ll be fully abstracting away anything that isn’t directly relevant to input; stuff like what exact usb or hardware slot we’re using, or weirdly formatted analog input values.

For the most part, we can just pass on slightly reformatted values from the framework layer, but there are two not-so-trivial problems to solve here:

• How do you tell if a button has just been pressed/released, given that we can only retrieve the current input state at any given time?

• How do you handle multiple gamepads?

Taking them in order, the first problem is simple. As mentioned previously, the game runs it’s logic once per “frame”, in my case every 1/60th of a second. While some applications will try to obtain the input state as often as they can, in my case I only have to do so at the start of each frame. But I can also store the input state from the start of the previous frame as well! By doing this, whenever something asks if a key/button was pressed, I just need to check the current state against the previous state. If the button was inactive last frame but is active this frame, that means it was just pressed down2!

The next problem is a little trickier. If you’re making a singleplayer game you can get away with just polling every connected gamepad for input and treating them like one weird schrodinger’s gamepad, but if you’re doing any sort of multiplayer you need to be able to differentiate between each specific gamepad; you need to assign each a unique, persistent ID.

I see many beginners inclined to just look up a controller’s ‘hardware slot’ (the number sometimes indicated by little green lights on controllers) and use that to identify it. Unfortunately, this runs into a number of pitfalls, mainly because it leaves you completely beholden to what the OS wants to do with this ID. Did you know that on Windows it’s almost impossible to change what ID a controller has been assigned without restarting your PC? If you plug in two controllers then unplug the first one, well, congrats: barring a restart (or a 15 minute unplug-replug sesh with 3 more controllers) you are Player 2 forever now. The number of games that don’t account for this is staggering, I’ve seen some singleplayer games that refuse to read anything from any gamepad except the one in the first slot. So this is a non-starter.

My recommended alternative is to assign virtual slot numbers yourself, in order, whenever a gamepad is plugged in. If a gamepad is unplugged it’s slot becomes available to the next gamepad that’s plugged in, so resetting slots is as simple for the user as unplugging everything then replugging it in the desired order. This does mean stuff can get mixed up if something is accidentally unplugged after someone leaves, but I think the gains in flexibility more than make up for this shortcoming.

And that’s that! A layer like this is useful in and of itself when doing stuff like prototyping or simple menus, but if things need to be remapped then we need to move on…

The mapping layer

At this point, things would start to get a little more game-dependent. This part of the input system wouldn’t usually be done as part of the base engine, but the idea can be applied to almost any game so I figured I’d cover it anyway. I’ll be assuming the game is singleplayer to keep things simple, but the idea would be the same in multiplayer games, just copied across multiple profiles.

This layer handles mapping (or ‘binding’) buttons to in-game actions, i.e. defining what will be shown to the player in the in-game input remapping menu. You wouldn’t typically want to allow this for stuff like simple menus (since the player could inadvertently softlock their program) but, in my opinion, any other in-game action should be on the table here. The exact actions and default mappings will, of course, depend on the game.

There’s not much else to say here, this layer basically just exists as a big switchboard. You ask it “what’s the button for jumping?” and it knows it’s the A button, which it can then pass along to the hardware layer to know whether that button is being pressed.

The verb layer

Finally, we’ve reached the end point. Here’s where things get a little interesting. You might have a “jump” button mapped in the previous layer, but sometimes just knowing if the “jump” button was pressed this frame isn’t enough. The main purpose of this layer is to be hardware agnostic (i.e. to check for an action’s corresponding input regardless of what input device the player is using), but it’s also used to implement input buffering, i.e. “storing” inputs for use in the near future. A common example that’s often given as a use-case for this goes like so: in platformers, players often want to jump as soon as they hit the ground, but if they press the jump button slightly before landing then the input will be ‘eaten’ (since you can’t jump in midair), which feels terrible. But if you ‘buffer’ the input by checking (when grounded) not only if the jump button was pressed this frame but at any point in the last 10 frames, then the player character will jump as soon as they hit the ground even if the input came slightly too early. The exact amount of buffer will vary from action to action and game to game (non-action games usually have no need for it at all), but granting this sort of margin of error goes a long way in making a game feel responsive.

So the end goal of this layer is to provide a list of “verbs”3 that can be used to make requests like “was there a [jump] input in the last 10 frames?”. You might have noticed that I already do a little bit of buffering in the abstracted hardware layer in order to check button presses and releases, and while I could handle more long-term buffering at that stage, doing it here (by storing a portion of the data from that layer) is a bit more efficient since I only have to keep track of the inputs the player has mapped to an action, rather than the hundreds of possible buttons that could be mapped.

Each action from the mapping layer usually gets 1-3 verbs (depending if you want to track a button press, release, hold, or some combination of the three). You’d also have verbs for actions that don’t necessarily have a mapping, such as left and right movement when using a gamepad (since that’s usually locked to an analog stick). Again, the point here is to be completely hardware agnostic, the layer will handle identifying what kind of controller the player is using and making the right request to the hardware layer using the correct bindings from mapping layer (or constant values, for actions with no bindings). It stores information for all these verbs every frame in its buffer, and uses this information to answer the aforementioned high-level requests.

Conclusion

Awesome! And with that, we’ve covered every “fundamental” feature a game engine needs to make an absolutely terrible super bare-bones “““game”””! Wow!4 From now on I’ll be talking about some important but less totally foundational engine features; join me next time to hear all about the audio system!

And by hear I mean read, I will not be including audio.

<<Introduction | <Previous post | Next Post>

<<Introduction | <Previous post | Next Post>

Y’know, I’ve always wondered why they’re called that. Wikipedia claims it’s because they “float on top of the background image without overwriting it, much like a ghost or mythological sprite”, but that seems awfully tenuous.

Anyway, what exactly are we talking about? Well, images! This is fairly common knowledge, but ‘sprite’ is the general term for any pre-drawn 2D image you might see in a game. They’re used to depict anything from characters to scenery to UI elements. One important thing to note: self-contained animations (such as a character’s walk cycle) might contain several individual images (i.e. animation frames), but they’re usually considered a single sprite. This makes sense, for reasons we’ll see later.

Now, what exactly goes into a sprite system? The goal when building one can be summarized thusly:

1. Get the drawing from the artist’s desk.

2. Convert it into something that can be rendered to the screen efficiently by the computer.

3. Make a system the programmer can easily use to tell the computer to do so whenever they want.

Get the drawing!

Our precious, precious artists. They are beautiful, innocent, unsullied. They are not to be exposed to anything as filthy as a command line. As such, I must find a way to automatically retrieve their work. Fortunately, we can make this step a part of our build system (see the previous post for details about that).

As mentioned last time, artists will be mostly working with Aseprite files. This is great for them, since they have all sorts of editing tools at their disposal and can work on an entire animation at once, but it presents an issue, since most tools can’t read aseprite files directly. Not to worry though! Thanks to Aseprite’s scripting API I have the ability to automate the export of these files to some pretty precise specifications. Since I need the individual image data of each animation frame for the next step anyway, I’ll export each frame stored in the aseprite file as an individual .png1 file and store it in a temporary folder.

One additional wrinkle: I need the image data, sure, but I also need to keep track of some metadata for each frame; stuff like the name of the sprite, the order of the frame, how long it lasts in the full animation, and a custom origin point. .png files don’t exactly have a predetermined slot for this data, so it’s not obvious where it would go. One option is to give the file a unique ID then create a separate file when exporting that tracks this data and maps it to the file id (which I’ll have to do later anyway), but, given that it’s not actually a lot of data at this point, I can use a neat trick and simplify things by storing that information in the file’s title! Here’s an example of an exported 4-frame animation; the folder name keeps track of the name of the sprite and each file title stores the frame index, duration (in milliseconds), and origin point:

Convert the drawing!

Alright, now that I have the images, I need to be able to render them efficiently in-game! This involves retrieving the image data from the files when the game is running, storing it in a ‘texture’ (essentially a blob of image data that lives in RAM), then rendering that texture to the screen using the GPU. The framework I’m using can do this by loading .png files directly into their own individual textures and using those, but this should be avoided for two reasons:

1. A game can end up having thousands or even tens of thousands of individual animation frames. Loading them all into memory separately while the game is running would involve just as many filesystem calls, which as I’ve mentioned before can be quite bad for performance.

2. This one’s more important, and the reason we can’t use a simple asset packer to get around the first problem: rendering a texture involves the CPU moving it from RAM to the GPU and… hm, I feel I should maybe explain these terms…

Sidebar!

Well dear reader, you’ve done great so far, but it’s unofrtunately time to subject you to another computer science lesson (tragic). If you know what a GPU is you can skip ahead to the next heading, but for everyone else, sorry, but I’ve already locked the doors. Now then, in the second post in this series we talked a bit about the CPU and RAM. As a quick refresher:

• The CPU (Central Processing Unit) is the part of your computer that does most of the “work” by moving bits of data to and from memory and running simple opertions on them.

• RAM (Random Access Memory) is the type of memory in your computer that’s only used while the computer is on. It’s faster to access than permanent storage like your hard drive, and most or all of a program’s information will be stored here while that program is running.

Understanding these is enough to get an idea of what most programs are doing, but once we add certain tasks (like graphics) into the mix, we have to start talking about the GPU! If you’re unaware, that stands for ‘Graphics Processing Unit’ (big surprise). It’s a processing unit just like the CPU in the sense that it receives data from memory, does stuff to that data, then sends it on it’s way. In fact, older PCs didn’t even have any, they weren’t even invented until the late 90s! So what exactly is the difference?

It all comes down to something called parallelism. Take the following computing task:

1. Read number a and number b from memory.

2. Add them together.

3. Take the result and divide it by 2.

4. Save the result to memory as number c.

This task can be described as sequential, that is, each step depends on the result of the previous step. More accurately, you would say it’s impossible to do better than the sequential approach when trying to complete this task. Now let’s take a look at a different example:

1. Read number a, number b, and number c from memory.

2. Add 4 to number a.

3. Subtract 2 from number b.

4. Multiply number c by 0.

5. Save the results to memory in-place.

One thing you might have noticed here: none of the operations on the numbers here really depend on what’s going on with the other numbers, which means this problem is parallelizable, i.e. the steps can be worked on in parallel.

To use a simplified analogy, let’s say your CPU contains 3 little worker elves. If you gave the elves the first task, it doesn’t really help that there are three of them. Even if each elf is assigned it’s own steps, the elf assigned to step 2 would still have to wait around for step 1 to finish, and the elf assigned to step 3 would have to wait for steps 1 and 2 to finish. This means it would take the same amount of time for one elf to do all the work as it would take for 3, 10, or even 100 elves! In fact, more elves might take longer, since they need to pass things around to each other. But when it comes to the second task, more elves helps a lot! Each elf can work on its own number without caring about what the other elves are doing, and things get done 3 times faster than if one elf had to go through all three numbers itself!

So what does this have to do with anything? Well, you can think of the main difference between the CPU and GPU as being their ability to work on things in parallel. For a while, CPUs could only work on tasks sequentially, and this is still their main strength today. The CPU in your typical home computer has about 2-8 elves (or, er, ‘cores’). Now, these are really jacked elves, they eat their protein powder and drink their juice; they can churn through tasks really quickly. But there are only 8 of them. Conversely, GPUs can have thousands of cores. Now, most computing tasks are sequential, the only way you’re getting things done faster is by getting a faster single core. But certain classes of tasks (such as, surprise surprise, graphics) are referred to as ‘embarassingly parallel’, which means more cores → faster performance.

To make this a little more salient, let’s take a typical graphics task: drawing a tinted HD image to the screen. There are 2,073,600 pixels in an image that size (1920x1080). If I were doing things sequentially, I’d have to operate on the color data of each individual pixel one at a time; millions of operations. But none of the pixels care what the other pixels look like. With a GPU, each core can work in parallel to work on thousands of pixels at a time, drastically speeding up the operation. Waow!

Where were we?

Huh? Oh yeah, sprite packing. So, why can’t all my sprite frames stay in their own little .png file? This is because, in order to get the GPU to do anything, the CPU has to send the data relevant to the task to it from RAM, which can often be the slowest part of the process. If each sprite is stored as its own texture in memory, then I’d have to send over a new texture every single time I want to draw a sprite, very slow.

So how does one get around this? Well, textures can get very big; many modern GPUs support textures up to 4096x4096 pixels in size, and almost all support textures up to 2048x2048 pixels. Since most sprites are much smaller than this (especially ones in a retro-style pixel-art game), this means I can “pack” more than one sprite on a single texture! When drawing a sprite frame, I send this whole giant texture, then tell the GPU to only draw the specific part corresponding to that specific frame. This might seem wasteful, and it would be if I was doing this every time I wanted to draw the sprite frame, but organizing things this way allows me to “batch” draw calls. Instead of sending the texture over every time I want to draw a sprite, I instead keep the drawing instructions in reserve. When it’s time to present a finished render to the screen, I send the whole texture over along with all the saved up instructions at once. This means the GPU will happily draw a bunch of sprites all using the same texture!

So how do I get these ‘packed’ textures? It’s technically possible to load a bunch of separate .pngs into one texture when the game starts up, but, as mentioned, it’s better to do this step ahead of time. This means packing all my smaller .pngs into one big .png known as a ‘texture page’2 (a.k.a. texture atlas, sprite atlas, or sprite sheet3). At this stage, since sprites are no longer split up into a bunch of different files, I also produce a separate ‘index’ file for each texture page that keeps track of sprite frame metadata (the stuff we saw earlier, like frame index and duration, as well as where that frame is positioned on the texture page). I can then read the data from this file when drawing to calculate the exact instructions I need to send to the GPU.

Make a system the programmer can easily use to tell the computer to draw sprites whenever they want!

Ok! Ok! We sort of already covered most of this in the previous section, but here are some neat things I included in my sprite system to make using it easier:

1. Part of the build process saves each sprite’s name to a code file in a special way that lets me refer to each sprite directly by name when scripting.

2. The most basic way to draw a sprite is by providing the sprite, as well as a position. I built my system to be able to do this by without the requester needing to deal with any of the texture page stuff.

3. Normally, when drawing a sprite at a given position, it will draw the top-left corner of the sprite there. To make things easier on me and the artists, I added the ability to specify a special “origin” layer in Aseprite, which is tracked by the exporting script. I mentioned this briefly earlier, but basically the ‘origin’ is the point on the sprite that will drawn at the given position. Being able to change this makes it easier to reason about where to draw a sprite (e.g. we usually want every entity’s position in a platformer to be set at their feet. If their sprites were of different heights, we’d have to determine where the top of the sprite would go for each entity in order to draw it. But by setting every entity’s sprite’s origin at that sprite’s feet, we can simply draw the sprite at the entity’s position with no adjustment necessary!). The origin can also be used as the rotation axis when drawing the sprite at an angle.

4. Scaling the sprite means mapping it to a differently sized rectangular area, but it’s often easier to think about multiplying a sprite’s scale. I wrote some code that lets me use that method instead, it also scales relative to the origin, so e.g. an enemy that gets scaled up will still have its feet on the floor.

Nice!

Yup.

Next time I’ll talk about the input system, stay tuned!

<<Introduction | <Previous post | Next Post>

<<Introduction | <Previous post | Next post>

I released a demo video recently showing off a bunch of the engine’s basic features! Here it is in case you missed it:

I… might be a bit further ahead than these posts maybe had you believing. Can’t spend all my time on my blog after all! So, uh, sorry for spoiling the next few posts I guess.

Now that the engine code has a functional core in the entity system and game loop, I can start actually writing code that will, y’know, do stuff.

Like the test app I wrote, setting up a display system involves just a few calls to the framework1. I’ll talk about what goes into a fully-fledged display system more in a later post, but for now I’m just setting up a simple texture I can draw to and clear every frame (sort of like a digital canvas), then scaling that texture to an application window displayed to the user. Once that’s done, I can write code in the main loop or in entity components that draws stuff to that texture, and it’ll show up on screen!

At this point I’m still kind of limited though. The framework provides functionality for drawing ‘primitives’ like lines and triangles, but last I checked it’s not 1962 anymore, it’s at least 19742; time to get some sprites in! To do that, I’ll need to load some kind of image data into memory. I could just use the framework to load individual .png files directly, but once a game starts using a lot of sprites this can get quite slow for several reasons, so I’ll want to pack sprites into larger image files. Also, hm, how am I gonna organize all those files? These are animated sprites, each frame is its own image file! And anyone doing art is probably gonna be using a program like aseprite, are they gonna have to export and sort everything themselves? And where am I gonna put other assets like text files or sounds? Come to think of it, compiling the engine code manually every time from my command line is getting kinda tedious…

Ok, it’s about time to set up a build system.

What’s that?

Build systems come in many shapes and forms, but they can generally be defined as “automated processes that turn a program’s source code and other asset files into a set of files that can be run directly” (for simple programs, you could consider the “build system” as just being the compiler which turns your source code into a single .exe file that anyone can run, but, as we just saw, more complex programs like games tend to have more elaborate requirements). If you pop open your steam directory and open up any game’s install folder, you won’t (often) be able to see a game’s source code or view/edit its assets directly, what you’re seeing instead is the output of that game’s build system.

So what are my goals? Actually, pretty specific. The shortcomings of Game Maker’s build system remain a thorn in my side to this day, creating something that avoids making the same mistakes is a huge reason I’m developing my own engine in the first place. With that in mind, here’s the plan:

• Any part of the game’s files that can be built individually should be. No need to rebuild every sprite when changing a line of code.

• An automated file watching system to ensure that files are rebuilt as soon as a change is detected. This means the build system is always running in the background to ensure the game is ready to be launched as soon as possible. Normally, a build system would only start running the moment the user manually triggered it, forcing them to wait for it to finish before the program actually launched. This helps avoid that3.

• Asset packing, which is basically just squeezing the raw data from multiple asset files into one big file that’s just a blob of ones and zeroes. This speeds up loading times in-game by reducing the amount of file-system requests I need to make, as well as slightly obfuscating the assets to make it harder for inexperienced users digging into the game files to mess with them.

• Support for building .aseprite files. Aseprite is basically the industry standard for pixel art, and is what’s typically used to make the bulk of the art and animations for the sorts of games I’m developing. Unfortunately, like most image editing programs, it’s not standard enough that its project files can be directly read in the same way that .png files can. This usually means that aseprite project files need to be exported to a set of intermediary files in order to actually be legible. But automating this process as part of my build system (as well as exporting additional data such as frame timings) would allow me and other team members to work directly on aseprite files and see the results reflected in-game without any need to manually export things, a huge quality-of-life improvement.

• A quick way to both run the current build and to initiate a new build from scratch. Having e.g. a keyboard shortcut to run the game makes it nice and easy to test changes on a whim. And initiating a build from scratch might take longer than running using any existing built files, but it’s a crucial ability to have given the automated file watching process might introduce errors or fail to keep up in rare cases.

• Ability to ‘hot-reload’ assets at runtime. What this means is that it should be possible to change a non-code asset after the game has been launched and see the changes show up in-game. Now, there’s a limit to how robust this can be without putting in a ton of effort, but even a simple, slightly unstable version of this is incredibly useful as a developer-only tool.

• Speed! The build system should be as fast as possible, wherever possible. This is a huge deal when it comes to iterating on a game, you want to be able to see changes you make reflected in-game as soon as possible. If it takes too long, your attention will wander and maintaining a tight iterative feedback loop in your own head becomes much harder. Say you wanted to tune a character’s walking and running speed to be just right. How much easier would that be if it took half a second for your changes to show up vs. 7 minutes? You might have noticed a lot of the features listed here are designed to cut down on the time a developer spends idly waiting; that’s all in service of the same goal.

Lofty goals! So how do I go about making something like this? It can’t quite be a part of the rest of the source code, that’s what we’re trying to build after all! In theory, I could also make all this using odin, it would just be a smaller, simpler set of programs that would be stored and compiled separately. This might even be one of the more performant options. But to be honest, it’s not exactly what the language was built for. A systems language makes sense when you’re trying to quickly manipulate a large, complex set of data in RAM. But most of the operations involved in a build system will either be requests to the filesystem or to other programs, which means the program instructions themselves won’t make up that large a portion of the overall execution time.

In that case, it makes more sense to look at a some sort of scripting language designed for these sorts of operations. The gain in ergonomics from e.g. not having to constantly recompile small programs (since interpreted scripts can just be run directly without needing to first compile them) or deal with odin’s more finicky text string manipulation seems like it would greatly outweigh the possible performance downsides. A popular language like python or lua could do the trick, but ultimately I decided to write most of my scripts in powershell, microsoft’s scripting language designed specifically for these sorts of tasks. And yeah, even at first glance it’s obvious that powershell makes it very easy to do file operations and to execute command line programs (it’s also probably as optimized as it gets for that sort of stuff… for an interpreted language). There’s definitely some syntax weirdness in other places, but it’s clearly the right tool for the job.4

Still though, the self-contained nature of each script makes it much easier to incorporate other tools into the build system. Jumping ahead a little, I ended up using a small lua script as part of the sprite exporting process to take advantage of aseprite’s scripting API, and the aformentioned asset packer ended up being written as a small odin program, since it involves manipulating a lot of raw data.5

And file watching?

So, tracking changes to files is a problem without an obvious approach. A while back, my thought was that I’d have to keep some kind of ledger that could be quickly checked against every time a build occured to see if anything had changed. Fortunately, after looking into it some more, I found out that there are a number of fleshed out file watching programs that can be customized to suit one’s needs. A file watcher is a program that runs in the background and periodically checks a specified directory for changes, and which can do stuff in response. I’m sure the details of how it does this efficiently are fascinating, but fortunately I won’t have to bother with them!

I decided to go with Watchman, a program developed at Facebook. It seems to be intended more for web stuff, but it’s simple and versatile enough to work well for me. By setting up a series of “triggers” (again, via a powershell script), I can have watchman pass information about individual changed files to my other scripts, to do with what they will.6

Waow!

That’s pretty much how the build system works, at a high level. To summarize, Watchman is initialized the first time the user builds the game, watches for changes in files in a project’s asset folder, and any changed files get processed by scripts and outputted into a dedicated ‘build’ folder. The build in this folder can then be run using a special script, tied to a keyboard shortcut, that makes sure everything’s done building correctly before opening the game’s executable.

For code, rebuilding is about as simple as calling the odin compiler whenever a change is detected in a .odin file7, but other types of assets each have their own special little process. Since each process closely tied to how that type of asset is used in-engine, I’ll talk more about them in detail when I get around to how that asset type is handled. And in fact, next time I’ll get back to the sprites, so look forward to it! But for now, you can check out the build system in action in the demo video linked above!

<<Introduction | <Previous post | Next post>

<<Introduction | <Previous post | Next post>

(Note: not to be confused with the game design term)

Game Programming Patterns has a pretty good chapter on these:

If there is one pattern this book couldn’t live without, this is it. Game loops are the quintessential example of a “game programming pattern”. Almost every game has one, no two are exactly alike, and relatively few programs outside of games use them.

If you have some intermediate coding knowledge you might be better served by that article, but I’ll try to summarize for the rest of you.

If you think of a whole program as a big tree of nested function calls (i.e. a bunch of code which executes more code which executes more code), then this is the root. A game (actually, almost any modern application) doesn’t end until the player asks it to stop. This means it needs to keep running in an endless loop until that happens, continuously waiting for input and reacting to it when that happens. Most games also differ from modern applications in that things keep happening even when the player isn’t touching anything. Enemies keep moving, animations keep animating, physics keep being simulated, etc. This means that, once the game is initialized, you naturally end up with a looping set of instructions like this:

1. Read the player’s input

2. Update the game (physics, player character, enemies, logic, animations, etc.).

3. Draw the updated game state to the screen.

4. If the player didn’t quit, go back to step 1. Otherwise, close the game.

Easy-peasy, right? Well, not quite. If you set up some code to run in an endless loop, it will just run as fast as the CPU will allow it to. This means that, depending on several factors such as the hardware or how intensive the game’s current workload is, the game will run faster or slower, resulting in constant fluctuations in the simulation speed. For example, say I set an enemy to move forward by 0.1 units on every loop. The loop might run 500 times per second on my PC, but only 100 times every second on B-san’s PC. This means the enemy would be moving 50 units per second for me, but only 10 units per second for B-san. Well too slow. Poor B-san. So, how do we fix this? There are multiple options:

Delta Time

Pop open any beginner Unity tutorial and they’ll tell you to make sure you’re multiplying all your speed values by a special value called ‘delta_time’. This is because the Unity’s default ‘Update’ functionality is basically a loop like the one described above; it runs as fast as possible. To account for this, the engine keeps track of the delta_time value, and provides it to you. This is basically the time, in seconds, between when the last loop started and when it ended. By doing things like multiplying speed values by this number, you can have the game simulate things “consistently” even if it’s running at different speeds.

Let’s take a look at our previous example. I set my enemy’s speed; assuming I want it to move 50 units per second I would set the speed value per loop to be 50 multiplied by delta_time. Let’s take a look at how this play’s out on my vs. B-san’s PC:

1. On my PC, the loop runs on average 500 times per second. This means delta_time usually about 0.002 (1/500). This means my enemy will move 0.1 units per loop (50x0.002), which, lo and behold, adds up to 50 over 500 loops.

2. On B-san’s PC, the loop runs 100 times per second, so delta_time is 0.01 (1/100). This means the enemy moves 0.5 units per loop (50x0.01) which, once again, adds up to 50 over 100 loops. Hooray!

Anyway, using this sort of thing for any kind of physics code is idiotic. Sorry, unity tutorials.

Say that, as a completely sane person trying to prove a point, I throw my laptop in the oven. The fans can’t keep up, everything heats up, the CPU starts throttling and everything slows down drastically. My loop now runs only 2 times every second. The enemy starts moving 25 units per loop. Sure, in theory they’re moving the same speed as before, but now they’re snapping around, phasing through walls, the simulation starts breaking, the floors start melting, chaos.

The issue here is that, while this method smoothly can handle fluctuations in hardware speed, it won’t produce perfectly consistent results. This makes it fine (or even preferable, for reasons we’ll see later) for stuff like camera movement, visual effects, animations, etc. since you could, in-principle, throw all that stuff out at any given moment and just (mostly) rederive it from the state of the game world without causing anything but a slight visual hiccup. But for anything that will the game relies upon in subsequent loops (such the position of the player, enemies, timers that affect what state they’re in, etc.) even small variations will propagate and cause significant differences in the overall state of the game. So what’s the alternative?

Fixed Update

In our original example, the game ran at varying speeds, but if you were observing the game from loop iteration to loop iteration without caring about how fast each loop was running then everything would appear consistent (i.e. the enemy would move the same distance over 100 loops on both my and B-san’s PC, it would just take longer in real-time on B-san’s side). If we had a way to ensure each loop took the same amount of time no matter what, this would fix the problem.

Despite the dismal state of it’s (mostly unofficial) introductory material, the Unity engine itself is naturally aware of this situation and provides an alternative ‘FixedUpdate’ functionality specifically for physics code. And Game Maker’s normal ‘Step’ functionality just does this by default (and requires that you do some questionable fiddling to even get it to work in the other way). But how does it work?

Step one involves picking a target game speed, i.e. how many times per second you want the loop to run. You may have noticed that I’ve hesitated to call this game speed the “framerate” so far; many engines will do so simply because the visual framerate is a natural number to use as your game speed1. However, many games use a fixed loop for physics tasks that isn’t tied to the visible framerate (for example, Minecraft servers typically run at a fixed 20 ‘ticks per second’, while the visual framerate can vary significantly). But if you want to keep things simple, 60 “fps” is a natural choice for this, since it lets you update the game then draw the updated result once per loop. It also results in a fixed delta time of about 16.67 milliseconds (1/60*1000).

Now that we have our target framerate and delta time, step two involves inserting a variable delay into the loop. Think of each loop as a block of 16.67 milliseconds that we need to fully occupy, we put all of the game tasks at the start of the loop then fill whatever time is left with a delay period. To do this, check the time at the start of the loop, run all the tasks for that loop, then check the time again. Subtract the time at the start with the latest time to get how long it took to do all the tasks, then subtract that result from the target delta time. This tells you how long you need to delay for. Going back to our original example, doing the tasks might take different amounts of time, about 2ms on my PC vs. 10ms on B-san’s PC, but this is all evened out by the added delay (14.67ms for me vs. 6.67ms for B-san). Hooray!

But… is it real hooray… this time… ??? ?

Lag

The big issue with using the fixed loop method for everything is lag. What happens when the time it takes to run tasks is higher than the target delta time? In cases like these, there’s unfortunately no way around slowing down the game. This feels pretty terrible even if the slowdown is minor, it makes the game unplayable on sufficiently weak hardware, and even on computers that can run the game fine most of the time, it can seriously damage the play experience during particularly performance-intensive periods.

It also means players with better hardware can’t take advantage of it to produce a visually smoother experience. This matters less for retro-style 2D games, but for 3D games or games that use 3D elements like models with interpolated animations or smooth cameras it’s a pretty silly limitation.

As we saw in the delta time section, this is not a limitation shared by the other method. Sure, the game might get choppier under worse circumstances, but it will remain decently playable under far worse conditions. This means that, unsurprisingly, best prescription for combatting the problem of lag and variable hardware speeds is an approach that combines both methods.

And that approach is…

Not something I really care to look into.

Huh???

Yeah, for the (retro-style 2D) games I’m making, a simple fixed loop approach is more than good enough. I might tweak things a little to account for slight differences in monitor framerates, but the overall approach will be the same. Also, while it’s possible that I’ll change my mind about this in the future, part of the point of making my own engine is to gain the ability to develop games where lag isn’t really an issue (on any modern device at least), so mitigation strategies become less essential.

Game loops are difficult to talk about comprehensively. Since they’re at the root of your program, they’re necessary from the beginning, but they’re also constantly changing alongside the rest of things. At a certain point, once the engine is in more of a finished state, I’ll probably make a part 2 detailing exactly what I chose to put in mine, but for now this should cover everything I had to consider starting out.

Well, that’s one thing down when it comes to really stress-testing this engine. Next week I’ll talk about the thing I’ve spent the better part of last month working on: the build system!

<<Introduction | <Previous post | Next post>

It spread, uh, maybe a bit further than I was expecting:

Now that I’ve had some time to mull over the reactions, I thought it might be fun to revisit them after presenting a more complete thesis.

It’s not unexpected that a lot of people’s default assumption was that I was trying to identify some kind of subgenre. Truthfully though, I didn’t have anything so definite in mind. In the replies to the original tweet, I included a list of characteristics which I picked out as the set of combined elements which I thought tied these games together in my mind:

• Exploration-focused.

• Very "free", open-ended traversal.

• Very hands-off tutorialization.

• Major content locked behind secret, optional, and often difficult puzzles.

• "Layered" secrets, "endings" that aren't really endings.

• Rich lore is present or heavily implied.

• Game knowledge is a major part of progression, veteran players can breeze through off knowledge alone.

• Minimal focus on action gameplay; action challenges, if any, can often be circumvented with tools/knowledge gained from exploration.

• Often features small puzzle-solving elements separate from wider exploration.

• Players often describe their experience with these games as deeply meaningful and/or mind-blowing.

I was pretty much just trying to draw a circle around games which share all of these characteristics; even at the time, “subgenre” didn’t really feel like an appropriate label for the category.

So, what was I even searching for? We’ll get to the snappy label in a second, but if I now had to summarize the core thing that these sorts of games have in common it would be this:

Each game involves the player mastering a bespoke, predictable, and systemic environment as a whole, primarily through the open-ended and unguided gathering of knowledge.

As promised, let’s test this thesis by responding to some of the replies to the original tweet. I’m sure everyone’s put just as much thought into this important question.

Thanks guys.

On a meta note, while writing that tweet I do recall heeding a raspy, goblin-like voice saying “phrase it like thisss, it will bring more engagement!” so I suppose I set myself up for this. And the tweet probably did spread a lot further than it would have if I had instead made a rambling thread full of caveats and clarifications. Which is probably… good? Yeah. Probably.

I feel this is a kneejerk reaction to certain people trying to make these kinds of categories more authoritative than they have any right to be, and I understand wanting to push back against that. But I hope I made it clear that there is something worth pointing to here, and not all efforts of this kind are pointless navel-gazing. As I touched on in a reply to grayfruit, I don’t think that we would be seeing the same level of experimentation, iteration, and ultimately results we see with metroidvanias if “metroidvania” wasn’t a coherent category with a lot of shared understanding around it. Without a cultural touchstone like this, quickly communicating what your game is trying to do (to collaborators, investors, audience, etc.) just becomes harder at every level (often we’re forced to rely on examples of existing games, and tough luck if they’re not really well known).

Having enough of a shared language that those unfamiliar can use to get an initial grip on things is valuable. As a younger medium, I think games have a lot of design space left to explore compared to stuff like literature or film, and I think a willingness to map things out will help us find foundational conventions, wisdom about what truly works, faster.

(and many more along these lines)

I’m not sure how many of these people actually took time to look at the list of similarities, but they do have a bit of a point: on the surface, the games presented play very differently. This is most of the reason why I don’t think the categorization is quite a “subgenre”. The core idea can evidently be applied to many different gameplay styles, though it does seem to mesh best with puzzle games (in the ‘bite-sized puzzle’ sense).

It does feel to me like other people are able to pick up on the shared heart of these games, given reactions like this:

And people managing to point out other examples that nail it:

But a wise man (who sleeps on my couch) once said you find what’s interesting about things by seeing how they differ from other things, rather than pointing out similarities. In that spirit, I did try to point out some games that I think fall just shy of this category and why:

• Inscryption: Too linear, not enough 'free' exploration, too strategy focused.

• Cave Story: Too linear, not enough exploration focus, progression is not so heavily based on game knowledge, too action-focused.

• Paradise Killer: "Puzzle solving" is too straightforward, mostly a collect-a-thon.

• Return of the Obra Dinn: Does not feature hidden "layers" of content, the method of exploration and discovery does not break much from expectations set at the start of the game.

• Baba is You: Not particularly lore rich.

• Stephen's Sausage Roll: Outright "hidden" content is minimal.

• Undertale: Main game is too linear, "open" exploration elements are minimal.

• The Stanley Parable: No real puzzle-solving to speak of.

Some other games people brought up also felt similar but ultimately separate to me, I’ll take the opportunity to go in-depth as to why:

Dark Souls titles, while featuring quite a surprising number of traits from the original list, are fairly easy to exclude simply due to their segmentation and linearity. The world as a whole is never turned into a puzzle for you to solve.

Elden Ring was admittedly harder to exclude; it does have a well-executed open-ended exploration aspect, and quite a pile of secrets and knowledge to collect. In its case, I think it’s simply a matter of where the focus lies. Progression in Elden Ring is not solely or even primarily based around knowledge, i.e. investigation, cracking the world’s puzzle, etc. RPG-style character building and the development of your action-based combat skills play a much larger role; this is ultimately what sets it apart from the original set of examples.

Well said gorillastats. Disco Elysium… it’s feels close. But despite all the freedom the player is handed, it’s all concentrated in how the moment-to-moment gameplay unfolds. In most playthroughs, all the same scenes will occur, even if their exact contents and order might be shuffled around (and give-or-take some optional questlines). And you’re never really alone in your journey to unravel the game’s mysteries, thanks to the more-or-less friendly NPCs you’re always talking to, as well as… the player character?

Yeah, that’s the other glaring thing, you’re not quite the one doing any puzzle solving, you’re roleplaying as a character that does so. There is no real systemic overarching environment to be analyzed and conquered, but rather a (skilfully woven) web of fiction the player gradually traces to its inevitable conclusion. That’s what sets Disco Elysium (and many other “adventure” games) apart.

Er, nowhere did I claim that games in this category are inherently better or worse than others, there are plenty of games on the “not” list that I like more than some out of the 7 original examples I gave.

Regardless, I wanted to bring up Obra Dinn since I think what distinguishes it is telling. It does seem to check a lot of boxes, so why doesn’t it fit? I think my response to the previous reply hints at what’s going on here. While Obra Dinn has something of an overarching system, deciphering it is not where the game’s challenge lies. All the important rules are freely presented to you fairly early on, and you are left with a very clear set of goals to accomplish. Heck, the game even hands you a comprehensive list of blank fields to be filled in as you go.

This is in contrast to the original example games, who are unguided; you’re always expected to fathom yourself not just the world and its history, but the very rules of the game you’re playing. Each discovery in this realm drastically shifts your perspective and recontextualizes your entire playthrough thus far, and the games are usually structured such that you come to these realizations at an interesting pace. These realizations, discoveries, perspective-shifts, one might even call them… epiphanies…

So, even I felt Rain World was a bit of an outlier in the original list, and now I think I can put my finger on why. It’s closer than any of the other examples of “almost” games I’ve presented thus far (obviously, since it managed to sneak onto the original list lol), but there’s one clear difference I can point to now between it and the other games. Rather than being entirely bespoke and predictable, its system is partially generative and non-deterministic.

Let’s use an example: in Outer Wilds, the developers (and eventually the player) can have complete knowledge of the solar system’s workings. Barring glitches and player interference, every celestial body will be in a known position at a any given time, every machine in the game will work the same way every time it’s used, and events and changes can be predicted with perfect accuracy. This means that any knowledge of the system that the player obtains is immediately and clearly applicable and reliable.

Conversely, in Rain World, a large and critical part of the game’s overarching “system” is its dynamic ecosystem. Animals all have their own AI will behave unpredictably in response to the player, the environment, and other animals. The ecosystem also exists and progresses independent of the player, which means the world and its inhabitants might undergo significant change while you’re not looking. While there are still rules to discover, significantly more experimentation might be necessary to do so, the knowledge earned is harder to apply reliably, and few things ever become truly 100% predictable.

Is this difference enough to disqualify rain world? Maybe not, I don’t think it’s necessarily satisfying a completely different internal drive, and it does feel very similar to the other examples. Still, there is a clear difference, and I think it might be worth further distinguishing these sorts of “emergent sim-y” takes on the core idea for those who can stomach the nuance.

Alright, let’s see if anyone’s come up with a good, snappy tag for this sort of thing.

I don’t really think sticking them under a broad umbrella like this is really helpful. For example, there are plenty of titles I and others would happily deem “adventure games” that clearly don’t fall in or even close to the category. Similarly broad labels don’t fare much better in this regard.

I had some, ah, choice words for this one:

Not much more to say, though to expand on the first comment, the reason I think an overreliance on genre terms based on existing titles is corrosive (doubly so for genre terms like this which are based on existing genre terms of the sort) is that it tends to obfuscate what we actually care about in those titles and makes it unnecessarily harder to communicate with those who might be less familiar with those titles. Some mentioned the term “tunicwild”, the same criticism applies to that.

Now we’re talking. I think all these monikers do a good job pointing at the specific thing that makes these games interesting. But as we saw in the Obra Dinn counterexample, “layers” is not quite at the core of this feeling. Can we do better?

I’m pleasantly surprised people kept recommending that video, since it seems to frame ‘KBUs’ as just a mechanic that some games have, rather than any sort of genre tag. It’s definitely on the right track in that regard, and, as we saw, knowledge-based progression is crucial to the category definition. Even the Hypnospace designer seems to agree. Unfortunately, this term seems too narrow, and it’s pointing to a mechanic that many games have, not just the ones we’re trying to delineate.

Consciously or not though, it seems Jay might have independently hit upon what we’re looking for in his reply…

This feeling. These might not be the only sorts of games that can provide it, but I can’t think of any type of game that provides a stronger or purer form of it than this one. If one lacks time to get into the nuance, I think ‘epiphany-driven’ is great shorthand.

Good job, team!

So… was there anything else? Well, some people took my original 7 examples as being comprehensive, which is pretty laughable. Therefore, I’d be remiss not to offer some game recs! Let’s see what the public has to say:

Yes, yes, ok! I can’t believe I forgot Tunic when I was making the original image. It might be a good bit more action-focused than the other titles, but it definitely fits the bill.

Regarding Fez, it’s been a while since I last played it so I wasn’t sure how closely it fit. Still, I wouldn’t expect anyone who likes this sort of stuff to have a bad time with it, so go check it out!

Seconded. Solid recommendation. It’s similar to Baba is You in that it checks pretty much all the boxes but doesn’t quite have much in the way of lore for you to uncover. That aspect of things adds quite significantly to the feel and character of an epiphany-driven game, but at this point I won’t go quite so far as to call it absolutely essential.

Neither of these games quite land in the epiphany-driven bucket imo, but it’s interesting that Subnautica came up in my discussion of the topic with friends. If you want a not-quite-epiphany-driven game that leans more in a survival-sandbox direction, it might be the one for you.

Also, here are all the games that look interesting from the trailers but which I haven’t otherwise played or heard much about.

That’s all, but if you have recommendations of your own, comment below!

Subscribe now

<<Introduction | <Previous post | Next post>

At this point, I’ve got all my tools set up; you might expect me to start talking about drawing stuff to the screen, or collecting the player’s input. But I already made my test app! I know I can do all that! I wanted to kick off the real engine project by building one of the many systems that would’ve been too much work for a test app, and what better place to start than the engine’s beating heart: the Entity system!

Do I know what this is?

Maybe. If you’ve ever used an engine like Unity or Unreal before, you’ll be familiar with ‘Entities’ (a.k.a. ‘GameObjects’ or ‘Actors’) in this sense. It’s an extremely common design pattern that many game engines use to organize and represent almost everything in the game world. My own system takes inspiration from those, while mixing in some ideas from Game Maker. I’ll tell you exactly how it works later, but before we talk about the “how”…

Why do this?

Let’s talk a bit about software architecture. There are a great many ways to think about it, but in this case it’s helpful to imagine it as a frame, a scaffold. What I’m doing here is building a core part of the thing that will make it easy to gradually construct a game by adding and tweaking parts while keeping the overall program smooth and performant.

Philosophies when it comes to this stuff are almost as numerous as the arguments surrounding them. To give you an idea of what I mean, here are a few ‘programming paradigms’ that one can follow:

• Imperative and Declarative Programming: These are sort of ur-paradigms, and most other paradigms will fall under either umbrella:

  • Imperative programming centers around the idea of telling the computer what to do, usually as a list of instructions, which, as we saw in the previous post, is pretty close to how things work under the hood. C is the classic example of an imperative language.

  • Declarative programming is a bit stranger; the idea is that you’re describing, very precisely, your program’s problem domain, in the same way that one would “declare” that 1+1=2. Instead of incanting “do this, then this, then that!”, you incant “given this, it is so!”. “Running” your program is then just a matter of solving the equation with the given parameters. This is closer to pure mathematics than engineering, and this style tends to be a significantly less popular, but some declarative ideas have been enormously influential, even for imperative work. Lisp is the classic example of a declarative language.

• Object-Oriented Programming (OOP): An incredibly popular imperative style. Due to how, er, storied its history is, it’s a bit difficult to nail down exactly how people use this term nowadays, but the basic idea is that your code is divided up into ‘objects’. Each object has data, as well as ‘methods’ (little bits of code that can be called to tell the object to do something). There’s a lot of neat stuff you can do with objects, but OOP has been criticized for encouraging programmers to come up with complicated object structures when a simple list of instructions would do fine. Java, C#, C++, Python, and many more popular languages are considered Object-Oriented.

• Functional Programming: A style of declarative programming that has seen some (relative) success. The style is based around functions, specifically ‘pure’ functions. A function is just a bit of code that takes an input and produces an output, but the idea of a ‘pure’ function is that it doesn’t ‘remember’ anything, it can’t read or write to any memory outside of itself. This guarantees that the function will always produce the same output if given the same input, and that it won’t silently affect any part of my program without my knowledge. A purely functional style constructs a whole program entirely out of pure functions, a very declarative way of doing things, but pure functions can still be very valuable as part of an imperative program and many ideas from Functional programming have spread all over the place. Haskell is probably the most well-known functional language.

• Data-Oriented Programming (a.k.a. Data-Oriented Design, DOD): An imperative philosophy that has gained popularity recently in response to perceived failures of the OOP style. The Data-Oriented philosophy encourages programmers to think more about hardware and memory (see the previous post for more details about this), and to envision their programs as machines purpose-built for funneling and processing large amounts of data in an efficient manner. Jai and ODIN are very much being built under this paradigm. To give a concrete example of DOD, say I’m making my little game with bouncy balls and whatnot:

  • If I were doing things OOP-style, I might conjure up a “ball” object, give it all the data and behaviors a ball would need, then stick a new one wherever whenever I needed it. When I want all the balls to do something, I’d define that behavior on the object, then go looking for each of them and tell them “do this thing you know how to do”.

  • If I were thinking of things from a DOD perspective, I’d say: “I’m gonna need about 100 bouncy balls!”. I’d figure out the exact way to lay out all the data about 100 balls would need, and bundle it in a way that makes it easy for me and the CPU to access. When I wanted the balls to do something, I’d make a big ol’ “process_balls” function that would churn through all that data and make it behave like about 100 bouncy balls.

Personally, I always try to do what makes sense for the task at hand, and my Entity system is designed to offer me the flexibility to do so. As the core around which most game features will be built, this is, uh, a pretty important thing for it to have.

And now, the how

To understand the reasoning behind the design of my engine’s Entity system, let’s take a look at how it’s design compares to the way I’d typically do things in Game Maker, with the help of some familiar faces from ANTONBLAST!

GM tends to push the user into an OOP way of doing things. You create “Objects”, and each has events that get triggered when something happens (my own system uses something very similar in this regard, so we’ll talk about it later). You’re also encouraged to use a very OOP technique for code reuse: Inheritance.

How a paradigm handles code reuse is core to its identity, one might even say its in a sense what defines a paradigm. Having to repeat yourself is time-consuming and tedious, so programmers are always finding ways to avoid it.

A classic example is functions themselves. I described them as bits of code that take an input and produce an output, but their real power is that you can ‘call’ them from anywhere, over and over, with just one line of code per call. If I have a complicated bit of behavior that I need to use often, I can put it into a function, then just call that function. If it takes no input, its practically as if I just copy-pasted that bit of code all over the place (but I can change every instance of it just by changing the function!). If it does take input, even better! I can make the function do something slightly different whenever I use it just by changing its input.

So, inheritance, what is it? Basically, it’s a way for objects to share functionality amongst themselves by “inheriting” it from a parent object. Confused? Let’s take the example of our three buddies1:

• Pippo is a simple enemy that walks around. The player can bounce on him to knock him over, and can also hit him to send him flying.

• Ballbuster is a more dangerous enemy that also walks around. When he sees the player, he’ll charge at him. Like Pippo, he’ll go flying when the player hits him.

• Mosquito doesn’t do much, just floats in place, but the player can also hit him and bounce off of him.

You’ll notice that these are all enemies, and they all have behaviors in common. Instead of rewriting those common behaviors three times, I can put all the methods and data needed for them into a parent “Enemy” object, and have objects for each of the three enemies that inherit from it (any behavior specific to an individual enemy gets put in that individual enemy’s object).

But wait! Pippo and Ballbuster walk around, while the mosquito just floats in place! Where do I put the walking behavior? Well, inheritance trees can go more than one layer deep, so we can do something like this:

And now, say I want as version of Pippo that’s mostly identical, but who sheds feathers when he gets hit? Instead of copying Pippo somewhere, I can just keep extending things!

As you can see, objects and inheritance trees can be pretty powerful, and a natural way of modeling game mechanics like enemies, but as a project’s size and complexity starts to grow, they can run into some problems. Take this guy, for example:

He’s a big totem guy that the player can stand on top of. He spits stuff. Nice guy. Now, question for you, is this guy a block, or an enemy? Stuff will collide with him, just like a block, but he also attacks the player, and can be stunned, just like an enemy. You can’t inherit from multiple parents (for complicated technical reasons), so you kind of have to pick one.

Usually, in cases like these, I have to pick the most relevant parent, and cobble together the other behavior as best I can. The other option is to rethink the inheritance tree structure, but rearranging the tree can be time-consuming and annoying, and will often cause problems for other objects.

Here are some other issues that crop up with inheritance:

• Say I have 10 objects. A handful of them want behavior A, a slightly different handful want behavior B, and another handful also want behavior C. Even if I’m aware of all this ahead of time, which I’m likely not, there isn’t an obvious way to make an inheritance tree that sorts the behaviors in a neat way. Making a parent with all three behaviors is doable, but would require shutting off certain behaviors in many of the children, which is annoying to do and keep track of, especially if it has to be done after-the-fact.

• If a bunch of objects all want behaviors A, B, and C, but a few only want behaviors A and B, well, tough luck, they’re also getting C. I can turn it off, but this often still introduces complexity and performance overhead to objects for behaviors they aren’t even using.

• Methods on parents can be inherited or ‘overriden’ by child objects, which involves the child either replacing or adding on to what a method does. This is an important and useful feature, but it introduces performance overhead related to having to retrieve all these parent and child methods while the game is running.

• Once inheritance trees start to reach a certain depth they get… annoying. Did I put that behavior in this object or that one? Should this new thing be a child of this or should I put it further down? I need to do all these things in order on this object but skip step 3 on this other object, do I split steps 1 and 2 into their own method? Oops, it’s now 3 months later and I don’t remember which part of the sequence is in which method, fun…

Ok, so… what, then? This design pattern, built directly into almost every major modern language as a first class feature, used by most software out there, present in nearly every tutorial, is it just dumb and bad?

Uh, yeah, kinda.

I’m not the only one who thinks this, a lot of engineers have been distancing themselves from the excesses of OOP over the past decade and more, despite its ubiquity. But what’s the alternative? Personally, I’m not quite ready to jump fully off the OOP train, but if I’m gonna be avoiding inheritance for the most part, how am I gonna handle code reuse? This is where a compositional approach comes in.

Go on then

Let’s take a look, finally, at how my Entity system works:

• Everything in the world is represented by an Entity. An Entity can represent anything: the player, a tree, an enemy, the sky, etc.

• On their own, Entities do nothing, are nothing. Their existence is defined by the set of Components attached to them.

• Components are little bundles of data that can be combined together modularly to form an entity. Components can be many different things. They might be, for example:

  • A set of coordinates that tells you where an Entity is in the world.

  • A set of physics parameters, like gravity and friction, which can be used to move an Entity around.

  • A set of rendering parameters, used to render an animated sprite.

• So, to give a complete example, say I wanted to make an Entity that represented a gremlin enemy. I’d attach a position and movement Component, so that I can move it around; a collider Component, so that it can collide with things; a hitbox Component, so that it can hit things with attacks; and I’d make a special new “gremlin” Component that would be used for anything specific to the gremlin.

• In addition to all that, Components can react to a standardized set of Events, just like Game Maker objects. The most common Events would be `init`, which is triggered just for a specific Component when it is newly added to an Entity, and `update`, which is triggered once per frame2. Put simply, I can define behavior for each specific component that will trigger in response to these events.

For the most part, this preserves a lot of what I like about Game Maker’s system while getting around the pitfalls of inheritance. Rather than bundling behaviors into parents, behaviors can be modularized into their own component and freely included or excluded depending on what a specific Entity needs. Take the totem guy from earlier: instead of agonizing over whether he should be an enemy or a block, I can just slap a bounce component and a block collision component on him and call it a day!3

The way the component system is designed under the hood also has performance benefits. Rather than going to each entity, scattered around in memory willy-nilly, and tracking down their methods, every component of a given type is kept in one block which the engine processes all at once. Since components are usually pretty small, processing them all in one chunk like this can be extremely quick. “Entities”, under the hood, are actually just like little address books that components sometimes use to get related components from a different chunk. Neat!

Hmm… still doesn’t seem very DOD

Well… yeah. If you were paying attention to the bouncy ball example, I’ll admit this isn’t quite that. I’m making a bit of a compromise… but hear me out. A lot of my work days look like me:

1. Getting a design for a new enemy, or block, or level mechanism.

2. Spinning up a new object that inherits from the relevant parent.

3. Writing up any new behaviors that object might need.

4. Revising and polishing that specific object.

And I haven’t quite found a way to map that workflow, in my head, to something that doesn’t end up looking at least a little bit OOP. The Entity system, combined with a dash of code generation and some (perfectly kosher) syntactic tricks, allows me to quickly spin up work environments that feel just like what I’m used to, but better.

But, and here’s the beauty of making my own engine, I don’t have to use the entity system for everything. If a new mechanic or system seems like it would benefit from a less OOP-like approach, there’s nothing stopping me from taking it in that case. So… we’ll see. Maybe, at the end of a long project with this engine, I’ll find that I hardly needed any Entities at all. But for now, I’d like to have some familiar ground.

Anything else?

Not really, though I’d be remiss to mention one last thing. You might have heard of “Entity Component System” architectures, or ECS. Despite the name, my thing is… not that. Rather than being Event-driven like mine, entities in an ECS system use things called “Systems” (brilliant nomenclature, I know), which are these things which identify entities which have certain sets of components on them and run code on them. It’s not a bad idea, but it’s never struck me as quite how I want things done.

At the moment, the Entity system is mostly done, but without other systems it’s like a heart with no legs. Or arms. Or pulse.

…

There are a few big things I need to get done before I really stress test it, the first of which we’ll be seeing next week: The Game Loop.

See you then!

<<Introduction | <Previous post | Next post>

<<Introduction | Next Post>

So, I know I’ve made a big deal out of starting from scratch, but nobody actually does that ever for anything1. In my case, there’s a whole bundle of tools I’ll be relying on third-party software for, but to even get started, I’ll need to decide on two things:

• A programming language

• A game development framework

What is a programming language, anyway?

You can’t just ask me that! Dear reader, to truly answer such a question I would be forced to do you a terrible harm! That is, give you a computer science lesson! No, that wouldn’t do, it simply wouldn’t. But… ah, needs must. Here’s what we’ll do: I’ll give you a unique, very special computer science lesson. It will be so special by being incredibly, magnificently brief! I guarantee, you will learn very little. It’s not ideal, I know, but it will surely be a mercy compared to the alternative. Now then…

What is a programming language? Put simply, it’s a set of logically consistent rules for writing text2, called a program, which can be turned into instructions that your computer can understand.

You might have heard that, fundamentally, your computer only deals in 1s and 0s, but how can it ever read text then? Well, inside pretty much any computer is a device called a Central Processing Unit. In (grossly oversimplified) essence, a CPU is a little machine that takes in and puts out numbers using electrical signals. Each is built with a big set of little tasks3 they can do, called instructions, and each instruction has its own little number to represent it. A program is basically a long list of those little numbers that the CPU reads in order. It’s even possible to write out that list of instructions directly using something called an assembly language, but this incredibly tedious and difficult, even for relatively simple programs.

With that in mind, programming languages can be grouped broadly into 2 buckets:

• Compiled languages: The more straightforward approach. Compiled languages use a program called a compiler, which knows the rules of the language, to read the text you wrote and turn it into a list of instructions for your CPU. You can then run the “compiled” program on its own, whenever you want.

• Interpreted languages: Instead of turning your text into little numbers ahead of time, interpreted languages use a program called an interpreter, which runs alongside your program, and reads the text to figure out what instructions to give the CPU as your program is running. Interpreted languages tend to be more flexible, since, unlike a compiler, an interpreter doesn’t need to know what to tell the CPU way ahead of time and can figure things out on the fly. Unfortunately though, this means programs written in interpreted languages are significantly slower, since figuring things out on the fly takes time.

Coming back to my own project: my interest in developing my own engine took serious shape about year ago, when I started more closely following the development of Jai (Jonathan Blow’s new programming language that he’s been working on since 2014). Its philosophy and design goals were fascinating. It seeks, in essence, to be a replacement for C++, the current standard for any low-level game development.

Many popular languages nowadays, like Python and Javascript, are interpreted4. This makes them easier to use in many ways than compiled languages like C++, but for tasks like serious game development, where performance is extremely important, the slowness of an interpreted language is unacceptable. In addition to that, many interpreted (and even compiled languages), in pursuit of ease-of-use, tend to obfuscate how your program actually interacts with computer hardware (specifically, for the most part, how your program manages memory). They’re designed to handle that sort of thing automatically in the background while you deal purely with the abstract logic (i.e. they are ‘high-level’, compared to low-level languages which are closer to the hardware). This does make things easier, but usually results in programs and programmers that don’t understand what is going on under the hood, which is quite bad for performance.

C++ is one of the only popular languages that still puts control of the hardware in the hands of the programmer. The language it’s based on, C, is also like this, but C lacks many of the features of C++ that make it feasible to write very large, complex programs. Even then, the way C++ handles that complexity is, in hindsight, less than ideal, and makes programs unduly hard to maintain and reason about.

Learning about Jai and the philosophy behind it exposed me to the true gravity of these problems, problems which it is aiming to fix as a C++ replacement. It was also very exciting, the language itself seemed incredibly fun to use compared to the much older and more bloated C++5, which made the task of serious game engine development under said philosophy seem a lot more manageable.

Unfortunately, Jai is still unavailable to the general public, which left me experimenting with alternatives. But before I talk about that ordeal…

The innovative, portable elephant in the room

As I write this, my Nintendo Switch devkit sits demandingly and NDA-protectedly on the corner of my desk…

The biggest, most glaring condition I set for myself as part of developing this engine was that it needed to be able to run on consoles (in addition to Windows, Mac, and Linux devices) without much additional work. This meant finding a game development framework that supported the major console platforms. What is a game development framework? You can- totally ask me that question, it’s not that complicated. Such a framework is basically a collection of existing code (a ‘library’) that you can include as part of your program that handles common tasks such as drawing to the screen, collecting input, playing audio, etc. It also abstracts that functionality across platforms, which means code written using that framework will work across any platform it supports. For example, say I want to draw a rectangle on the screen:

• If I was handling this stuff myself, I would have to write different code that draws a rectangle for every single platform I wanted to support, taking into account all sorts of things that differ like how the CPU is built, the graphics interface, requests to the operating system, etc. Obviously, this is extremely time-consuming and complicated and requires an obscene amount of technical knowledge.

• Alternatively, I can simply tell a framework “Draw me a rectangle!”6 and the framework will handle all the complicated stuff for me, changing how it does things under the hood depending on the platform I’m targeting. Not only does this save me the effort of actually writing the code that draws the damn rectangle, it means I only have to worry about the platform when it really matters.

As you can see, frameworks are an essential tool, and even amongst indie studios which write their own engines it’s very, very rare to see someone not using one. So, finding the right framework was a must. And while finding one that supported console development was my main goal, I also had a number of other things in mind when looking:

• It should be in line with the philosophy outlined in the previous section, i.e. it should be written in a low-level language and able to be used with a low-level language.

• It should be primarily designed for 2D game development. Often, frameworks created for 3D development (or both 3D and 2D development) tend to come with a lot of unnecessary bloat from the perspective of someone like me, who works only in 2D.

• It should strike a nice balance between having enough features and still being relatively simple and easy to learn.

• It should be primarily designed for PC and console development, as opposed to mobile development.

• It should have a track record of quality, commercial indie games being made with it. This is the best proof that a framework is powerful enough to suit the needs of a commercial game developer like me.

So how did it go?

Annoyingly.

To my surprise and dismay, pretty much the only framework that advertised itself as having full support for all consoles (aside from those used by full-on engines) was Monogame. At first, this didn’t seem like the worst thing in the world. It fit most of my criteria and even came with a number of useful tools. And hey, if it was good enough for Terraria and Celeste, surely it would be good enough for me? But Monogame was built on Microsoft’s old XNA framework, which means it’s written almost exclusively in and expects you to use C#, Microsoft’s special little language.

C# is… in a weird middle ground. It uses Just-In-Time Compilation, which means rather than being compiled ahead of time, a program called a runtime, which is sort of like an interpreter, compiles your program as it’s running. Sorta. Look, the details aren’t important; this basically just means that C# is faster than an interpreted language, but more flexible than a compiled language. But, y’know, you could also rephrase that as it being less flexible than an interpreted language and slower than a compiled language. Especially because C# hates the idea of giving you control of memory… but I was blissfully unaware of the full extent of this hatred at the time, and so, with a notepad of full of low-level memory tricks I wanted to try out, I decided to jump in and give Monogame a shot.

Cut to one month later, and I was at my limit. See, C# technically gives you the ability to do low-level memory control, but holy sh— it’s like pulling teeth!! Half the language features aren’t built for it, you have to ask pretty please every time you do it, and whenever I wanted to ask a question about it every forum answer (and half the official documentation… and ChatGPT…) basically just told me “you’re crazy, don’t do it”! They literally call it “unsafe code”! And of course, the runtime is so full of implicit background behavior when it comes to this stuff that there’s never any easy way of knowing if things are working as intended or if you screwed up and wiped out all the performance benefits you were aiming for. The simplest tasks, stretched out into days of infuriating research and fiddling around! What foolery! What nonsense!

Uh… memory…?

Ah. Crap, another computer science lesson. Alright, let’s get through this quick, I believe in you.

You might be familiar with the idea that your computer has memory, i.e. places where it stores information (as little numbers) when the CPU isn’t using it for its little tasks. But did you know that your computer has different kinds of memory? In essence, different memory components on your computer trade-off between how much data they can store, and how quickly the CPU can access them. So a component might be able to store a lot of data, but take a really long time to access; or it might only store a little bit of data, but be really fast to access. Here’s an overview of the different memory components in a typical PC:

• Hard Drive (or ‘the disk’): This is basically “cold storage” for your data. Hard drives are huge, with hundreds of Gigabytes or even Terabytes of storage space7, and they store data even if the computer is powered off, but they’re really slow to read from. When a game is “loading”, it’s usually because it has to move a bunch of data from the hard drive to RAM. Speaking of…

• RAM (Random Access Memory): This is basically where all the programs running on your computer store themselves and any data they’re currently using, after being loaded in from the hard drive. It’s called that because you can access any part of it just as quickly as any other part, instead of having to wait for a literal spinning disk to move to the right position. RAM is pretty big, usually capable of storing several gigabytes on modern PCs. It’s also much faster to read from than a hard drive, but not as fast as…

• CPU cache: Your CPU comes with a number of little memory components called ‘caches’, each one smaller and faster than the last. The smallest ones are usually on the order of a few kilobytes. Whenever a program tries to send a piece of data from RAM to the CPU, it (and some surrounding data8) gets copied to a CPU cache. The next time your program tries to read data from RAM, the CPU will check if it’s in a cache first. If it is, great! It can just read it from there instead (this is called a ‘cache hit’, and if the CPU can’t find the data in a cache, it’s a ‘cache miss’). This is useful because getting data from a cache can be hundreds of times faster than getting it from RAM.

• CPU registers: This is where the CPU puts data it’s directly working on. They’re tiny, usually just a few bytes. If your CPU is in the middle of, for example, adding two numbers together, each of them is gonna take up one register.

So, bringing it back to the earlier discussion, how do different programming languages interact with this stuff? Generally, anything that has to do with memory is considered fairly low-level, so many languages do their best to make it so you don’t have to think about it. In C#’s case, it employs a common strategy called ‘garbage-collection’:

• Say I want to store a bunch of numbers for later use: in a garbage-collected language, I just need to say “store those numbers somewhere!”, that’s it. Another special program that runs alongside mine, called the ‘garbage collector’ (GC), will hand me a reference I can use to get my numbers back later, and I can go about my merry way. The GC will automatically handle putting and shifting those numbers around in RAM, and cleaning them up when my program doesn’t need them anymore (it does this by continuously checking if the reference it gave me is still in use).

• In a ‘manual memory-management’ language like C, I would be in control of memory, but also responsible for it. So for my bunch of numbers, I’d have to explicitly ask the operating system for somewhere (in RAM) to put them, make sure there’s enough space for them, keep track of exactly where they are, move them somewhere else if e.g. I suddenly need to add more numbers than I have space for, and free up the memory as soon as I no longer needed it.

Wow, manual memory management sounds like a pain! Why bother? Well, as mentioned, it all comes down to performance. Running a GC introduces overhead, but worse than that is that in a GC’d language you have no clue how your program is actually laid out in memory. This makes it basically impossible to optimize your program for the cache, since the main way of doing that is to very carefully arrange your data sequentially in RAM, to minimize cache misses. This is a big deal, even simple programs can, in practice, run dozens to hundreds of times faster if properly optimized for the cache. This makes low-level memory control a must-have if you’re serious about performance. But as much as C#’s design insists otherwise, it doesn’t have to be a nightmare…

Alternatives

I can actually remember the specific line of code that shattered my faith in C#9… it was time to try something else. After all, in many ways, C# was diametrically opposed to Jai. It’s a decades-old language designed by committee with a huge emphasis on automatic memory management. Frankly, it’s a bit crazy that I got as far with it as I did. Perfect, guaranteed console support was just not worth having to use it, so I loosened my criteria: if I could get a test app running on my Switch devkit, that would be good enough for now. With my expectations properly humbled, I decided to look closer to “home”.

It was through my research at this point that I realized that we’re truly living in a bit of a renaissance period for C-like languages. Jon Blow wasn’t the only person who saw the need for a new C successor; over the past decade or so, several projects have sprung up trying to be more pleasant alternatives to C/C++ for systems programmers. Go, Rust, Zig, V, and many more have been slowly carving out their own niches. But for my purposes, one language stood out to me: ODIN.

Created by Bill “gingerBill” Hall, ODIN is a C-like language whose design philosophy is squarely in the same camp as Jai’s, and it shows in both the syntax and language features. It was created primarily to help with the creation of the VFX software that Bill works on, and seems to have been a huge success in that regard10. It’s also considered to be incredibly well suited for low-level game development, in-part thanks to its out-of-the-box support for many existing C-based game dev libraries. Most notably: Simple Directmedia Layer 2.

SDL2 is an incredibly popular game development framework with an extremely impressive track record. While I was already aware of it from my previous research and some dabbling years prior, I had glossed over it since it didn’t seem to advertise having out-of-the-box support for consoles. But color me surprised! Upon closer investigation of an old readme document hosted at the back of their website, I uncovered the existence of official Switch and Xbox ports of the framework!11

(Now is probably a good time to mention: getting one’s hands on these sorts of things is a bit of a pain. Console manufacturers are extremely secretive about the inner workings of their machines, so ports like these can’t be hosted freely alongside the normal framework. They can only be made available to licensed developers, on pain of a visit from the ninjas. Fortunately, I have all the right credentials, so getting access to the Switch port of SDL2 was just a matter of a few twitter DMs.)

Hope!

The temptation was too strong, I had to try it! I set up Odin on my PC and hooked up my new project with the SDL2 port. This was it! The moment of truth! Would I be able to get a test app written in Odin using SDL2 working on my devkit?

…

Yes, of course, or else we wouldn’t be here. Did you not read the introduction post?

Still, it was quite the endeavor. I learned a lot about setting up compilers. After a weekend of desperate trial and error I actually leapt out of my chair and cheered once I got my devkit to display an empty red screen. I can’t talk too much about it unfortunately, or else the ninjas will be at my door, but let’s just say that Odin working seamlessly with any existing C code was a big deal.

Great success!

Indeed. I’ve been working on the engine for the past couple of weeks now and ODIN has been delightful to use and learn about, a huge improvement over C#. I feel like almost every day I’m picking up new and better ways of doing things. I didn’t really touch on Object-Oriented vs Data-Oriented programming in this post, but I might cover it later on; my opinions on the matter are seeing quite the rapid evolution thanks to this language.

My plan right now is to hit some basic milestones in terms of engine features, build a small prototype game using those features, and make sure everything still works on Switch. An Xbox port of SDL2 exists… I think… but that will have to wait until I get access to a devkit. As for Playstation, that console will probably be the hardest to support; it uses a platform-specific graphics API, which in simple terms means that a lot of work specific to that platform has to be put in to get a framework working on it. Likely because of this, SDL2 sadly doesn’t seem to have a Playstation port. So… Switch now, Xbox later, and Playstation, uh… maybe never? We’ll see.

Next post, we’ll finally get into actual engine design, so look forward to it! See you then!

<<Introduction | Next Post>

It chafes!!!

Constant tiny annoyances! Endless compile times! Crappy tools that get utterly crushed by literally any specialized alternative! An IDE so laggy I don’t even use it anymore1! Pathetic performance un-helped by a pitiful profiler! Literally as I am writing this github desktop is chugging away trying to revert a mountain of files that got messed up after an update.

It’s still the engine I know and love, but on a project this size every flaw is exacerbated, and every annoyance gives strength to the voice. What voice, you ask? The voice of my pride, as an engineer! The voice telling me that I won’t be a true sage until I roll my own CPU out of sand and grit. The voice that won’t be chained to the prescribed toolset of a company, no matter how nice their head of product is2! The voice that wants to know what’s going on in memory! But most importantly, it’s the voice that belongs to Jon Blow wants me to grow, take on the challenges that yesterday’s me couldn’t!

And so, what is left to do when my tools no longer fit my hands but to roll up my sleeves and make ones that do? I have about half a year until the end of my current project and the start of something new. Will I, in that time, manage to make something production-ready, or will I be forced back into Game Maker’s abrasive embrace? Only I can decide, that’s the Handmade spirit! Or something.

What are you doing exactly?

Let’s take a step back. Earlier, I drew an analogy between Game Maker and software like Photoshop, but what does that mean? Essentially, “Game Engines” like GM and similar software (Unity, Godot, etc.) are collections of tools for making games, like a level editor and asset browser, built around central software framework that makes it easy to write only that code which your specific game needs (by providing certain code abstractions, seamlessly interfacing with aforementioned tools, and handling low-level tasks like drawing to the screen or getting user input). My goal is to replicate that entire stack of tools with a combination of specialized third-party software and code libraries alongside a mountain of my own custom code.

Isn’t that, like, really hard?

When I was starting out as a game dev, I was pretty adamant about avoiding engine development. I would hear (horror?) stories of developers spending 6+ years endlessly working on the same project, just building and rebuilding their stack. I was an artist, and I wanted to make games dammit, not waste my youth fiddling with some backend. And this attitude was and still is reinforced by the community at large, on both sides of the aisle: engine development is something engineers do for its own sake, not something worth attempting if your main goal was to produce an artful end product in a timely manner.

But after 8 years, from my current perspective, a project like this seems extremely doable, even on this timeframe! And for all the reasons listed above and more, there’s plenty of benefits to doing this beyond just my self-satisfaction as a software engineer3. Plus, that’s not just a crazy inside view opinion, there are a bunch of examples of experienced developers producing great works without the help of a third-party engine (Braid and FTL come to mind, both are games which were made mostly from scratch in 1-2 years).

So what explains the discrepancy? Well, I’ve got a lot of things going for me:

• I have years of experience pushing an existing engine to its limits, trying to make as comfortable as possible to work with. This has given me a very, very clear vision of what I’m trying to make for myself.

• I’ll be working almost entirely in 2D, which is a huge load off. True 3D development is an entirely different beast which I very much do not have the confidence or interest in tackling.

• As mentioned, I have a very precise idea of what kind of games I’ll be making with the engine, but will nonetheless not be making a full commercial game with it from the start. Certainly some test prototypes, but they will be quickly discarded. This will let me focus on the engine itself until it’s in a fairly stable state without the aimlessness that typically comes with such an approach.

• I’ll be using existing libraries and tools like SDL and LDtk as much as possible to handle difficult problems that would take too long to solve myself. I’ll talk more about what this means exactly in later posts.

• It’s 2024. The amount of support and tools available to developers nowadays is enormous compared to even 10 years ago. As a research tool, ChatGPT alone has been a tremendous help in my work on this so far (though not without its fair share of frustrations).

I would still not recommend this approach to anyone starting out in game dev and, in fact, I still think Game Maker is a great tool for beginners, even those setting out to make a commercial product. But for those with enough experience, something like this is certainly not as daunting as some make it out to be, and can be a great way to improve yourself, your working environment, and your ultimate product. At least, I think. Maybe I’ll change my tune in 6 months.

Why blog about this? Who is this for?

Engine development is a complicated winding path that will require a lot of careful design decisions. I feel like sorting out my thoughts on things to the point that I can explain them to a layman will be a useful exercise. As the title suggests, this series is intended to be legible for non-programmers, though it should hopefully also be of interest to programmers of any experience level. Basically, it’s my hope that anyone interested in this part of the game development process, even just as a consumer, will come away with something valuable after reading this series.

Also, I’ll be figuring things out as I go, and I think that’s the best state to be in when writing something like this. Often, those who’ve walked far along the path can find it difficult to relay that knowledge back to those just starting out, as so much of it has been compressed into intuitions and shorthand. As someone who’s just slightly ahead of those starting out, there’s no better time to wave back at them and point out where next to walk.

And who knows, maybe I’ll get a bit of fame and status out of this. For what other reason does anyone do anything?

Where are you at now?

As of a few days ago, I managed to compile and run a test app I made, using the ODIN language and SDL, on the Nintendo Switch (it’s got a moving character and everything, wow!). This gives me the confidence I need to move forward with these tools, and I’ve got a big ol’ todo list that I’m ready to start churning through (there’s a couple dozen list items and each one will probably get its own post… yay…). In my next post, I’ll talk about how I ended up choosing the ODIN language, so look forward to that!

Next Post>

Back in 2019 I put out a video essay analyzing System Erasure's previous game, ZeroRanger, mostly as a way of seeing if making video essays about games might be fun enough to spend time on1. I really enjoyed that game, but I distinctly remember that after beating it for the first time that I felt a bit disappointed in the scarcity of the narrative content relative to its high quality. SE seems to have acausally taken that unspoken disappointment as a challenge because their excellent new Sokoban puzzler Void Stranger is a bottomless fucking rabbit hole of lore, plot, and secret endings2. But rather than spoil people on that for no good reason, I fell into one of my classic game design fugue states and wrote something more in the vein of my old ZeroRanger vid, boiling down what I think are the most innovative aspects of Void Stranger's design. And I will proceed to talk about that after this very important message:

WARNING: This essay contains MAJOR gameplay spoilers for Void Stranger (as well as very minor spoilers for some other popular puzzle games). The game is best experienced blind. No seriously, the discord has like 5 levels of spoiler channel so people can get help without spoiling themselves. If you haven't played the game go play it (it's 10/10, highly recommend), if you don't want to then watch the release trailer and reconsider. If you still don't want to, then try playing ZeroRanger and realizing how good SE is at making games that appeal to people outside of that game's genre niche. This will surely convince you and you will not make the foolish mistake of continuing to scroll out of laziness.

The traditional formula

To understand the interesting thing I want to point out in Void Stranger's design, it's useful to look at how a typical hardcore puzzle game is laid out. The most basic recipe is to have the game split up into isolated puzzles accessible from a bare-bones level select, with sets of harder puzzles being unlocked by beating easier ones.

More interesting games such as Baba is You or The Witness tend to play with the "level select" side of things by including more obscure puzzles outside the context of the normal levels as well as an exploration element (among other things). But one thing remains almost constant across all games in this genre: The puzzle is sacrosanct. You will, with very few exceptions, always be given the exact same tools and starting conditions every time you start up the same puzzle. To expand on this point:

• There is no way to earn new abilities (outside of new knowledge) that can be applied to previous puzzles.

• Puzzles generally have (roughly) one intended solution.

• You can undo mistakes freely.

• Because of all this, you aren't really expected to solve the same puzzle more than once.

And this makes sense:

• Granting you new abilities that make puzzle solving easier is, in a sense, just removing the actual puzzle and replacing it with an easier one.

• Admittedly the "one intended solution" is less of a hard rule, but slide too far in the other direction and you've basically just made a strategy game.

• The challenge of solving a puzzle isn't in the execution, solving a puzzle more than once is just a tedious exercise in memorization. On a similar note, not giving the player the freedom to undo and reset at their leisure usually just introduces unnecessary friction rather than any real challenge.

But Void Stranger's great innovation is that it, amazingly, breaks all of these rules and gets away with it through some very clever design decisions. Let's take a look at its structure and see how it differs.

First impressions

To recap, here's how the game appears to be structured at first glance:

• Your character starts on the floor of a dungeon and must make progress by reaching the stairs located somewhere else on the same floor (the entire floor is always visible and stairs are helpfully highlighted should anything be obscuring them). Reaching the stairs puts them on the next floor down. There is no other way to traverse floors; you cannot travel backwards.

• Reaching the stairs often necessitates solving a (difficult!) puzzle that involves moving floor tiles around, manipulating predictable enemies, and pushing blocks and statues. Stuff in the level only moves when you do.

• Many floors contain optional objectives. Obtaining these is usually significantly harder than simply just reaching the stairs. Oftentimes one of the optional objectives is a chest that grants you a locust idol when opened.

• Falling into an empty floor space or running into an enemy kills you, consuming a locust idol and resetting the puzzle to its initial state. There's no way to undo actions, so it's sometimes necessary to kill yourself if the puzzle has been put into an unsolvable state. Presumably, something will happen if you die without any locust idols (This is just one of the many unexplained mysteries the game presents you with as you climb downwards).

• Some floors contain NPCs, murals, or memories that will expand on the game's plot and lore, as well as hint at secret content.

• It's worth noting that virtually no mechanics are outright explained and the player is left to figure out pretty much everything by themselves, though as we’ll see in a moment important stuff tends to be strongly hinted at.

  

So the game seems, at the moment, like a curious mix of a dungeon crawler and the more traditional puzzler structure seen above. Certainly a lot of quality of life features are missing in service of the strange life system and forced linear progression, but overall puzzles still function like the sealed off systems we discussed.

Now, speaking of the life system: if you die without any locusts (which will happen to most players, this game is tough) you'll be given the option to continue right where you left off or give up. The game does not indicate at this point what the downside to this is3, so I imagine most players choose to continue on rather than risk losing progress. Continuing on afflicts you with the VOIDED status, allowing you to die freely without losing any new locust idols you pick up. Funnily enough, this status brings the game closer to the traditional style by allowing unlimited resets, but it also serves as the trigger for the first part of the game's interesting structural subversions.

Before I get to that though I'll mention briefly one of the more unique NPC interactions found about halfway through the dungeon. Your progress is blocked off by a large head, who (incapable of moving) demonstrates a secret way to use the smirking statues you've been seeing throughout your climb: By falling down in front of one, all your locust idols will be consumed and you'll be skipped ahead an equal number of floors. This is your first glimpse at how movement between floors isn’t as rigid as it might seem4.

Second loop

Once you've managed to traverse the entire dungeon, about 200 floors, one of two things will happen depending on whether you have the VOIDED status or not. If you've been absurdly careful and managed to not void out you're rewarded with the game's first real ending. But the much more likely outcome is that you've voided out and will therefore be presented with a hauntingly beautiful vocal musical number, the game's "bad" ending. You’re then forced to use the hidden functionality of a four-eyed statue (also found throughout the dungeon), which clears your VOIDED status but resets you back to the top of the dungeon.

At first, this set up seems pretty rough, and if the game was simply asking you to solve the same couple-hundred puzzles again (but without making mistakes this time) it would be a pretty egregious design flaw. But right before resetting you're given a pretty blatant hint on how to use one of the game's main hidden systems. Roughly 20 floors down is a "brand" room. Arranging the tiles here in the fairly obvious 6x6 pattern being shoved in your face unlocks a hidden room that grants you the "Memory" item, allowing you to speak to rocks (who drop gameplay hints and lore). From this point on, the second half of Void Stranger's gameplay starts to unfold: an ARG exploration element that recontextualizes the entire game. If you've been taking notes on the murals found throughout the dungeon you'll notice that each one is shortly preceded by a brand room with the exact right set up to draw the brand depicted by that mural5.

As you proceed through your second run, new NPC interactions and information obtainable from rocks scatter bits of novelty throughout the old floors. More interestingly though, you'll pick up two items from the secret brand rooms that make progress much faster: wings to fly over gaps and a sword that can kill enemies (which you get from one of the game's sick-ass Sokoban boss fights). Once-brutal puzzles become trivial, which brilliantly weaves that exhilarating feeling you get from using cheat codes for the first time right into normal gameplay. You tear your way through to the bottom of the dungeon once more. If you've voided again (Sokoban boss fights ain't easy!) you'll be reset, but keep your items. On your third run, thanks to some new interactions on the first few floors, you'll learn how to collect much more locusts, as well as how to use those locusts to discover shortcuts. A knowledgeable player with the right items can go straight to the bottom of the dungeon in minutes, a task that might’ve originally taken them hours. Thanks to this fascinating knowledge-based pseudo-roguelite6 progression, reaching the bottom without voiding just gets easier and easier.

Hardmode(s)

Once you've obtained the Void Stranger's first good ending, you'll be put through two additional gameplay modes. The first is a return to the game's initial structure, with harder versions of every level, colloquially known as "Hardmode". While you can technically obtain the items again in this run, the game initially nudges you in the direction of not doing this by removing them from their original locations. This is a purer puzzle-solving mode, with some of the hardest puzzles in the game, but it won't matter if you void out. Plus, a determined player can get around solving them if they really feel the need to.

Once you've beaten Hardmode, you're sent into a third mode that's much more focused on the secret-hunting exploration side of the game. Levels are back to their original, easy configuration, and every item is unlocked from the start, but reaching the ending is no longer a simple matter of getting to the bottom. You'll have to use all your secret tricks to jump around the dungeon and probe around until you find what you need, training you to observe carefully and follow up on the mysteries left unsolved. The gameplay this reminds me the most of is Outer Wilds, but I feel Void Stranger's more rigid structure and ability to mix things up with long strings of hardcore puzzles7 lends it more engaging and varied pacing.

Once you've completed all three main modes you aren't left with any obvious direction to go in. But, like with any great puzzle-exploration game, combining all your skills and investigating those secrets that have been right under your nose from the start eventually brings you to the game's "final" ending... which I see no need to spoil here!

...

Ok, I can't help myself, post-game spoiler warning, decode with ROT13: Vg vf *nofbyhgryl vafnar* gung arneyl 100% orngvat guvf *40-ubhe pelcgvp Fbxbona* tnzr haybpxf na *ragver frpbaq tnzr* va n *pbzcyrgryl qvssrerag traer*. Gur snpg gung guvf jnf abg rira uvagrq ng naljurer va nal znexrgvat zngrevny fubjf gehr qribgvba gb gur Neg naq V pbzzraq Flfgrz Renfher sbe vg.

Wrap up

Now that we've covered both the traditional structure of hardcore puzzlers and how Void Stranger diverges from it, let's review those traditional rules and how the game avoids the problems that might arise from breaking them:

• No new abilities and only solving puzzles once: By getting the player to loop through puzzles multiple times, Void Stranger can maintain the purity of the puzzle solving on the first run while shifting the player's focus to exploration and secret finding on any further run. Because of this shifted focus, the game is free recontextualize the puzzle with new abilities, even if it ruins the difficulty, because the challenge no longer lies in the puzzle itself.

• Freedom to undo: On later runs that are trying to avoid voiding, limited resets add a welcome sense of challenge to puzzles that have technically already been solved. But thanks to the safety net that voiding provides, Void Stranger is still able to provide this freedom to undo when it’s trying to present a purer form of puzzle solving.

• Open-ended puzzles: While most puzzles still have roughly one intended solution, optional objectives and the slightly open-ended nature of some puzzles (especially once you have items) blends well with the lives system and adds a unique element of resource management and risk-reward not typically found in the genre. Notably, a certain common optional collectable only appears when you aren’t voided, preserving that risk element and often providing novel challenge on later runs.

And there you have it. Eero Lahtinen and Antti Ukkola have further proven to be game dev geniuses and I hope this game makes them gobs of money so they can fly to a convention somewhere where I can congratulate them in person for once again Saving Indie Games. Oh, and if you two are reading this and want to get this game onto the switch, DM me on twitter or discord or something.

Crafted vs. Emergent

Often when talking about game narrative people like to bring up "emergent narrative". These are stories that were not specifically foreseen by a game's designers, but arise organically through the interaction of the player and the game's rules. Examples include stuff like:

• Getting a crazy strong build in a roguelike game but running into a boss that hard counters it and snatches away your victory at the last moment.

• A chess master making a critical blunder against a longstanding rival.

• Losing a unit you've grown attached to in a strategy game with permadeath.

• Playing a violent action game as a pacifist and imagining in-game characters' reactions.

While designers can craft their game to encourage such moments, they're never the kind of thing where the exact situation has been planned out, the way it is in most books and movies. It's very much one of the unique strengths of the medium. And it's really cool! Plenty of my favorite games do very little narratively besides emergent stuff.

But.

What I really want to distinguish in people's minds in this essay are crafted narratives whose interactive element is fundamental to them, stories that simply would not function without it. I mean "crafted" in this case as more or less the opposite of emergent, narrative elements that have been meticulously planned out, where the designer does know pretty much exactly what every player is going to be experiencing. Many of you can probably think of a few examples of what I'm talking about but to really drive the point home I've developed a simple chart that should make what I'm talking about clearer...

The chart

There's two axes to go over here:

• Pure Game vs. Pure Narrative: Examples that are higher up on the chart will be what you would intuitively consider more "game-like" rather than "story-like"; they will have fewer narrative elements and what narrative elements they do have will lean more towards emergent narrative rather than crafted. Conversely, examples at the very bottom will have little-to-no interactivity whatsoever.

• Non-interactive vs. Interactive story: If an example is further to the right of the chart, that means its interactivity is more fundamental to telling its story. This is really about asking the question "How much would the story suffer if you stripped out all the interactivity? Would it still make sense or be interesting?". Important to note: this does not refer to a story's linearity or non-linearity. For example: The Beginner's Guide would not make sense without its interactive elements, and as such would be placed on the far right of the chart, yet it still features an extremely linear narrative with a single ending and very few optional branches along the way. On the other hand, many Choose Your Own Adventure novels feature several different endings, but only limited interactivity which does not add much to the story, and would therefore be placed close to the left side of the chart.

Here's the chart divided into rough sections, examples to come:

Note that the chart, categories, and following examples here are not rigid or exhaustive. It's not "everything in this genre goes here and nothing else", it's "the typical work in this genre would probably be placed around here in my opinion". With that disclaimer out of the way, I'll explain my thinking for each category (though this is all really an exercise in pointing out the right side of the chart, so if you just want to see that you can skip to the bottom of this list):

• Games With Basically No Story/Games With A Small Amount Of Linear Story That Is Not Strongly Tied To The Gameplay (Top left):

  

  Mostly self explanatory, this is what is traditionally thought of as a pure "game", e.g. chess, minesweeper, most sports, etc. Further down in these areas would be games with a minimal story that mostly serves as a backdrop to the gameplay. Tohou is an interesting example here, since it has such a rich lore that has spawned countless fanworks set in its universe. Take most games in the series in isolation though and you'll get a fairly simple plot told through only brief (yet charming) character interactions. So... top left. All told though I'd argue it's these exact properties, in combination with the developers' permissive attitude towards copyright, that makes the franchise so easy to remix and reinterpret.

• Strategy Games (Mid Right-Top Right):

  

  This is another category of games with minimal narrative elements. The distinction here though is that the stories these games tell usually end up completely nonsensical when divorced from the game. On the left side you can still extract a simple yet meaningful narrative (two armies engage in tactical warfare until one claims victory, Mario adventures through many obstacles to defeat bowser and rescue the princess). A mostly complete, somewhat interesting story is told whether or not Magnus Carlsen is leading one of the armies or stomping on koopas. But on the right side, aside from maybe the premise, the stories are pretty nonsensical on their own. Medieval india fails miserably to conquer the world using war elephants? Virus MEGABUTTS wipes out humanity? These "stories" may be kinda funny, or at least a starting point for an actual narrative, but their full impact is only present when you're the one authoring them through the game, or at least watching someone else do so. I called this category strategy games, but I think a lot of management/simulation/sandbox games fit around here as well.

• ???/Ghost Train Rides (Center Left):

  

  Ghost Train Ride is a term for linear cinematic adventure games coined by Yahtzee Croshaw. For the purposes of this chart we'll just say these are games with a fairly significant narrative element, but whose interactivity is relatively shallow and ineffectual when it comes to adding things to its story. It’s unsurprising that a few of these games have seen recent semi-successful attempts at film or TV adaptations. But these games' interactivity still arguably adds *something* to their stories, even if it's just a slightly enhanced sense of immersion. The ??? category is reserved for games whose interactivity, in theory, adds literally nothing to the story. Games like this might exist, but to be honest the idea sounds so difficult to pull off while being so unappealing that I didn't really want to spend time thinking of examples.

• CRPGs/JRPGs (Upper Middle/Middle):

  

  The middle of the chart is probably one of the looser zones, and the labels' vertical placement come mostly from the fact that JRPGs tend to have more predetermined storylines and characters, while western RPGs put more emphasis on open-endedness and building your own character1. RPGs end up further right on the chart since pretty much at the genre's core is the idea that the game mechanics are all representative of some kind narrative element. They don't make it all the way to the right though, since a lot of the time their stories can somewhat survive being separated from a gameplay context (just look at cutscene compilations on youtube).

• Not Videogames (Bottom Left):

  

  This part of the chart is reserved for traditional media with little-to-no interactive elements, such as books, movies, etc. I thought it would be funny to put sesame street a bit further on the right since shows like that technically do sometimes expect the viewer to interact with its prompts.

• Visual Novels (Bottom Middle):

  

  Further to the right at the bottom we have visual novels. These are works of fiction that have basically no elements we'd consider game-like aside from dialogue choices and saving and loading, but who will often speak directly to the reader (or a reader stand-in) and incorporate their nature as a choice-driven branching storyline into the text itself. I'd say examples that do this to a greater extent would be further right in this zone, and examples that are simply a more traditional story that branches would be further left.

• Point-And-Click Adventures:

  

  Right above visual novels we have point-and-click adventures, and I think many games even in this category get lumped in with VNs due to their text-heavy narrative focused approach. I think the key differentiator here, and why these games can stretch so far to the right of the chart while still hovering above the very bottom, is that the gameplay elements are very often centered around forcing the player to truly understand the very deliberately crafted plot, setting, and characters. Progress both as a player of the game and as a reader of the story is, at many points, one and the same. With all that said, some may find Ace Attorney's placement here a bit unusual, what with all its non-game direct adaptations. Personally though I've always found these adaptations to be hollow, limited imitations of the source material, which just serves to reinforce my impression that AA's story and those like it were really made from the ground up to be experienced through interaction.

• (Good) Walking Simulators (Bottom Right):

  

  i.e. games made by Davey Wreden. When thinking of this corner of the chart it's difficult to point out anything else. These are works that are almost wholly lacking in what one would consider traditional game-like elements and yet are so entirely constructed around their interactivity that removing it would be incoherent. I think it's natural that even the works themselves wrestle in-text with being categorized as a game or not, what that even means. That is in large part the failure of our existing categories that I want try and rectify with this essay, partly in the hopes that it'll help people talk about and create more works like these and those in the next category.

Last up, we have the (center right) area that I really want to talk about, not covered in the bullet list above, that this chart has hopefully helped you to distinguish:

The title "Indie Zone" is a little tongue-in-cheek but it does hold a kernel of truth. I think, because this category of work is so unclear in people's minds, works that try to capitalize on what make it special have a hard time selling themselves and their strengths. They therefore only end up being made by those willing to take a gamble or experiment. No wonder many are lauded as innovative; creative revolutions within the medium.

Anyway, I think it should be clear what I'm trying to point out at this point: these are works that incorporate many elements of a traditional game, yet most or all of those elements directly serve the telling of a specific story (or the conveyance of some deliberate narrative thing, from grand themes to small jokes). Well, an important general point here is that this isn't a one-way street, the narrative will also take influence from the "pure" game design and what it's best at conveying. This powerful synthesis of crafted narrative and interactivity has produced some of my favorite art, and yet I rarely see it discussed on its own (outside of people analyzing a specific game that does it well).

As a short aside, I think it's worth distinguishing the upper part of "The Indie Zone" a bit. I think games here are still trying to convey something deliberate, but go about it in a more open-ended or subtle way. I put The Witness here cause it's a great example of this, basically a plot-less open world of meticulously crafted environments all loudly yet oh-so-obtusely screaming the same specific message on the nature of epiphany.

Here’s the full chart with zones + every example:

On Meta

I’ve got one last big point I'd like to make. You may have noticed that a lot of the works on the right side of the chart have many narrative elements people describe as "meta". I don't think this is a coincidence, and I could write a whole essay about this (and probably will at some point), but I'll summarize a little here.

Meta elements often get a bad rap due to often being used as a cheap way to inject comedy, shock value, or "depth" into a story that hasn't been built around them. I think in non-interactive mediums there's only so far you can take meta, and despite the examples you can pull of its artful use it remains merely a useful tool. But interactive mediums are different, and I'd argue that the fact of the reader/player interacting with the story makes it meta by default. Read about the creation of a lot of these narratives and you'll see the creators incorporating meta elements because it's just what makes sense. The player is not a passive observer, and thus in a fleshed out self-consistent story it takes more effort to separate them as a participant than it does to weave their influence and internal experience in as a natural part of the story. Sure, this can be done poorly, but I'd argue that this is more akin to the fact that not every game with jumping and platforms is as good as your favorite Mario game, despite technically sharing the same core gameplay.

Conclusion

To wrap things up I just want to reiterate, this was meant to serve as a crystallization of my thoughts around a lot of my favorite games. I feel I now have a better model of the kind of art I want to make and see more of, and hopefully you do too! As always when it comes to someone presenting a four squares chart that can supposedly plot every example of some complex multidimensional thing, it's important to mention that this isn't meant to exhaustively describe every aspect of a story, and works can differ significantly along plenty of other dimensions. Plus, this is just a toy model based primarily on my intuitions rather than hard data, it's definitely open to refinement! If you have disagreements on aspects of it or even just on the placement of a specific game I'd love to hear your opinions in the comments or on twitter/discord!

Subscribe now

Share

Heyo, it’s me, lovable lead programmer on ANTONBLAST Massimo Gauthier, here to talk about how I implemented the layer jumping mechanic! By following this simple guide, you too can become authentically inspired by 90s and 2000s era 2D platformers and their weird pseudo-3D gimmicks!

This system went through a few iterations throughout development (before I realized VB Wario Land was doing it better than me and just kinda copied how they did it). I'll just be focusing on how the final implementation works, so careful about making any inferences about how easy something like this is to build from scratch.

If you’re having trouble reading the code at any point, I’d recommend pasting into an empty script in Game Maker just to get the syntax highlighting. Substack seems to unfortunately not be great when it comes to code blocks.

Design Constraints

Starting out, here are the requirements and constraints for the layer system (laid out during the design stage or while experimenting with earlier iterations):

• The game will only ever have 2 layers, a background and a foreground layer

• A parallax effect is in place. We decided on a horizontal ratio of 0.5, meaning the camera will move about half as much on the background layer for any movement on the foreground layer. I'll expand a bit more on this later.

• Anton can jump between layers by interacting with springs. Doing so will cause him to jump to a corresponding background/foreground position based on his position and the parallax adjustment.

• Layer jumps always take the same amount of time.

• Anton will virtually always land on the ground after layer jumping (there are a few acceptable exceptions, such as if no ground is available to land on).

• The player has a small amount of horizontal control over a layer jump.

• Anton will always appear to travel in a small vertical arc during a jump.

Parallax

Probably the most annoying thing to figure out and adjust for with layer jumping and basically everything else having to do with the layer system was the parallax. To summarize briefly, the true position (when it comes to collision and interaction) of things on the background layer does not correspond to their rendered position, as that has to be adjusted in order to create a parallax effect. Here's a Game Maker blog post explaining parallax in more detail. Normally this would not be such a big deal, but when you have stuff moving between layers that becomes an issue, as an object's true position according to the collision system can suddenly not correspond to where it's "supposed" to be according to what's actually being shown to the player. Usually this manifested as the object (Anton) snapping or warping around in strange ways after a layer jump.

To fix this, you have to take a position on one layer and convert it to a position on the other. Initially we were doing this in all sorts of places but I eventually consolidated things to a single function:

function parallax_adjust(_position, _backToForeground=false){
    if(_backToForeground){
        var _camPosAtPosition = (_position - VIEW_WIDTH/2)/PARALLAX_RATIO;
        return round(_position + clamp(_camPosAtPosition, 0, room_width - VIEW_WIDTH)*PARALLAX_RATIO);
    }
    else{
        return round(_position - clamp(_position - VIEW_WIDTH/2, 0, room_width - VIEW_WIDTH)*PARALLAX_RATIO);
    }
}

Let's break things down. This function takes an x position from one layer and converts to the equivalent x position on the other. You can specify with the second parameter whether you are converting from background to foreground or vice-versa. This might seem a little abstract, so I will now employ VISUAL LEARNING to help you conceptualize what is being done here. First, consider this example level layout (foreground elements are red and background elements are orange):

Here's what things look like for the player when Anton (technically, the camera following Anton) is fully on the left side of the stage:

No parallax is applied at this point, so the background's true and rendered positions are the same:

Now here’s what happens when Anton moves to the center of the stage. The background needs to move only half as slow as the camera. To achieve this effect, the background's rendered position (shown here in transparent grey) is set to be equal to its true position + the camera's current x position multiplied by the parallax ratio (0.5 in our case) (the camera's x position is the leftmost side of the black rectangle):

Here's what the player sees:

So, back to the conversion function. Basically what we're doing is running the rendering offset in reverse to get back the true position of whatever position we point at in the rendered background. Going step by step:

• Foreground to background:

  • Take where the camera's position would be at the provided foreground position (_position). This is just _position minus half the camera's width (saved in the macro VIEW_WIDTH), with some clamping applied since the camera cannot move past the left or right edge of the room.

  • Multiply this camera position by the PARALLAX_RATIO (also a macro in this case). This gives you the background's rendering offset.

  • Subtract this rendering offset from _position to get the true background position.

• Background to foreground:

  • Pretty much the same steps as above, but a little more complicated since the camera's position here relative to _position is dependent on the parallax effect. To account for this, simply divide the camera position by PARALLAX_RATIO before clamping it.

  • You also need to add the rendering offset to _position here instead of subtracting it to get the desired foreground position.

A Special Trick

Now that we've got a way of adjusting for parallax it's finally time to tackle the jump itself. Though you might be asking yourself at this point: "The parallax adjustment can only handle positions two layers! Isn't a jump supposed to smoothly move between them? How are you interpolating between the start and end positions?" This is in fact what I was trying to do at first. But then I discovered VB Wario Land's special trick. See if you can spot it in this gif where the player's collision mask is visible:

That's right, no physics interpolation is happening at all! As soon as the player initiates a jump, valid grounded position is identified and they are teleported there right away! The actual jumping Anton is just a rendered "ghost" that slowly approaches the true position. This has a number of useful advantages:

• You can determine a valid grounded position before the jump even starts by doing the following:

  • Identify an initial target position using spring's center position adjusted using the parallax adjustment seen previously, as well as a y position slightly higher than the spring's (both of these "target" values can be overridden by the level designer if they want the spring to send you somewhere that isn't quite the exact position that corresponds to the spring's position).

  • If said target position would put the player inside terrain, move them up until they are just above it.

  • If said target position would put the player in midair, move them down until they are on top of terrain, with an exception if no terrain exists below.

• Since you know the player will start in a valid position, you can give the player limited movement control using the existing speed and collision systems without worrying about them getting stuck in a wall or something. Because the ghost Anton is approaching the true position anyway, it takes minimal additional effort to allow this movement while still making it so both the ghost and true positions sync up at the end of a jump.

• This allows you to know the relative heights of the player's initial and final position, which is invaluable for pre-calculating variables for a jump arc of fixed duration and height for the ghost Anton to follow.

The Jump Arc

The last big step before getting into the nitty gritty details is how to do the jump arc. As we all know, acceleration and deceleration can be modeled using the following kinematic equations:

d = distance
t = time
a = acceleration (or gravity)
f = final velocity
v = initial velocity

f = v + a*t
d = ((f + v)/2)*t
d = v*t + 0.5*a*t^2
f^2 = v^2 + 2*a*d

Each half of the jump arc can be modeled by one of these equations. Here's what we know:

• The final velocity of the first half and initial velocity of the second half, they're both 0 (i.e. the apex of the jump).

• The highest point of the jump, which you can use to get the distance value for each half. You can determine the highest point by taking the higher of the starting or final y positions and subtracting a fixed offset (which can be adjusted by the designer). You then subtract the highest point from the starting and final y positions to get the distance values for each half of the jump.

• The total time of the jump, which remains fixed by design.

Here's what we need to determine:

• The time to the apex of the jump, which can then be used to get...

• The gravity, which remains constant across both halves of the jump.

• The initial velocity of the first half of the jump.

Since I wasn't able to figure out how to obtain those three variables mathematically, I wrote a bit of code to brute force the problem. This doesn't really affect much performance-wise but if anyone knows how to solve this properly do let me know. Here is the code in question (the y variable here refers to the target y position, which was determined earlier):

var _layerJumpHighPoint = min(_startY, y) - layerJumpHeight;
var _fallDistance = y - _layerJumpHighPoint;
var _jumpDistance = _startY - _layerJumpHighPoint;
layerJumpGrav = 0;
var _currentJumpTime = 999;
while(_currentJumpTime > layerJumpTime){ 
    layerJumpGrav += 0.01;
    var _timeToApex = sqrt(2*_jumpDistance/layerJumpGrav);
    layerJumpVerticalSpeed = -layerJumpGrav*_timeToApex;
    _currentJumpTime = _timeToApex + sqrt(2*_fallDistance/layerJumpGrav);
}

The Details

Now that all the big conceptual stuff is out of the way, all that's left to go over is the specific implementation details. Please note that some edits have been made to code snippets keep things focused on the essential functionality, you guys don't need to know the filename for every sound Anton is making while jumping. Also to note, the player object uses a finite state machine, I won't go in-depth on that pattern so here's a good explanation of how it works for those unfamiliar.

Let's start with the variables used on the player object:

layerJumpHeight = 25;
layerJumpX = -1;
layerJumpY = -1;
layerJumpVerticalSpeed = 0;
layerJumpGrav = 0;
layerJumpTime = 50;
layerJumpTimer = -1;
layerJumpMaxHorizontalSpeed = 1;

• "Height" is the offset used to determine the peak of the jump during the arc calculation. We measure units of distance in pixels, native screen size is 384x216.

• "X" and "Y" here are used to keep track of the Anton "ghost"'s render position during the jump.

• As we saw earlier, "Grav" and "VerticalSpeed" are determined during the jump arc calculation and affect the shape of the jump arc.

• "Time" determines how long a jump takes in frames (at 60 FPS the value given above would be about 0.83 seconds)

• "Timer" keeps track of how long the player has been in a layer jump. While the end of the jump is not triggered by the timer, it is still useful for other things we'll see later.

• "MaxHorizontalSpeed" determines how fast the player can move from side to side during a layer jump.

The player triggers a layer jump by standing on a spring in the normal state and jumping (we also check that they aren't holding left or right):

if (jump){
    var _spring = instance_place(x, y+1, mySpring);
    if(!moveLeft && !moveRight && _spring != noone){
        layerJump(_spring.targetX, _spring.targetY);
    }
}

layerJump = function(_targetX, _targetY){
    myLayer = (myLayer == 0) ? 1 : 0;
    currentState = playerStates.playerLayerJump;
	
    horizontalSpeed = 0;
    verticalSpeed = 0;
	
    if(myLayer == 0) layerJumpX = round(x + camera_get_view_x(PLAYERVIEW)*PARALLAX_RATIO);
    else layerJumpX = round(x - camera_get_view_x(PLAYERVIEW)*PARALLAX_RATIO);
	
    var _startY = y;
    x = _targetX;
    while(
        place_meeting(x, _targetY, myBlock) || 
        place_meeting(x, _targetY, myPassthrough)
    ){
        _targetY -= 1;
        if(_targetY < 0){
	    _targetY = y;
	    break;
	}
    }
    y = _targetY;

    while(
        !(check_below(_targetY) || 
        check_below_passthrough(_targetY))
    ){
        _targetY += 1;
	if(_targetY > room_height){
	    _targetY = y;
	    break;
	}
    }
    y = _targetY;
	

    var _layerJumpHighPoint = min(_startY, y) - layerJumpHeight;
    var _fallDistance = y - _layerJumpHighPoint;
    var _jumpDistance = _startY - _layerJumpHighPoint;
    layerJumpGrav = 0;
    var _currentJumpTime = 999;
    while(_currentJumpTime > layerJumpTime){ 
        layerJumpGrav += 0.01;
        var _timeToApex = sqrt(2*_jumpDistance/layerJumpGrav);
	layerJumpVerticalSpeed = -layerJumpGrav*_timeToApex;
	_currentJumpTime = _timeToApex + sqrt(2*_fallDistance/layerJumpGrav);
    }
	
    layerJumpY = _startY;
    layerJumpTimer = 0;
}

The layer jump function does a bunch of setup:

• Changes the player's layer

• Puts the player in the layer jump state

• Zeroes out the player's speed

• Sets the Anton ghost's initial render position based on the player's current pre-jump position

• Determines a valid position based on the desired target coordinates and teleports the player there

• Resets the jump timer

• Calculates the jump arc, as seen earlier

Once the player object is in the layer jump state, it'll start running this code in its step event:

layerJumpX = approach(layerJumpX, x, 0.4);
layerJumpX += horizontalSpeed;

var _moveDir = moveRight - moveLeft;
horizontalSpeed = layerJumpMaxHorizontalSpeed*_moveDir;

verticalSpeed = 0;

layerJumpVerticalSpeed += layerJumpGrav;
if(layerJumpVerticalSpeed < 0) layerJumpY += layerJumpVerticalSpeed;
else{
    layerJumpY = approach(layerJumpY, y, layerJumpVerticalSpeed);
    if(layerJumpY == y){
	if(!onGround) verticalSpeed = layerJumpVerticalSpeed;
	    currentState = playerStates.playerNormal;
    }
}
layerJumpTimer++;

Said code does the following:

• Approach the render position to the player's true position, such that they're guaranteed to sync up before the jump ends.

• Move the render position based on the player's movement speed.

• Lets the player move left and right based on the layer jump horizontal speed. This should be done after the previous step to allow collision, which would usually run after this, to properly affect the speed being applied to the render position.

• Keeps vertical speed at 0, eliminating the normal physics' gravity. Leaving gravity on would cause various issues given this implementation, and it coming into play at all is enough of an edge case that I decided it would be easiest to just disable it.

• Does the usual physics stuff with gravity and vertical speed to the ghost.

• Once the ghost is on its way down, checks whether it's reached the target y position. Once it has it transitions the player back to their normal state.

Last but not least, let's take a look at the code that's rendering all this:

if(currentState == playerStates.playerLayerJump){
    var _scale = map(layerJumpTimer, 0, layerJumpTime, (myLayer == 1) ? 0.5 : 1, spriteScale);
    _drawX = round(layerJumpX + ((myLayer == 0) ? 0 : (camera_get_view_x(PLAYERVIEW)*PARALLAX_RATIO)));
    var _palette = map(_scale,0.5,1,2,1);
    pal_swap_set(playerPalette,_palette,false);
    draw_sprite_ext(
	sprite_index, image_index,
	_drawX, round(layerJumpY),
	_scale, _scale, image_angle, image_blend, image_alpha
    );	
}

Going line-by-line:

• The player's scale is smoothly adjusted using the layer jump timer as they transition to or from the background.

• The draw position is determined by taking the render position and adjusting for parallax based on whether the player is in the background or not (remember, the new layer value is set as soon as a jump is initiated).

• The player's palette is also subtly adjusted (based on their scale) as they change layers to create an atmospheric scattering lighting effect.

• The player's sprite is then drawn using the values we have painstakingly calculated.

Extra Tidbits on Keeping the Player in the Background

To avoid this post getting too long, I'll be brief with this stuff, especially since it shouldn't be too hard for others to figure out the details. For the most part the player works the same while they're in the background, with a few notable exceptions:

• Like other objects that appear both in the foreground and background, Anton is rendered at half size while in the background, and his collision mask is also adjusted to match.

• The player object's physics variables are halved to keep the movement correct despite the player's small size

• The player object can only collide with things on the same layer as it. Our current implementation of this is pending a complete rewrite. My intent is to replace the collision functions with ones that have the layer check built-in, perhaps using collision matrices similar to unity.

Conclusion

Well there you have it, all the information you need to totally rip us off as badly as we ripped off, uh, a bunch of stuff actually. There's a surprising amount of platformers that have a gimmick like this. Guess that speaks to its strength as a level design tool! If you have any questions feel free to leave a comment or join our discord and ask in the #your-computer channel, which I hang around in regularly. Thanks for reading, see you next devlog! Oh, and be sure to check out the kickstarter page!

There’s a video on that page where (after a masterfully edited action-packed trailer) I talk a bit about the past and future of this project’s development. That video marks the end of my plans to vlog the game’s development (mostly, I might still make the occasional announcement video here and there), and I figured, what better way to break in this blog than to pedantically expand on whatever I was saying there!

When I started making those videos my thinking was something along the lines of “Video Games are cool but you can’t really regularly put out a really great, polished product the same way you can with other kinds of internet content (unless you only make tiny prototypes), which makes it difficult for an unknown developer with very little artistic skill to garner attention online. But if I make regular devlogs I can develop the game I want to and produce regular content for my (future) adoring fans, not to mention leverage the youtube algorithm. And look at all these other developers on youtube making it work, this is totally doable! Most likely I won’t reach quite that level of success, but I’m sure it’s worth trying out.” Now, after a year of actually making devlogs, my thinking hasn’t actually changed too much, it’s just (not unexpectedly) developed quite a few caveats that I’ll be getting into.

First though I want to say I definitely don’t regret making those videos, that last part about it being worth it turned out to be entirely true. I’m now way more comfortable in professional editing software, I know what my strengths as a video producer are, I know I can produce a decent video if I ever need to (as well as about how long it’ll take), and, most importantly, it helped me land my first job as a game programmer by being something in my portfolio that really put my sense of humor and adaptability on display (which, turns out, is pretty important in tight-knit indie development environments).

So then, why switch over to text based blogging? Well… ever notice notice how popular youtube game devs (except for Jonas Tyroller) tend to either produce very small games or seem to get stuck working on the same project forever? Turns out making good youtube videos is just as hard as making any other kind of art (shocker), and doing it regularly is almost a full time job. As fun as those videos were to make, putting out even just one of decent quality per month would have left me with upsettingly little time to actually develop my game. Maybe if I was really into making youtube videos as an end, the same way I’m into making games, I would have been faster and happier working on them, but a lot of the time I just felt like they were slowing me down when it came to the stuff I actually cared about. So here we are. I figure I can still achieve most of the marketing value (and dopaminergic gratification) that I wanted out of those videos for a fraction of the effort just by focusing more on substack and twitter, and people on substack will probably be more interested in the kind of game I’m making than the average youtube viewer anyway. Plus, this way I can explore a whole bunch of other ideas that I really didn’t care enough about to turn into full videos. If you’re interested, you can-

Subscribe now

Share Massimog's massiblog

Leave a comment

Follow me on twitter

…yeah that.

I’ll start writing posts soon, in the meantime you can subscribe and check out the about page to learn more about me!

Subscribe now