Just to do something different over the holidays, Marc and I decided it would be good practice to hold our own small game jam with some of our friends. One is Computer Programming graduate (Alison), another works as a Java programmer (Ray), while the third is artistic in drawing and music (Dean). We thought that the five of us could work for 48 hours on a theme and see what we could come up with!
To make it a little more realistic, Ray’s girlfriend texted us an idea once we were all together at 6pm on the Friday (Day 1). We were told to “rescue the animals from the lab,” which I thought was a very neat concept. As a group, we thought that we would spend the first few hours just bashing out some ideas, writing down what we thought could work, and coming up with a plan of action for the following two days. We essentially had until the Sunday evening to finish up something that was at least semi-playable.
First and foremost, we started by discussing the core mechanics of the game:
- Did we want it to be in real time or a turn-based system?
- What sort of game style did we want?
- What sort of goal was the player attempting to accomplish, outside of the overall rescuing of the animals?
After some deliberation, we thought the best sort of game for this was a sneak puzzle. The player would control the little animals and find a way through the lab levels while avoiding the lab assistants patrolling around. This seemed like a simple enough game style that could be done in real time, with simulated AI for the lab assistants and simplistic controls for the animals.
We felt like the way to accomplish this would be a field of view, with the assistants moving on a set path. If the animals crossed that field of view, they would be caught and the player would lose a life (although, for ease of design, we would start with a simple game over and introduce a life count if there was time afterwards).
There were also some other things we could add as hazards to the levels:
- Slippery floors – the animal won’t be able to stop and will continue moving in the direction they were travelling in when they walked over the wet floor.
- Sticky floors – this lowers the speed the animals can move at, which might put them at greater risk of being discovered.
- Lab assistants – there could be one or more assistants on patrol through the lab levels, on the look out for anything strange going on, including escaping animals.
- Security cameras – could act in the same way as the assistants, with a specified field of view that the critters have to avoid passing through.
Some of the ideas we came up with were a beyond the scope of our abilities and (likely) time, however we thought there wasn’t any harm in writing them down. For example, some animals might move faster than others, while others might be able to cause a distraction that changes the patrol route of a lab assistant. We also thought, to add some silliness to the game, progression through the higher levels could result in odder animals trying to escape. We would start with a mouse, but could go as far as bears or a yeti, just whatever might be locked away in the deepest levels of the lab.
Figuring out the timing and controls took a bit of thinking, since we wanted it to be in real time but we didn’t want the player breaking the controls or cheating the levels by taken an unconventional route. With this in mind, we thought it might be good to use a grid-based system the player and the AI could move on. This also meant we could speed up or slow down the movement through scripting for the various types of hazards in further levels.
We toyed with a couple of other ideas, including having one animal start at its cage, but free other animals along the way before making it to the exit and winning the level. There was also the idea of making it a snake-like challenge, where collecting the animals along the way would create a chain and make dodging the hazards more difficult. Finally, we also thought that, to unlock the use of animals and their abilities in later levels, perhaps you would have to rescue a certain amount of them in the lower levels.
After a few hours, we were ready to come up with an overall game plan and a list of priorities. Our initial focus and minimum game requirements ended up being the following:
- P1a: Player models and basic movement
- P1b: A first level designed and ready to utilise
- P2a: Basic game assets, which would include but not be limited to pawns (animals, lab assistants, etc), background (going with a top-down view), and obstacles (crates, desks, general level dressing)
- P2b: A spawn point, exit point, and any objectives we wanted to include throughout the level
- P3a: Basic enemy movement (either lab assistants, guards, or cameras)
- P3b: Field of view detection
- P4a: In-game menus and transitions
- P4b: Interface/HUD or any game information the player might need
The scribbles at the bottom were Dean figuring out the size of the grid we could work with and what sort of scale we could use for the game. We ended up deciding on 1920 x 1080.
Overall, I think we came up with a good game design and something we could make at least a first level of before the 48 hours were complete. The next post on day 2 will go further into detail on the contributions I made – my focus was with Ray and Alison, working on the programming and scripting of the game, while Marc and Dean concentrated on the graphics and general level design.