Design to Product - Post-Production (17 / 17)

Now that the product has been released, it is time to look back, recollect on lessons learned, and already be buried in to the next adventure.

If you took a look at the game design from the previous section and took a look at the game video (or played the game itself ideally) you might notice quite a few discrepancies from what is described in the document as opposed to what actually was developed.  I cannot stress enough that this is what happens.  Throughout the articles I talked about stuff like requirements creep, play testing, and things like this.  Pretty much all of those things happened, we applied our creative process on to the original game design, and ended up with the product you [hopefully] saw.  Yes, we were bad and never updated the original document, but we also ended up preserving what we started with, and what the end result was.

During development, and using the design as a guideline, we also took a bit of time discussing what features were necessary as opposed to being acceptable for future updates.  One of the fairly easy features to figure as "something for later" is code optimizations.

The game needs to be playable, some minor speed enhancements are ok during development, but finer tuning the engine performance isn't required to get the product completed.  Thus, these things are "nice to haves".

We will also be tweaking some graphics, offering different qualities of game resources, and changing things like timing, based on customer feedback now that the initial product has been released.  We did some basic play testing while the product was under development, but we admit that we are a bit subjective with what is and is not "good" from an outsider's perspective.  Therefore, we will also not rule out "customer feedback" as a guiding principle in what we will still do to the product in to the future.

Of course, some of the blatant things we will work on is when the inevitable "omg this doesn't work on my phone/tablet" feedback comes in.  This is expected to happen and we just await the first complaints.  There really is no way to guarantee that our software will work on all of those device configurations short of us physically testing our product on all hundreds/thousands of them ourselves.  Yes, we can use the emulators, and we do, but this is different than using the actual devices.  For example, it is impossible to test application performance against an emulator if the emulator itself is at the mercy of the power of the computer in which it is run against... this complicates accuracy of the performance testing.

From here, we gaze out in to what we will accomplish with this product.  Minor feature corrections, product enhancements, and possibly even small new features will likely occur and we will be delighted to integrate those things as they happen.  Any major new thing will either warrant a re-release of the product in the form of "2.0" or possibly become a whole other product all together.

At the end of the day, version 1.0 shipped and now we can expect all those hundreds of pennies to come piling in over the months/years it is active in the market!  The product that went from "design to product" took just over 3 weeks to go from start to finish and only time will tell how much money we will gain or lose in the bigger picture from this endeavor.