Global Game Jam postmortem

So, this is pretty late, but I figured I’d chat about how our Global Game Jam game turned out.  It’s a puzzle game called 2 Rats 1 Cage in which you guide two lab rats through a maze using an experimental brain implant that makes them move together.  It actually turned out really well and we got a lot of awesome feedback.  You can play it at http://markandrewgoetz.com/ggj/2Rats1Cage 2015-01-31.html, or check out the playthrough below:

Now, for the standard what went well / what went badly:

  • Our team was structured well.  In addition to myself, we had two artists, a level designer, a level builder, and a sound designer.  The combination of talents, and prior knowledge of Unity across the team, made it possible for us to produce a completely absurd amount of content within a short period of time.  We ended with 17 levels, a ton of art including two completely separate character sprites, a lot of polish to the UI and game flow, and excellent sound.
  • My first experience with a 2D sprite-based game went well.  I learned a lot about how to use sorting layers and Order In Layer.  I even went as far as to put together a quick script that dynamically set the Order In Layer on awake, so that the three-quarters perspective would automatically be retained:
    public class BlockSorter : MonoBehaviour {
    	void Start () {
    		GetComponent().sortingOrder = (int)((transform.position.y / -75) + 6);
    	}
    }
  • Lots of little components.  In addition to the BlockSorter component above, I also broke down the player code into smaller scripts.  There’s a script for moving, a script for dying, a script for exiting, a script for audio, etc.  Maybe it’s not a complete best practice, but it kept me pretty sane in the timeframe.
  • Public enums.  Seriously, this may be my new favorite line of code:
    (type == DeathType.Squished ? PlayerSounds.SquishSound : PlayerSounds.ElectSound)

 

Now, stuff that I have yet to figure out:

  • Prefabs, prefabs, prefabs.  These are great in theory.  You make a change on one instance of a prefab and it affects every other instance in the same scene, or in different scenes too.  But when you’re developing on the fly like this, you don’t have time to plan out the prefabs you need from the start.  You have to kind of build as you go, and it’s not hard to design a prefab for a level structure or camera or player, only to throw it out.  Then you have to go back through every level and replace the old prefab instances with the new one.  This was also a problem when I shared prefabs with the level designer – it wasn’t long before his version was out of date, and we even ran into conflicts.
  • Check your references.  A lot of game objects have to reference other game objects.  Switches reference the doors they open, teleporters reference their destinations, and players even reference objects like the fadeout effect when you died.  It started to become tiresome to have to set this again and again, especially when passing levels back and forth between team members, and obviously can’t be included in prefabs.
  • Sprite animation.  Some of the animations didn’t make it into the game.  In particular, the hammers actually have a swinging animation that does not appear.  It was ultimately too time-consuming to adjust the pivot points for all of the animation.  Also, the tool chain wasn’t tested ahead of time; when I imported the sprite atlas into Unity and tried to slice it into separate frames, the frames frequently did not fall on exact pixel boundaries, which made the animations look jittery.

Anyway, hope this was meaningful!

Leave a Reply

Your email address will not be published. Required fields are marked *