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!
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts
Tuesday, February 21, 2012
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.
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.
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.
Subscribe to:
Posts (Atom)