The Game Jam Starts Two Weeks Early

I have five consecutive Global Game Jams in version control, 2014 through 2018, and the commit dates say the same thing five times.

The weekend itself runs 60 to 80 commits a day. The two weeks before it run about one commit a day, and none of them are gameplay.

The Prep Is Never the Game

Here is the whole of the 2018 preparation, ten days out, three commits:

2018-01-16  Add ggj 2018 project
2018-01-16  Add engine extern
2018-01-16  Fix ggj2018

And 2016, fifteen days out, where the commit messages name it directly:

2016-01-14  [ggj2016] Add project
2016-01-14  [ggj2016] Add engine extern
2016-01-14  [ggj2016] Prep
2016-01-16  [ggj2016] Add post build script to release
2016-01-16  [ggj2016] Install Script
2016-01-16  [ggj2016] Fix ios
2016-01-17  [ggj2016] Make project use refrenced dir for engine

A repository exists. The engine is mounted into it. The project compiles and runs on the targets. That's it. Nothing in those lists is a mechanic, a level, or an idea about what the game is, because the theme isn't announced until the jam opens and none of this depends on knowing it.

2017 goes further and writes the list down. A todo.txt lands in the first prep commit, fifteen days out, and the asterisks are the completed items:

*get code backup
*find new testbed code
*fix code for vs2015
*make room
integrate fpv controller into engine
*integrate json entities into engine
*load json scene that loads a bsct and places entities on locators
*have entities be interactable

"Fix code for vs2015" is the entire argument in one line. Discovering that the project doesn't build under the current toolchain is a two-hour problem. Discovering it at hour one of a jam is a two-hour problem plus five idle people.

2014 Is the Control Group

The first jam has no preparation at all. Its first commit is ggj 2014 initial import at 21:58 on the opening night, and the reason is in the file tree: 2014 is a Unity project. Thirty-five C# scripts, a space real-time strategy game with planets, ships and three unit classes a side.

With Unity there is nothing to prepare. The editor is installed, the empty project takes a minute, and the build works because somebody else maintains it.

From 2015 onward every jam runs on Carbon Monoxide, the engine I wrote. That single decision is what created the prep phase. An engine I own has no empty project, no maintained build, and no guarantee that last year's toolchain still compiles it. The two weeks are the bill for using my own tools, and the rest of these repositories are five years of getting that bill down.

The Prep Is for Other People

The jam weekends have between three and seven committers.

That number is what the preparation is actually sized against. One person can take a broken build at hour one and fix it. Seven people cannot, because six of them have nothing to do while it happens, and a jam has no slack to spend on six idle people.

The first commit of the 2018 jam weekend, at 08:06 on the Friday, is this:

Remove linking via pragma and instead make Debug/Release configs of the engine lib output to their respective configuration subdir, and the Debug/Release configs of the game link against the correct one, so they're not stomping each other.

Two developers on different configurations were overwriting each other's engine binaries. That's a problem which does not exist when one person works alone, and it got found and fixed before anyone wrote a line of the game.

The Installer Moved Backwards Through the Years

In 2015 the NSIS installer script is committed on 2015-01-28, three days after the jam ended. In 2016 it is committed on 2016-01-14, fifteen days before the jam started, in the same batch as the project and the engine. Same for 2017 and 2018, both times in the first prep commit of the year.

The post-build script follows it. From 2016 onward the packaging path exists before there is anything to package.

That movement repeats across these repositories. Something hurt once at the end of a jam, when it is most expensive and least recoverable, and the following year it moved to the front where it costs nothing.

Each Year Starts From the Last One

The prep shrank from fifteen days of engine work to three commits, and the reason isn't discipline. It is that each jam inherits the previous one.

By 2018 the game project is the 2017 game project. Forty-seven of its files carry 2017 names, fourteen of them byte for byte identical, and the additions are AStar, Host, GameOverScreen, and IntroScreen. The 2017 project has a 2016entities directory in it for the same reason.

Luchador, Turret, Box, and BoxGrid appear in both the 2017 and 2018 games, which were different games. The classes survived because they described what a thing was rather than what it meant, and a wrestler that walks a grid is reusable in a way that a specific wrestler in a specific game is not.

So 2018's three commits of preparation are real, and they are also a year late. The preparation happened in 2017, and 2018 collected it.

What the Weekend Looks Like

The 2018 jam, from the first build fix to the small hours of the second night:

01-26 08:06  Remove linking via pragma ... so they're not stomping each other.
01-26 09:57  Add art folder
01-26 10:07  Strip some stuff out and make a test scene
01-26 10:09  Whitebox Environment
01-26 10:10  AStar, totes works, first try ;P
01-26 10:15  [XInput] Hooked up controller connect/disconnect.
01-26 11:12  First pass at host and infector entities.
01-26 11:55  AStar debug visualisation. Fixed AStar so it *really* works :)
01-26 13:03  Most basic dude possible
01-27 00:00  Merged Jim's host work into Matt's. Hosts are now driven by database.
01-27 01:02  Infections now fade out over time. Hosts can die, turning black and stop moving.
01-27 01:28  Hosts are pathfinding around the walls.
01-27 03:15  Hosts now walk erratically when frenzied, or very ill.
01-27 03:24  Limited number of hosts at once. Displayed scores on HUD.

Pathfinding at 10:10 on the first morning. A playable loop with illness, death and scoring by three in the morning on the second night. The engine, the build and the packaging never appear in that list, because they were finished ten days earlier.

Note the two AStar commits. The first says it worked first try, the second, an hour and forty-five minutes later, says it now really works. That is what jam code is, and it is fine. The value of a jam is finding out what is fun, and the way to find that out is to get something running and look at it.

The Tail Is Uneven

Work does not stop cleanly at the end of a jam, and it does not continue reliably either. Within four months of each jam:

Two of the five kept going. 2015 kept going hard, and it is also the year the installer arrived after the jam rather than before it, which is what continuing to work on something looks like from the version control side.

What Transfers

None of it is about game jams.

Do the knowable part early. Everything in those prep commits was knowable weeks in advance. None of it depended on the theme, the idea, or the team. Any deadline has a set of tasks with that property, and doing them under the deadline is a choice to pay more for them.

Preparation scales with people, not hours. The prep here looks disproportionate for a 48-hour project until the committers are counted. A broken build costs one person an hour and costs seven people seven, and the second number is the one that decides whether the deadline is survivable.

Let the last one pay for the next one. The three-commit preparation in 2018 is not a sign of getting better at preparing. It is the 2017 project still being useful. The cheapest way to be ready for the next deadline is to leave the previous one in a state that can be picked up, which mostly means keeping the shapes and throwing away the specifics.