Sean Collins

Sean Collins

Site Reliability Engineer

Contact Me

Game jam

Background

Ever since I was a kid, I wanted to make video games. A huge step in the right direction was joining the Toontown Rewritten [link] team, but I realized after a while that I was leaning heavily on my programming ability. Programming is a very versatile skill, which meant I didn't need to develop the game design or other creative skills that I lacked. In short, even though I was a game programmer, I didn't know how to actually make games.

I made a plan! I would pick a game engine and learn it well enough that I wouldn't feel held back when the time came to make something. Then, I would force myself to develop six game proof of concepts in the game engine within three months. They didn't all have to be good, but they all had to be complete ideas.

My motivations:

  • I theorized that game design was a part of my mind that could be trained. If I didn't know how to do it at all, I needed to force myself to make *something*, no matter how bad, to start developing the skill.
  • Making six games in three months meant I gave myself a little over two weeks to develop an idea from pen and paper into something playable. The timeline being so short was intentional; the short amount of time would force me to make decisions and aggressively cut ideas to keep the scope small.
  • As long as I had at least an hour to spend and access to my laptop, I wanted to consistently work on the project every day.
  • Working on this project everyday would give me a lot of practical hands-on experience with the game engine I chose outside of the initial learning phase.

Learning phase

I decided to use the Godot game engine and learned it by completing HeartBeast's fantastic Godot Action RPG Series course over the course of three months. (It definitely shouldn't take this long normally, I just went really slowly.) Once finished, I spent another three months to expand the game I worked on in the course to something complete, with a full overworld, dialogue, (very simple) story, boss fight, and ending.

It was very slow going, but by the end of the process, I had a much better practical understanding of the game engine, as well as practice with scoping and cutting features as I needed to.

However, the process taking so long inspired me to take on the game jam idea in the first place! After a long break and month of planning, I started making my first game of the game jam in October 2022.

The game jam

For each game, generally I started by writing out ideas on paper until I got to an idea that I could feasibly implement. Then, taking a lesson from my game developer friends, I started aggressively cutting down the scope of the idea to get it to comfortably fit within a 2 week development timeline. e.g.,

  • INITIALLY: A big boss fight where the game mechanics change as the fight progresses
  • CUT DOWN: A big boss fight with one of these mechanics
  • INITIALLY: A turn-based rhythm game with events that occur every 4th, 16th, or 32nd beat
  • CUT DOWN: A live rhythm game where each beat charges an energy meter that can be released every 4th beat
  • INITIALLY: A ship-based real time tower defense game
  • CUT DOWN: A ship-based game with a real time positioning phase and a turn based defense phase

Overall, I was quite happy with how consistent I ended up being -- as I expected, not every idea ended up being very fun, but by the end of the three months I both achieved my goal of developing six game ideas, but also got myself thinking about video games again. For my games which weren't so fun, I also got a better idea of why they weren't fun, which hopefully will help me in the future.

Lessons learned

I'm proud of the amount of practice I got aggressively cutting features -- keeping the scope of each idea small and watching closely to prevent any one feature growing too big was the biggest contributor to me completing the challenge at all.

I got a lot of experience with prototyping -- jotting ideas and sketches down on paper, and then later replacing them with very simple assets allowed me to catch mechanics which wouldn’t work early on, and to have something playable as quickly as possible.

Again, I was quite proud of the consistency I achieved. I noticed that oftentimes it was most difficult to get started -- both with the progress to be made each day and when starting a brand new game. In both cases, momentum took hold once I was able to get something on paper, in code, or on the screen, and it became easier to make progress as time went on.

Finally, making games gave me exposure to unique problems that I never had to think about when programming before, such as dealing with geometry or optimizing for on screen performance. Being primarily a backend developer, dealing with visuals or thinking in terms of frame time were definitely not second nature to me. It felt like I was learning how to program again!