Garrison Gourmet
Overall this jam was a great learning experience for how I can improve my game jam process overall as I go into new projects. I’m going to start focusing on getting the core mechanics up and running even earlier in the process in order to ensure that if there’s a delay there is still enough time to properly proof out the core mechanics and find which parts of them are the most fun.
Ultimately we made the submission deadline, but the playable build was still buggy and lacked a tutorial. We continued working after the jam to fix the major bugs and uploaded a working build, but ultimately fell short of our initial plan and ended with an incomplete if still technically playable final product.
The tl;dr
5 day game jam
Team of myself and one developer
Project submitted on time but with major issues
Continued dev after the jam
The Requirements
5 days of development time
Based on the theme “messing”
Playable in browser
The Jam
Identified multiple meanings of “messing’ - making a mess & referring to a mess hall
Decided on an art style, engine and basic mechanics
Came up with simple mechanics with a plan to have them finished by day two, then spend time polishing
Both myself and my teammate lost a day of our time to unexpected IRL interruptions
The mechanical implementation was more complicated than expected and was not finished by the end of the jam
The playable build that we uploaded had a number of game-breaking bugs when played in browser that were not present in the editor
We submitted a technically playable, but buggy and unpolished final version
We continued development after the jam
What I Learned
Methods I’d used to create 90s-style analog effects for Flicker work well when applied to other time period aesthetics
Start with even simpler mechanics that can definitely be finished quickly and go from there
Make and upload a first build earlier to catch issues that only show up in-browser
Garrison Gourmet was created for the Games Now! Game Jam 2024 over the course of 5 days, since we started a bit late. I worked with one other developer to create a submission to the competition.
The main requirement of the jam was to use the word “Messing” somehow. We discussed different ways we could do this and ultimately settled on using multiple meanings of the word at once. We aimed to create a project that included both making a mess, and the idea of a mess hall to feed a large number of people all at once.
With that idea in place, we discussed how we were best going to be able to create a project that we were both happy with that could be accomplished with the time limit and resources we had available. We decided that we wanted the final project to be playable in browser, that we would use a simplistic pixel art style similar to the one that I used in Orbital Decay to compensate for our lack of a dedicated artist (pictured below), and that the game would be single-player only. To accomplish this, we chose unity to meet the above conditions as well as both having familiarity with it.
We decided that given the short time limit, we would keep the game very simple mechanically and use any extra time that we had after getting core mechanics into place to add polish. We started with the idea of being able to hear the soldiers cheering or booing depending on overall morale was doing, and making the player’s performance the deciding factor in that morale. We decided to go in the most absurd direction that we could based on that concept, and made the player’s performance in the kitchen the sole deciding factor in whether the war was won or lost. From that the project was named Garrison Gourmet.
Mechanically, we started on punching in combinations of WASD or arrow keys in rapid succession while the game’s pace, art and sound made the player feel like they were under more pressure than they actually are with simple mechanics. We started with the idea of the player as a cook in the mess hall kitchen, but realized that the directional inputs would also feel at home in the process of unwrapping or opening the bulk-boxes of ingredients and checking them for spoilage immediately before being sent to the kitchen. This led us to add another element of needing to direct the food to either be sent to the kitchen or to be destroyed depending on if it was spoiled. Punching in the correct key combination as well as checking and directing the food felt like a good level of complexity, so we began developing with these features in mind.
I focused on creating the game’s overall theme to match the concept that we had decided on. This process included deciding on a layout and color scheme for the UI and mechanical elements of the game, and putting together the sound effects. I started with the military theme, and based the color scheme of the game on color photos from WWII.
Using pictures like the one above as a guide, I selected the base colors we would use within the UI with a military theme in mind. I wanted to give the impression of the UI being a piece of military hardware, so I selected a very boxy design that worked well with pixel art. I used a pixel perfect camera component on the main camera and lined up the size of the game’s viewport to fit cleanly with pixel art. That allowed me to 9-slice UI elements without worrying about breaking off of the main grid of the game.
Once it was easier to work on a fixed grid, I put together basic UI elements to represent the basic concepts that we wanted to work with within the game. This went through several iterations as the game’s mechanics continued to develop before reaching the final version that was used in the playable build of the game. This backdrop UI was then used along with pixel art sprites representing the game’s food item to create the overall aesthetic. We had also planned to lean into the “mess” aspect of the game using particle emitters to create splatter as the player interacted with the food, but the implementation was ultimately more complicated than we had time to complete and did not work out as we had planned.
Ultimately we made the submission deadline, but the playable build was still buggy and lacked a tutorial. We continued working after the jam to fix the major bugs and uploaded a working build, but ultimately fell short of our initial plan and ended with an incomplete if still technically playable final product.
Overall this jam was a great learning experience for how I can improve my game jam process overall as I go into new projects. I’m going to start focusing on getting the core mechanics up and running even earlier in the process in order to ensure that if there’s a delay there is still enough time to properly proof out the core mechanics and find which parts of them are the most fun.