New School Blues Dev. Diary #36: Post Mortem

New School Blues and its development came from an idea: introducing 3 newly graduated game designers to the realities of developing a game in an indie studio atmosphere.  Untold Entertainment President Ryan Creighton took it upon himself to give three greenhorns a shot at building something in the Untold office.  Artist and animator Jonathan Phillips, programmer Amir Ashtiani, and myself, producer Mike Doucet, got together with the purpose of building a game and launching it for the web, iPad, and Android Tablet, in a bit less than two months.  

The original idea was to start in mid-October and launch by mid-December.  Being the first intern on the scene I placed postings online and screened candidates for the team, wrote up an initial design doc based on Ryan’s specifications and when the group was settled, off we went.  By specifications I mean two things.  The first was the type of game and its target audience.  Untold is a family friendly studio so the game had to be suitable for kids in case Ryan decided to publish it himself (he held that right).  The second was it had to be developed using the UGAGS engine (Untold Graphic Adventure Game System), which Ryan was gracious enough to let us use knowing we didn’t have much time and could use the hand.  UGAGS also meant the game would need to be a graphic adventure created in Flash.  We were happy to make the game kid friendly since the school setting lent itself well to that audience.  And as for UGAGS, as you’ll read later, we were definitely grateful to have it.

The deadline was extended to mid-February for a thankfully awesome reason:  Ryan had decided to publish the game and its ports himself!  This meant, however, a delay in launching since Untold had its fair share of commitments for the New Year.  The good news is that gave us an extra month and a half to playtest, fine tune, and polish the game so it ended up better than ever.  That extra time also gave us the opportunity to look into and perform extra promotional duties we had to sideline in getting the game done on schedule.

We launched on February 25th, 2013 and that week alone managed to get just over 750 downloads on the App Store, not including Android downloads and online web players.  It’s hardly breaking records, but for the three of us it was a great start and we’re proud our little game made it to that many hands in its first week out.  Obviously, none of this would’ve been possible without Ryan Creighton’s understanding, tutelage, and time; so if he’s reading: thanks Ryan!

Now that you’ve got the brief rundown on how NSB came to be, let’s look a little deeper at its development, specifically at…

——

What went right:

1) Audio - POWER PONY!:  

Early on in development it was abundantly clear that we’d need someone to take care of the audio assets needed for the game.  I had dabbled a bit with it in past projects but we were all hoping for something a bit more professional and polished.  We sent a call out across various social media outlets in the Toronto game development community for audio designers who had experience composing and recording voice work.  After a few interviews we decided to partner with Ryan Roth (@DualRyan - also IGF nominee for Starseed Pilgrim!) and held a few quick meetings just to make sure everyone was clear on the type of audio design and score we needed.

To say audio went well is an understatement.  Not only was communication, regular, fluent, and professional on both sides, Ryan delivered his audio assets on schedule and was receptive to any comments or feedback we had to give.  Everyone knows sound gives off much of the game’s personality, and without a doubt Ryan’s ideas and work gave NSB a ton of its character.  Dexter Howe (@DexterHowe) provided the vocal talent and he was a delight to work with as well as an excellent narrator to our game.  We couldn’t be happier with how NSB sounds and it is one of the most commented on and complimented aspects of the game.

2) The Dev Diary - Keeping things real:  

Very early in the project we had decided to start and maintain a development diary on the processes needed to complete NSB.  This idea isn’t anything new, but rather than the standard “here’s a pic of what we did, see you next week” sort of posts, we wanted to make regular and daily entries into the dev diary, as well as describe in detail the process in question that day.  It added up to a lot of extra work, but the rewards were threefold.

First of all, in researching and writing about each step of game development in an indie studio setting, we were that much clearer and more informed on the tasks that lay before us.  We engineered each post to be as if we were describing the process to someone unfamiliar with the games industry.  Simply put, typing something so anyone can understand it, means YOU have to understand it, so the dev diary kept us informed and on task.

Second of all it was a great way to get the word out about the game and get people both in and out of the industry to see what we were doing.  Having updates every single day, as well as updating our Facebook, LinkedIn, and Twitters with each entry, really lent legitimacy to what we were doing and showed other devs and the press we were serious about creating something polished and fun.  Finally, it provided a road map to wherever we were in the present and served as a great reference piece after the game had launched to see where things may have gone right or wrong.

3) Teamwork - Ego checked at the door: 

This one is probably the most important, and the one we are the most proud of getting right.  Communication all during the project was fluent, regular, and most of all professional.  Anytime there were disagreements regarding design, story, puzzles, heck - anything at all, we discussed it without any kind of egotripping.  Every change, cut, or tweak was for the good of the game and we all knew it.

We held meetings every Friday in a Scrum-like fashion, listing what was done, what would be done next week, and what might stand in our way.  These light Agile practices, combined with our trust and commitment to the game and making it great, made for a very smooth development experience in terms of professional relationships.

So three perfect strangers get together in a foreign setting and build a game from scratch, dealing with whatever new obstacles or tasks that get thrown at them.  And when all was said and done what came out of it?  A game that’s fun and finished on schedule, and a team that got along the entire time and never wanted to kill each other.  Sounds like a win for teamwork to us.

4) Polish - There’s done, and then there’s DONE:  

The polish here stands for polish in gameplay design, UI design, art and animation.  As stated before we had extra time following our original mid-December launch window since Untold decided to publish the game.  We used that time not only for promotional work, but mostly for polish.  We sent builds to members of the game development community in Toronto and received a ton of constructive criticism and feedback regarding how to make the game better.

Some issues meant tearing up a bit too much of the game for how long we had until the new launch date though, and some, while dealt with, could’ve been prevented with a bit more foresight (as explained later).  But either way, the majority of the criticisms were addressed, culminating with an NSB experience that is much smoother than before.  One of the most frequent compliments we received since launch is how polished the game looks for what amounts to a 2-3 month project by interns new to development.  That polish also went a long way in getting the press to notice NSB as not just another rough around the edges basement Flash game.

5) UGAGS - The backbone: 

As stated before, one of the provisos for working at Untold to complete this project was that we would use the Untold Graphic Adventure Game System - graciously offered to us by Ryan - to do it.  We were incredibly grateful for having a tool to help us through the development process.  Granted UGAGS was incomplete at the time, but the majority of the framework was there and we filled in the gaps where needed.  While we occasionally struggled, we never felt it was the engine getting in our way, more our own inexperience.  Quite simply, NSB wouldn’t have happened without it, so UGAGS is definitely something that went right once we learned its intricacies.

What needed work:

1) Promotion - Get the word out: 

Simply put, none of us are experts on promoting products and forming relationships with the press because we never really had to.  While the dev diary, LinkedIn, Facebook, and Twitter accounts were successful in drawing attention to the game and worthwhile in updating it still didn’t reach quite enough people as we would’ve liked.  Also while statements and a press kit were formed and releases sent out, responses from the press were pretty rare and not many people really picked up the story.

This could be for a bunch of reasons - arguably a big one being that a mini graphic adventure game made by 3 interns isn’t too sexy of a news item - so we’re not kicking ourselves too hard.  That being said though, on future projects we’ll use the feedback we’ve received on how to make things more newsworthy and effective to plug our game across a lot more media channels and really push the promotional side.

2) Flexibility - Not Agile enough: 

When developing NSB we tried to make things as flexible and Agile as possible.  Rather than a typical waterfall approach we opted to split the two months into 3 week sprints where upon the end of each sprint we’d have a prototype better than the last culminating in the final build.  This IS technically what happened.  By the end of the project, however, our initial flexibility was replaced by “on-rails design”.  In other words, while we started fairly open-ended and conducive to changes in design, as time went on we felt more and more constricted to using the assets and gameplay design we currently had, even if that meant it wasn’t the best we could do.

For example, we had a puzzle that dated all the way back to our initial document.  It had been prototyped and planted in game and everything seemed rosy for a couple weeks.  When playtested though it became really apparent that the puzzle wasn’t clear and needed to be tweaked.  Not only did that mean changing a number of assets in game, rewriting code, and re-designing the puzzle, it also meant we needed to get our voice actor back in studio to re-record some lines.  It all ended up working out fine, but none of this would have been necessary if we had kept things as flexible as we had previously.  By putting off testing and pushing the creation of sound and art assets (albeit for the right reasons of getting the game done) we unwittingly shoehorned ourselves down a path that made deviations tricky.  The opposite of Agile, really.  Next time, we’ll know to keep things looser.

3) Underestimates - You’ll need more than you think you’ll need: 

Underestimating the amount of work or assets needed to complete a project while during the pre-production phase is hardly rare.  In fact you could argue virtually every project begins with people underestimating how much really needs to be done.  Something always comes up down the line you hadn’t thought of before.  That’s pretty normal, and we’re not beating ourselves up too much for that one.

Still though, it became abundantly clear halfway through the project that whatever documentation, schedules, and asset lists were created, and however detailed they were, they were not detailed enough.  Fortunately with such a small team and with us all dedicated to the project as we were it didn’t result in any real damage.  But still, next time around more time will be spent creating much more detailed schedules with specific action items and milestones, as well as exhaustive lists of the art, code, and audio assets needed.

4) Inexperience - Plain and simple: 

To be blunt, a lot of the little things that went wrong were just due to us having never done it before, and therefore not having a reference point for when things are going awry.  For example, Jonathan now feels like he spent a bit too much time early in the project creating fully fleshed out assets, instead of creating quick placeholder art and tweaking as time went on.  While everything still got done, not being able to accurately gauge from experience just how much time tasks should take definitely had consequences that in hindsight we see pretty clearly.

Amir spent a significant amount of time creating workarounds to UGAGS issues using XML, rather than going into the actual AS3 code and tweaking from the source.  That was a team decision brought on by us concerned we wouldn’t have time and that workarounds would just have to do.  Again, it all worked out great, but in retrospect we now know we would’ve been better off taking that time in AS3 so workarounds wouldn’t have been necessary later.

Audio was a similar situation in that we (justifiably) felt that the sooner we get the assets done, the better.  After all, if studio time or vocal talent needed to be rebooked we didn’t have much leeway, if any.  It makes sense that we’d push for that to get done.  The problem was having all the vocal work finished made us feel chained to that script and design (as indicated previously).  For future reference, we’ll have a better idea of how long the audio will take to get done and schedule it a bit further in development so not to create another instance of “on rails” design.

Obviously this same problem with time estimation applied to scheduling and documentation as well.  We designed the schedule with preconceived notions of how long it would take assets to be created and prototypes to be made.  With the knowledge we have now those milestones would be much more realistic, detailed, and regimented.

——

All things considered we had an amazing time and are very proud of our first title.  We worked hard, worked together, learned a ton, got our game out on 3 platforms for players to enjoy, and received a healthy chunk of positive feedback from devs and players alike.  As a first time development team on their first game, you can’t ask for much more than that.  Thanks for reading and catch you next post!