Design to Product - Release (16 / 17)

Release time is around the corner, some things you might want to check over:

• Take several screenshots of gameplay, use them for marketing purposes
• Save local copies of everything, and I do mean everything, then back them up somewhere
• Make sure the release version number is correct in the software and documentation
• Do one last final general test of the product on your deployment platform

Once everyone on the team has given the thumbs up for release, it is time to package everything up, do one last sanity check over everything, and then publish the product!

Below you will find our original design, screenshots of gameplay, and a link in to the Android marketplace where our product, Bubble Zing, may be found.  This product was in development over the duration in which these series of blog articles were written and took approximately 3 weeks to go "from design to product".

Game Design:
Bubble Zing Design (pdf)

Screenshots:

Menu Screen

Gameplay

Gameplay

Oo, a heart!

Gameplay

Options

Video of Gameplay:

Bubble Zing:
https://market.android.com/details?id=com.eondev.bubblezing
http://slideme.org/application/bubble-zing

Next - Post-Production 

Design to Product - Software Testing (15 / 17)

When is a software product "finished"?  This all depends on who you're asking and in what aspect.  One of the crucial aspects of software houses is testing.  Unlike play testing where people have the potential to have fun with the product, software testing is mostly the opposite.

There are several types of software testing, and this article isn't meant to be a definitive guide on how to perform this job, but I will give a quick run down of what it means and what we do.

Data Validation
During any testing, are the proper inputs handled?  This should be one of the first questions that arise.  Of course, what is good input data, if we can't throw some bad input data in there to spice things up.  Data validation is the process of testing software against good, bad, and unknown data.  What happens when that 0 or 1 input was actually a -1 as input?  Does the program blow up?  We won't know unless we test it!

Unit Testing
This is basically the smallest form of testing.  Do small units of logic perform as expected.  This usually means I test a specific function or method and if the resultant output from that logic is what is expected, I could say that this unit test passed -- it performed as expected.  This testing is more or less automatically performed by the programmer as code is written, or at least it should be!

Performance Testing
Does the software do what it is suppose to do, and do it fast enough?  We may make the next best game ever, but if it runs at 8 frames a second... that's probably bad.

Compatibility Testing
This can sometimes go overlooked (especially on Android phones!), does the software work on multiple different configurations?  Are there weird effects?  Specifically for Android, will the product work on a phone, and an Android tablet?


Acceptance Testing
This is like Software Quality Assurance or Quality Control.  Does the software deliver, on a high level, what the design is?  Think of this like a marriage of software testing with play testing.  Does the product allow the player to actually play the game as designed?  Does the code actually allow for the player to launch new marbles and perform all the functions needed to play?  If these are both yes, then it passed both the play test, and the software test, this the product can be accepted as the product.

For more information about testing, validation, methods to perform them, etc... really, we encourage you to look at the wikipedia article here: Software Testing.  The trick is to find what works for you and use that.

Next - Release

Design to Product on Android - Game Design (7 / 17)

Finally, we can start making a game!!! Let's crack open our favorite Integrated Development Environment (Eclipse in this case) and start forging all that hot code all over the place... err wait, what am I going to make?!  Oh who cares, I can make a game/product on the spot!

Whoah easy there code vigilante!  Let's take a moment to actually design what we're doing first.  Again, in software engineering, lots of people assume that programmers just make code.  Well, that's nice, but there probably should be at least some documentation in terms of what are the features needed in a project to make. Programmers use this as a roadmap (and even a task list) of what they need to make.  Once made, it serves doubly useful as a checklist of what to test to make sure the product was made correctly.  Remember, at this point, we're not even talking about software design, just the content of the product itself -- not even code yet!

Of course, testing the product is a fairly large topic in itself as well and will likely get its own article.  Suffice to say, an acceptance test looks at a design, looks at a software product and then validates and verifies that the product is what was desired in the first place -- thus it is accepted as the product.

We will come back to game design on and off throughout the series.

*** Updated section ***
Originally, we did not post the game design here because it wasn't finalized, plus we didn't want the "spoilers" of the actual game getting out before we really thought the whole game through.  Since the product was posted, the finalized game design can be found here:
BubbleZing game design

This game design document was first linked when we released the product at the end of this series, but is now retroactively linked here for convenience.
*** End new section ***

Next up, let's start analyzing what kind of art specifications and styles we want to incorporate in the game.  Once our design was completed, we started toying with ideas of what it should look like, the theme, how to go about generating/acquiring the art assets.  So, next up is the design of the art itself.

Next - Art Design