My First Experience Entering a Game Jam

Last month I announced that I might run a Game Engine Jam, but I realized that I've never even participated in a Game Jam. To rectify this situation I entered the 2026 Dungeon Crawler Game Jam, but I did it in the way that I wanted to run the Game Engine Jam. This is the story of how I did it, and what I learned in the process.

TLDR

If you don't have time to read then here's the quick points:

1. My game was a De-make set in the world of Kenshi.
2. The game jam was fun and helped me find a lot of things to improve.
3. I used the core of another game I'm working as a Game Engine for this game.
4. I did all of the art and code live on stream and kept all of the videos.
5. I made a challenge of having to use Paint.NET for all of the art.
6. The submission process on itch.io was really good, and I may host my own game jam there too. They have great infrastructure.
7. The only problem I had was itch.io had me make a project for the game jam, but didn't automatically submit that project. I almost missed the deadline because of this.

The Game Jam Rules

Here's a copy of the rules from the Game Jam's page:

• The game must have first-person exploration at all times. Exceptions are point to point overworld map movement (fast travel), combat screens, cut scenes, town screen, inventory screen other relevant screens.
• The game must have explorable locations. It doesn't have to be a dungeon in the traditional sense. It can be urban environments, outdoors, spaceship interiors, planetary surfaces etc. (depending on the jam theme). Whichever environment the game has it must be viewed and explored in first-person.
• The game must feature step movement on a square grid (no hexagons, octagons, etc.). Smooth transitions between grid squares are allowed. Half-steps or dividing a logical grid square into smaller squares are NOT accepted. The size of a square should equal the size of the wall segments it is connected to. Consider a grid square as a cube with a ground, four walls, and a ceiling. If there are visible enemies, they must also move on the same grid as the player.
• The game must feature 90-degree turns in four cardinal directions. Smooth transitions between 90-degree angles are allowed. Turning must be invoked by keyboard (or gamepad) control. Mouse-look is permitted as a temporary way to look around, but it should snap to 90 degrees when not in use. Games that allow 90-degree turns up and down are also acceptable.
• The game must have a player controlled character (or party of characters), or the abstraction of a character or persona.
• The game must at the very least have some basic stats. (Minimum a single health/power bar)
• The game must have combat or a similar mechanic for determining outcome of certain situations, enemy encounters and events.
• The game must have a win condition.
• The game must have a death/perish/fail condition, or some other end-of-game mechanic. Roguelite mechanics where you restart game upon death but retain some progress is allowed.
• The game must have at least one way to affect character stat(s). Examples are resting, potions, items with bonuses, food, water, powerups etc.
• The game must include an interpretation of the (to-be-announced) theme.

The theme for the jam was any of these:

• Cleaning up the hero's mess
• Dragons
• Retrofuturism
• Elemental Rock Paper Scissors (link)

I decided to do a De-Make (retro) set in the world of Kenshi (a retro-future game world) to go with the Retrofuturism theme.

My Game Idea

I've wanted to do a De-make for a while, so I decided to use this jam to do it. A De-make is where you take an existing game and create a retro version of it, or a game set in it but in a retro style. I decided to base my game on Kenshi, because Kenshi is awesome and you should play it. However, since Kenshi is not a dungeon crawler I had to create a new concept that's simply set in Kenshi's world with a retro style.

I came up with the idea that you play a Thrall (a robot) who works for Agriculture Bot in Ashland Dome I. There's random wildlife and enemies that have snuck into the lower depths of Dome I and you have to go down there, kill everything, and close the door on the 6th floor. To make things worse the security bots are malfunctioning so you'll have to kill them too.

Extracting my Game Engine

There's a subtle tension between effectiveness and reusability in programming. Effectiveness is how much you can get done in a current project, while reusability is how much you can get done in future projects. The tension comes from decisions about how much effort you spend on things for future projects vs. the current project. One bad idea is to yak shave endlessly making a framework for future projects you can't possibly predict. These always end up insanely over engineered--and ironically poorly designed--which makes them not very good frameworks. The other end of the bad idea spectrum is never thinking of the future to the point that every project is a totally reinvented one-off from scratch. These kinds of projects eventually collapse under the overwhelming weight of tech debt.

The trick--which mostly only comes with experience--is to have a "framework mindset" while you create a real tangible thing. You create code for a real project, but you design things in that project so they're easy to configure, install, test, and expand. In theory, if you make it easy to do all these things then that's basically a "framework of one."

However, one single project with a framework style isn't very useful. What you have to do is complete the project, then on the next project try to reuse code from the previous project. This gives you a first glimpse at an actual framework. You then continue this process creating new projects is so easy that you now have a framework for your future projects.

I'm not really trying to make a framework for my game, but I got the idea that I might find things to improve if I try to create a framework from it for the game jam. To do this I simply grabbed my game's code, ripped out everything specific to it, created some terrible placeholder art, and refined it a bit.

Using My Engine for the Jam

My "engine" mostly consisted of .json files that configured common things in a Dungeon Crawler:

• Textures -- This would be things like wall textures.
• Sprites -- These are the 1-3 frame sprites for enemies or animated fixtures.
• Animations -- Data that describes how sprites are animated.
• Map Generation -- This is a little "scripting language" I made to describe how to generate random dungeons.
• Enemies -- Descriptions of enemies like their damage, HP, and how their AI works like if they run away at low health.
• Player Character -- Same thing just for the player.
• Sounds -- Sounds to play with actions and events.
• Enemy AI -- A description of an anemies AI using a Goal Oriented Action Planning library I wrote.
• Devices -- How things like chests, traps, lootable containers, etc. work. Mostly just the thing that goes down a level and lootable bodies for now.
• Icons -- Little icons for the UI to represent things like items picked up.
• Items -- Items you can pick up.

In addition to this there were a few components written in C++:

• Raycaster -- This is an old school style Wolfenstein 3D renderer responsible for rendering the walls and sprites.
• DinkyECS -- An Entity-Component-System for managing the state in the world.
• lel-guecs -- A GUI library I wrote for games that combines a layout engine (LEL) with a ECS. You make the layout, then load components into the ECS so they get rendered in the layout.
• Pathing and Collision -- Very simple Dijkstra algorithm and a very simple spatial map. You don't need more than that in a turn based grid crawler.

With this I had to create the following for the Jam:

• All new art to match the theme and story. The previous game is more "Steam Punk" while the new theme is "Sci-Fi Sword Punk." If you've ever played Kenshi you know what that means.
• All new screens for the start, story intro, next level, win and death scene. Read below because this took up the majority of the time weirdly.
• All new combat mechanics for the enemies and player. This game needs a lot of new combat mechanics like individual body part damage, death only when certain parts take damage to 0, and weapons having randomized damage over those parts.
• New items for healing and fighting. I kept it simple at a single repair kit you find and other rusty swords that are just as terrible as your starting weapon.
• Lots of little tweaks to the original game engine, like keep enemies from going through doors, changing how the systems are configured, etc.
• All new UIs for this new design. About the only thing I kept was the Raycasting component.
• A simple learn by doing system where each successful hit given or take will increase an experience stat, and when that stat hits a threshold you "level up" that stat.

What Worked

I was surprised at how quickly I had a working basic dungeon crawler going. All I mostly did was crank out some art with Paint.NET and configured it in the .json files. A few tweaks here and there for the enemies and player and I had a first version of the game that let me walk around and beat up Security Spiders.

Next was crafting the Kenshi style limb damage combat, and that was also fairly easy. The lel-guecs GUI I created made it incredibly easy to modify the basic status component to show individual limbs. The DinkyECS system made it easy to record player and enemy stats immediately. The animation system made it easy to give everything animations and sound. Overall incredibly easy and mostly worked as planned.

It was also really easy to distribute. My build system makes a totally static executable that's 13MB when compiled for release. All I needed was to pack that into a .zip along with the assets directory and anyone could play it. I even made builds for Linux, although that ended up only working on specific Linux systems due to weird errors with libFLAC of all things.

What Did Not Work

Despite the ease of development there was one massive pain point that I'm now solving. Let's take a look at a little table of the videos from the game jam and see if you can spot the problem:

• Ep01 -- Making a Kenshi De-make
• Ep02 -- The Start
• Ep03 -- Adding Combat
• Ep04 -- UI and Stats
• Ep05 -- Kenshi Style Damage and Combat Animations
• Ep06 -- More Damage and Combat
• Ep07 -- Game Levels and Loop
• Ep08 -- Start and End Graphics
• Ep09 -- More Start and End Screens
• Ep10 -- Even More Game Loop Work (Screens Again)
• Ep11 -- Make the Screens Work
• Ep12 -- Intro Storyboard
• Ep13 -- The Full Game Loop (This was Screens...Again)
• Ep14 -- Learn by Doing
• Ep15 -- Refinement and Art P1 -- Screens Again
• Ep16 -- Refinement and Art P2 -- Screens...AGAIN!
• Ep17 -- 2 Hours to Go

Keep in mind I stream twice a day so this isn't 17 days of videos, but 2x day with a few that I did 3/day.

Can you see the problem astute reader? What's this "Screens" thing you keep seeing for NINE DIFFERENT VIDEOS? Why, that is nothing more than a single full screen image and 2 buttons. Yes, I'm not kidding. The vast majority of work on the game jam was nothing more than making it so my game could just transition between 4 total screens. Each of these screens was nothing more than a stupid image and a couple buttons the user could click.

To put this into perspective, I had a fully working 2.5D dungeon crawler game with invidivdual limb damage, learn by doing, lootable items, healing, death, multiple enemies, animations, and semi-random world generation in the same time it took me to show 4 graphics and 8 buttons.

That's--to put it bluntly--fucking stupid. There's no way it should take that long to make some graphics with buttons. It definitely shouldn't take that long to simply show a few temporary UIs either. I took this to be a personal challenge to fix before I get back to working on my original game. Mostly because it pisses me off this was so unreasonbly difficult as to be absurd, but also because my original game is going to need the exact same features soon, so might as well fix it in Under the Ashland Dome where the problem already exists.

The Submission Process

The submissions for the game jam were done on itch.io at the game jam's main page. The submission process was actually really good and I will probably use itch.io for my own jam if I run one. The only issue I had was this:

1. You go to the DCJam 2026 page and click to submit. Totally reasonable.
2. If you don't have a project already you are then sent to the project creation screen. Totally reasonable.
3. After you've finished creating your project, you are sent back to the game jam...but you are not actually submitted.

I almost missed the submission window because of this bug, so my recommendation is to make your project first and then submit it. Don't follow their process.

I should also say, I am not positive this is a bug. When I went back to the DCJAM2026 page it said I didn't submit, but that might be an update thing where my submission was made but the DCJAM2026 page didn't reflect it. The only clue that this was actually not submitted is it let me submit it. I'm assuming if I had already done as submission it would stop me from doing it twice.

Post-Jam: What I Improved

After the game jam I started working on improving my GUI library to make it quicker to produce stacks of UIs to show. I created a ScreenStack class that can take any number of UIs and switch to them as needed, as well as send events to the currently visible screen. This cuts down on a significant amount of code in the main state machine.

I improved how the Meter component works since it had bugs during development. I made it possible to have horizontal and vertical meters, change the foreground and background rectangles, and gave it a render/update cycle to fix the games.

There was also a problem on macOS because clang has decided that nobody is allowed to use codecvt even though it still worked. I had to go get the utfcpp library by nemtrif which seems to work well everywhere. It's still ridiculous that the clang project has time to force depricate codecvt but they haven't fixed a significant issue with source_location for four damn years.

Someone claimed that the clang project is overworked. Bullshit. They just don't utilize their time well by wasting time on things that help nobody while ignoring important things. I also don't really have sympathy for a bunch of programmers with cushy millionaire jobs at Apple. Because of them I have to swap out a unicode library and can't use Clang for my own development because I can't get good line numbers for logging. Idiots.

Lessons Learned

Overall this proved the entire point of doing the game jam: If my game's design was solid I should be able to pull out an engine and make another game. It did prove that my design is working and also that significant flaw in the GUI library that made me wase 4 whole days on four screens. I highly recommend that if you're working on a game try doing this. Give yourself a week and try to reuse your code. It'll improve your game, and you may find the new game is a better idea and has a cleaner design.

More from Learn Code the Hard Way