I recently took part in the Game Maker's Tool Kit Jam, which had an amazing total of over 5000 entries! It's been a great weekend and I'm enjoying seeing what everyone else has made.
This post is an overview of my experience developing my entry 'The Runaway Invasion', which you can play in browser here.
I really enjoyed my experience participating in this jam and I learnt a lot. However, with personal development / self-reflection in mind I've taken a critical approach when reviewing my experience.
Having followed Game Maker's Toolkit on YouTube for the last few years I had eagerly been waiting for this years GMTK Jam, especially after having missed last years.
The theme for the jam was 'Out Of Control' and lasted 48 hours, with project submissions locked after the final hour of the jam.
Planning
Knowing I only had 48 hours to make a game I didn't want to spend too long generating ideas. I experimented with a few different concepts such as control schemes that would change to make the player character somewhat 'out of control', and just simply placing the player in a situation that was 'out of control'.
It took roughly an hour and a half to settle on an idea I liked.
The plan was to create an survival shooter set on a runaway train during the midst of an Alien Invasion - a situation completely outside the main character's control. To help better incorporate the theme I wanted to add a number of systems:
Randomly changing playable environment - carriages of the train would switch around, be destroyed, change or have new sections added.
A day/night cycle (with random lengths) to add variety to visibility and challenge.
A range of enemies with different AI's that would spawn on random carriage locations.
A range of weapons with limited ammo so the player couldn't just stick to one they liked.
Environmental obstacles such as tree branches that would hit the player when on top of a carriage.
Execution
Initial development went well and I managed to get most of the basic systems up and running relatively fast. The control system was finished and I had a mock up environment. I even created a system that allowed me to quickly make a variety of guns that had bullets with different physics properties. I kept the default gun preset and planned to add in more weapons once I had finished some enemy AI and a few other game systems.
It was at this point I created a simple procedural environment spawner that made the train look like it was moving (shown in the gif above). This was great, however development significantly slowed down after this stage.
I wasn't fully set on an art style, so after an hour or two of experimenting I decided to play it safe and use a similar style to the one I made for Ludum Dare - a black/grey aesthetic with some grainy post-pro effects. I think this was the right call as it worked well with the games' theme and atmosphere I wanted to portray.
At this stage I should have returned to developing the enemy AI, however I went on a complete tangent and continued to focus on the visuals instead of the core gameplay.
I added unnecessary details such as flickering lights and spent a considerable amount of time working on the day/night system (which at one point even had a rotating moon and sun cycle that got scrapped).
By the time I was happy with how the game looked I began working on other game features, such as creating the foundation system for the randomly changing playable train environment, as well as the spawn system for enemies. The spawn system should have been completed much earlier in the jam and it was around this time that I started noticing and repairing bugs.
The end of the jam was near so I had to make the harsh decision to cut a lot of content to allow myself time to make a menu system, fix bugs and add sound. The rushed development towards the end led me to create even more bugs which needed fixing last minute, which took even more time away.
I never got around to adding in the new enemy AI's, carriage/environment switching system or new weapons. These systems were all nearly ready to implement, but I kept putting them off when they could have easily been added much earlier in development. Sound was completely neglected and literally added into the game within the last 40 minutes.
Closing Notes
In all honesty I don't think I hit the mark with this jam. The final game wasn't much of a game and it certainly didn't match the theme by feeling 'out of control'. The existing enemies are passive and can be completely avoided by the player by standing out of reach.
I still believe the initial concept for the game would have fit the theme well had I actually finished implemented the systems I created early on and added in a variety of aggressive enemy types as planned.
Positives
Although I certainly could have managed my time better by focusing on more important gameplay aspects, I am still happy with what I produced. I wouldn't necessarily call it a game, however I still think it looked great and I had a lot of fun developing it.
The day/night cycle felt great and really added to the atmosphere.
Although unnecessary for a jam, the flickering light script I created looked great. The script can also be added to any light source and be easily customised in the inspector - I'll certainly be adding this to my toolkit.
I was really happy with the procedural generated background environment, although it wasn't particularly optimised. I spent longer than I'd like to admit watching trees go by instead of working (this sounds negative but it means I liked it).
Key Takeaways For My Next Jam
I'll certainly be experimenting with the art style again in future jams (but not to the extent I did for this one). When I knew what I was going for it was quick to produce assets and easy to iterate on for minimal effort.
Some things to keep in mind for future Jams:
Keeping the planning stage under 2 hours removes a lot of early stress.
Work out the minimum viable product (essential features/mechanics) before doing any work.
Gameplay focused development - the core gameplay loop is the minimum viable product.
Sound should be implemented into code right away, even if the 'play sound' code is commented out until sounds are found.
A simple and attractive art style is great, but it doesn't mean anything if you don't have a game.
Only add in aesthetic details and extra mechanics/features once the core game is working and polished.
Add the Universal Render Pipeline before starting the project to allow access to 2D lighting and Post Pro effects. All assets in the scene will need their materials replacing with lit materials if URP is added later in development, so early implementation = time saved.
Post Jam Development
I'm not sure if this game is something I will develop further, but I'm open to the idea. I'll update this post or make a new one if anything happens.
That's all for now folk's, thanks for reading and happy developing!