…on time, every time.

I’ve been game jamming for many years, from physical jams like Global Game Jam and online ones like Ludum Dare, as a solo jammer and in teams, using lots of different engines and tools. Some games did really well, others not so much, but most were fun, and every one was a useful learning experience.

And I’d like to share some wisdom with you!

One of the toughest challenges in game jams is how to finish on time. Everyone tells you the same advice - keep your scope small, have a plan or schedule, be flexible, use the tools you know best, take breaks and sleep - and after a few jams this advice quickly becomes experience… but somehow we keep having trouble finishing on time! Making something in such a short timeframe is really tough.

But here’s the one trick that has worked really well for me: make something you’ve already made before.

I know; that sounds wrong! Aren’t you supposed to make something new and innovative! What about the jam theme, are you just going to ignore that? Hear me out.

Have you ever lost hours of work before - maybe you were writing an essay but your computer died, or writing some code and accidentally reverted the work? Oh no! you think; this is going to take me forever to redo!!!

But instead of hours, it takes only 10 minutes to restore.

Sure, it was tedious and painful, but it was finished before you knew it. How was it so easy?

Because the reason it took you hours the first time, is because you didn’t know what you were doing. It was completely new to you. The hard part, in any creative endeavour like writing code, creating art, composing music, was figuring out what to do in the first place. The execution part is quite simple. Once you’ve done it before, it’s fresh in your mind.

So here’s my advice for game jams: make something you’ve made before, finish it quickly, and then gradually change and polish it into your ideal jam game. The first part is easy, because you’ve done it before - that’s the point. You’ll have a finished game very early in the jam, and this is a big advantage - no rushing to get integration and builds working last-minute, no stressing out over menus or stitching game screens together. Then you iteratively improve the game - make a change, test it out, fix it, come up with new ideas - all the while having a working, finished game. It’s low stress, and very effective.

Example

Suppose your idea is a platformer with a fun gimmick. But you’ve never made platformers before; you’re not even sure how to implement your gimmick! But you have made top-down shooters before. So just start with that! Build a top-down game, with a player running around the screen. Add walls and collision, rudimentary animation. Add some basic objectives, like collecting things, progressing to the next level, maybe a hazard so the player can die and go to a game over screen. That’s all there is for a basic, finished game, and it probably only took you half a day, because you’ve done it all before.

At this point things could go one of three ways:

• You gradually implement your original idea into the game, piece by piece. No problem; you always have a working game, and you have a steady stream of progress showing your vision taking shape

  

• You notice hey, maybe the top-down game wasn’t so bad, or maybe you have an even better idea at this point, and completely pivot into another game. That’s cool too! It’s all about the process of finding the fun

  

• Or most likely, you do a combination of the two. As you build out your idea, you find things that work, things that don’t, and adjust accordingly

  

How to Execute

To pull this off, you will need your basics covered. This will depend on your approach:

• If you’re quite new to making games, or don’t have a good game to work off, find a good project template or tutorial, one that is easy to follow, easy to extend, and has all the features of a complete game. Despite what I’ve implied, I also think it’s great to try new things in a game jam! But just be aware of the added danger of getting stuck and not knowing how to proceed in a new engine or tool. It’s therefore very important to pick the right tool and project template to work off. Stick to mature products and popular templates/tutorials, do your research to find that it fits your needs.

  

  There’s no shame in taking a game template, then changing it until it’s an unrecognisable frankenstein-game, and it works well! Personally my best games haven’t been made this way, because it’s much more productive to work with tools you know well, but when I do use this approach, it’s usually been fun and an excellent way to learn something new.

• If you’re making a game from scratch, but based off a previous game you’ve made, know your tools like the back of your hand. Make sure you’re practiced in the game engine, programming language, or whatever tools you used to make that game, so you can re-make it without friction. Do some refresher exercises to see if you still remember all the tricks. It might even make sense to avoid using the latest version of the tools, just in case something broke or doesn’t work the same way as before, but if you do, try it out first.

  

  I’ve been bitten by this on quite a few occasions. After not using a game engine for a year, I come back to it thinking everything is the same, but there’s always one or two things that aren’t. Debugging this, Googling for answers, cost valuable minutes and hours that I could ill afford in a game jam, which threw my entire schedule into chaos. I’ve since learned that updating versions is a luxury you cannot afford for a jam. Leave it for before, or after the jam.

• Also, keep making games! Make different games, different genres, using different techniques! Not only will you get better at making them, but you build up your repository of knowledge, so you have more games to re-make quickly.

  

  The game jams where I learned the most were ones where I tried to make a game in a different genre. I was at my most creative because I had less experience to draw from, so even though I tried to make things that I thought would be fun, I was unconsciously doing things differently enough to create surprising results. And sometimes this works out really well! Either way, you build your repertoire of game making tricks, and knowledge of what works and what doesn’t.

And that’s my two cents. I wish you good luck in your next game jamming adventure!

I’ve been working on C-Dogs SDL lately, and one thing that often bothered me about that game is that its default random map generator provides an uneven experience. It’s exciting at the start when everything’s unexplored and there are many corridors and rooms to visit, but in the late stage when you are hunting for keys and objectives, backtracking all over the map, it can be quite tedious.

C-Dogs’s map generator is quite configurable and produces a wide variety of maps, but at its core it’s pretty simple:

• Start with an open area
• Randomly place rooms around the place
• Randomly lock some rooms, and place keys in the rooms

The lock-and-key system is in series: the yellow key is in an unlocked room, the green key is in a room locked with the yellow key, the blue key is in a room locked with the green key and so on. Here’s a tree to illustrate this simple structure:

Because the keys (and objectives) could be in any one of several randomly placed rooms, you may need to criss-cross the map many times to collect them all. That’s a lot of backtracking! Another issue is the structure - rooms are isolated from each other, all leading outside. This gives all maps a similar feel. What if there were a map generator that could:

• Provide a more interesting structure
• Feel more like an indoors experience, like a building interior or dungeon?

I was first inspired by sauer2, maker of many C-Dogs SDL custom campaigns, which often take place indoors. These have cool features like:

• Corridors linking many rooms
• Rooms connected directly to each other
• Locks separating entire sections of the map at a time
• Branching pathways
• Minimal required backtracking

Searching online, I came across a neat technique that uses binary space partitioning to generate a building interior. The algorithm recursively splits the area in half, placing a corridor at the split, and continues splitting (while alternating horizontal/vertical splits). Areas left unsplit are then filled with rooms. It’s a simple yet flexible technique.

As the structure of the map is a deeper tree, by finding a critical path that starts and ends at leaf nodes but passes through the root, we can get a fairly long main path, with shorter branches along the way. Here’s what that looks like, in my initial adaptation:

Here’s where lock-and-key systems come in. Many games, including turn-based RPGs and action games, employ a lock and key puzzle system to get the player to explore and provide a sense of progress. Games like The Legend of Zelda do this particularly well - an analysis of the dungeons shows that most dungeons are quite linear, with few and shallow side branches, but the clever placement of locks and keys makes the dungeons feel more complex. The key to this is the placement of locks before the key that opens them, which provides foreshadowing.

It was quite easy to adapt this to the BSP map. As the critical path starts at a leaf node, goes up through parent nodes to the root, then down through child nodes to another leaf node, we can place locks in the intermediate parent nodes, and place keys somewhere in the sibling hierarchy.

Not only do players encounter the locks before keys, because of needing to sidetrack to find the key and then return to the lock, but the map is also made to feel bigger and more complex than otherwise.

Finishing touches like removed rooms, locked rooms where hidden objectives or powerups are placed, are then added.

It’s a simple and effective technique!

For more reading about this kind of technique, also visit Mechanic #004 - Environment Tree

I’ve done a lot of game jams and have used many engines and frameworks in these jams. They all have pros and cons, but lately, I’ve been using fantasy consoles as my platform of choice, and I think you should too - they are fantastic for game jams.

What are fantasy consoles? In short, they are virtual consoles that mimic retro computers and their limitations, but also provide a complete game development environment. Within the same application, you can draw simple sprites, compose chiptune music and sound effects, and write code using a limited API. Its severe limitations are also its appeal; it’s not only a piece of cake to pick up and learn, but the limitations encourage creativity. PICO-8 is the most popular, but there are many others to choose from.

One of the most important factors when choosing a platform for jams is development speed. You want to be able to put something playable together as quickly as possible, as time is the scarce resource. Here the popular engines do very well; Unity, for example, has a lot of functionality built-in, or easily accessed via its asset store, so you can quickly piece something rough together.

Fantasy consoles represent an alternate approach - with limitations and fewer tools at your disposal, there is less time wasted in choosing how to make your game and more time on focusing on gameplay and making something fun. It’s easy and quick to put together something playable, so you can start iterating and polishing on top of a solid base.

Here I’ll show you my weapon-of-choice: TIC-80. It’s very similar to other popular fantasy consoles, so the experience is transferrable. Within the same tool, you can:

• Code in Lua*, against a simple sprite-and-tile based 2D API
• Draw sprites and tiles using a 16-colour palette
• Create chiptune sound effects and music with up to 4 channels in a simple tracker
• Edit tilemaps
• Export to HTML

Coding

TIC-80 primarily uses Lua for coding, but you get other language choices - Moonscript, JavaScript, Wren and Fennel. I like Moonscript the best because it’s like Lua without the bad parts. Its class syntax is excellent, something that sucks in Lua.

As a fantasy console, the editor window is tiny. While charming, I highly recommend getting the pro version for $5, which lets you code using any text editor.

This way, the entire game fits in a single text file, even graphics and sound, which is great for version control and collaboration between your artists and musicians. No more headaches from merging everyone’s work - it’s just lines of code in a file!

Graphics

TIC-80 has a mainly sprite-based 2D API, with built-in sprite editor and tilemap editor. They’re nothing to write home about, and get the job done.

Worth mentioning are the shape drawing functions available. In addition to the expected lines, rectangles and circles, you can also draw textured triangles, and which some enterprising folks have made 3D engines out of this. Not that you should do this for your jams, but they’re nifty tools to have. Check out the API for more details.

Sound & Music

Sound and music work differently in TIC-80 than you might be used to, but in a way that makes it quite fun to use. In essence, you build these up in layers:

• Create waveforms - you get 16 of these. You get the standard square, triangle, sawtooth and noise waves, but you can also draw your own, something which few other tools let you do.

  

• Edit envelopes - these are the sound effects, defined as four parameters: waveform, volume, arpeggio, and pitch. It’s a bit hard to explain, but here are some examples of things you can do:
  • Create a plucked-instrument with a sharp attack, by starting with a noise wave
  • Fade in or out using the volume envelope
  • Create a melodic chime with the arpeggio envelope
  • Create a vibrato effect with the pitch envelope

  

• Edit music. Here the editor is a more conventional tracker - you use instruments (which are the sound effects created earlier) and lay notes on patterns. Patterns are per-channel and can be reused, which is handy because you only get 60 of them.

  

I’ve found it handy to keep a notebook of all the sound effects and pattern numbers used, as this is perhaps the clunkiest part of TIC-80.

Exporting

Exporting is probably the best part of TIC-80 for jams - how easy it is to export games from it. You can:

• Save the game as a .tic cartridge, loadable by anyone running TIC-80
• Export to a single .html file using export html
• Export to an executable using export native
• Take a screenshot using F8
• Record a gif using F9

So preparing a jam submission is a cinch. What might take an hour messing around with screen recorders, exporters and so on, take only minutes with TIC-80. Take screenshots and gifs early and often and tweet/blog your progress!

Try it out!

That’s it! Fantasy consoles are so simple to learn, use, and are perfect for jams. Here are some games I’ve made with TIC-80:

• Dunkman
• Grow Quickly

And you can even take a look at the source code and how the game was put together - these fantasy consoles are editor-and-player all-in-one.

Try it out and happy jamming!