Terminal Operations
Summary
Results
- Won the Bard Award for Best Game Pitch
What Worked?
- Open discussion around inspirations and design meant the team was excited to work on the project.
- Initial core-loop plan stayed intact.
- Exposing system variables in-editor meant we could quickly tune on day 3.
- “Still Frame” of the game was a strong guiding star for the whole jam.
What Didn’t?
- A lack of initial systems interaction planning meant spending time refactoring later.
- Lack of Godot knowledge meant I wasn’t able to assist in programming as much as I would have liked.
The Jam
Over the last weekend, I got to participate in the Town One Game Jam by Quiver Games. Alongside my team, Bamboo Bytes, we had 48 hours to design, program, pitch, and play test a game with a given theme. Although it was my first time working with the team, I managed to find and fill a niche they needed - System Designer and Project Management.
The theme we were given this year was Space Vehicles
Day 1
Designing
We were given around 3 hours to make our initial design and a powerpoint presentation about it, so we got to work straight away. I knew we needed a strong verb as quickly as possible to have a hook, and that we needed to be unified in the concept. It wouldn’t be enough to have an idea I thought was fun, we all had to think it was fun.
We spent about 20 minutes discussing verbs and making themes with the only limitation being the theme. We then started to collect the verbs into genres we could imagine our game existing within. The mentors a the event offered the advice that we should try to think of games we knew that could work as a framework to build off of.
All that being done, we settled into a low-duration high-intensity mini-game rush. Our 1-sentence pitch was “The mini-games of Among Us meets the chaos of Overcooked”.
The basic idea: You move around a spaceship, repairing machines by completing a mini-game at each machine that needed to be repaired. Being Red-green colorblind, I also wanted to take extra care that we made sure the game was accessible and playable for being with colorblindness from the start, so we wanted to have distinct icons on the screen to direct the player rather than just arrows or green/yellow/red text.
All that being said, we made a single image we could leave on the whiteboard the whole weekend and refer back to whenever we needed guidance on our design or how to make something. It became our north star, so to speak.
Planning
While all of this took time, it was worth it. We had a strong foundation and a unified vision for what the game should be. Having more programmers than artists, we wanted to leave them open to influence the style and keep the art requirements as light as possible.
We knew this plan was beyond the scope of the weekend, so we started to discuss our MVP. None of us knew multiplayer, and there wasn’t a point in implementing it if we didn’t have mini-games or a core loop that was fun to begin with. We decided on 1 player, ~2 minutes, 3 mini-games. I knew I wanted to be able to control the rate at which the mini-games spawned from the editor so I could quickly adjust values once we got to play testing, and we started to discuss what each game should be.
It was important to me to ensure I didn’t overburden anyone on the team with more scope than they could handle, especially given my role as project manager and designer for the team. I’d rather have time to made additional art assets than have spend time re-evaluating what to cut, and given the time constraints of the jam the games each had to be fairly simple. We ended up on the games being a simple but frequent game(Press the correct button), a complex but short game(Place the shapes into the slots), and a simple but long game(Flappy Bird).
Initial Pitch
The first day ended with each team giving a 90 second pitch of their product. Once we all agreed on the work each team member was going to tackle, I decided that my time was best spent working on the slides and speech we needed to give. Rather than spending valuable time figuring out how I could fit into the coding style of the team, given there was no code written yet, I decided to tackle making the slides and presentation.
I also used this time to ensure we defined our goal for the Jam. Making a multiplayer mini-game rush over 2 days isn’t feasible, but a vertical slice of a short, single player experience with 3 mini-games was definitely a goal we could reach.
If you want to see the presentation, you can view it through this Google Slides link
Day 2
I wish I had more to discuss in depth about Day 2, but it was a lot of just “Heads down, get programming” and learning the Godot Engine. The thing I do want to discuss is the invaluable feedback we got from the mentors that came through. So much of what became the final product was born out of their feedback and guidance.
It’s always humbling to interact with someone who has years of experience in a field you’re interested in, and this was no different. Initially, we had wanted a significantly larger map - more akin to The Skeld from Among Us - but the mentors pointed out to us that this created a lot of problems for a single-player vertical slice.
To quote one mentor, “If the fun part is your mini-games, why are you making the player spend so much time running between the games? Why not just make the game fit on a single screen to minimize the time between the fun parts?”
Thankfully, the artists hadn’t started on the ship art, so we were able to design the map and have the artists draw the entire map rather than having to use grey-box assets. This was a huge reduction, and something I’ll be keeping in mind moving forward.
I should focus on organically growing the core loop starting from a second-to-second view rather than trying to plan too far ahead.
Day 3
Untangling Some Spaghetti
The final day started with a lot of merge conflicts. We came to a realization that we didn’t design an interface between our mini-games and the core game, which meant each mini-game was interacting with various global and player variables in unexpected ways.
We decided each programmer would continue working on their games, adding sound and the art assets in the meantime while I fixed the merge conflicts and made an interface.
I started by cleaning up the bits of game logic that were floating around and making an abstract class to contain each games start, and stop methods. Next I made a class to contain the various machines around the ship the player interacted with to launch the mini-games. This meant each machine had to have an associated mini-game, and each mini-game had the same entry and exit point.
I then took the various global fields each game was using and refactored them to ensure they were contained within the instances of the mini-game.
At the end of it all, we had a clear hierarchy - games didn’t update the player score, the machines did, and the machines didn’t handle the starting or stopping of the games, each game handled its own logic.
Although this took time, it made tuning each game later easier since we didn’t have to worry about breaking other systems when we edited each games variables. It was definitely worth the time.
The Final Pitch
With the core systems all cleaned up, and our conflicts resolved, I started on the final pitch. The concept of the final pitch at Town One is that you need to make a pitch you could use to ask for the funds to complete the game.
Using my experience as a QA, and having been included in milestone reviews and analysis, I broke the full project into 3 smaller milestones and tried to make reasonable goals for each milestone, building the core features first and adding polish later.
The final pitch slides are viewable on Google Slides, if you’re interested in them.
Conclusion
In the end, Bamboo Bytes won the Bard Award for Best Game Pitch, which was an incredible way to end my first game jam.
The whole experience was amazing. I’m so thankful to Quiver Games for making it all happen, Bamboo Bytes for including me, Blackbird Interactive for hosting, and the mentors for making their time and expertise available to all of us for nearly 3 days. I definitely learned a lot as a programmer, designer, and project manager, and I’m hungry for chances to learn more and improve.