Programming Hamsterwell

TL;DR: Github, Github actions, game jam template, ..., profit!

I’m delighted by the positive response to Hamsterwell! Thank you!!

I’m going to try to answer the question best expressed, in my opinion, by @ScaryPastry:

“Holy crap, you did this in a week!?”

Hamsterwell was created by an eight-person team in 9 days.

• 1x programmer
• 1x game+level designer and project coordinator
• 1x composer/sound designer
• 1x UI/UX designer
• 4x artists

Many people on the team were editing the project inside Godot and committing their changes to source control. I don’t want to evangelize this approach as much as acknowledge we could not have completed as much as we did without a quick and easy way to combine everyone’s work. There are probably different ways to do that, but I’m biased by my career experience as a developer. So it was Github and Github actions.

I helped anyone in need to get setup with access to the game’s private repo, installing and using Github desktop locally, and the basics of using source control (pull / change / commit / pull / push). I have plenty of practice and confidence handling git problems from my career and while we hit issues during the jam, they were only minor inconveniences.

Not everyone was comfortable committing directly to source control, or committing to the main branch, so for those cases another team member would handle it. Getting assets into the game was a shared responsibility, not the job of one person who might (ahem, will absolutely) become a bottleneck. Speaking from experience in and out of game jams, it’s not a good feeling to be the bottleneck.

Here are tables of the commits-per-day and commits-by-author for the repo.

Date        Commits           
----------  -------
2024-06-14    1
2024-06-15    3                 Role            Commits
2024-06-16    4                 --------------  -------
2024-06-17    6                 programmer        122
2024-06-18    7                 level designer    104
2024-06-19    19                artists            36
2024-06-20    48                sound designer     19
2024-06-21    54                ui/ux               4
2024-06-22    92
2024-06-23    120

Some of the increasing number of commits per day was the team learning that smaller commits create fewer conflicts. We did “go faster” as everyone developed muscle-memory for the process. Tilemaps were the biggest headache and I think the 4.3 TileMapLayer changes are a very good thing from the source control perspective.

Playtesting was also shared and ongoing from the moment we had enough gameplay to test. Github actions were used to export and upload the game to Itch.io regularly. There are lots of examples out there for how to do this, including my own at godot-4-ci. The game page was created as restricted and the team added as contributors from day one. Anyone in the team could hit the page and play the current “build” of the game.

In past jams I’ve used starter templates and I strongly recommend them once you’re looking for a certain level of polish. Leave settings and credits and the wrapper of the game to a template so you can focus on the gameplay. Of course, I just had to create my own template. I don’t recommend it over others but check it out if you want at godot-4-jam-template – and use it if you want, but caveat emptor.

If you read this far, you rock! What are your thoughts about source control or this workflow? How did your team handle assembling code and assets into a working game? What’s your your worst (best) Github horror story?