Showing posts with label business. Show all posts
Showing posts with label business. Show all posts

Monday, April 2, 2012

So many Android devices to cater to...

In follow up to my earlier post about being envious of software houses of yesteryear, I have to admit that in a sense, they had it easier.

When they made their games and products, they had a single target system with known specs and limitations.  Code that relied on *timing* of events and things like this can be planned for meticulously.  Developers also knew 100% ahead of time what features a system did or did not have.  Yet, they also dealt with 8-bit / 16-bit processors, no FPU, no advanced graphics pipeline, and all sorts of "limitations", and they still cranked out great products after great products all without needing all these patches and what not.

Well, fast forward a bunch of years, and here we're in the age of the smartphone.  In some regards, we have it easy - a powerful CPU (relatively speaking), an amazing graphics processor, and sometimes a FPU.  Wait, sometimes?!  Yes, that's right, if you're a developer for the Android platform, you can't be guaranteed to have a floating point unit.  You also have no guarantee of having any given amount of RAM, disk space, or really much of anything.  Sure, you can *use* float data types, but on devices with no dedicated float processor, it is software emulated!!! Talk about a massive performance hit if you want to do updates and renders at any sane framerate!

Our earlier game, Bubble Zing, ran amazingly awesome on newer Android phones, but on older phones, it ran terribly.  With the 1.0.3 release of the game last month, we thought all major compatibility issues were resolved; well, that was only partially correct.  The major bugs seemingly were ironed out, and the core game "worked", but with no guarantee of how well it would work - sometimes outright unplayable on some devices!

So, we delve further in to the "why is this running like terrible on x,y,z,q,f devices, but great on others".  Well, this is where the things Android does is both great and bad at the same time.  We coded 1.0.3 in 100% Java as this was seemingly the correct way to make any app on Android devices.  In theory, it sounded good since Java apps are suppose to work 100% on devices with a compatible JVM (ie, all Android devices) - clearly something we wanted, and it is fairly easy to crank a Java program much faster than an equivalent C/C++ program, so it sounded like a great idea at the time.

Our test system was a Droid RAZR with Android 2.3.6.  Our initial testing was running well, FPS was over 40 and everything seemed great.  The emulator running an AVD 1.5 seemed sluggish but that could be written off as being an emulator and running not on the most powerful host computer.

Things got really confusing and exciting when we tested 1.0.1 and 1.0.2 on a Samsung Galaxy tablet -- that's when all hell broke loose.  Everything that should have been working in theory wasn't.  On top of that, the frame rate was a dismal 10 to 15!  What the flying expletive!  How can a program go from 40+ FPS to 10!  It wasn't an issue with the version of the Android OS, it must have been something device specific.

I ran a traceview to track what was eating all the processing time and it came down to rendering a full screen background PNG file.  On the phone, this wasn't such a big deal, but on the tablet, it was eating almost 60% of all CPU time!

We're sitting here with a complete Java game that worked ok on an emulator and great on our target test phone, yet are dumbfounded with why the same exact Java code on the tablet ran so terribly.

A lot of trial and error later we figured that to get things working faster and better, the only way was to ditch Java and start programming on a closer-to-the-hardware level as we could to squeeze out a lot more performance and manage memory more effectively.  Java made it very frustrating with garbage collecting at some fairly inconvenient times and this compounded other issues making the game run very badly at certain instances.  It was time to bring on the NDK.

Frustration is what is in store for Android developers.  It can be done, but good apps will need a very persistent set of people to make these products and make them well.

Oh, and I'm still in awe of game programmers from decades ago on consoles, but at the same time, I'm jealous of their "single architecture" deployment platform as that probably simplified a lot of these problems thousands fold.  I suppose this is another reason Apple is winning the smartphone wars with developers as it is "easier" to make apps on iOS with very heavily controlled hardware features by Apple.

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.

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.


Saturday, January 28, 2012

Posting a new app in the Android Market

Eon Edge Studios posted a new app today at 11:15AM PST.  Now, with all weekends, the Android marketplace is usually *packed* with app submissions and updates.  We're going to see exactly how long this new release will take to propagate in the marketplace and report back here when it happens.

When we posted our first app, Simple Match, it took seriously like 6 or 7 hours for it to even show up in the marketplace.

When we posted our flashlight app, it took about an hour to show up, but this app was submitted during the week, as opposed to the weekend.

Of course, FINDING the apps themselves, once they hit the market is another story -- something I'll probably blog about here when I get a chance.

UPDATE: I guess it would help if I actually clicked the PUBLISH button as opposed to only the SAVE button in the marketplace.  Once I actually hit the right button, it took about half an hour for our new app to get published!

Wednesday, January 11, 2012

Challenge or Opportunity?

Competing in the mobile app market, especially in the Android market alone seems quite challenging, but more importantly --- seems very difficult to be able to make enough money per month to pay the bills!  We'll be tweaking our products and strategy over the next couple of months to see what does and doesn't work.  We'll probably post here also with what we find.