This will be the greatest devlog—in the series of devlogs I’m making for the Diorama Break Kickstarter—yet!!

Early Stages

Since I knew the demo’s environments would feature a lot of trees, I figured that having a way to “cheaply” place varied, animated foliage around would help us a lot with saving on environment art load and keeping the environments visually interesting1. I also figured that, since the appearance of trees in real life is the result of fairly comprehensible stochastic/fractal processes, recreating something like that procedurally would be doable and likely produce results that felt “natural” without much additional effort.

The first steps involved developing a simple random algorithm for generating a “branch”:

1. Start from a “root” node, and assign it a starting “decay” value and random direction.

2. Pick a new direction slightly randomly offset from the node’s direction. You will now create one or more child nodes. Roll a random value to decide first whether to “split”, “decay”, or do nothing:

   1. If you “split”, create two new child nodes slightly offset from the chosen direction in opposite directions, both with a “decay” value reduced by 1.

   2. If you “decay”, create a new node in the chosen direction, with a decay value one less than the parent.

   3. If you do nothing, do the same as b., but set its decay value the same as the parent’s.

3. Repeat step 2 for every new node, unless its decay value is 0, at which point it is considered a “leaf” node and gets no children.

Funnily enough, the resulting data structure would totally be described in computer science terms as a “tree”, making the normally abstract terms used to talk about said structures (branches, roots, leaves, etc.) hilariously literal in this case.

Anyway, once I had this structure, I could render it in game. All the trees rendered this way actually just use a single branch and leaf sprite, simply varying the size and rotation. With just the root node’s position, as well as the decay value and relative angle of it and every other node, I can derive the position and rotation of every sprite to draw by traversing the structure recursively (lower decay values have a smaller scale and offset, causing the tree branch to “taper off”, and decay values of 0 draw the leaf texture instead of the branch).

I continued to mess with the constants for random variables—stuff like angle ranges, starting decay value, chance of splitting/decaying—until I had something I was satisfied with for a single branch.

At that point, I began to work on animation. My idea would be to be able to assign a “wind force” to each node, and make them springy, so that they would sway back and forth. Wind force could then be applied at random throughout the branch to give the impression of random gusts. Thanks to the way I re-derive the position and rotation of every node every time the branch is rendered, force can be applied to the relative angle of a single node, and the angular change will “propagate” to all its children.

Overall this idea worked out, though it took hours of staring at footage of trees on windy days (as well as the trees outside my window) and a lot of tweaking to get just right2:

Full Background

Now that I had nice-looking animated branches, I could begin populating the background. First step was to just spawn in a bunch of branches:

Not bad, but this was immediately taxing on my PC, so it was time for some optimization! At first I was just drawing every branch and leaf node individually, so the obvious thing was to construct a proper mesh first, then push the entire thing to the GPU in a single call.

Handling the final render positions in my own code had a few, uh, false starts…

Got it working eventually though, at which point I could start layering branches of different size and color to create more of an illusion of depth:

And to complete the effect, a parallax offset for each layer:

Getting the exact distribution and branch size for each foliage layer also took some tweaking, but I’m pretty happy with the results!

Final Touches

And that’s where I left it, for the most part. Some more optimizations came after, particularly culling, though the effect is still not as performant as I’d like it to be. I think the big win will be in translating all the animation logic into shader code, so that a lot of that work can be done on the GPU and I don’t have to push these giant meshes (hundreds of thousands of vertices!) to it every frame, but that’ll have to wait until work on the full game begins.

We also ended up adjusting the colors to have the leaves match the branches, creating a more “silhouetted” look which distracts less from the foreground. Here’s that final iteration of the effect, straight from the demo:

“But wait!”, I hear you wail, “This is not the only animated foliage in the demo! What about the rest!?”

Ah, dear player, you will surely be raptured to hear that Diorama Break has, in fact, a second, entirely separate foliage system for foreground trees! That’s right!! But alas, my time here today is limited, so remember to vote for it as the next devlog topic in our latest backer update to get another sweet, sweet foliage fix. Until next time!

Subscribe now

Long-time subscribers will remember the series of devlogs I did a couple years ago over the course of building my own custom game engine. A lot of my thinking on the subject is captured in that original post, but now, after over a year of actually using the engine and producing a successful game demo with it, I thought it would be worth revisiting.

Why Use a Custom Engine?

The “common wisdom” around this topic often boils down to this idea that creating a custom engine as a solo dev or small team will necessarily suck up half a decade without any actual game to show for it. While there are a few anecdotal horror stories to this effect, for the most part this is a myth. Use of third-party engines like Unity, Unreal, or Godot was nowhere near a dominant practice until the mid-2010s. Many of the most influential indie games of all time—games like Braid, FTL, and Terraria—were all made with custom engines in just 1 to 3 years. And thanks to the release of new and friendlier low-level languages and frameworks like Odin, Raylib, SDL3, etc. over the past decade and a half, this style of game development is easier and more approachable than ever!1 My own experience involved getting fed up with the limitations of Game Maker, giving myself half a year to replicate all the basic features I liked from it in my own software (and add a few I thought were sorely missing), and managing to get it all done in just about five months!

There are a few caveats of course. It’s not something I would recommend to total beginners; without experience actually using an existing engine you wouldn’t even really know what to build in the first place. Having at least one major project under your belt, ideally one made for commercial release, will give you indispensable insight into what you’ll actually need in terms of tools. 3D is also a much greater challenge compared to 2D. While I feel confident that I could tackle a custom 3D engine now, after my experience building my 2D engine, even at the onset I recognized that trying to do something 3D from the start would have added waaay more complexity and potentially spiraled into something unsustainable. And if you’re angling to compete with high-fidelity AAA graphics, it’s not clear to me that as a solo dev going custom is viable in at all the same way that it is for something 2D or stylized.

But I still haven’t really answered the question “why bother”? If third-party engines developed by all these well-resourced companies and communities are just sitting there for the taking, why put in all this extra work reinventing the wheel? At the core of it, it’s perhaps a sense of pride and self-reliance, wanting to have the agency, deep understanding, and control that building my own tools affords me. But I can also list a lot of practical advantages:

• Third-party engines can be extremely bloated, with years of feature creep, abandoned functionality, and “legacy support” taking their toll on usability and the ease of learning the engine. When building your own tools, you can choose exactly what you do and don’t need, and you’ll have a full understanding of what’s available to you once you get to actually building your game.

• Most third-party engines are built to be extremely general-purpose, in order to give all users the option to create almost any sort of game. That often means that the tools you’re given won’t be quite suited to your specific needs, which can range from them just being slightly annoying to work with, to requiring enormous additions and workarounds (which are often more work to integrate with existing engine bloat than it would be to just build the whole tool from scratch in your own clean ecosystem). More specialized engines like RPGMaker and Ren’Py exist, but they’re even more susceptible to the next problem…

• If a third-party engine doesn’t support a feature or have a tool you need for your game, it’s often a serious problem. Building the tool from scratch and integrating it with the engine can range from extremely time-consuming to outright impossible, especially if the engine is closed-source. With your own engine, you built everything anyway, so one more feature is just that. Much, much easier.

• Similar to the above point, if a third-party engine does technically support a feature but it’s broken in some way (either buggy or just unfinished), you’ll often be caught between trying to fix it yourself, hoping and waiting for the engine developers to fix it, or just working around it in a way that makes your game worse; all risky and annoying options. With your own tools, you can of course just fix them yourself as easily as you built them in the first place.

• Many third-party engines will encourage the use of tools and scripting languages that offer very limited control of the exact behavior of your final program, especially when it comes to things like memory layout. This might make things easier when starting out, but will eventually spiral into you having performance issues you have no easy way to solve (or even properly diagnose). Certain designs will even be outright impossible to achieve without the ability to finely optimize your game; Noita is a game that simulates every single pixel on screen as a powder-like physics object, something that feels to me like it would be impossible or at least unbelievably onerous to do in an engine you didn’t have complete control over2.

• This is more of an issue diffused across the industry, but widespread use of third-party engines, among other things, has caused an observable decrease in “diversity” in modern games. When you’re forced to build everything yourself, you’ll end up making a bunch of tiny idiosyncratic decisions about things like physics, lighting, rendering, etc. that cause your game to feel “unique” in subtle and not-so-subtle ways. When everyone is instead reaching for the same cookie-cutter solutions that engines offer for basic problems, designs and game feel are pushed more in the direction of what is easy to do in these engines, and many games end up with, for example, “Unity smell”. While it’s possible to get around this by carefully replacing and tuning every aspect of an engine, at what point does it not just become less effort to do everything from scratch?

• Many (but not all) third-party engines demand fees, either fixed fees for access to exporters for certain platforms, or in the form of a portion of profits from successful enough commercial projects that rely on them. Not entirely unfair of them to want to be paid for their work, but avoiding these fees can be a compelling reason to stick with your own tools if you plan to develop a large commercial game.

How’s it Going?

Again, my old devlog series is probably the best place to go if you want to get more into the nitty-gritty of how I actually built the engine, but here’s how things have been going in the past year and a half for those who have read it:

In general, I’ve probably become even more handmade-pilled. The original engine had a few third-party libraries and tools in the pipeline that were so annoying that I’ve since stripped them out and replaced them with my own solutions3. I’ve definitely gotten the itch to try and replace every third-party library and tool once I have more time to work on the engine, though FMOD and SDL are still worth keeping in my opinion4.

Odin has also continued to be a blast to use, no major complaints there. Especially now that I’ve explored most of the features of the language, I’ve come to really appreciate the general philosophy it has of only trying to give you one great tool per problem you’re likely to encounter. Avoiding choice paralysis and footguns like that is great for my mental bandwidth, and I can always feel confident when I encounter a new problem that, if it can be solved with just Odin, there’ll be a straightforward way to do so (and this is indeed true of most problems I’ve encountered so far). Probably the biggest thing missing in my opinion is some way to automatically generate symbols (such as by reading asset directories), something I have to rely on external “metaprogram” scripts to do, but I definitely get why Bill can’t5, say, just quickly whip up a robust metaprogramming system to cover cases like this.

The biggest addition since I got all the basic engine features done has probably been the custom stage editor for Diorama Break. Having the ability to just whip up any feature I want for this tool has been great for producing something useful and ergonomic, though I do wish other members of the team would take advantage of this more and pester me about desired fixes and features. It’s a bit embarrassing to leave the tool in their hands for a while then try it out and notice a bunch of places where I left things horribly unfinished!! Anyway, there’s a lot I could talk about here, but I’ll leave it for a future devlog.

Overall, I don’t think I’ll ever be inclined to return to a third-party engine. The ease of use and sense of security all this control gives me has been fantastic, and especially now that we’re well over the initial development hump, the return on investment is really starting to show. I was able to implement our entire localization system in just a few days6, something which I’ve heard other developers say took them weeks if not months to do.

I also feel like I’ve grown tremendously as a programmer, maybe not as drastically as after the initial engine development period, but every day brings more improvement to my skills and confidence to just manifest whatever tool I need to knock down the problems in my path7. Sometimes it takes a little longer than expected, much to my producer’s frustration, but the results in Diorama Break’s demo hopefully speak for themselves. There’s still a ton to work on though, so let’s keep that Kickstarter momentum going!

Subscribe now

…and said Kickstarter is proceeding smoothly, with 50k CAD raised at this point. Our goal’s set at 95k, and for those less familiar, it’s practically certain at this point that we’ll be able to hit it. A huge victory! Diorama Break is well on its way to being a big commercial release! So, how did we get to this point?

Early Ideas

The first ideas for Diorama Break came around early 2018, mainly after having played OneShot. The idea of an RPG where you could talk directly to the protagonist the whole time was a fascinating one, and something I thought could be interesting even outside of OneShot’s more limited scope and adventure/puzzle gameplay style. More generally, my teenage years (2013-2019) were something of a golden age for this “sincere postmodern” style of interactive storytelling, and the impact projects like Undertale and The Stanley Parable had on me had left me wanting to try my own hand at that sort of storytelling1. My exact memories of this time are fuzzy, but I distinctly remember starting out with a strong vision of the game’s opening as well as its climax, and filling in the rest from there in my head whenever I had spare time to reflect on it.

The combat system was initially an entirely separate idea for a different game, but as it happens I realized it would fit really well as a JRPG combat system, and so gradually grafted it on to the core concept.

At the time, I was still in school, and ended up building up the idea as something I could work on solo after graduating. My final project at the time though was also a simple RPG, and I definitely structured things such that I could reuse a lot of the technical work from that after it was done.

First Prototype

After a tumultuous graduation in May 2020 (note the timing), I spent some time trying to land a job in Montreal’s indie scene. After a few months of nothing though, I figured I’d have to get busy with something on my own, and set out to create the first prototype for the gameplay. I even took the time to document the process in a series of polished devlogs (real Massimoheads will know), which you will NEVER find.

That process took about a year, from July 2020 to July 2021, of coding, art, and videomaking. At the end of it I had an ok-looking prototype featuring over a dozen stages, a bunch of wacky mechanics, and an insane learning curve. Many things differ in that system from today’s demo, for example:

• No turns. You had to define unit actions every single step. As soon as a unit became free, you could commit a new action. As you can imagine, this was pretty tedious, and even more confusing for people used to traditional tactics systems (many tried to attack immediately and got interrupted by faster enemies).

• Movement was “free”, i.e. as long as a unit was available you could move and commit an action on the same step.

• Enemies would not show their future “plans”, instead, for the most part, you were expected to bait them into committing an action, then avoid it and counterattack.

• The point of this prototype was to test the limits of the combat system, so battles near the end featured up to about a dozen units and many wacky actions were implemented. The most egregious example was an action attempting to emulate a “reflector”-style attack, which would “attack a small area around the user for 3 steps and prevent all damage and hitstun from attacks, but ONLY if the attacker was over 8 tiles away”. Needless to say this was kind of a nightmare to explain to playtesters.

• The average unit would take up 4x4 tiles, rather than the current demo’s 3x3. We ultimately changed this since odd-numbered unit sizes allow units to have a well-defined “center”.

• Virtually no narrative was featured, just units fighting on islands.

Ultimately though, the combat felt fun enough to give me the confidence to move forward with the idea in the full game. The experience also taught me that doing Youtube at the same time as making a game is really freaking time-consuming and mostly just distracted me from actually working on the thing I cared about.

Anyway, at the same time that I was working on this, my career as a contract indie game programmer kicked off, so I ended up putting the project down for a bit in late 2021 to focus on that. This was also around the time that ANTONBLAST was beginning development, and helping get that Kickstarter was exciting enough to keep a lot of my spare attention.

Getting the Team Together

Over the next couple years, I kept an eye out for opportunities to really get the project started, and worked on concretizing a lot of the project’s scope and worldbuilding. Working on Antonblast had sparked within me a desire to not compromise and make something smaller or less polished for my own project, so the plan I worked out ended up being a lot bigger than something I could take on by myself.

With said plan in mind, the first thing I resolved to do, before anything else, was nail down an excellent art director. Getting someone who could not just support the project in terms of producing assets but really create and maintain a concrete and cohesive vision for how the entire project should look was a must-have to avoid falling into the trap of hiring a bunch of siloed artists whose work might be good on its own but would not end up cohering. While I eventually ended up taking on some of this job myself simply in my role as Director, at the time I considered this not my area of expertise, and therefore something I ought to hand over completely to someone more qualified.

To this end, and to help build a shortlist of potential artists of all stripes, I constructed a bot to scrape Twitter2 for game artists looking for work that matched the style and interests I was looking for3. While this did help me get my list started, I ended up finding SaKo through other means (I was scrolling follower lists, saw a profile picture I liked, and looked up who drew it). After a few months of talking back and forth and commissioning some concept art from him, I convinced him to join the project and help me recruit the rest of the team.

Once SaKo was on board, around the start of 2024, “pre-production” on the demo could finally start ramping up. Production on Antonblast was slated to finish by the end of the year. Once that was done, I’d be free to move full time onto the full production of the Diorama Break demo without missing a beat. My plan began to solidify, by the end of 2024 I’d have to:

• Get a team of artists to commit to working on the game.

• Obtain funding to pay those artists for the duration of the demo’s production.

• Plan out all assets that would be needed along with time and budget estimates.

• Define a schedule and art pipeline to keep production running smoothly during the busy period.

• Create the game engine for the demo.4

• Work with SaKo to complete as much concept material for Chapter 1 and the rest of the game as possible to give people an idea of what we’d be working towards.

Ultimately, pre-production ended up going fairly smoothly, with most artists we reached out to agreeing to join the project between November and January 2025. I applied for CMF funding around March 2024, and was ultimately rejected after the 6 month review process, but the silver lining here is that this pushed me to recruit people very early, which made it a lot easier for them to agree (“I have a job lined up now!” and not “I’m too busy to join this project immediately”). I’m fortunate enough that despite the funding from the CMF falling through, I was still able to cover costs for the demo’s development with my own savings and money borrowed from family; this sort of endeavor at this level of ambition is not something I think would be easy for most people to do and I’m incredibly grateful to be in a position where I was even able to take the risk in the first place.

One thing that might surprise you is that most team members on Diorama Break, including SaKo, were just people I cold-called after seeing their portfolios, usually through twitter DMs or their business contacts. I had prepared a couple-page document pitching the project and explaining my goals, timelines, and remuneration structure; combined with SaKo’s concept work this ended up convincing most people to come on board. Let it be known then, if you come to them with a mutually beneficial offer, people are quite willing to hear you out! The most exciting example of this was Mariru; I was originally hesitant to reach out since I couldn’t really speak Japanese, but I gave it a try anyway and it worked out great! I even managed to set up a bot in our work discussion server to translate messages back and forth so that he could easily participate like anyone else5.

Antonblast ended up taking a little longer to release than expected, and I had a fun couple of months where I had to stay in a temporary SRO in between moving houses while finishing that and at the same time getting Diorama Break ready for full production. I feel like I have terrible luck when it comes to the timing of big life events like this… got through it though, and proper production got started in December 2024.

Demo Production

This part of the project is both easier to talk about for being fresh in memory and harder for not having as much distance from it and the hindsight that comes with that. The original production timeline ended up being extremely optimistic, I had modeled it off Antonblast’s Kickstarter demo production, which only took 4 months. Turns out that making a content-heavy JRPG with a completely fresh team and half-finished tools takes a little longer than that. One thing we were really struggling with for a while was satisfactorily laying out the environment art with the right perspective, fortunately though I was able to recruit Mirrorfloria in June after attending a local pixel art workshop she was running and deeming her a good fit for the job. She managed to right that aspect of production quick, something I’ll be eternally grateful for.

Anyway, I’ll spare you more recountings of embarrassing production mistakes I made early on. I’m at least relieved that we only went over-time and not over-budget (although some sources of income ended up not coming in, or coming in later than expected, so that still felt quite stretched near the end and contributed to us launching the Kickstarter so soon after the demo launch). Here’s roughly what production milestones we hit and when:

• February 2025: All basic tooling and game mechanics (dialogue, stage editor, combat system, overworld movement) functional. Models and concept art for all major characters complete.

• May 2025: First non-combat stage (Pro’s room) implemented and first cutscene done.

• June 2025: First playtest demo shown at a local event (featuring just the combat tutorial).

• August 2025: Most Stroma Village stages complete (no NPCs), teaser trailer released, demo build shown at PAX West (featuring all critical-path content from the intro to the end of the combat tutorial).

• October 2025: Finished draft of all remaining critical-path dialogue and cutscene code.

• December 2025: “Gameplay reveal” trailer, Diorama Break appears in the “Choose Wisely” Steam festival.

• January 2026: Finished all dialogue.

• February 2026: Finalized all cutscenes and stages, demo releases in open beta.

• April 2026: Demo releases on Steam with new trailer and several polish improvements. Kickstarter launch.

And now here we are! While the time it took to get this demo out the door might seem daunting in the context of the full game’s eventual production, with the lessons learned, the foundation we set up through the demo’s production, and the financial cushion from the Kickstarter, we’ll be more than efficient enough to deliver on time. Though whether we get to that starting line is now in your hands! 24 days to go, let’s get it done!

Subscribe now

There’s a distinct sort of dialogue style you’ll see in a lot of RPGs and other games, where one line gradually appears after another inside a textbox, sometimes with a portrait to go along with it.

Many indie developers, then, seek to emulate this style for their own games. A very common and straightforward way one might think to do this1 is to just write every individual line of dialogue directly into their code, usually inside some sort of linear structure. Toby Fox even said he was partly inspired to create Undertale and its dialogue system after reading about “array data structures”. You can then render your textbox, and one line of dialogue at a time, showing the next line every time the player gives the input. This has a number of limitations though:

• It doesn’t account for branching dialogue.

• It makes it difficult to swap out lines conditionally, such as when changing the game’s language.

• It forces non-programmers to dig into the code files to change dialogue.

• It alone can’t account for style, like italics, text coloration, text scroll effects, and more.

• It adds a lot of boilerplate code syntax that isn’t strictly necessary.

A lot of online tutorials therefore recommend you move all your dialogue into spreadsheets:

This fixes a lot of the issues above, and is a lot more “industry-standard”. In general, the idea that you should treat dialogue as a data asset that you work on separately from your code (like sprites or audio) is correct. Even if this alone can’t handle branching dialogue, being able to load and refer to dialogue as data like this makes it a lot easier to implement such a system.

However, this still isn’t great! Spreadsheets are a very general-purpose tool and weren’t exactly designed with scriptwriting in mind, and especially not interactive scriptwriting with branching paths, dialogue flags, and potentially very complex conditional behavior based on the state of a bunch of game data. They might work ok if you have all your dialogue already mapped out and ready to go, but creating and editing all that dialogue in the first place can quickly spiral into an overcomplex nightmare!

What tools, then, are more precisely engineered for the task? Well, Disco Elysium, a game with one of the most complex dialogue systems in recent memory, uses a tool called Articy:

You can glean from the screenshot that this is sort of a cross between a scriptwriting tool and a visual scripting system, allowing the devs to express branches, set flags, have conditions and jumps, define dialogue styling, and more, all from a single editor. It might take a little more legwork to get it to talk to your game code, but it seems well worth it for the resulting ease-of-use when editing. And if it seems a bit pricy or daunting, similar open-source alternatives like Twine exist.

If that sounds cool to you, Articy might be the place to end your search, and I had seriously considered giving it a shot for Diorama Break, but something about visual scripting tools has always put me off. Being able to just write out my branching dialogue in a simple text editor, same as any cinematic or theatrical scriptwriter, had been the holy grail of ergonomics for me. I wanted that. And there really didn’t seem to be a tool that came up in my research catering to me so… why not make my own?

Designing the System

Since I was looking to end up with a workflow where the bulk of dialogue “content” is just line-by-line text that can be stored and edited like any text file, I decided the right tool for the job was a markup language. That is, a language where text content lives alongside “code-like” annotations, which a renderer can use to produce a final document output. The most famous example of one is undoubtedly HTML, which determines the layout of pretty much every web page on the internet (you can press F12 right now to see the HTML behind this page!) Full disclosure, I had already experimented a bit with this sort of thing in school and for the Diorama Break prototypes, but now I was set on making something truly polished that could comfortably support me through the development of a whole JRPG.

So the basic plan was to design a language of annotations that I could add to my dialogue text to express things like branching, text style, and more. I then need to build an interpreter and renderer in my engine that can read the resulting text files and display the appropriate dialogue and choices, as well as an editor that can display these annotations in a way that’s easy to parse at a glance and edit.

One very popular markup language right now is Markdown. Lauded for its simplicity, it barely feels like a “language” at all, just a very simple set of rules you can use to write out documents with headings, images, basic text styling, and more, all by hand.

Its popularity gave it something I could spin to my advantage: a whole ecosystem of text editors that support it natively. This solved a big problem for me: rather than build a text editor from scratch with all the extra features I would need, I could use an existing Markdown text editor, write my annotations with markdown syntax, then write my interpreter in a way that it could parse that markdown into in-game dialogue, basically cutting the work in half!

For my editor of choice, I ended up going with Obsidian, since I was already familiar with it for note-taking.

To recap then, I was looking to build my markup language with these features:

• Simple text as the backbone. One line of plain text in the document = one line/box of dialogue in-game.

• Stylistic markup for bold, italic, and colored text.

• A simple way to express nested branching dialogue with both conditional checks (“if statements”) and player dialogue choices.

• Ability to jump to different points in dialogue for more complicated branching behavior.

• Ability to set flags.

• Ability to call arbitrary engine functions (for more complicated behavior, e.g. starting cutscenes).

• Ability to set the speaker’s profile picture and have it be visible in-editor.

Here’s the syntax I ultimately settled on:

Styling

This one was a no-brainer. Markdown supports using asterisks for *italic*, **bold**, and ***bold italic*** text. Colored text was a little harder, but I ended up using an Obsidian plugin that will color the text you highlight by inserting a special HTML tag:

Jumps

For jumping between different points in dialogue, I decided to use Markdown headings (which I call “labels” in this context). This lets me naturally segment the file in a way that looks nice in-editor (and lets me fold up segments). By inserting a Markdown link, I can tell the dialogue to jump to a new label, and as a nice bonus I can click on said link in-editor to jump there too!

Branching Dialogue

By using Markdown quote syntax, I can create a pretty nice looking “dialogue tree”. This will pop up a question box the player can use to give a response:

It’s even possible to nest these choices and jump to and out of them using labels:

Here’s what that looks like without Obsidian’s prettification:

If you’ve played Diorama Break, you’ll know it also features “optional” dialogue choices, called “interjections”. I mark these just by adding a ‘!’ at the start of the first choice. If the player ignores the choice, the dialogue will just skip past the entire choice block.

Conditionals and Commands

By using Markdown’s backtick syntax, intended for showing code blocks, I can separate normal text from basic scripting logic I want to insert. The first thing this can be used for is conditional blocks (also nestable):

As you can see here, I can also use backtick commands to set flags.

I can also call parameterized commands to the engine to do stuff like play cutscenes, adjust characters, change the dialogue speed, etc. Here’s an example from the game demo:

These work by calling from a predefined list of commands that interpret the parameters as an array of strings:

Commands return a string that can be inserted in the dialogue if need be.

Portraits

These work using obsidian’s image links. By including a symlink to the folder in our sprites directory containing all the character portraits, we can simply link the filename, which gives us a command that changes the portrait in-game and previews it in-editor:

Obsidian will even auto-suggest filenames:

Combining it All

When put all together, these features can do some pretty nifty stuff. Take a look at this example from the game:

This does the following:

• It can be started by (when interacting with the relevant object in the overworld) jumping to the “repository” label in the relevant dialogue file.

• Sets and unsets the dialogue portrait.

• Shows a differently colored line of dialogue if certain global flags are not set.

• Displays a set of choices that bring you to different parts of the dialogue. Certain choices only display if a flag is set one way or another.

• Inserts a random line from another special dialogue file using the repoLine command.

• Closes the dialogue when a choice that doesn’t jump elsewhere is selected.

Designed!

And that’s how it all works in-editor!2 For most of you, I’d recommend getting off here. If you enjoyed this post, check out the latest backer update to vote on the next post’s topic! Oh, and also:

Subscribe now

For the rest of you who might be curious about how it all works under the hood though, let’s take a peek!

Nitty-Gritty Boring Technical Details

Like most systems in-engine, the dialogue system relies on a set of global variables for state. Since only one dialogue can play at any given time, a lot of the system’s state is just stored globally:

I won’t get into all the bits and bobs like HD portraits, the log, and localization, instead focusing just on how a dialogue file gets read into the engine and then interpreted at runtime.

Loading

First, when building the game, the dialogue build script copies all the dialogue files and places them in a flat intermediate folder for the asset packer to bundle into the final packed asset binary. It also reads all the filenames and generates an “id” code file that my Language Server can use to provide autocomplete for dialogue assets, much like the other asset build scripts. The only unique part of this script is the preprocess step, which strips out comments, trailing whitespace, unneeded heading hash symbols, and empty lines:

At startup, the asset loader loads the dialogue data into memory and maps it out like so: each dialogue line is its own string, stored in an array, and each dialogue also gets a map that maps each label name to an index in that array.

“Running” a dialogue

At almost any point, the dialogue_open proc can be called to open a dialogue (from the top, or at a specified label).

“Blocking” here refers to if activating the dialogue should prevent the player from making other inputs for its duration.

From the open proc, I call dialogue_next_line. This is a monster 200-line proc and the beating heart of the interpreter. It works on the following principle:

• The dialogue system tracks its current position using a “head” (the index of the line we’re on).

• Read ahead from this head in a loop until you have content that can be displayed, then stop (with a few exceptions).

Let’s look at it step-by-step:

First, it:

• Ensures it’s not being called with no dialogue open.

• Sets a flag that says the dialogue is currently “parsing”. This is mainly for certain label jump procedures, since they need to behave slightly differently if called from inside vs. outside the parsing loop.

• Sets a “temporary head” to start reading the dialogue data.

• Gets the current dialogue’s line data3.

At the top of the interpreter loop, it:

• Checks if it’s reached the end of the dialogue file, or if the exit flag was tripped, and if so closes the dialogue and stops the loop.

• Checks if it’s reached the end of a “block”. These are used for conditionals and choices like we saw before, and stored on a stack. If it has reached the end of the current block, it pops it from the stack and sets the temp head to the appropriate point outside the block.

• If inside one or more blocks, the block “indentations” (either tabs or quote arrows ‘>’) are removed from the line it’s parsing.

• Labels are never rendered into dialogue, so if it hits a label, it sets some flags, then skips over it.

Next in the loop, it checks for choice blocks. If found, it:

• Skips over interjection choice blocks the player chose to advance past.

• Begins scanning the block with another temporary “head”. The entire block is read and the information is used to determine what choices are available in the choice menu, and where the block should end.

  • Some choices will be conditionally disabled, those expressions are parsed here and used to filter those choices out. Since the start of the next choice option is used to determine when the last choice’s block ends, it always adds every choice to the choice array, and disabled ones are just hidden in the menu.

  • Some choices are “labelled”. They will jump immediately to a label when selected, but get disabled if that label has already been seen.

• Pushes the information about the choice block to the block stack.

After that, a quick check for label jump expressions. We don’t jump right away, instead waiting for the whole line to be parsed.

Next up, conditional blocks. These are similar to choice blocks, but without a need to wait for player input to pick a branch:

• Again, the whole block is first scanned to get every conditional expression in the “if-else” chain and determine where it ends.

• The conditionals are then checked in order. If any return true, the interpreter enters the block there and stops checking, otherwise the whole block is skipped over.

Next up, it parses all expressions constrained to a single line. This is stuff like styling, setting portraits, calling commands, etc. We’ll get to this later.

Next, it jumps to any label that was set during parsing, then continues from there. Jumps must always be to somewhere outside of a block, and so the block stack can be safely cleared here.

Before the last step, it checks if the parsed line is empty. If so, it continues on interpreting until it finds content to display, unless we’re in “auto-advance” mode (i.e. when the player cannot skip or advance dialogue manually).

Finally, it’s ready to display the content it parsed. For the last few things, it:

• Sets the “displayed” dialogue string to the parsed line.

• Dialogue uses a “typewriter count” variable to create the scrolling effect which gradually reveals the newly displayed line. If the dialogue was set to pause on the first character (“rune”) of the displayed string, sets the count to 0, which will cause the dialogue box not to be displayed for the duration of the pause.

• Updates the actual dialogue head to the temporary head’s value.

That would normally be the end of it, but the proc needs to do one last check. In order to display the prompt for interjection choices, it reads ahead a little to check if one exists, and constructs the menu.

Parsing Dialogue Lines

Rather than using the string data directly, dialogue lines get parsed into “dialogue strings”, which contain per-character metadata for styling and pauses between characters:

The line parsing proc takes an annotated dialogue line string, and constructs a parsed DialogueString. It can be used outside the main interpreter loop with any string, making it a useful tool in general. Let’s break it down:

First up, it makes the output array and clones in the input line in order to be able to mutate it. It’ll handle “non-positional” expressions, i.e. ones whose position inside the string doesn’t matter, before anything else.

So, portrait and name tag expressions first. This simply extracts the sprite name and sets it (or sets the sprite to nothing if a blank expression is given. For name tags, the string is just extracted and set. Once these expressions are parsed, they are removed from the clone of the line that was made earlier.

Next, it gets into the positional expression loop. This goes rune-by-rune and appends them to the final parsed output. It starts by getting the rune at the current index. The first check is simply for a backslash \, which causes the parser to treat the rune after it as a literal, appending it straight-up and not doing any parsing with it.

Next, since these can do anything, command parsing. These are the special custom commands we saw earlier, as well as stuff like setting flags. We’ll get to the exact way expression parsing works later.

The result of the command’s expression is inserted into the parsed line in place of the command, and the loop continues.

Next, some simple parsing for bold, italic, and color expressions. Values are set that all runes which get added to the output from now on read from. For expressions like this that don’t insert anything into dialogue, the parser can simply move the index to skip over them before continuing the loop.

Next up, cadence. To make the dialogue scroll feel more like natural speech, the parser inserts pauses at spaces after certain sets of characters like commas or periods.

At the end of the loop, the current rune is appended to the output string, and the index is advanced by one.

Finally, once the parsing loop is done, any trailing spaces are trimmed and the output is returned.

Expression Parsing

This is the most “programming language”-like aspect of the markup language, since it’s used for simple conditionals and setting variables. It might seem quite rudimentary to some; it’s handled entirely through simple recursive calls and I’m not doing anything “proper” like constructing an AST. Partly this was to save me the trouble of learning and implementing that stuff, and partly this was a deliberate design decision to keep expressions from being able to get too complicated. If I need to express anything much more complicated than “add one to this flag” or “check if flag x is true and flag y is not true” then I should probably be writing that code in-engine and calling a custom command.

Once again, let’s break it down:

The parser starts by:

• Removing whitespace.

• Returning early for empty expressions.

• Checking whether it should tell the interpreter receiving the result to insert it into the dialogue.

• Checking whether the expression is only a string literal, in which case it just returns the contents.

Next, if the expression is a valid float, the parser returns it as-is.

Next, if it’s not doing a conditional check, the parser checks for an assignment expression. If found, both operands are parsed individually, the result is calculated, and the new result is assigned.

I use my global flag system for variables here. It’s really just a map of flag names to string values, though if the parser can interpret these string values as numbers it will gladly do math with them here.

Similarly, after the assignments, the parser handles comparison expressions. For boolean values, it uses the strings “0” and “1”, which get converted to floating point values for comparisons like this.

Next, if the expression starts with ‘!’, the parser is set to invert the final output.

Next, command parsing. The command name and arguments are split by commas.

Finally, anything else. At this point, the expression should just be some arbitrary non-numeric string:

• If inside a conditional, the parser will check whether a flag with that name exists, and if so return its value. If the flag doesn’t exist, the expression will be treated the same as if it did and was set to false.

• If not inside a conditional (and not trying to insert the value of a flag into dialogue), the flag with the same name as the expression will be set to true. This allows me to simply write e.g. `myExampleFlag` in order to set a flag.

Conclusion

Wow! Thanks for getting through the whole thing! Once again, you can check out the latest backer update to vote on the next post’s topic! See you next devlog!

Subscribe now

Click here to check it out!

The first few days are going to be crucial. If you want to help the project succeed, here are some things you can do (besides backing, of course!) which would be a huge help to us:

• Wishlist, follow, and leave a review on the demo’s steam page!

• Share the trailer with your friends!
  
  Oh, and:

  Subscribe now

I’ve learned a lot in setting this campaign up and will probably put out an interesting post-mortem when all’s said and done. For now though, I have many things to attend to!

Huge thanks to everyone’s support in the last few weeks, especially hasu, who clutched up and did some great work producing most of our campaign assets.

Let’s all work together to make this project a big success!

It's pay what you want, Bandcamp only lets us offer 200 free downloads per month though so if you do want to download it, get it while it's hot!

We'll also be uploading it to Youtube over the next week and a half in anticipation of the Kickstarter! Check out the first track here:

Thanks again to dante (https://soundcirclet.net) for mastering everything and putting it all together (and, of course, for composing all the music!) It all came out better than I ever could’ve asked for and I’m looking forward to seeing what everyone has to say about it standalone!

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>