After coding for a bit, redesigning, testing, then coding some more, we ended up with the basic elaboration to our software design. Please note that this is a live process. In other words, when we found snags, re-analyzed what we were doing, and asked ourselves how we could go about doing it better, we scrapped some work "for the greater good" (whatever that means).
So, here is a breakdown of the major classes of the project and what they do on a conceptual level. Normally a UML diagram or something here would be sufficient, but we're renegades like that.
Bubble
This class deals with every "bubble" in the game. The gameplay is such that new bubbles are spawned at the top of the playing field and slowly descend towards the bottom of the screen. This class handles the updating process (how much and how far does each bubble move), as well as drawing each bubble. Each bubble also has a value which pertains to its assigned color (which is randomly assigned in generation).
For some static functionality, this also handled loading all game resources associated with bubbles (like the bubble graphics themselves). The most important point here is that all graphics should be loaded once and only once then drawn per instance of a bubble.
Gamedata
This is a convenience class that handles persistent data about the game itself. Specifically, this remembers the player's options whether to have the sound on or off. Originally, it was designed to also keep track of in game purchases with points, but as the design evolved, this feature was removed. Because all of the "persistence layer" stuff was conveniently packaged in this one class, adding and removing new things is easy.
GameThread
The bulk of the higher level stuff is in this class. Big questions are handled here, like "is the player in any menu", what to do when the player wants to pause/resume the game (this is the in game feature, not the activity pause/resume), high level resource initialization, the game loop itself, touch event propagation to support classes/objects, and things like this.
This class also handles the Android lifecycle events of pausing and resuming, which is completely different than the in-game feature. We put this functionality here because it has high level access to basically everything in the actual game logic that needs to know about activity life cycle events such as these.
GameView
Not too much to say here other than this is our version of the SurfaceView class used by Android.
Marble
Like the bubble, this class handles everything that has to do with the player marbles. These marbles need to be updated every game cycle so they have an update method, need to be drawn on the playing field, and need to be spawned based on player input.
There are some methods that let us query what kind of marble this is. Specifically, is this a "normal" marble or is this a "special" marble. In the gameplay, normal marbles are simple red, green, blue, yellow playing pieces, and special marbles are just that. They do things that normal ones don't. The game design had changed over development - originally, we had rainbow marbles, rocks, purple marbles, and heart marbles. This changed to only have rocks and purple marbles (more on this in the post-production article later).
At any rate, this class is very similar to bubbles and share the same design, but different code from each other.
MarbleSlot
This class is "part of" the playing field. This handles the player's desire to launch marbles from it. Each slot contains a marble value and when it comes time, the playing field spawns a new marble based on which slot the player initially touched.
Logically, these slots are just defined zones in the playing field that define whether or not the player touched a specific area and don't do much else other than that. Based on the assigned marble value, it also draws a colored marble to represent what marble will spawn when interaction occurs.
PlayingField
This is the over-arching class one step down from the game thread itself. This "contains" every intractable aspect of the game, all marbles, all bubbles, and even the GUI while playing. This large class handles all the essential gameplay logic to include setting up a new game, actually creating new marbles from the slots, propagating update method calls, propagating draw method calls, increasing player marble stock, harming the player, resource management, and lots of supporting methods - including collision detection/response.
From the game thread, a playing field instance is created and basically sticks around until the program is considered "finished".
PlayingPiece
This class is a parent class to Marbles and Bubbles and defines what exactly makes them playing pieces. The class defines a collision flag (used for collision detecting), a velocity vector, a RectF object used to define piece positions (and drawing boundaries), a method to calculate the distance to another playing piece (used again for collision detection between marbles and bubbles), and some convenience methods shared by marbles and bubbles.
Almost anytime there is overlapping features or methods used by more than one class, it is almost always a good idea to create a parent class. Essentially, this is like saying "ok, so, we have this cool new game, it involves some playing pieces that collide with each other"... what does that mean? Well, those pieces are either marbles or bubbles and their interaction with each other. Excellent candidate for a parent with two children sort of situation.
Wednesday, February 29, 2012
Wednesday, February 22, 2012
Design to Product - Software Design (12 / 17)
Finally, let's talk about how the code should be set up.
We mentioned earlier that we took the game design, analyzed it, and figured that nouns become classes and verbs become methods. This sounds good on paper, and there are even tools available to help this process. We could sit around and chart UML all day, every day in regards to the design, but is it necessary? That depends.
Because our product isn't an enterprise solution, our team is small, and one guy is basically doing everything, a massive UML chart isn't really necessary. Of course, we could never discount the idea that someday in the future these things could become useful (like if we sold our products off to another company, as an example).
Regardless, the best way forward for us is to pick apart the major components of the design and start designing what logic should go where and what it should be called.
Honestly, because of our development methodology (or lack there of, depending on who you ask), we take more of an extreme programming measure in this regard. We make classes as we need them. We start with a basic skeleton framework, then start adding new classes as they are needed in the code itself as we program the meat and bones of the product.
We start with the largest classes in the skeleton. Specifically, for Android programming, we start with the GameActivity class. This class acts, more or less, as the "starting point" for the program and interfaces with the OS. Because of how Android itself is designed, we must make a GameThread class that contains the top level logic for the flow of the game itself. We also will need an extension of a View class so that we can interact with the screen and display stuff.
Right away we have:
GameActivity
GameThread
GameView
Without really even going further, based on the game design, we know we already have 2 major components to the product, a Marble, and a Bubble. These playing pieces are what are the basic, interactable things in the game itself. Because both things follow the same physics, we decided that it is best they share a common parent class; PlayingPiece. This parent class defines movement vectors, collision information, the abstract methods of how the pieces are updated and that each child class should know how to draw itself to the screen.
At the same time, we can't really play the game without some sort of logical thing to interact with and where the playing pieces do their magic. Enter the PlayingField, a logical container that contains everything the player can interact with and see.
The game design indicates the need for persistent data over game launches, so we made another class Gamedata that is our "middle man" that handles data saved and loaded between game sessions.
We also ended up needing a class called MarbleSlot, a place where players can touch and interact with the playing field in which marbles can be spawned from.
All that said we now have:
Bubble
Gamedata
GameThread
GameView
Marble
MarbleSlot
PlayingField
PlayingPiece
There are one or two utility classes that are used to assist in the passing of data and messages between classes, but those are fairly technical and don't have anything to do with the direct design of the content of the game. Suffice to say, those can take a while to design and program as well. Just because a game design is "simple" doesn't mean the work behind it will take a set number of hours based on the relative ease of that design. Lots of "stuff" can go on behind the scenes that can take days or even weeks to implement that have no actual, obvious visual effect on the product itself.
For example, a programmer could spend a month just drawing some graphics on a display. They are very proud of this accomplishment, but to non-programmers they usually have the attitude of "you spent a month on this, and only have this to show for it?!". Get used to scenarios like this because it happens more often than not.
Anyways, now that we have our basic classes determined, the essentials are fleshed out.
Tune in next time for elaboration of the class designs and the overall flow of the logic for some of them.
We mentioned earlier that we took the game design, analyzed it, and figured that nouns become classes and verbs become methods. This sounds good on paper, and there are even tools available to help this process. We could sit around and chart UML all day, every day in regards to the design, but is it necessary? That depends.
Because our product isn't an enterprise solution, our team is small, and one guy is basically doing everything, a massive UML chart isn't really necessary. Of course, we could never discount the idea that someday in the future these things could become useful (like if we sold our products off to another company, as an example).
Regardless, the best way forward for us is to pick apart the major components of the design and start designing what logic should go where and what it should be called.
Honestly, because of our development methodology (or lack there of, depending on who you ask), we take more of an extreme programming measure in this regard. We make classes as we need them. We start with a basic skeleton framework, then start adding new classes as they are needed in the code itself as we program the meat and bones of the product.
We start with the largest classes in the skeleton. Specifically, for Android programming, we start with the GameActivity class. This class acts, more or less, as the "starting point" for the program and interfaces with the OS. Because of how Android itself is designed, we must make a GameThread class that contains the top level logic for the flow of the game itself. We also will need an extension of a View class so that we can interact with the screen and display stuff.
Right away we have:
GameActivity
GameThread
GameView
Without really even going further, based on the game design, we know we already have 2 major components to the product, a Marble, and a Bubble. These playing pieces are what are the basic, interactable things in the game itself. Because both things follow the same physics, we decided that it is best they share a common parent class; PlayingPiece. This parent class defines movement vectors, collision information, the abstract methods of how the pieces are updated and that each child class should know how to draw itself to the screen.
At the same time, we can't really play the game without some sort of logical thing to interact with and where the playing pieces do their magic. Enter the PlayingField, a logical container that contains everything the player can interact with and see.
The game design indicates the need for persistent data over game launches, so we made another class Gamedata that is our "middle man" that handles data saved and loaded between game sessions.
We also ended up needing a class called MarbleSlot, a place where players can touch and interact with the playing field in which marbles can be spawned from.
All that said we now have:
Bubble
Gamedata
GameThread
GameView
Marble
MarbleSlot
PlayingField
PlayingPiece
There are one or two utility classes that are used to assist in the passing of data and messages between classes, but those are fairly technical and don't have anything to do with the direct design of the content of the game. Suffice to say, those can take a while to design and program as well. Just because a game design is "simple" doesn't mean the work behind it will take a set number of hours based on the relative ease of that design. Lots of "stuff" can go on behind the scenes that can take days or even weeks to implement that have no actual, obvious visual effect on the product itself.
For example, a programmer could spend a month just drawing some graphics on a display. They are very proud of this accomplishment, but to non-programmers they usually have the attitude of "you spent a month on this, and only have this to show for it?!". Get used to scenarios like this because it happens more often than not.
Anyways, now that we have our basic classes determined, the essentials are fleshed out.
Tune in next time for elaboration of the class designs and the overall flow of the logic for some of them.
Tuesday, February 21, 2012
Design to Product - Requirements Creep (11 / 17)
While designing, programming, and testing, we came up with some new ideas of how to make the game better.
The dreaded phrase "ya know, this would be cool if...". Yes that. What just happened is something called requirements creep, or rather, features and things that were not part of the original design document, but have become desired enough to "add in" some extra things or at least change a couple of things that we had already designed.
This sneaky way of adding new things in to the product forces us to change code, update documentation, and start our testing all over again with the new things put in to the product. Long and sad story short, it simply means more time is required before the product can be released. WARNING: If this gets out of hand, your product will be delayed indefinitely as more and more new things keep getting piled on!
Fortunately, some of these sneaky new features that were drafted up can wait until after the game is released and we can put the new content in with a content patch later. If you've been reading along, during an earlier blog article I mentioned separating things that we need versus what we want. Requirements creep operate the same way. What must we absolutely have to have in the initial product release versus what can wait. There is a risk involved with this. The more we "must" have before initial release, the longer the product will take to get out the door... but if those new features really enhance the product and make it more appealing or playable, we certainly should include it.
For example, during our play testing, we saw that most the gameplay levels were "too easy". The player could easily fly through the game levels without much of a challenge. According to the design, this was basically as the product was designed. Well, unhappy with it, we decided that different sized bubbles should play a part of making the game more difficult as the game levels were increased. This new "feature" wasn't part of the original design - nor was the existing code ready to make such a new leap in to catering to differing size bubbles.
Because we felt that this sort of thing should be required to make the game more challenging and offered in the initial product, we accepted the new feature, and the recoding of the necessary systems began.
Since our code was relatively easily adapted to the change, it took about 4 hours to modify the existing code and test it to approve that the game now has incorporated the changed feature. If your software person/team is inexperienced, or the code you've inherited is "bad", even a simple change like this could take days to implement. You may scoff at this idea, but I will reiterate my earlier warning, even the smallest things can take a dreadful amount of time to incorporate. Even something as so much as changing the color of something can take a very long time - it all depends on how the software was designed, their existing features, and how well things were programmed, and of course there could be other unforeseen technical problems further complicating the desired changes.
During our testing and development, we also found it necessary to upgrade our core code reuse library to incorporate more graphics utility functions because of the demands on this product. This took a couple extra hours to research, code, and test. The tradeoff is such that now projects in the future can reuse this code, saving the time and headache later of having to redevelop it again.
While programming a game, or really any software, the programmer should always be aware of what they are making could be generalized in to useful and reusable modules for other projects. There is, again, a tradeoff to "just make this feature" and "generalize" it for generic use. It usually is quicker just making the solution once while specifically tailoring it for the one active project, but if another project needs that functionality, it takes more time later to surgically remove that code from the project and alter it later for the newer product. The experience of the programmer here will help them dictate when and what they should generalize.
A specific example of this - one of our products that hasn't been released yet uses a feature to flash the screen red when the player takes damage. During the development of the new product, it was mentioned "hey, it would be nice to have a visual indicator for when the player takes damage". It was quite apparent that the code from the older, unreleased project should be recycled in to this new project. Of course, this functionality wasn't generalized in to a code library; however, the existing feature was found to rely on almost no external variables in the older product, and the code was easily extracted from the 3 different functions that it was hooked in to. There were a couple of dangling variables that was required for the code to work as well, so there was some time needed to track those down and copy those over as well. These variables had to do with the time involved with "how long to flash the screen" as well as "how much red is flashed at a given time".
If the older code was sloppy, or had I not been intimately familiar with the code, a job like this - tracking down code/features to extract - can take a while. This is something that shouldn't be taken lightly when planning how long a product will take to develop. Code reuse is good and saves time, but if you have to attack another product with a scalpel to find all the code to reuse, it can be a nightmare in itself.
Ok, so, we had a requirements creep with the flashing feature. It took about 30 minutes to track down our existing code to make this happen and we integrated it in to the new product -- in theory. Remember, we need to test the new code to make sure it wasn't rejected by the new product! Sure enough, we attempted to test it; and nothing happened when it was suppose to.
A quick "oh duh" moment later, and we realized we forgot to call our new flashing code when the condition warranted it. We integrated the code, but forgot to actually use it.
We decided to call the new flash code from inside the method where players take damage and decided to test it again. Huzzah, it worked! Not only did it work, but it worked as expected!
Long entry, but take away from this that new things, small things, and even big things can, and will, come up during coding and testing. Some of these things fall in to the "need to have" category and can add substantial time involved in to the development of your product.
Next time we'll get in to the software design aspect of the product, I hope!
The dreaded phrase "ya know, this would be cool if...". Yes that. What just happened is something called requirements creep, or rather, features and things that were not part of the original design document, but have become desired enough to "add in" some extra things or at least change a couple of things that we had already designed.
This sneaky way of adding new things in to the product forces us to change code, update documentation, and start our testing all over again with the new things put in to the product. Long and sad story short, it simply means more time is required before the product can be released. WARNING: If this gets out of hand, your product will be delayed indefinitely as more and more new things keep getting piled on!
Fortunately, some of these sneaky new features that were drafted up can wait until after the game is released and we can put the new content in with a content patch later. If you've been reading along, during an earlier blog article I mentioned separating things that we need versus what we want. Requirements creep operate the same way. What must we absolutely have to have in the initial product release versus what can wait. There is a risk involved with this. The more we "must" have before initial release, the longer the product will take to get out the door... but if those new features really enhance the product and make it more appealing or playable, we certainly should include it.
For example, during our play testing, we saw that most the gameplay levels were "too easy". The player could easily fly through the game levels without much of a challenge. According to the design, this was basically as the product was designed. Well, unhappy with it, we decided that different sized bubbles should play a part of making the game more difficult as the game levels were increased. This new "feature" wasn't part of the original design - nor was the existing code ready to make such a new leap in to catering to differing size bubbles.
Because we felt that this sort of thing should be required to make the game more challenging and offered in the initial product, we accepted the new feature, and the recoding of the necessary systems began.
Since our code was relatively easily adapted to the change, it took about 4 hours to modify the existing code and test it to approve that the game now has incorporated the changed feature. If your software person/team is inexperienced, or the code you've inherited is "bad", even a simple change like this could take days to implement. You may scoff at this idea, but I will reiterate my earlier warning, even the smallest things can take a dreadful amount of time to incorporate. Even something as so much as changing the color of something can take a very long time - it all depends on how the software was designed, their existing features, and how well things were programmed, and of course there could be other unforeseen technical problems further complicating the desired changes.
During our testing and development, we also found it necessary to upgrade our core code reuse library to incorporate more graphics utility functions because of the demands on this product. This took a couple extra hours to research, code, and test. The tradeoff is such that now projects in the future can reuse this code, saving the time and headache later of having to redevelop it again.
While programming a game, or really any software, the programmer should always be aware of what they are making could be generalized in to useful and reusable modules for other projects. There is, again, a tradeoff to "just make this feature" and "generalize" it for generic use. It usually is quicker just making the solution once while specifically tailoring it for the one active project, but if another project needs that functionality, it takes more time later to surgically remove that code from the project and alter it later for the newer product. The experience of the programmer here will help them dictate when and what they should generalize.
A specific example of this - one of our products that hasn't been released yet uses a feature to flash the screen red when the player takes damage. During the development of the new product, it was mentioned "hey, it would be nice to have a visual indicator for when the player takes damage". It was quite apparent that the code from the older, unreleased project should be recycled in to this new project. Of course, this functionality wasn't generalized in to a code library; however, the existing feature was found to rely on almost no external variables in the older product, and the code was easily extracted from the 3 different functions that it was hooked in to. There were a couple of dangling variables that was required for the code to work as well, so there was some time needed to track those down and copy those over as well. These variables had to do with the time involved with "how long to flash the screen" as well as "how much red is flashed at a given time".
If the older code was sloppy, or had I not been intimately familiar with the code, a job like this - tracking down code/features to extract - can take a while. This is something that shouldn't be taken lightly when planning how long a product will take to develop. Code reuse is good and saves time, but if you have to attack another product with a scalpel to find all the code to reuse, it can be a nightmare in itself.
Ok, so, we had a requirements creep with the flashing feature. It took about 30 minutes to track down our existing code to make this happen and we integrated it in to the new product -- in theory. Remember, we need to test the new code to make sure it wasn't rejected by the new product! Sure enough, we attempted to test it; and nothing happened when it was suppose to.
A quick "oh duh" moment later, and we realized we forgot to call our new flashing code when the condition warranted it. We integrated the code, but forgot to actually use it.
We decided to call the new flash code from inside the method where players take damage and decided to test it again. Huzzah, it worked! Not only did it work, but it worked as expected!
Long entry, but take away from this that new things, small things, and even big things can, and will, come up during coding and testing. Some of these things fall in to the "need to have" category and can add substantial time involved in to the development of your product.
Next time we'll get in to the software design aspect of the product, I hope!
Sunday, February 19, 2012
Design to Product on Android - Delays (10 / 17)
During our software design and programming of the app, various delays have already been cropping up. Specifically with the business side of the house. We've been meeting with people and potential contractors for other projects we're working on. While ultimately this is a good thing, it does take a toll on the direct development of the project.
Truth be told, these were fairly predictable delays and were taken in to account during earlier phases of planning.
In other good news, we acquired a music track that will be placed in one of our products. In addition, we have been created more artwork and content for this new product.
Er, instead of going in to software design next, we'll be talking more about a prevalent issue with software development - the requirements creep. A dreaded topic in all software shops and definitely something of prominence in the games industry.
Truth be told, these were fairly predictable delays and were taken in to account during earlier phases of planning.
In other good news, we acquired a music track that will be placed in one of our products. In addition, we have been created more artwork and content for this new product.
Er, instead of going in to software design next, we'll be talking more about a prevalent issue with software development - the requirements creep. A dreaded topic in all software shops and definitely something of prominence in the games industry.
Wednesday, February 15, 2012
Design to Product on Android - OMG Code, well almost! (9 / 17)
Ok, finally, we're talking about the core of app development, the coding!
First, I must emphasize that it is probably in your best interest to consider using an app library, or writing your own. This will substantially cut down on the time needed to make a game (or probably any app for that matter). Of course the trade off is learning the external library, figuring out its limitations, and making new products with it, which translates to more initial time involvement, but could pay out in the end.
As for us, we developed a small game library that has some very basic code all wrapped up in to a tiny, neat package. It mostly allows us to mangle with time functions, "button" code, random numbers, and some other graphical utility functions (like getting the current display orientation, the density of the screen, the screen dimensions, etc).
If you make your own library, like we did, I highly recommend putting any and all code that you think is generic enough that *all* projects of yours in the future could want.
If you didn't already know, you will have to have some way of writing code. We recommend using Eclipse with the Android SDK, it's free, works, and packs various useful conveniences while developing. You will also need someone versed in Java and able to use the Android SDK.
If your person doing the development is new to Android, Java, or both, we highly recommend making some test projects first, before attempting to make your dream game/app.
It is our intention for this to not be a tutorial on how to make an app in detail, but rather talk about designs and coding specifics instead, more or less from a management perspective/process.
Ok, so once we have our IDE all set up, we can look over our game design and start plotting how we want to design the software itself.
Different software process methodologies deviate greatly in this area, our studio essentially identifies major topics/nouns used in the design of the product and USUALLY makes an assumption that those will be Java classes. I mentioned *usually* because this isn't always the case and we also do not use any automated tools or UML or anything goofy like that.
Instead, we look at the major concepts of the design and turn those in to classes first. Specifically, we know that we will need a PlayingField where by all "game playing" will take place. That becomes a class (and a very useful one at that).
Because of how Android works, we must have an Activity class. From there, we also must have our own SurfaceView class (we implement a GameView class that inherits from SurfaceView), and a class which encapsulates the main processing of the game. We make a GameThread class that inherits from Thread so that all our game processing can take place on its own.
So, without really getting in to picking apart our design, we know we have the following classes already:
GameActivity
GameView
GameThread
PlayingField
While we pick apart our design and start coding, the blog will be inactive for the next couple of days.
First, I must emphasize that it is probably in your best interest to consider using an app library, or writing your own. This will substantially cut down on the time needed to make a game (or probably any app for that matter). Of course the trade off is learning the external library, figuring out its limitations, and making new products with it, which translates to more initial time involvement, but could pay out in the end.
As for us, we developed a small game library that has some very basic code all wrapped up in to a tiny, neat package. It mostly allows us to mangle with time functions, "button" code, random numbers, and some other graphical utility functions (like getting the current display orientation, the density of the screen, the screen dimensions, etc).
If you make your own library, like we did, I highly recommend putting any and all code that you think is generic enough that *all* projects of yours in the future could want.
If you didn't already know, you will have to have some way of writing code. We recommend using Eclipse with the Android SDK, it's free, works, and packs various useful conveniences while developing. You will also need someone versed in Java and able to use the Android SDK.
If your person doing the development is new to Android, Java, or both, we highly recommend making some test projects first, before attempting to make your dream game/app.
It is our intention for this to not be a tutorial on how to make an app in detail, but rather talk about designs and coding specifics instead, more or less from a management perspective/process.
Ok, so once we have our IDE all set up, we can look over our game design and start plotting how we want to design the software itself.
Different software process methodologies deviate greatly in this area, our studio essentially identifies major topics/nouns used in the design of the product and USUALLY makes an assumption that those will be Java classes. I mentioned *usually* because this isn't always the case and we also do not use any automated tools or UML or anything goofy like that.
Instead, we look at the major concepts of the design and turn those in to classes first. Specifically, we know that we will need a PlayingField where by all "game playing" will take place. That becomes a class (and a very useful one at that).
Because of how Android works, we must have an Activity class. From there, we also must have our own SurfaceView class (we implement a GameView class that inherits from SurfaceView), and a class which encapsulates the main processing of the game. We make a GameThread class that inherits from Thread so that all our game processing can take place on its own.
So, without really getting in to picking apart our design, we know we have the following classes already:
GameActivity
GameView
GameThread
PlayingField
While we pick apart our design and start coding, the blog will be inactive for the next couple of days.
Monday, February 13, 2012
Design to Product on Android - Art Design (8 / 17)
Ahh, what the game will look like. More importantly, how does the art work in a game title anyways? What is the visual play experience? Also, the design of the art had better match the programming capabilities of the game engine! No point in making beautiful 3d graphics if the software you're making cannot do 3d anything!
For sake of simplicity, our studio is currently using mostly Inkscape (it's free!) for high quality Scalable Vector Graphics. We have limited talent in-house for art, so this takes us a little while to "get right".
Android apps require some special handling when it comes to the artwork, specifically with catering to different graphics densities on various displays. This means that ideally, we will have a couple different versions of the same piece of art so that displays that can do "high definition" can use higher quality graphics, while displays that are from forever-ago can still render something (albeit very pixelly - hah new word).
The design of the art should be such that the same art can be easily scaled up and down. This requirement led us to Inkscape (or Illustrator I suppose if you wanna pay money) so that we retain ultimate flexibility with scaling stuff up or down while using the same piece of art. Short of pixel art, vector graphics are simply amazing and save a ton of time later down the road when you want to recycle graphics.
To keep things simple, we usually try to make hard colored, cartoony like graphics. The lighting and shading usually translate very well to small display sizes, and that is a big bonus for small displays.
Something that we learned from our earlier title Blocks Away! Is that we can use a grayscale version of a graphic and apply colors (using a multiply colorfilter) to the graphic in the game engine, this reduces the graphics work needed by quite a lot if the graphics themselves are simple enough and don't require too much recoloring work. For example, in that game, we used a single white block, then just recolored the other blocks in the engine. For this new game, we will try to reuse this trick to save work on the art, but ultimately, we may need to have different graphics for differing colors of game pieces.
Regardless of what we do, we need to consider the design of the art itself. Shy away from ultra realistic and super mega amazing high quality stuff -- it simply does not translate well to small screens of phones, plus the production time and cost involved can be astronomical for small studios if this is outsourced, meaning we sort of have to do this ourselves with out limited experience in this area.
Some of the graphics we're probably going to use are here, don't worry, these are just samples and are really low quality -- they are meant to be teasers, rather than directly useful to you the reader. Let's not go stealing people's work now (something that is rampant in the app markets as it is anyways!).
I probably should have mentioned this in the beginning of this article, but our first step here was to more or less finalize what the game visual layout would be. In other words, we took our doodles, cleaned them up, and made actual graphics that represented what the game layout would be. Where does the ad go? How much space would it take up? Where is the playing field, how big is it relative to other graphical assets? From there, then we started making the actual graphics that filled in those zones.
The pic here is our first draft of the layout of the playable game area and where stuff goes. Naturally, this can change a bit over the course of development, but this serves us sufficiently for now.
As a bonus to this article I should mention a bit about display densities. When first developing for Android, I was accustomed to dealing directly with pixel sizes and spaces. This is not generally a good thing for the novice Android developer.
Each Android device has something called a display density, or how many pixels per inch exists on the physical display. This is stupendously important for knowing about how your graphics work with Android apps (specifically for placing them in the correct position!).
A point of reference:
Low density (LDPI) -> 120 dpi
Medium density (MDPI) -> 160 dpi
High density (HDPI) -> 240 dpi
Extra high density (XDPI?) -> 320 dpi (used for tablets probably)
In other words, when making mobile apps and games, you will likely need code that handles each specific density because you definitely have no guarantee that all your customers will be running on the same display density!
For example, if you want to place a graphic "in the middle of the screen", what does that mean? How do you know at what pixel location is the middle of the screen? I will get to these answers during the development cycle in a couple of articles from now. However, an honorable mention happened here because when designing your artwork, you will likely want separate graphic assets for each different density that exists. This directly translates to additional time required to make your product, catering to differing hardware by your customers, and this is only the graphics end of the deal.
Next up, we will start talking about some code (finally!).
For sake of simplicity, our studio is currently using mostly Inkscape (it's free!) for high quality Scalable Vector Graphics. We have limited talent in-house for art, so this takes us a little while to "get right".
Android apps require some special handling when it comes to the artwork, specifically with catering to different graphics densities on various displays. This means that ideally, we will have a couple different versions of the same piece of art so that displays that can do "high definition" can use higher quality graphics, while displays that are from forever-ago can still render something (albeit very pixelly - hah new word).
The design of the art should be such that the same art can be easily scaled up and down. This requirement led us to Inkscape (or Illustrator I suppose if you wanna pay money) so that we retain ultimate flexibility with scaling stuff up or down while using the same piece of art. Short of pixel art, vector graphics are simply amazing and save a ton of time later down the road when you want to recycle graphics.
To keep things simple, we usually try to make hard colored, cartoony like graphics. The lighting and shading usually translate very well to small display sizes, and that is a big bonus for small displays.
Something that we learned from our earlier title Blocks Away! Is that we can use a grayscale version of a graphic and apply colors (using a multiply colorfilter) to the graphic in the game engine, this reduces the graphics work needed by quite a lot if the graphics themselves are simple enough and don't require too much recoloring work. For example, in that game, we used a single white block, then just recolored the other blocks in the engine. For this new game, we will try to reuse this trick to save work on the art, but ultimately, we may need to have different graphics for differing colors of game pieces.
Regardless of what we do, we need to consider the design of the art itself. Shy away from ultra realistic and super mega amazing high quality stuff -- it simply does not translate well to small screens of phones, plus the production time and cost involved can be astronomical for small studios if this is outsourced, meaning we sort of have to do this ourselves with out limited experience in this area.
Some of the graphics we're probably going to use are here, don't worry, these are just samples and are really low quality -- they are meant to be teasers, rather than directly useful to you the reader. Let's not go stealing people's work now (something that is rampant in the app markets as it is anyways!).
 |
| Sampling of actual game graphics |
I probably should have mentioned this in the beginning of this article, but our first step here was to more or less finalize what the game visual layout would be. In other words, we took our doodles, cleaned them up, and made actual graphics that represented what the game layout would be. Where does the ad go? How much space would it take up? Where is the playing field, how big is it relative to other graphical assets? From there, then we started making the actual graphics that filled in those zones.
The pic here is our first draft of the layout of the playable game area and where stuff goes. Naturally, this can change a bit over the course of development, but this serves us sufficiently for now.
 |
| Layout |
As a bonus to this article I should mention a bit about display densities. When first developing for Android, I was accustomed to dealing directly with pixel sizes and spaces. This is not generally a good thing for the novice Android developer.
Each Android device has something called a display density, or how many pixels per inch exists on the physical display. This is stupendously important for knowing about how your graphics work with Android apps (specifically for placing them in the correct position!).
A point of reference:
Low density (LDPI) -> 120 dpi
Medium density (MDPI) -> 160 dpi
High density (HDPI) -> 240 dpi
Extra high density (XDPI?) -> 320 dpi (used for tablets probably)
In other words, when making mobile apps and games, you will likely need code that handles each specific density because you definitely have no guarantee that all your customers will be running on the same display density!
For example, if you want to place a graphic "in the middle of the screen", what does that mean? How do you know at what pixel location is the middle of the screen? I will get to these answers during the development cycle in a couple of articles from now. However, an honorable mention happened here because when designing your artwork, you will likely want separate graphic assets for each different density that exists. This directly translates to additional time required to make your product, catering to differing hardware by your customers, and this is only the graphics end of the deal.
Next up, we will start talking about some code (finally!).
Thursday, February 9, 2012
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.
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.
Wednesday, February 8, 2012
Design to Product on Android - Risk Management (6 / 17)
In Software Engineering, one of the evil parts of making products is the Project Management aspect of the whole thing. Ya know, the guys that always tell programmers what they can and cannot do; as well as how everything was due yesterday.
Well, as a small software shop, we have the luxury of being our own managers, for all its amazing glory, and huge amounts of risks. Everything you do and plan for needs to be evaluated for risks, especially in software. Even the smallest feature can take weeks to accomplish!
Before designing a game, think heavily about what features should and should not be part of a product. Yes, it would be great if a game was a simulated virtual reality, or interacted with websites, or touched on databases all over the world to present a real time view of the world in to your digital dream of a game... but all these amazing features have tradeoffs in terms of time involved to make it happen, and problems testing/debugging. Everything remotely complicated can take large amounts of time to make, and even sometimes simple things turn out to be a lot more complicated than originally planned.
Good project managers have a wide understanding of programming and should give lenient amounts of time to get anything done on software projects. If this person is you, the rule of thumb is to take any time estimate for getting anything done and multiply it by 3 and that's probably more realistic. As the manager gains more experience with more varieties of software features and products, their "expert opinion" will likely become more accurate over time.
But I digress, let's focus back on the Risk side of things. This aspect of the software process is fairly complex but essentially boils down to assessing what is and is not an acceptable risk to take. This can apply to lots of things, but for our sake, we will focus only on the risk of adding features to our small software project. Throughout the development cycle, risk assessment and reassessment will happen, so this isn't like we can just up and say "yea, I'm done figuring out the risks for this project". However, having a good place to start couldn't hurt.
Projects do not need risk assessment, but it sure can save you a lot of time, effort, and headache in the long run. Unfortunately, it usually requires a well-experienced project manager to make this really effective.
At any rate, things you will want to assess for risks, specifically for games, is what features are worth the time investment. In other words, what features MUST be in the product versus what features would be nice to have. There's kind of a 3rd category also, what features can wait for a future patch/release... things that really should exist sooner or later, but can wait.
When considering features that must exist in the product, assess features worth the time involved to make, or can the design of the game change a little bit to cater to time constraints (budgeting, investors, your boss, bills, etc). There is nothing worse than developing a feature in a product and realize halfway through that you will run out of money or time making it happen -- worse yet, your business may have already paid for supporting services and resources for that feature (art, music, etc), and now you might have to scrap or change the design -- huge waste of time and money. This is why assessing risk is fairly important, it is an attempt to mitigate as much problems as possible before dumping a lot of effort in to things that really might never make it through to the end of the day.
Did I mention risk management happens throughout the project? I did? Let me say it again here, this should be a constant nagging during software development, not enough to drag you down and admit defeat before you start, but should be just close enough to have you on the edge of your seat. Never be too proud to admit defeat (just 3 more weeks to get this done, I swear!). Always think about how long things will take and, well, assess if it is worth the time and bother. At the end of the day, is your hard work worth the risk of ultimately getting money for your efforts?
A specific example to watch out for -- "wow, this anti-aliasing on this button is so awesome cool, but it took me 4 weeks to make happen". Yea, users will love that their button looks all slick, but if it took you 4 weeks to make happen, that was a lot of time wasted that could have been spent somewhere else! But don't worry, you have a slick button... and 3 weeks of lost time to play happy fun make-up crunch time with.
"Uh, yea, we're gonna need you to go ahead and come in on Saturdayyy, mmkay... oh and, I'm going to have you come in on Sunday too". Yes, it was from Office Space, but really, that is what is going to happen if you have to play catch up. Risk management isn't the magic bullet (nothing in Software Development is) to solve all your problems with time management, but it sure can help give a better perspective on what is and is not important enough to dump a lot of time and money on during the whole ordeal.
Well, as a small software shop, we have the luxury of being our own managers, for all its amazing glory, and huge amounts of risks. Everything you do and plan for needs to be evaluated for risks, especially in software. Even the smallest feature can take weeks to accomplish!
Before designing a game, think heavily about what features should and should not be part of a product. Yes, it would be great if a game was a simulated virtual reality, or interacted with websites, or touched on databases all over the world to present a real time view of the world in to your digital dream of a game... but all these amazing features have tradeoffs in terms of time involved to make it happen, and problems testing/debugging. Everything remotely complicated can take large amounts of time to make, and even sometimes simple things turn out to be a lot more complicated than originally planned.
Good project managers have a wide understanding of programming and should give lenient amounts of time to get anything done on software projects. If this person is you, the rule of thumb is to take any time estimate for getting anything done and multiply it by 3 and that's probably more realistic. As the manager gains more experience with more varieties of software features and products, their "expert opinion" will likely become more accurate over time.
But I digress, let's focus back on the Risk side of things. This aspect of the software process is fairly complex but essentially boils down to assessing what is and is not an acceptable risk to take. This can apply to lots of things, but for our sake, we will focus only on the risk of adding features to our small software project. Throughout the development cycle, risk assessment and reassessment will happen, so this isn't like we can just up and say "yea, I'm done figuring out the risks for this project". However, having a good place to start couldn't hurt.
Projects do not need risk assessment, but it sure can save you a lot of time, effort, and headache in the long run. Unfortunately, it usually requires a well-experienced project manager to make this really effective.
At any rate, things you will want to assess for risks, specifically for games, is what features are worth the time investment. In other words, what features MUST be in the product versus what features would be nice to have. There's kind of a 3rd category also, what features can wait for a future patch/release... things that really should exist sooner or later, but can wait.
When considering features that must exist in the product, assess features worth the time involved to make, or can the design of the game change a little bit to cater to time constraints (budgeting, investors, your boss, bills, etc). There is nothing worse than developing a feature in a product and realize halfway through that you will run out of money or time making it happen -- worse yet, your business may have already paid for supporting services and resources for that feature (art, music, etc), and now you might have to scrap or change the design -- huge waste of time and money. This is why assessing risk is fairly important, it is an attempt to mitigate as much problems as possible before dumping a lot of effort in to things that really might never make it through to the end of the day.
Did I mention risk management happens throughout the project? I did? Let me say it again here, this should be a constant nagging during software development, not enough to drag you down and admit defeat before you start, but should be just close enough to have you on the edge of your seat. Never be too proud to admit defeat (just 3 more weeks to get this done, I swear!). Always think about how long things will take and, well, assess if it is worth the time and bother. At the end of the day, is your hard work worth the risk of ultimately getting money for your efforts?
A specific example to watch out for -- "wow, this anti-aliasing on this button is so awesome cool, but it took me 4 weeks to make happen". Yea, users will love that their button looks all slick, but if it took you 4 weeks to make happen, that was a lot of time wasted that could have been spent somewhere else! But don't worry, you have a slick button... and 3 weeks of lost time to play happy fun make-up crunch time with.
"Uh, yea, we're gonna need you to go ahead and come in on Saturdayyy, mmkay... oh and, I'm going to have you come in on Sunday too". Yes, it was from Office Space, but really, that is what is going to happen if you have to play catch up. Risk management isn't the magic bullet (nothing in Software Development is) to solve all your problems with time management, but it sure can help give a better perspective on what is and is not important enough to dump a lot of time and money on during the whole ordeal.
Tuesday, February 7, 2012
Design to Product on Android - Game Doodles (5 / 17)
After yesterday's rant about the vision documentation, we sat down and started tossing ideas around for a new game. We started out by saying what we can't do -- specifically, a project that doesn't involve complex graphics or animation, and to speed things up a bit, recycling simple graphics, and redoing and upgrading existing assets that the business already owns, specifically for art, but really should recycle anything and everything to save time and money.
If you're familiar with our catalog of titles, you know that we don't particularly have a strong set of visually intensive titles at our disposal.
On our budget, we can't really afford an animation house and lack the experience in-house to really make it happen... therefore, the design of the game had to involve basic elements and basic graphics. More visual candy will come in time, but we'll work our way up.
That said, we began throwing ideas around about a board game, and a bubble popping game. We went back and forth a bit, but settled on the bubble popping game (oh no, not another one of those!). "The project" was now being fleshed out. Attached here is our gibberish of ideas, which by themselves don't really mean too much, but combined with the talk we had back and forth, makes more sense to us.
The scans of the documents turned out "meh", but you get the idea, basically in the doodling vision stage, we put down ideas and jotted some notes while having discussions. Here are scans of two of the documents we came up with.
The next logical step is to start creating the game design by combining the talking with these notes. However, the next blog entry will reflect on Risk Management (arg, management stuff), then we'll get to the design of the actual game.
If you're familiar with our catalog of titles, you know that we don't particularly have a strong set of visually intensive titles at our disposal.
On our budget, we can't really afford an animation house and lack the experience in-house to really make it happen... therefore, the design of the game had to involve basic elements and basic graphics. More visual candy will come in time, but we'll work our way up.
That said, we began throwing ideas around about a board game, and a bubble popping game. We went back and forth a bit, but settled on the bubble popping game (oh no, not another one of those!). "The project" was now being fleshed out. Attached here is our gibberish of ideas, which by themselves don't really mean too much, but combined with the talk we had back and forth, makes more sense to us.
The scans of the documents turned out "meh", but you get the idea, basically in the doodling vision stage, we put down ideas and jotted some notes while having discussions. Here are scans of two of the documents we came up with.
The next logical step is to start creating the game design by combining the talking with these notes. However, the next blog entry will reflect on Risk Management (arg, management stuff), then we'll get to the design of the actual game.
Monday, February 6, 2012
Design to Product on Android - Vision (4 / 17)
The vision of the product is a very abstract idea of what you want to make. What are we going to make anyways? Sketches, ideas, text documents, lots of yelling at things, oh yea, all that stuff is here.
In normal Software Engineering, generally, the vision document is a document that describes the high level things that the people involved want from the product. For anyone curious, the wiki link here might help to elaborate.
Essentially, every software house has their own take on the process in which software is suppose to be made. Our studio brainstorms for a couple hours or days, and starts writing the general idea in an openoffice writer document. Some rough sketches of what the product will look like at certain screens are included, especially sketches about what the game looks like in the main mode of playing, the options screen, etc.
For example, in our game SimpleMatch, we drew a big box to indicate the playing field, then a bunch of boxes that populate that playing area, wrote some notes off to the side about how each box inside is a different color, and the goal of the game is to simply touch the "tiles" and match colors.
The vision has basically nothing to do with coding, instead it is more focused on what the user sees, and is expected to do. This could be confused with the game design because there should be some overlap. For our studio, we see the vision as what guides the game design. The vision is the paraphrased executive summary, and the game design describes in detail the meat and bones of the game itself.
Like all documentation, it is a live document that can change over time.
Is a vision necessary? No, nothing is necessary to do, however the time involved with "doodling" your ideas in to a tangible and real product is a good first step in to making an actual product, and not just expelling hot air that you "want to make a game". If this document doesn't serve you, don't do one.
Personally, we've found that the vision is a nice way to start the process, but usually we abandon the document once people in the team understand the basic idea of what we're doing, where we're going, and agree with the direction. More importantly, we use the vision as an outline while the game design is being done. Once the design is done being drafted up, the vision usually disappears.
Oh, and do you need a title of the product at this point? No, definitely not, you can keep it called anything you want, as long as people can centrally refer to "the project" in a conducive manner.
For the sake of this series, we will be envisioning a product here. Stay tuned for a vision dump of our new product from our team tomorrow!
Sunday, February 5, 2012
Design to Product on Android - Costs (3 / 17)
One of the big factors in business is to keep the costs down. Here is a ranting of sorts on how stuff costs too much, but more importantly, what are some costs involved with making an Android App, in no particular order.
Rent (apartment/house/office)
Going to need a physical place to make the product, either for yourself, or for your team of people.
Utilities - Gas
It is always nice to have a comfy place to work, and paying a gas bill is conducive for temperature control. If you're living at your place of work, and you're the software guy, you might be able to skimp on this cost by living in your room; if it is anything like mine, your copious amounts computers provide enough heat to replace the gas bill.
Utilities - Electric
Without this, you're not going anywhere in this business.
Food
Generally a good idea to be able to eat stuff. Though cutting back on going out to eat and consuming frivolous luxury foods can really add up and should be put in check if you want to keep costs down if you're working for yourself. Buy a water filter and don't waste money on bottled water or soda/pop. Rice, beans, anything that keeps a while, easy to make, and can buy in bulk, is a good idea to get used to.
Travel
Most software people usually don't go outside much, but in the freak accident of circumstance, it can happen... and it does cost money usually.
Phones, gizmos, and gadgets
An Android phone or tablet or both is highly recommended if you're serious about making apps. You'll probably want some other trinkets to entertain you as well, like some sweet binary clock or something.
License fees
Yep, these are going to happen. Google takes $25 up front for your developer license. If you want to port to iOS one day, they take $100 a year. Various software tools have license fees. Fortunately, for Android, using Eclipse and the Android SDK is free, but if you use any sort of supporting program, like Photoshop, 3ds MAX, various sounds programs, all of those are very expensive. Weigh this cost with the related contracting cost of outsourcing those needs.
Distribution fees
The Android market place takes a cut of your sale price if you decide to release an app as a paid app. Based on how much money you make, the rate fluctuates, but you may as well chalk this up to a 30% reduction of income to the "payment processing" that is associated with the marketplace.
Personnel
People need to do work to make a product. If you yourself are not personally creating some aspect of a product, it needs to be outsourced somewhere, and even if you could provide an aspect of a product, the question is should you use *your time* by providing whatever that is. For example, as a developer, I can and do make some graphics, but for every hour "lost" to making graphics, is an hour away from programming. For every hour programming, I lose to marketing -- unfortunately humans have that bad habit of existing in linear time, forcing us to do one thing, then the next, and time is what drives costs up. Carefully weigh your time versus costs involved with outsourcing. At the end of the day, paying someone else to do something for you will probably be your largest cost, and can fluctuate wildly.
Don't even bother with the idea of hiring someone else as a staff member unless you have a lot of money at your disposal. Contract anything and everything out on a per-job basis to keep costs down as much as possible.
Contracts
Anything that can't be done "in house" basically has to be contracted out. Some initial quotes from contracting houses for graphics work ranged from $2,000 ~ $50,000 for the same set of art requirements. We're talking about really basic things too, about a dozen static backgrounds, some animated characters, some promo art. Shop around for quotes as you can see the range has a large distribution, but regardless, you will be paying the costs for this, no matter what it costs.
Legal
Fees, fees, and more fees. If you make an LLC, incorporate, whatever, the federal government and the state will likely want a piece of your company or at the very least, a hefty portion of your income no matter what your legal status is. Lawyers and all that good stuff could be put in this category as well.
Medical
My advice to you, if you're in the United States anyways, is simply don't get sick or get hurt. You basically can't afford to have anything bad happen to you. In other words, don't quit your day job if you have medical benefits. At the same time, don't even bother thinking about hiring employees because, depending on your state, YOU may have to cough up cash for medical coverage of employees... the insurance of those people... costs keep stacking up going this route.
Insurance
In the US, if you hire people, your business might be subject to being forced to pay certain insurance costs -- like unemployment, workers compensation, etc... these costs can sneak up on you if you're not prepared.
Other things
Website fees, hosting fees, marketing and advertising costs -- depending on what you want to do to maximize your presence, these costs could be all over the place, but probably should be considered if you're factoring costs.
Miscellaneous
Hah, made two sections for other stuff. Seriously though, you will want to add in some buffer zone above your initial costs allocated to "just in case", things always seem to take longer than expected, or more expensive than initially discovered; either way, YOU will have to cough up the cash to make it happen; nothing worse than paying for 75% of something and running out of cash making you eat all those costs with no hope of recovering any of said costs by failing to deliver the product at all!
This isn't an itemized list, but should give you a decent idea of the general costs that could be involved with a business associated with making Android Apps. I can wager this isn't a 100% complete list either, as small expenditures like to just show up when they are least expected.
Proper planning for costs will increase the chance you have in creating and finishing a product by giving you an idea of how much money and resources you will need to go from start to finish.
Rent (apartment/house/office)
Going to need a physical place to make the product, either for yourself, or for your team of people.
Utilities - Gas
It is always nice to have a comfy place to work, and paying a gas bill is conducive for temperature control. If you're living at your place of work, and you're the software guy, you might be able to skimp on this cost by living in your room; if it is anything like mine, your copious amounts computers provide enough heat to replace the gas bill.
Utilities - Electric
Without this, you're not going anywhere in this business.
Food
Generally a good idea to be able to eat stuff. Though cutting back on going out to eat and consuming frivolous luxury foods can really add up and should be put in check if you want to keep costs down if you're working for yourself. Buy a water filter and don't waste money on bottled water or soda/pop. Rice, beans, anything that keeps a while, easy to make, and can buy in bulk, is a good idea to get used to.
Travel
Most software people usually don't go outside much, but in the freak accident of circumstance, it can happen... and it does cost money usually.
Phones, gizmos, and gadgets
An Android phone or tablet or both is highly recommended if you're serious about making apps. You'll probably want some other trinkets to entertain you as well, like some sweet binary clock or something.
License fees
Yep, these are going to happen. Google takes $25 up front for your developer license. If you want to port to iOS one day, they take $100 a year. Various software tools have license fees. Fortunately, for Android, using Eclipse and the Android SDK is free, but if you use any sort of supporting program, like Photoshop, 3ds MAX, various sounds programs, all of those are very expensive. Weigh this cost with the related contracting cost of outsourcing those needs.
Distribution fees
The Android market place takes a cut of your sale price if you decide to release an app as a paid app. Based on how much money you make, the rate fluctuates, but you may as well chalk this up to a 30% reduction of income to the "payment processing" that is associated with the marketplace.
Personnel
People need to do work to make a product. If you yourself are not personally creating some aspect of a product, it needs to be outsourced somewhere, and even if you could provide an aspect of a product, the question is should you use *your time* by providing whatever that is. For example, as a developer, I can and do make some graphics, but for every hour "lost" to making graphics, is an hour away from programming. For every hour programming, I lose to marketing -- unfortunately humans have that bad habit of existing in linear time, forcing us to do one thing, then the next, and time is what drives costs up. Carefully weigh your time versus costs involved with outsourcing. At the end of the day, paying someone else to do something for you will probably be your largest cost, and can fluctuate wildly.
Don't even bother with the idea of hiring someone else as a staff member unless you have a lot of money at your disposal. Contract anything and everything out on a per-job basis to keep costs down as much as possible.
Contracts
Anything that can't be done "in house" basically has to be contracted out. Some initial quotes from contracting houses for graphics work ranged from $2,000 ~ $50,000 for the same set of art requirements. We're talking about really basic things too, about a dozen static backgrounds, some animated characters, some promo art. Shop around for quotes as you can see the range has a large distribution, but regardless, you will be paying the costs for this, no matter what it costs.
Legal
Fees, fees, and more fees. If you make an LLC, incorporate, whatever, the federal government and the state will likely want a piece of your company or at the very least, a hefty portion of your income no matter what your legal status is. Lawyers and all that good stuff could be put in this category as well.
Medical
My advice to you, if you're in the United States anyways, is simply don't get sick or get hurt. You basically can't afford to have anything bad happen to you. In other words, don't quit your day job if you have medical benefits. At the same time, don't even bother thinking about hiring employees because, depending on your state, YOU may have to cough up cash for medical coverage of employees... the insurance of those people... costs keep stacking up going this route.
Insurance
In the US, if you hire people, your business might be subject to being forced to pay certain insurance costs -- like unemployment, workers compensation, etc... these costs can sneak up on you if you're not prepared.
Other things
Website fees, hosting fees, marketing and advertising costs -- depending on what you want to do to maximize your presence, these costs could be all over the place, but probably should be considered if you're factoring costs.
Miscellaneous
Hah, made two sections for other stuff. Seriously though, you will want to add in some buffer zone above your initial costs allocated to "just in case", things always seem to take longer than expected, or more expensive than initially discovered; either way, YOU will have to cough up the cash to make it happen; nothing worse than paying for 75% of something and running out of cash making you eat all those costs with no hope of recovering any of said costs by failing to deliver the product at all!
This isn't an itemized list, but should give you a decent idea of the general costs that could be involved with a business associated with making Android Apps. I can wager this isn't a 100% complete list either, as small expenditures like to just show up when they are least expected.
Proper planning for costs will increase the chance you have in creating and finishing a product by giving you an idea of how much money and resources you will need to go from start to finish.
Saturday, February 4, 2012
Design to Product on Android - Resources (2 / 17)
Before we start going over what we want to make, we need to assess what kind of production power we have, and figuring out if we need more of something. Usually, more money pumped in to a startup means more money coming back from the return investment -- the formula sounds good on paper, but doesn't always reflect reality because there's an assumption that all money invested has any return at all.
The most important resource to business is money, liquid cash. Your purchasing power is what will ultimately drive your business to success or failure. The trick is to acquire/accomplish a lot, while using little. Time is money, so if you can create a product or service yourself, you won't have to pay others to do it for you -- though sometimes "outsourcing" things that save you time can be worth the money!
For our intents and purposes, we're making Android apps, so how do we go about doing that. Obviously we will need someone to *make* the product - a software person that specializes in Java programming, specifically for Android OS. Someone that can make pretty graphics is a plus, and possibly making some sounds and/or music. Ideally someone should also create a design for the game, and put it all together as well. If you're the business-type and cannot or will not fill any of these roles, you have a large financial obligation already since "high-tech" workers, especially in the USA, are not cheap. Plus, things usually tend to take a lot more time/money than people expect, which would translate to much higher costs than expected.
Personally, I'm operating as most of the required roles myself, and I recommend doing something similar. If you don't like it, this business probably isn't for you. Remember, at the end of the day, you have to make money from this to at least cover your costs of production!
So, you have an Android developer picked out and working with you (or is you).
One of the first questions is, do you need some sort of Android hardware to make Android products? Well, technically, the answer is no, but I will attest that buying an Android device was overwhelmingly useful during development and testing in earlier products. The emulator is free, so the business side of me wanted that, but the techie in me demanded a "real device". The reasons behind this can be long and complicated, but suffice to say, if you want a good end product, you need to target what you're making stuff for. You can get by with the emulator, but ultimately we settled with buying a device, while using the emulator to test specific versions of the Android OS other than the version that came with our actual phone. This topic warrants its own article and will be linked later.
We now officially have a burden of making enough money to pay for this device, at least, and ignoring the fact that we're not even paying ourselves! However, we now have our first asset for the business, and this should be considered one of our resources.
As a point of reference, our business started with approximately $6,000 of "disposable cash". In other words, our business has taken the acceptable risk of losing 100% of the cash in this endeavor. I cannot stress enough that Android development is very risky in terms of money spent, versus money earned. To any other prospective or current Android devs out there, if you can't risk at least several thousand dollars to make your products (assuming you're the dev yourself), this probably isn't the business to go in to. If you aren't the developer, this figure can easily get in to the 10's of thousands of dollars.
Let's recap, you will probably want a bit of cash to get things started and pay for the ongoing production of your apps, an Android device (phone in our case), some people to make products, and a hunk of time to produce the product. This will put a large dent in your startup money and is the subject of the next article, the costs involved with producing apps.
The most important resource to business is money, liquid cash. Your purchasing power is what will ultimately drive your business to success or failure. The trick is to acquire/accomplish a lot, while using little. Time is money, so if you can create a product or service yourself, you won't have to pay others to do it for you -- though sometimes "outsourcing" things that save you time can be worth the money!
For our intents and purposes, we're making Android apps, so how do we go about doing that. Obviously we will need someone to *make* the product - a software person that specializes in Java programming, specifically for Android OS. Someone that can make pretty graphics is a plus, and possibly making some sounds and/or music. Ideally someone should also create a design for the game, and put it all together as well. If you're the business-type and cannot or will not fill any of these roles, you have a large financial obligation already since "high-tech" workers, especially in the USA, are not cheap. Plus, things usually tend to take a lot more time/money than people expect, which would translate to much higher costs than expected.
Personally, I'm operating as most of the required roles myself, and I recommend doing something similar. If you don't like it, this business probably isn't for you. Remember, at the end of the day, you have to make money from this to at least cover your costs of production!
So, you have an Android developer picked out and working with you (or is you).
One of the first questions is, do you need some sort of Android hardware to make Android products? Well, technically, the answer is no, but I will attest that buying an Android device was overwhelmingly useful during development and testing in earlier products. The emulator is free, so the business side of me wanted that, but the techie in me demanded a "real device". The reasons behind this can be long and complicated, but suffice to say, if you want a good end product, you need to target what you're making stuff for. You can get by with the emulator, but ultimately we settled with buying a device, while using the emulator to test specific versions of the Android OS other than the version that came with our actual phone. This topic warrants its own article and will be linked later.
We now officially have a burden of making enough money to pay for this device, at least, and ignoring the fact that we're not even paying ourselves! However, we now have our first asset for the business, and this should be considered one of our resources.
As a point of reference, our business started with approximately $6,000 of "disposable cash". In other words, our business has taken the acceptable risk of losing 100% of the cash in this endeavor. I cannot stress enough that Android development is very risky in terms of money spent, versus money earned. To any other prospective or current Android devs out there, if you can't risk at least several thousand dollars to make your products (assuming you're the dev yourself), this probably isn't the business to go in to. If you aren't the developer, this figure can easily get in to the 10's of thousands of dollars.
Let's recap, you will probably want a bit of cash to get things started and pay for the ongoing production of your apps, an Android device (phone in our case), some people to make products, and a hunk of time to produce the product. This will put a large dent in your startup money and is the subject of the next article, the costs involved with producing apps.
Design to Product on Android - Intro (1 / 17)
Hi everyone,
Welcome to a large blog series about what it takes to design, plan, budget, develop, test, and deploy an Android app, in this case, a game. Over the course of a year or so, our studio has been reading countless articles, some do's and don'ts about how to get in to the Android marketplace. Super long stories short, basically, it doesn't make much sense to dump a ton of time and money in to this hoping you'll make millions over night. But, because we're persistent (and possibly borderline crazy), we're going to do it anyways.
The Android marketplace relies on independent developers to populate their app catalog. This is both good and bad. It's good because the apps released there usually do not have a large budget behind them and perform and look subpar, usually. It's bad because the marketplace is absolutely *flooded* with apps, making any release you make almost impossible to find and gain exposure, and thus popularity. On top of that, Android users overwhelmingly don't want to pay for anything, which actually makes sense because of the absolute crazy amount of free apps all over the marketplace.
I recall reading an article last year about how a businessman went in to the games industry with a bit of cash to fund his startup, so he thought, and make good on his returns for all the cash he put in to it... well, he deeply regretted the whole thing and attributed his failure to the fact that he had absolutely no experience with software, development, or really had any idea on how complicated things can get, and how long they can take... needless to say, his projects went over their time estimates, over budget, and he folded within a year. His "lessons learned" were that he wished he had at least a software developer background so that he had a better idea of how long things would take, which I'm sure would have helped his planning and budgeting.
I'm coming more from a software dev's perspective going to business. This series will focus on our journey, how we are going about this project, the business itself, budgets, ideas, some sarcasm, maybe some code, and some other stuff. This series won't be too focused on "the techie side", but more on the process itself of how to go from the idea -- I want to make a game -- to a product.
Friday, February 3, 2012
Chrome incognito mode
As a follow up to my admittance of switching over to the Chrome web browser, it would be in good order to share how to use chrome in incognito mode. No, this mode will not make you impossible to track, though it is a feature that assumes you don't want websites to track you down by remembering things about you.
To use Chrome in incognito mode, you must run chrome with a parameter. Specifically:
chrome.exe --incognitoTo launch chrome without using a command prompt, make a shortcut on your desktop with chrome, and edit the "Target" to be
C:\Users\[YOUR USERNAME]\AppData\Local\Google\Chrome\Application\chrome.exe --incognitoYou will see a little masked spy in the upper left corner of your chrome window if you did it right... and probably some errors or other demoralizing things if you didn't.
Conversion to Chrome
After many years of using Firefox, I think I've finally converted over to Chrome. Chrome now seems more responsive, uses less memory, and just seems to deliver a smoother web experience. The only thing I use Firefox now is for streaming videos or movies off the internet. For whatever reason, Chrome seems to puke while streaming video still.
So, I guess my "normal" browser is Chrome, while using FF as my "I'm watching movies" mode.
Oh, and I also don't quite understand why Firefox is on a version runaway train. Congratulations FF team, your version numbers are now ahead of Internet Explorer; though I'm a tad concerned that isn't really a good thing. Sure, it might convince some people that your browser must be better because it has a higher version number than IE, but that marketing ploy won't work on a lot of people.
So, I guess my "normal" browser is Chrome, while using FF as my "I'm watching movies" mode.
Oh, and I also don't quite understand why Firefox is on a version runaway train. Congratulations FF team, your version numbers are now ahead of Internet Explorer; though I'm a tad concerned that isn't really a good thing. Sure, it might convince some people that your browser must be better because it has a higher version number than IE, but that marketing ploy won't work on a lot of people.
Subscribe to:
Posts (Atom)