One Game a Month Retrospective, February 2014, for “Respawney”

This is a look back at the development of my first One Game a Month entry, Respawney, developed using Unity 3D.  You can find details about #1gam here.  Respawney is available to play in your browser, here, and my #1gam profile is here.

The inspiring tale of a spaceman searching for crystals, probably.

The inspiring tale of a spaceman searching for crystals.

My First #1gam

My foray into the #1gam challenge originally began in January, 2014, where I had decided to develop a “single-player co-op” idea I had had for some time, where you used pre-recorded copies of yourself to assist… yourself with solving puzzles.  These pre-recorded “ghosts” would do things such as step on distant pressure pads to open doors, allowing you to progress.

The decision to develop this idea came from the key word for January: “respawn,” as my intention for the game was always to have your character dying a lot, with respawning being crucial to success.

Join me, my minions, and togehter we wwill solve all of the world's puzzles!

Join me, my minions, and together we will solve all of the world’s puzzles!

Unforeseen Delays

Unfortunately, I didn’t have a development machine at home to work on, due to my beloved laptop being stolen the month before.  Possibly by ninjas.  So, ideas were scribbled down in my notepad and fleshed out a bit before any code was written, which ultimately turned out to be a good thing – my initial idea had mutated and simplified somewhat by the time development began proper.

I imagine the people who stole my laptop live in a place like this, where bright yellow crystals make it hard to sleep.

I imagine the people who stole my laptop live in a place like this, where bright yellow crystals make it hard to sleep.

Scheduling / Planning

Before beginning, I decided to set a rough schedule to guide development and keep things on-track.  As I am an experienced software developer by day, I know that, in order to release a quality product, around half of the available development time needs to be allotted to non-feature work; another way of saying this, is that by the halfway point in your development schedule, you should be feature complete.  The remaining time is used for testing, tweaking, polishing, and finally publishing.

Publishing may seem an odd thing to schedule, but it takes time, so must be included.  Publishing involves deploying your product to your target platform (be it web portals, app stores, or just building and zipping your project).  It also involves promoting your product on forums, Reddit, etc, and other related things, such as writing blog posts.  Lastly, it involves updating your #1gam profile to get the sweet, sweet, XP 🙂

Level 6!  That's way better than level 5.

Level 6! That’s way better than level 5.

Available Resources: 1x Joel

After estimating my free time, I aimed to work on the project for a few hours, perhaps 3 times per week.  Sometimes I may work more, sometimes less.  Sometimes I may get to sneak a few hours in over the weekend.

My general unit of measurement for scheduling was a “night” of around 2 hours work.  A schedule week would equate to about 3 nights, so in a week I could expect to get 6-10 hours of work done.  Years of software development experience told me that this is not a lot of time to work with, so the feature list would have to be short.

Lastly, in each “night” of work, I tried to get at least one thing implemented, to maintain momentum and a sense of accomplishment.

"Got it?"  "Got what?"  *smash*

“Got it?” “Got what?” *smash*

How I Think Things Work

My One-Month Schedule was as follows:

Week 1: prototype and settle on the mechanics of the game.

Week 2: add “content” and tweak for playability and fun.  By “content,” I mean creating levels using the mechanics developed in Week 1.

Week 3: test and polish for publishing.

Week 4: publish and promote.

Googled for images of "plans," got this.

Googled for images of “plans,” got this.

How Things Really Work

Here’s what actually happened.

The first week, prototyping, went quite well.  I was able to implement the recording and playback mechanism fairly easily.  I then moved on to content and tweaking.

Content, or creating levels for the game, took quite a while, as I had to read up on some basics of Unity 3D, namely the terrain tool and light-mapping.  The environment assets I had purchased from the Asset Store (First Fantasy) were very pretty, however, I needed to tweak the pre-built terrains to suit my puzzle designs.  I naively thought this would be a simple matter, but quickly learnt I lack experience in artistic matters, so getting things looking “just right” took a few nights.

I spent a night tweaking some particle effects used by the “respawn point.”  I am terrible at particle effects.  They were ultimately replaced with particle effects that came bundled with First Fantasy, and are far better than anything I could ever have achieved.

Lesson learnt: explore your assets thoroughly!

I also spent some of the “content” time implementing new features, namely the ability to throw items, and the ability for the “ghosts” to carry and throw items.  These kinds of things should have been finished for Week 1; Week 2 should be purely for creating content from existing mechanisms.  Looking back on it, I definitely didn’t have the time to implement these things in Week 1, which tells me that my idea was too grand!

Lesson learnt: simplify your game!  You think it’s simple, but it really isn’t!

Ultimately, the “content” phase took around 2.5 weeks, and still fell short in terms of actual content!  There are only two levels in the game, no UI and no sound.

I can live with no UI, and in fact prefer minimal UI in games, but not having managed to put any sounds in makes me a sad panda.  Sounds are probably something that should be implemented “as-you-go,” but I think I could have muddled something together in a night of work.

Lesson learnt: allocate time for adding sounds!

This left me with half a week to test, polish, publish and promote.  Each of these things basically got a night each.  Not great!

I am glad with my decision to spent these remaining nights testing, polishing, publishing, and writing this retrospective, even though the game is a bit short and perhaps doesn’t merit release, as I still learn from the experience.  For example, during the one night spent publishing, I discovered my 20MB game takes a long time to load in a web browser, and could have been shortened using a “web streaming” feature of Unity 3D.  The long download time hurts the user experience, in my opinion.

Lesson learnt: allocate time and plan ahead to make use of web streaming.

If anything, I’ve identified weak areas in my development cycle, so can definitely improve for next month’s game!

I am also resisting, very hard, the urge to develop this game further, rather than begin a new game in March.  #1gam2m

Assets Used – Credit Where Credit is Due!

I should take the time to highlight the assets I have used to help make Respawney what it is, and will definitely be using for other #1gam projects!

As briefly mentioned, the environments, props and effects are from First Fantasy for Mobile.  A great package.  I’ve only used some of what it contains.

First Fantasy

The spaceman character is from Toon Character Pack.  Again, I’ve used a tiny portion of what this package offers.

Toon Character Pack

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s