Star Duck Post-Mortem

Note:  This Post-mortem was written in 2013 and is likely out of date.  I've done my best to transplant it from an old google doc to this web page.

Star Duck is a short proof-of-concept for several design concepts I had been playing with while developing Huskerball.  A short story told in the format of a space shmup, Star Duck can be beaten in about 2 minutes and lacks any real balance testing or longevity.  I entered the project hoping to build upon a basic wave handler / timeline creator and manager that I had built during a different project. I also wanted to see how I could make a pixelated game with 3D models.

I don’t typically make single player games, and when I have (Immo & Thic) they were without dialogue or context.  The hardest part of releasing Star Duck was putting my written dialogue segments into the wild.  While Star Duck is a purposefully sloppy venture, I felt that the writing could have used some tightening up.  I’ve demoed buggy, broken games to people without an issue, but the dialogue in Star Duck has made me feel more vulnerable to other people’s critiques than ever before.  I could probably rewrite it forever and still never be happy with it.  Regardless, I’m happy with Star Duck as far as a proof-of-concept project.

What Went Right

I really love the rendering in Star Duck!  I think there’s huge opportunity space for some crazy stuff with low-fi 3D.  The graphics blitting uses a render texture, so while I have an android build functioning, without Android Pro ($1500!) it runs full res.  When Star Duck runs full res, the over-simplified 3D models become an eyesore, mostly because of the vertex shading on the asteroids.  I also thinking choosing to use real-life images for the portraits meshed well with the goofy feel of the game. I have yet to determine whether using my boss's chin for the bad guy image (Dr CHIN) was a good idea.

The Timeline system and its several components that handle everything from the structure of the level to the behaviours of each enemy is super versatile, primarily because its super simple.  I feel like its the first time I’ve built something that combines flexible, modular code with Unity’s greatest asset - the visual editor.  Levels can be built by dragging ‘Wave’ components into a timeline array.  a wave component can also be its own timeline array, meaning breaking levels into modular pieces is super easy and requires no code.  The same system works for each enemy, where you can create repeatable loops for them to cycle, or recycle themselves after.  if Star Duck was made in 40 hours (probably accurate, thats 8 weeks of work lunches), about 2 hours total was spent executing on level design.

A huge part of Star Duck was having Troy and Orie hop on to help out with audio and music!  It was nice to see the concept resonate with people and have them effectively volunteer to make some stuff for it.  I’m also hugely grateful to Mack for taking the time to test out the latest build every day for a couple of weeks, while giving valuable design feedback.

What Went Wrong 

As mentioned before, I was disappointed to discover that render textures are a pro-only feature in Unity.  The game’s appearance on device made me forfeit writing proper touch controls and releasing an android version, opting to instead just give the .APK to anyone who asks for it.

I also had (probably grandiose) plans to use some friends as voice actors, but at some point I started cutting features like crazy just to finish off the prototype.  Jams, am I right

What Happens Now

Well, I’m back to working on Huskerball.  Mack has asked for the Star Duck source code to fiddle with the timeline based stuff and potentially write some new enemy scripts, so I’m going to pretty that up for him and pass it along.  Once I know more about how well Huskerball’s 2D physics conversion works, I’ll be willing to make a decision regarding making a full-fledged Star Duck game.