To add something relevant over the holidays Kelly and I organised our own personal little game jam challenge with a few friends of ours with skills to contribute. One is a computer programming graduate (Alison), another is a Java developer (Ray) and lastly is our second artist (Dean), who did the same Uni course as me 12 years ago. While the majority of the group had no experience with Unity we thought it would be a laugh to see how far we could get in two days.
We had considered picking a theme ahead of time but then worried people may start sneaking in work before we began. To keep it random we asked Ray’s other half to text us a random theme at 6pm on the Friday, this came through as “rescue the animals from the lab”, which was a little bit specific for a jam but it didn’t matter. Time to get to work.
We had bought a flip chart and stand for the occasion and spent the first night sitting around throwing ideas at it and trying to make a plan of action for the morning.
Before the group even got to whats above we had to figure out some core mechanics:
- What style of game would work?
- What would be plausible within the time frame given lack of experience?
- Since the theme was rather specific, what goals would the player have to achieve to save the animals, i.e what is your win condition?
- 2D or 3D?
After much debate and several cups of coffee, we settled on sticking with 2D and making a top down stealth game. The notes above in the photo were other gameplay suggestions we considered before stealth. Each level would be a different animal trying to escape on its own through a level, while trying to avoid obstacles and staff, also toying with the idea of each species having its own unique ability which may help it in certain situations. A mouse has less visibility, a cat could see in the dark etc. Jokingly Dean suggested a bear (who tests on a BEAR) could steal a staff uniform and walk out, we had a chuckle and continued the joke for two days.
Using a top down perspective we could keep the controls relatively simple, it kept art asset creation simple and the most difficult part seemed to be the coders figuring out how to make a line of sight for the enemy/staff sprites. So in theory, it all seemed plausible.
When moving the player/animal sprite if you crossed the line of sight (we wrote FOV in the notes above) of the enemy sprite you would lose a life, or the level would reset. Whatever we had time for. We covered some other ideas for obstacles/game progression on this page.
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.
Multiple Lab assistants – there could be one or more assistants on patrol through the lab levels, on the look out for anything strange going on.
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.
We started coming up with ideas that were well beyond our time frame and ability, ideally we should have stopped there to save some time but in the moment it seemed like a good idea to flesh it out as much as possible. We considered some of the animal abilities being able to cause distractions and alter the enemy/staff patrol routes and to accomodate Dean’s joke bear we added a bit of silliness, where further levels would delve you deeper into the lab to find all kinds of weird animals or science experiments that were trying to escape.
Figuring out the timing and controls took a bit of debate, the group eventually decided on a grid based movement system to easily lock all the player and enemy sprites onto a certain path. The coders believed it would be easier to add in line of sight this way and despite I argued for a more direct input control (because its what I’ve done in Unity so far and inbuilt) I was over-ruled.
Another few ideas were thrown around regarding gameplay, such as animals having to free other animals along the way and making a snake like chain (making it harder to avoid enemy sprites) and needing to rescue so many of a single type of animal to unlock their use for later stages.
So a few hours passed and we drew up a plan and a list of priorities. From this we created a list of minimum requirements to make this a game:
- 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
End of night one and everything seemed to fit together along with seeming plausible within the time frame. The team divided into Kelly, Ray and Alison coding, myself and Dean making the art assets. I’ll write up day two soon and also give a link to Kellys blog to see her side on code (as she has already posted everything) in contrast to my side on art.