Table of Contents
Last Jam of 2020
I love game jams! The first game that I completed and released, Defender of Earth, was made at a game jam. I’m the type of developer that can sometimes take a little too long architecting and thinking about what I’m building. Which can lead to projects not getting completed because I get bogged down trying to figuring out the best solution instead of actually building anything. Game jams force you to push through procrastination by giving you a hard deadline deadline. You can’t spend too long thinking about what you’re building, you need to start getting parts working as soon as possible so that you have a complete game by the end of the jam.
Can this lead to some bad code and some poorly optimized solutions? It absolutely has for me! But it gives me a base MVP product that I can build off of. I have a proof of concept that I can get into the hands of players, and get some real feedback of my work. At the end of the jam, you have a game! After the year that has been 2020, I decided that the way I wanted to end it was adding another game to my resume.
About the Jam
I found the GrapeFruit GameJam via Itch.io. This is a ranked game jam, which is kind of a first for me. I’ve participated in game jams with rankings in the past, but I’ve never submitted the games I produced for the review processes. For me it was more just about the process. This time I’m planning on submitting my game for ranking at the end of the jam. I’m not too concerned about where I end up ranking. I’d just like to not be last place! But anything outside of that I’d be happy with. I’m honestly not going to think about the ranking too much, and just focus on making something that I am happy with.
GrapeFruit is a 48 hour game jam that starts at 2:00 pm Saturday and runs until 3:30 pm Monday. I have to work on Monday, so I’ll be losing some of my jam time unfortunately, but I’ll just try to account for this deficit by limiting the scope of my project.
I’m going solo for this jam, and as per the rules of the jam, I will be making EVERYTHING from scratch over the next 48 hours. That includes the game design, gameplay code, art, music, and everything else that goes into the game. Since I’m timeboxed to doing all that work within the time frame of the jam, you would think that I wouldn’t have much to do prior to the start of the jam, but that’s not true! Even though I can’t start making anything until the jam begins, I can still take advantage of the handful of hours I have before the jam starts to do some serious planning.
Pre-Jam: Goal Setting and Planning
Before I sit down to make my game, I want to have clear goals of what I’m trying to accomplish over the next 48 hours. My first goal in making this game is to increase my skills with Unity’s Entity Component System, so that’s the framework I’ll be using to build this game. As much of the game logic as possible, I want to have running through ECS and the DOTS tech stack. My second goal is to incorporate some form of procedural content generation in the game mechanics. I’m a big fan of procedural generation and game jams are great opportunities to explore an implementation.
Since I’ll be building the game from scratch using a framework that I’m just gaining experience with, I’m going to aim to keep my game loop very small and compact. Until the jam starts and we get the theme, I won’t be able to really start to plan what kind of game I’m going to make, but as I’m waiting I’m brainstorming a bunch of different kinds of small games. Maybe some kind of Sokoban with procedurally generated levels? A simple infinite runner with procedurally generated art assets? Right now I’m just trying to come up with as many options as I can think of to explore once the theme is announced.
I’m starting to sketch out a rough timeline for development. It’s mostly a loose plan at this point as I know things will change a lot, but this is my planned schedule:
- Saturday
- 2:00 pm: Theme released, Jam begins.
- 2:00 – 3:00 pm: Design
- Brainstorm game idea
- Plot out game structure
- Create MVP feature list
- 3:00 – 5:00 pm: Prototype Coding
- Implement as much of the gameplay as possible
- 5:00 – 5:30 pm: Food and Evaluation
- Take a break for dinner and evaluate progress
- Decide on any course changes that need to be made
- 5:30 – Sleep: Get As Much Done As Possible
- Ideally by the time I go to sleep the MVP is playable
- Sunday
- Finish the Game
As you can see, the further my schedule gets into the future, the looser things get and this is by design. I want to be flexible. In fact the only two things that I want to make sure I rigorously stick to on that schedule are:
- Forcing myself to take a full hour of planning and designing before I start to code. I say I’m “forcing myself” because in the time-pressure of a jam it’s easy to want to jump in and start making progress before you’ve properly thought things through. So I’m forcing myself to really think through my plan before I start by setting a time limit rather than just finishing when I feel like I’m “ready to start working”.
- I want to make sure I take a break to eat and evaluate the project after I’ve spent a couple of hours working on it. I find that once I start working, it’s too easy to get swept up in the development and the desire to solve the problem that’s right in front of you, and I will forget to take a step back and make sure I’m solving the right problem. It’s important to take time to occasionally re-evalute your plan and schedule based on the work that’s been completed.
In addition to planning out my goals, I’ve been setting up a few of my admin and logistical solutions. I’ve created a fresh Trello board with the columns you see above. I’ve also started a fresh github repo, and diagrams.net project. I have everything I need, now I just need the theme to launch and I’ll be ready to go!
Theme: Absolute Zero
Finally the time has come and the jam begins. The theme: Absolute Zero. I start my hour of brainstorming and start jotting down the first ideas that come into my head.
I looked up the definition of absolute zero: the lowest temperature that is theoretically possible. My first two thoughts were ice, and space. An ice sliding sokoban is my first game idea. What if instead of a temperature, absolute zero was the goal? Like an bug exterminator in a maze. I’ve played with using genetic algorithms as maze solvers, and it would be cool if I could incorporate that somehow into the behavior of the bugs you have to exterminate. Maybe absolute zero could refer to needing to have absolute zero doubt. I could create some sort of law game where you play as the jury, with procedurally generated cases to adjudicate. Zero as a value factors heavily in binary. I could do some kind of platformer puzzle game that involves having to flip switches and logic gates to zero out some binary equation. What if the absolute in the theme meant absolute as in totality? Then absolute zero is complete nothingness. I could make a simple path walking game where you play a monk trying to achieve enlightenment. I liked that idea so much, I did a quick character mock up for the monk.
My hour of brainstorming was fertile and I had a bunch of ideas, but I didn’t have THE idea yet. None of my concepts really sparked my interest. I was still waiting for that moment of inspiration where you can visualize the game that you wanted to work towards, and you get filled with excitement that propels you forward with momentum. But whether I was inspired or not, the clock was ticking and I needed to get down to work.
The First Two Hours Of Coding
As scheduled, I started into my first two hours of coding. I hadn’t picked an idea yet, but I knew that whatever game I decided to make, there were common elements that were going to be involved. Elements like a main menu, a game over screen, and a way to transition between those scenes. I also wanted to set up a functioning escape key so that players can quit my game. I’ve played too many jam games that can’t be quit once they’re launched without alt-tabbing and force quitting, and it’s a personal pet peeve of mine when developers leave that out. My hope was that I would be struck by the fickle muse of inspiration while I was building out the menus.
Since this project is built on Unity ECS, my first step was setting up the project dependencies. Installing the required packages and coding the basic game manager consumed all my coding time until my scheduled dinner break. Since the game manager isn’t part of the gameplay, I decided it didn’t need to be an ECS system, and built it as a singleton Monobehaviour that is not destroyed on load. From that singleton I use coroutines to manage transitions between the different scenes, along with some simple input processing for the escape key, and some hard coded menu transitions for my prototype.
Once 5 o’clock hit, as planned, I took a break to grab some food and evaluate where I was at. By the time I stopped coding to take my scheduled dinner break, I had a basic manager that could switch between my menus and my empty game scene. Even if I hadn’t scheduled time for re-evaluation, I would have needed to stop at that point anyways because I was getting to the point where it was impossible to go any further without settling on an idea for the game.
Zero-Friction Something
After eating some food and looking back at my brainstormed ideas, I am still not in love with any them, but I have to pick something. I decide to create something where the player slides around with zero friction. While still not sure how all the details are going to work themselves out, I think that if I can make some sliding around in zero friction controls that are fun to play with, I can sort the rest of the details out later. Will it be a race? Some kind of maze? Some kind of Rocket League sort of sport? I could put off having to answer those questions if I just started with creating something that was fun to control as you were sliding around and bouncing off stuff. I can fill in the gameplay specifics later.
The first element I implemented was a basic character controller. Using a simple 3D cube as my player character model, I started by setting up the entity conversion code for my Player entity. At this point my Player entity is just a box mesh with a collider, a rigidbody, and my PlayerAuthoring component. I was leaning towards some sort of top down perspective for the game, so I decided that I would keep my player controls very simple. Just press in the direction you want to go, and your character goes in that direction. To make my life simpler, I’ll keep user input bound to the four cardinal directions: north, south, east and west. The player object will be free to slide around the level in any direction, but in terms of momentum input from the user, it will be limited to just those four directions inputs.
My first step in implementing my character controller was to make sure my system was ingesting user input properly, and that I could rotate the player character to the direction that user input. The uniformity of the 3D cube I was using as my temp character mesh had reached its useful limit. I’m not a very good 3D modeler, so I decided to use MagicaVoxel as my art asset creation tool. Since I still wasn’t sure what my game was going to be, and I had liked my little monk character design earlier, I decided to create him in 3D to use as my stand in model. After doing some googling to find some artistic inspiration, I sat down made my monk model.
First Character Movements
Importing the model from MagicaVoxel into Unity was super simple. Setting up the ECS system to parse player input and rotate the model took a little bit longer and wasn’t as simple. After some experimentation, ended up implementing a system that compared the model’s forward vector with the desired input vector and rotated the model if necessary. Eventually I wanted to the system to incorporate a rotation speed, and lerp the model’s rotation to the desired direction over time, but for the first implementation, I was happy just snapping the model’s rotation to the desired direction.
By the time I got my model rotating, it was starting to get late. My original scheduled called for me to have my game prototyped out by the end of day one, leaving me all of day two for iterating and polishing. As it stood, I hadn’t even decided on what game I wanted to build. It sucked to end day one having fallen short of my scheduled goals. The temptation was there to stay up late grinding until I made some positive progress. But I know that game jams are a marathon, and if I don’t get enough rest I’m going to burn out. As well, I just wasn’t feeling inspired by the idea, and that always leads to disappointing results. Forcing myself to spend time working on it without the inspiration would produce a bunch of results that wouldn’t be worth the effort it took to produce them.
I hadn’t gotten as far as I had planned, but the day wasn’t a total failure. At least I had built most of the major meta game elements that I would need, like the menus and game over screen. I had tested and proved that I could make and import art assets via my pipeline with MagicaVoxel. And I had the basic framework of a player controller that was reading user input. Now if I could just come up with a game for all that infrastructure, I’d be golden!
To Be Continued…
Read up on how the second day of the jam, and the rankings went by reading the second post in this series here.
If you’re not afraid of spoilers, you can play the game here.
Pingback:GrapeFruit Game Jam 2020: Day 2 – lvl_0