Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Global Game Jam 2015 Post Mortem - Girl's Flu

A team of two indie game developers participated in the IGDA Malaysia-hosted Global Game Jam 2015 event. Here's a post-mortem from the programmer's perspective.

WY Leong, Blogger

January 27, 2015

6 Min Read

Reblogged from http://wyleong.tumblr.com/post/109276098198/last-weekend-my-partner-and-i-wanted-to-join-the

 

Last weekend, my partner and I wanted to join the Global Game Jam 2015 held in Kuala Lumpur, hosted by IGDA Malaysia. Due to a sudden emergency, we had to rush home to Penang and thus, couldn't physically participate. Thankfully the organisers were nice enough to let us join remotely.

We reached Penang at 8pm, and just in time to find out about the GGJ'15 theme: "What do we do now?". We had earlier planned a few template game ideas for the GGJ, but as expected, the theme was so unusual, we didn't know how to fit our game ideas with the theme. And so we decided to come up with new ideas based off it.

Girl's Flu is a game about a clueless dad (with an absent mom) with a daughter who just had her first period. You collect items around your house and try to cure your daughter's anxiety. The idea came about because we thought... wouldn't a guy be clueless most of the time, when forced with handling a girl's period? I was. Still am.

And so I thought the game would help raise awareness on the lifelong inconvenience that girls have to face in secret -- something men take for granted.

So we got down to designing the game. The following were some thoughts that came up (somewhat chronologically):

  • We don't know how much we need to do to finish a game in 48 hours.

  • We knew it had to be 2D because we had little 3D experience.

  • My partner wanted to do 16-bit or higher-resolution sprites.

  • I insisted on 8-bit (targetting a 160x120 screen resolution) sprite size.

  • I wanted to try out Haxe/Flixel as our game language/framework.

  • We didn't think about the audio at this point.

And so we started our work. Here are some highlights of our development progress:

1) I spent about 8 hours on trying to learn HaxeFlixel. I've forgotten all my knowledge in Actionscript3, so it was tough picking up the syntax again. After 6 hours in, I discovered that it was really difficult to look for tutorials/examples of things I wanted to do in Haxe or Flixel. The documentation was not sufficient, to put kindly. At the 8th hour, I gave up trying to use Haxe. I switched to Unity. I had been spoiled by Unity's UI, MonoDevelop's autocompletion and component-based objects. It was a relieve to go back to the convenience of writing only game code instead of figuring out how to work out the API on HaxeFlixel.

2) I originally wanted to use a Tiled parser in the game, but realised that the game only had 5 screens at most. So I told my partner to save the whole room as one image rather than split them up in tiles. The result? We saved a LOT of time because I didn't have to parse any map data (just used some invisible BoxCollider2Ds as floor and walls), and my partner only focused on laying out the room in Photoshop.

3) We wanted to implement an adventure game-isque mechanic -- pick up items from the house, combine, examine, use... We thought of all sorts of fun mix-and-match possibilities. Imagine how much fun the player would have if they could give inappropriate items to the daughter, or try to combine weird items and then give it to the daughter. Unfortunately, by the time I had written down most of the basic code (movement, wall/floors, simple inventory, item spawning, door/daughter events, dialogue system), we only had about 4 hours left.

4) We originally wanted a top-down game. We later decided that a 2-direction (platformer) game was easier to code than a 4-direction (top-down) one. It was a tough decision because we preferred it top-down...

5) With the remainder of our time, we thought to just have a simple mechanic and goal: you can pick up items and use -on yourself- or -on your daughter-. Using it on yourself affects your panic bar, using it on your daughter will affect her anxiety. Your panic bar decreases as you idle, it fills up as you run. Your daughter's anxiety increases over time, and you have to give her the right items to reduce it to zero.

6) On the final hour, we rushed to add in all the audio. Thankfully my partner had finished all the art assets for the game before I was done coding, so she made some quick sound effects in bfxr and searched for a nice chiptune on Soundcloud for the game.

7) We spent the remainder of the day uploading the game and broadcasting it to our friends and blogs, and then getting some well deserved rest. :)

 

Here are some highlights post-event:

1) Although I'm a programmer, I'm slow at learning and I'm bad at maths. As such, it was a bad idea to try to pick up HaxeFlixel because I had almost no experience with it.

2) We made the right decision of making an 8-bit styled game. If my partner had gone any higher on the resolution, it would have taken more time and effort. As a result, we now have a better idea of how much effort we needed to make a 48-hour game.

3) Scope creep happened a few times during our development. Half-way through the jam, we'd discuss about what other features to add into the game that would make the game more fun. I felt bad for having to say "no" to my partner so many times -- partly because it makes me feel like I'm an incompetent programmer, and partly because it felt like all I ever did was reject my partner's ideas. In the end, thanks to cutting out a lof of our planned ideas, we barely made the game in time. So yea, we learned of the importance of scoping.

4) I made the whole game in Unity 4.6's UI canvas. The 2D colliders work on the canvas items, and the cameras all scale almost perfectly. The new UI system is a blessing!

5) Thanks to the 48 hour time constraint, I bypassed a lot of things I normally did when coding in Unity. For example, I used a lot of (what I would assume to be) inefficient code that would slow or break the game if it were a large-scale project. I have a habit of commenting my code, but for this GGJ, I wrote minimal comments. I think the whole game is full of spaghetti code. However, despite all these dissatisfaction with my code, we still managed to finish the game (with only one bug so far -- if you can find it!). I'm thankful enough.

And so that wraps up our Global Game Jam 2015 post mortem for Girl's Flu. I hope you enjoyed the article.

 

You can find the game downloads and screenshots/gifsets from the links below:

http://globalgamejam.org/2015/games/girls-flu

http://wyleong.tumblr.com/post/109087879478/gifsets-from-our-48-hour-product-of-global-game

http://wyleong.tumblr.com/post/109085654703/we-finished-our-game-for-global-game-jam-2015

Read more about:

2015Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like