Making indie gams for the Toronto gamedev scene

Crappy Lion Safari – Post Mortem

Category : Game Jams, Post Mortem · No Comments · by Jan 27th, 2015



The 48 hour Toronto Global Game Jam for 2015 is complete and my little game is finished. The theme for this year was “What do we do now?” which, as far as themes go, is pretty uninspiring. Going into the game jam I knew I wanted to do something with a ‘spinning plates’ style gameplay where the player is dashing backwards and forwards around the screen trying to keep things moving. I was thinking of maybe doing a cooking game or perhaps a sinking submarine where it’s falling apart and you are trying to run backwards and forward fixing things to stop it from imploding. Once they announced the theme though I figured that there needed to be two people present so the question could at least be asked, eventually settling on having tour guides trying to lead angry tourists through a crap zoo. The end result was Crappy Lion Safari.


The not so good:

Managing States: The more I work on these games the more I’m noticing that I run into the same problems over and over. At the top of that list is managing states. It always in the last 30% of the project that I find myself hacking in solutions to manage this, and it never works out well. In Odds Mansion I had a very basic state machine for the player (which worked quite well), but never botherd with the rest of the game. That meant the whole UI was a complete hackjob of “When X happens, do C, D, G, not F, maybe H…” every time the user clicked something. With Crappy Lion Safari I didn’t have any sort of state machine at all. Instead I had properties like “IsBeingLedByPlayer” and “IsAtCage” and “IsAutoWalkingAngrily”. This led to all sorts of wonderful hacks where I’d check “IsBeingLedByPlayer” in one location, but then forget to consider that an animation could be running in another. Anyone who stopped by to play the demo during the 48 hour game jam immediately became accustomed to dead bodies creepily sliding from cage to cage taking photographs…

DOTween oddities: There’s not much I could have done to avoid it, but I found some really strange behaviors with DOTween. I wasted about 3 hours Sunday morning trying to get some simple alpha fading to work only to figure out it was something to do with re-using pooled objects. I have an object pooler I use in my game, and it seems (and I need to test this) but when you create a new sequence it seems to run in its own little world that doesnt take into account the current state of your code – this means if you pull an object from your pool, reset some variables and then pass it to a new sequence, the sequence is unaware that the object even exists unless you pull the pooled object inside the sequence as well. Super weird and I need to do some testing.

Not making a full screen game: I wanted to keep the game at 500×500 for simplicity, but it certainly didn’t stand out as much as some full screen games people had running. Nobody seemed to mind and it pulled it’s fair share of people in to give it a go, but I think for my next game jam I’m going to try and make something I can leave running in full screen.


The good:

Cinematic handler – After Odds Mansion I realized I needed a better way of handling cinematic’s. I ended up building a little system that allowed me to add manual steps using player feedback or progressing automatically by building some helper methods on top of DOTween. Basically you push an event into it using a callback, which by default pauses after every sequence. The player then taps the mouse and it resumes the tween. Getting the short intro and end game animations done was probably the fastest part I worked on. This also let me use a much better tutorial system than I’ve had in my games before (I think).

Not bothering with sounds: I never really considered it until the last day but not bothering with sound effects or music worked out great for a game jam. It didn’t really occur to me until another jammer mentioned it but when people are playing your game they are not going to be able to hear the sound anyway. If you planned ahead and bought speakers with you maybe then they can hear, but if too many people are also blasting sound effects it’s just going to get drowned out. Obviously this is only relevant for game jams but it saved me a ton of time. Originally I wanted a little whistle sound effect like Pikmen so players knew when they had picked up and dropped off, but players wouldn’t be able to hear the sound anyway. So at the last second I threw in a little bounding box around the tourists, which worked out great.

Artwork – Super simple and ended up drawing a lot of attention. What was meant to be mostly placeholder art got good feedback so I just left it as it was with some small cleanup on Sunday. Funnily enough the main reason I went with a zoo theme (apart from the reasons above) was because when I was uploading screenshots of all my games to this site I realized most of them had dark backgrounds. I wanted to do something colorful to break up the pattern a bit 😀



Overall I’m happy with how the game turned out – sure it’s small and it’s not exactly minecraft, but just making a game in 48 hours is a challenge I wasn’t sure if I could ever complete. The Toronto Global Game Jam was better than I could ever have hoped too. Cool people all round and amazing organizers 😀

Getting prepped for Toronto Global Game Jam 2015

Category : Game Jams · No Comments · by Jan 22nd, 2015

Tomorrow night the Toronto Global Game Jam starts! I’m signed up, my bags are packed, laptop is charged, I’m ready to go.


I registered as a Solo dev instead of joining a team since this will be my first foray into the GGJ – I figure if I go down in flames clutching my copy of Unity like a parachute, at least I’ll be the only victim. But it’s going to be great to meet some of the Toronto folk and seeing what crazy crap they come up with. Who knows, maybe next year I’ll be able to join a team if my skills can cut it.