Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
15. August 2011


This began life as a post here but it became long enough and IMHO important enough, I am going to clean up the spelling a bit and repost it here.  It was in response to a fairly new developer with a question about class design.



This is one of those things that is nearly impossible to explain in a post, or hell, short of a small book.

But generally ( and yes, there are exceptions, thousands and thousands of exceptions ) you want to decouple your objects from each other as greatly as possible. You also want to keep code as self contained as possible, again, with thousands of exceptions.


A lot of the time when you are designing your classes ask yourself "If I changed this class, how many other aspects would need to be changed as well?" Then go about breaking those dependencies where possible. If two classes don't really need to know about each other, break that dependency. If two classes share 90% of their functionality, derive from a common base class.


On the other hand, you have to let common sense be a factor. One really common reason to abstract away your classes into engines and various components is so you can make switches later. For example, if you are using SDL, but want to be able to switch over to SFML at a later date, it's common to make a Renderer class, and an intermediary class over all the various objects like Bitmaps and Sprites, that both SDL and SFML provide so you can transparently change Renderers without making a code change. Reality is though, for 90+% of projects, this is just an added layer of complication and work that will never ever be used. This is where common sense has to come into play. Yes, from a purely object-oriented perspective, it is a very "pure" design that implementation details are abstracted away. From a practical and getting shit done sense, it's just a stupid waste of time.


This is where we get to the next sticking point and another area where new developers ( and experienced developers! ) get it really wrong most of the time. Global variables. See, when a new developer learns about global variables they seem like a godsend, as then you frankly don't have to design classes at all, just make everything globally available! This in a very short while makes extremely unreadable and maintainable code. Other new ( and experienced developers ) have heard about this and had it drilled into their heads that GLOBALS ARE BAD!!!! and react accordingly. Ironically enough, 9 times out of 10 this seems to always result in the same discovery... the Singleton. If you haven't yet, some day you will discover the singleton pattern and you will think it is the answer to your prayers. It's not a global, it's an object!!! Actually no, it really is just a global with a pretty layer of object oriented goop wrapped around it(**). Then you will encounter another group of people that will yell from the mountains SINGLETONS ARE BAD!!!! Which in the end leads you to engineering half a hundred "Manager" or "Adapter" classes to eliminate your dependencies on global variable and singletons. All the while, no work is getting done on your game.


Now it's time to let you in on a dirty little secret. Globals aren't bad, they are actually pretty frigging useful and important. The most important thing is, DO NOT ABUSE THEM. That is it. Chances are, you are going to have some form of global object, like perhaps a Game, App or World class, this is completely reasonable. On top of that you are going to run into code that needs to be globally accessed, such as your Audio class or Event class, which is also quite reasonable. It simply does not make sense to pass in an Audio class to say, a GameEvent, because that game event might on occasion need to play a sound. There are quite literally only a handful of things that should be made globally available but if it makes sense to be globally available, make it globally available.


But here is where the design gets tricky again, if you are making something globally available, do not make the relationship two-way, or at least not unless the two-way relationship is completely generic or via an interface. For example, if you have a game engine ( globally available ), and that game engine has a (globally available ) event queue, that at some point a game object needs to add events to, make sure that the event queue has the most absolutely minimal requirement to know anything about the game object and that the game engine itself needs to know absolutely NOTHING about the game object, as this is where your design can start to fall on it's face.


One last general rule of thumb when dealing with globally available classes, make them static whenever possible, it will lead to less potential hazards. Additionally, when make global objects provide access to other global object ( for example Game::SoundManager ), use accessor methods and const whenever possible. Keep all allocation and de-allocation specifically in the realm of the containing object.











(**) There are actually more to singletons than just object oriented globals. Yes, Singletons are global in scope but they have a couple very important properties. First of which is deferred allocation, meaning the Singleton isn't using memory until the first time it is used, unlike a traditional static variable. Additionally, a Singleton can be sub-classed as a mechanism of providing a single interface to potential disparate code bases, so for example you could have a Renderer::GetInstance(), which is sub-classed as OpenGLRenderer or DirectXRenderer, which will provide your code with a single global runtime determined instance. If you don't understand this paragraph, that’s completely fine, I'm just throwing it out there as a caveat so my over simplification of a Singleton isn't misleading... they do have their uses.

Programming Design

1. May 2011


Hmmmm, really need to settle on a name for the bipedal robotic characters that isn't Mech/Mecha soon just to ease these conversations! Not my most creative day so I’ll just go with GPR now.


Anyways, the GPR is very much fundamental to the game.  One of my favorite things about Autoduel and Mechwarrior Mercs was the sense of acquisition.  Start with a lowly machine and work your way up the ranks.  One of my favorite factors of Chromehounds was the customization aspect.  I intend to incorporate both into our game.


The very first Mech, er GPR the character starts with is power_loadervery primitive, like the Powerloader from Aliens that Ripley used.  Very simple bipedal machine with a single weapon forward firing weapon mount.  As the player wins matches, they will have the option of swapping that weapon out for better weapons and eventually with be able to buy better GPR frames.  In the end though, it will entirely be about trade offs.


Each frame will have a certain number of slots available, of different sizes to accommodate different sized weapons.  Additionally frames will be able to have different power plants, that will be a factor in speed, battery life, weapon power and charges.  So you could mount a big heavy laser, that really sucks the juice or mount smaller engine which would be lighter and faster but couldn’t power the weapons as well.


It is all about trade offs, so you could create a fast lightly armed frame, or a heavily armed slow machine or simply an average all around machine.  You could also use munitions based weapons like rocket launchers or machine guns that don’t use energy from the engine, but once they run out of ammunition are as good as useless. 


cci_40All frames start with a certain amount of energy, tied to the type of power plant installed.  Things like the weight of the frame ( from weapons and armor ), firing of energy weapons, running at high speeds, taking damage from certain types of weapons, etc.  If energy goes to zero, you stop dead and can’t fire.  Engines will recharge slowly on their own, so you need to balance speed and weapon use to keep your power levels healthy.  Or, go with a power plant that has a rapid recharge rating.  In my head now, statistically a power plant is rated by:  size ( amount of space needed by frame to install ), weight, power available, recharge rate and frame class(es) ( what size of frames the engine can be install into ) and finally cost.


Frames work on a very similar manner, with various weight classes, like featherweight, light, medium, etc…  In addition they have variant number of weapon mounts of different types ( forward facing, 360, back facing, 360 degrees auto tracking, pod based, etc ), maximum weight for all add-ons ( engines, weapons, armour, etc ), maximum internal space for engines.


So, in the beginning, machines would be only a few meters tall, with a single weapon and underpowered engines and minimal armor.  By the end though, the player could be piloting a literal titan, several meters tall and bristling with weapons and armor.  Of course then, so will their enemies. 


From a developers perspective, this means I need to figure out how to make weapons44784_md-Guard, Imperial, Sentinel, Tank, Walker, Warhammer 40,000 modular.  In the end I imagine this comes down to dynamic parenting of bones, but it is something I need to look into from a technical point of view before continuing too far ahead.  I had been tempted to make frames even more customizable, so different legs, torsos, cockpits, arms and weapons, but truth is I think the level of work is too high to handle right now, especially when it comes to creating the animations.  If the modular weapons end up being not too difficult, I may revisit this concept.


You know, the name Frames is starting to grow on me.  BattleFrames?  Battle Frame Formats?  Yeah, that’s the perfect name, BFF!  Oh, wait….  *groan*  Back to the drawing board.


For those looking at the various inspirational images in this post, they are from the top Ripley in a Power Loader in Aliens, the Walker from Avatar and finally the Imperial Guard Walker, which is probably the closest in my minds eye to the kind of vehicle the player will start in.  Think of it like the go-cart of Frames.


25. April 2011


So, in its relatively short lifespan Android has seen a 1.0, 1.5, 1.6, 2.0/2.1, 2.2, 2.3 and most recently 3.0 release.  As a developer, you need to decided which of these to target and which of these to ignore.  In many ways, if you are using Unity or another engine it makes the decision easier, as they set a minimum level and abstract away the details in their own code.  For the record, the minimum Android version supported by Unity is 2.0.


One of the most obvious factors in deciding what version to support is market penetration.  Luckily, Google provides such information.  This chart shows the OS version of devices that have connected to the market in the past 14 days.


Hmmm, pretty simple really when you look at it.  Support Android 2.1 and higher and you are good to go.


From a developer perspective this is pretty true too.  There were vast numbers of changes between 1.5 and 1.6, things you would think would be a no brainer like multi resolution support, but due to such small market numbers in the first place, I think we can simply ignore 1.5 and earlier.  Trust me, they aren’t worth developing for.

Android 2.0/2.1

From a game developer perspective Android 2.0 really isn’t all that different from Android 1.6 but there are a few giant gotchas, not to mention the various “undocumented” features.

First off, due to a move towards virtual buttons, HOME, MENU, BACK and SEARCH buttons now execute on key up, instead of down.  These little changes cause all kinds of nightmares moving between platform versions.

Perhaps of the most importance to game developers, MotionEvent can now report multiple simultaneous touches ( aka, multitouch ).  Also, if you are using the NDK ( C native code ), OpenGL ES 2.0 is now supported.

Really, that’s about it.  There are other changes of course, support for bluetooth 2.1 profiles, better thumbnail generation, etc… but to a game programmer, not much else of consequence changed between 1.6 and 2.0.


Android 2.2

This was the big daddy of all updates.  First of all, they enabled JIT in the Dalvik VM, resulting in 2x-5x performance increase CPUwise over Android 2.1.  Personally, I never experienced anywhere near that level of increase, but the improvement in speed is extremely noticeable.  So first and foremost, your code is going to be faster running on Android 2.2.  If CPU bound, in some cases then, your code is going to be MUCH faster on Android 2.2.

Besides enabling JIT there were a number of other changes of note to a game developer.  One exceedingly big one is the ability for Apps to install to SD card instead of into the devices memory.

Perhaps biggest of all is that OpenGL ES 2.0 support is now available to Java based apps.  The media framework also gained a few new abilities that are quite useful, like the ability to detect the completion of a sound loading in a SoundPool.

That’s about it, but then again… a massive increase in speed, the ability to load to an SD card and OpenGL 2.0 ES support…  that’s a pretty substantial upgrade.


Android 2.3

Android 2.3 is one of the first versions that actually looked at gaming as a priority.  They improved the garbage collector to minimize pauses, which are killer to immersion.  Nothing like having a 30fps shooter slow to a crawl because the garbage collector kicked in.  They also increased the performance of touch and keyboard events and used a 3rd party OpenGL ES video driver to increase 3D performance.

In the feature perhaps most called for, they implemented OpenSL ES for native audio support.  Up until 2.3, audio support has been at best weak on Android.  Now expect to see a lot of audio applications from the iPhone show up on Android because frankly until now, they were impossible to implement.

For the very few games that require it, if you want to use a front facing camera, Android 2.3 is where support was added.  Also added support for a slew of new sensors to enable Wii-esque actions, if of course the device has said sensors installed.

Really, in the end, the audio changes are the main event in the 2.3 release.

Unless of course you are doing Native Development using the NDK.  If that’s the case, this release was huge.  Until 2.3, you basically used the NDK to develop libraries that you called from a Java code.  All your UI and event management code had to be done in Java.  With 2.3, they added the NativeActivity class which pretty much allows you to work 100% in NDK/C++ code and kiss java goodbye. 

This should result in a performance improvement and make porting to Android easier.  My question is, will it fragment the market even more?


Android 3.0

And this brings us to the most current release as of writing, 3.0.  3.0 was mostly about adding tablet and tablet UI support to Android, but from a developers perspective there were a few new additions that are handy.  Lets go with the biggy first, Android 3.0 is the first OS release to support multicore processors.  So I suppose you want to target that shiny new Tegra2, 3.0 is where you are going.

They also added new animation support, but that’s not really animation support in a way that a game developer would care, that’s more for flying bouncing windows and other annoying and overly abused eye candy.

They did however add hardware acceleration for 3D graphics.  I am kind of surprised it took this long, but is definitely a welcome feature.

They also added something called Renderscript, which due to my ignorance may or may not be of use to game developers.  I really need to look into it further, but for now I will let Tim Bray @ Google explain it.

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.

When I get the chance I will look into this Renderscript a bit closer, but it does sound interesting.  3.0 is such a niche of installed devices however that it really isn’t a feasible minimum level to target at this point.



So in summary, 1.5 and earlier are so ancient and decrepit you are just as well as ignoring them.  1.6 is pretty much the “core” of the current API, but a large portion of the 1.6 install base will be running on old hardware where the resolutions simply may not be worth supporting ( like 320x480 ) in a game, so this generation may be skippable on that merit alone.  Multi-touch and ES2.0 native support are the big draw to 2.0/2.1, while 2.2 offered a fair number of advantages.  Simply put, 2.3 and 3.0 currently don’t have a big enough install base to bother supporting as your minimum target.

Therefore, and this is purely opinion, if I were starting a game today… which I suppose I am, I would look at 2.0 as my baseline target unless I really needed one of the new features or the performance gains that 2.2 offers.  Luckily in my case, the developers at Unity already came to the same conclusion I have.

One last word of warning.  In my brief time working with Android, I found version bugs to be a major pain in the ass, especially in code dealing with media.  I had code that wouldn’t work in the emulator, that would only work in the emulator, that would work in 1.6, and 2.2 but not in 2.1.  Put simply, Google have done a pretty terrible job at times in the forward/backward support category.  With your code, make sure you test on as many devices and as many OS versions as you can.  This single handedly is the reason I am not developing directly for Android any more.  I spent more time, by a large magnitude, dealing with crap like this than I actually did developing.  Of course, your mileage may vary!


24. April 2011

I suppose now is as good a time as any to actually talk about “the game” we are in fact going to create from scratch.  There are a few very key things to keep in mind when going through the game design process…  imagination is cheap and easy for most people, but you always have to keep in mind, at the end of the day you need to implement all these zany thoughts you have had.  So, in a nutshell, when designing a game, keep in mind your capacity and timeframe and ask yourself “can I actually do this?”.  In a nutshell I’m just saying don’t bite off more than you can chew.  So very often you hear people talking about how they want to make their first game, then go about describing some epic MMO that EA would have a hard time budgeting!

At the same time though “Pong from scratch” really isn’t all that exciting, although in all honesty it is a very good place to start.  I have created many “simple” games in the past and one of the quickest things you learn is, that simple it isn’t!  Ok… game time.

auto_duel_01Way back in the land of 80s computer gaming, there was a title called Autoduelcreated by Origin of Ultima and Wing Commander fame.  It was based off the Steve Jackson Games, um, game Car Warswhich in a nutshell was essentially MadMax the roleplaying game.  It’s the future, the world has gone to hell and we put guns on our cars… go!  Pretty much that was Autoduel.  Thing is, outside of creating my character, acquiring more money and sporting up my car, the game was actually rather lame, but the first few hours…. pure epic awesome.  Especially the time spent in the Arena and then using your winnings to design your first car! This bit of character building, customization and arena combat has always been buzzing around in the back of my head as the core of a very good game.

Now also may be a good time to point out that referring to yourself as “Lord British” is not really all that indicative of sanity.  This is to say nothing of poor “Chuckles” who you know had to have been talked into this whole thing.  Now Richard “Lord British” Garriott created many of the defining games of my childhood, so I am going to give him a pass on this one, but to you budding game designers, I don’t recommend it at all!

Anyways, back to the whole game design.  In a nutshell the big things I took away from Autoduel were the character development, arena combat and vehicle customization and of course the arcade like controls when you are actually duking it out.  The kernel of a very fun game is in those simple points.

Then in 2002, what is perhaps my favorite game of all time was released, Mechwarrior 4: 300px-MwmercsboxMercenaries. In this game you control a giant Battlemech, which is essentially a giant piloted robot killing machine.  What made this game truly great, especially compared to earlier versions, was the ability to purchase and customize your mech.  A perfect blend of strategy in the mech creation aspects, then thrust you into the action just like Autoduel did years earlier.  Even more uncanny, their was a portion of the game where you character competed in arena games, and again like years earlier with Autoduel, this was hands down my favorite part of the game.  Now, as I understand it, I need to be very very very careful in my use of terms here.  Mech, Mecha, Battlemech, etc… are all trademarked terms and will summon a hoard of avenging lawyers faster than you can say “lawsuit”.  This is why over the years we have been introducted to Chromehounds, Gears, Hercs and hundreds of other words that aren’t Mechs.  So let me say it loudly and now, this is not in any way going to be a game about Mechs!  This is going to be a game about giant mechanical human piloted robots!

So, before I get into more detail later on, essentially I am looking to create a game that combines Autoduel and Mechwarrior, with an arena focus.  Let me say this as loudly and plainly as I possibly can… our giant robots are not, in any ways Mechs!  So please don’t sue me.


21. April 2011

One of the very first things you need to decide when creating a game is what your target hardware is going to be.  This affects so many things, from the engines available to you, how many polygons you can use to create your models, how large your textures can be, etc…  In many cases, like with the Unity Engine, they take care of scaling across platforms to a certain degree but you still need to be frugal when resources are tight.

This then is a general summary of the “power” available to various different platforms and devices you may choose to develop for.

First off, is the land of the PC, which was probably always the hardest to determine as there is such a wide gamut of machines out there, from people running multiple GPU Alienware machines to the Walmart special your mom plays Farmville on.  That said, there is now an extremely wonderful resource for figuring out what the “average” machine is, thanks to Steam.  Steam runs a constant survey through their client and make the results available to everyone.This shows the most popular configurations, OS, GPU, RAM, software, etc…  A virtual goldmine of information for those intending to target the PC.  Nicely, they have recently started releasing Mac statistics as well.  One thing to keep in mind though, Steam skews more heavily towards “hardcore” gamers, as you obviously need to have installed a Steam powered game to be included in the survey.  Therefore the computers that have never seen anything outside of Facebook aren’t being represented.

As of right now, the average machine as reported by Steam is:

  • Windows 7 64 Bit
  • 2 core, 2.3 – 2.7Ghz CPU
  • Nvidia GeForce 9800 GPU 1GB
  • 4GB RAM
  • 1920x1080
  • 2MB internet connection


Frankly I am actually rather shocked by a few of those stats, including the fact Win7 64 is 37% of the install base!  The very key thing to note there though is the average video card.  The GeForce 9800 was released in 2008 and is a DX10 compatible card.  Key features as given by nVidia:

  • 112 Stream Processors
  • 512-1024MB of GDDR3 memory
  • 256-bits Memory Interface Width
  • 600 MHz Graphics Clock
  • 1500 MHz Processor Clock
  • 900 MHz Memory Clock
  • Texture Fill Rate (billion/s) 33.6
  • Memory Bandwidth (GB/s) 57.6
  • DirectX 10, Shader Model 4.0, OpenGL 3.3, and PCI-Express 2.0.


So there you go, if you are targeting the PC with your game, the above is the current markets “average” machine.

The end results of the above stats are actually being dragged down quite a bit by the Mac.  If you look at the Mac market only, your average target becomes quite a bit weaker.  The “average” Mac as reported by Steam is:

  • OS 10.6.6
  • 2.3 Ghz – 2.7Ghz CPU
  • 4 GB RAM
  • 1280x800 resolution
  • NVidia GeForce 9400M w/ 256MB RAM


So, if you are going to target the Mac, be very aware the average machine has a much lower resolution screen ( Blame the MacBook! ) and a much worse video card.  9400 doesn’t sound that much worse than 9800 does it, how bad can it be?  Actually, honestly, quite bad.  The key is M, as in Mobile, which is a card optimized for battery life and heat more than speed.  A quick look at the specs on NVidia illustrate this clearly.  Fill rate is 3.6 (billion/s), almost 1/10th the speed of the 9800.  So, keep in mind if you are targeting the Mac, if you want maximum compatibility, you need to set the graphical target quite a bit lower than If you are targeting the PC.


Now we move on to devices, where it gets quite a bit more difficult to come up with an average, as there are so many different devices out there.  As of right now, there are only two and a half viable targets, iOS ( iPhone/iPad/iPod ), Android and Windows Phone 7.  I list Windows Phone 7 as a half because their market share is currently quite appalling, worse than I would have expected at this point.  That said, they are about to become the exclusive OS of Nokia, which should change their market share drastically.   Android has significant market penetration, but to be honest the state of their app market, especially for games, has been absolutely horrid.  Since I purchased my first Android phone well over a year ago, the same game has been at the top of the charts, that’s pretty sad.  On the upside, with so many phones and such a crappy selection of games, the market is wide open for a good game to excel. When Game Dev Story was released to the Android market, it instantly jumped to the front of the charts, so if you make a great game, sales are possible.  I have to warn you though, if you haven’t played GDS and you wan’t to get your own actual game completed, DON’T!  I lost a few days of my life when that game came out!


Anyways, now on to the actual phones.

IPhone 3G/8-16GB iPod


This is pretty much the 800lb gorilla in the mobile phone space.  Easily the best selling and thus most common phone out there worth making games for.  Now for the specs:

    • 320x480 screen
    • 8/16GB storage
    • 128MB RAM
    • ARM 11 412MHZ CPU


The phone supports multitouch ( registers multiple screen presses at the same time ), a camera, light sensor, 3 axis accelerometer and a proximity sensor mostly for detecting if the phone is pressed to your ear or not.  In practical terms, you have touch and tilt to work with for inputs.  Other than the main button, volume, orientation lock ( now mute for some unknowable reason ) and the power button, there are no physical buttons available to you as a developer.

Of key importance is the GPU, the PowerVR MBX Lite which according to the all knowing brainthat is Wikipedia, it is capable of 3.4 million triangles per second and 270 million pixels per second.  Now keep in mind, these numbers are theoretical maxes, reality will be much different.  Even working with maximum values, the restraints start to become clear.  At 30 Frames Per Second, that means a maximum of 113K polygons per frame.  Now lets keep in mind, there is no way in hell you are going to come even close to that number, especially once you start adding textures.  I have heard 7,000 polygons is a pretty reasonable number to use as a target.  That’s 7000 polygons to represent everything visible on your screen, your player, your world, enemies, GUI, etc.  It sounds tight, and compare to the PC it is, but at the same time, the Nintendo DS is around 2K, so if you look at it that way, its absolutely massive!

iPhone 3GS/iPod 32-64GB

This was mostly just a spec bump release and probably didn’t sell enough to target at the exclusive of the 3G install base. The new specs:

  • 320x480 screen
  • 8/16/32GB storage
  • 256MB RAM
  • 600MHZ ARM Cortex-A8 CPU
  • PowerVR SGX535 GPU


In addition to the spec bump, the screen is now finger print resistant and the camera is quite a bit improved.  The most important details from a game development perspective are obviously the increased RAM and the improved GPU capable of a theoretical 14M polygons/sec an improvement of 4X that of the 3G.  Again sadly, this power is probably going to be of limited use to you simply by the economics of the massive 3G install base.



Next up, we have the iPad.  In essence it’s a really big iPod until you look at the guts.  Speaking of which, here they are:

  • 10 inch, 1024x768 screen
  • 16/32/64GB storage
  • 256MB RAM
  • Apple 1Ghz A4 CPU
  • ( 1 Ghz ARM Cortex-A8 + PowerVR SGX535 GPU )


So, that’s it.  On top of the functionality and buttons of the iPhone, it also added in magnetometer ( compass ) but otherwise the form factor and controls are pretty much identical, well except the whole being 2.5x bigger and heavier that is.  The most interesting change is the move to the A4 processor, which is an Apple designed and Samsung manufactured system on a chip.  In a nutshell, it is an ARM 1 GHZ Cortex-8 CPU coupled with a PowerVR SGX535 GPU.  So, pretty much this means the iPad is for all intents and purposes the same speed as the iPhone 3GS from a graphics perspective, and almost twice as fast from a CPU clock speed perspective.  The biggest difference between the 3GS and iPad from a developers perspective is the amount of screen real estate available.

iPhone/iPod 4


That brings us to the present, as of time of this writing, the iPhone 4.  Basically the iPad in phone/ipod format:

  • 960x640 3.5” screen
  • 16/32 MB storage
  • 512MB RAM
  • 800Mhz A4 CPU
  • 3 axis gyroscope


In addition, a 5 MP camera and a .3MP front facing camera were added to the iPhone4.  Again, the GPU is identical to that of the 3GS and the iPad, while the CPU is right in the middle clock-speed wise.


So, as a developer, you can essentially look at the iPhone 3GS, iPhone4 and iPad as more or less comprable devices, with the exception of slightly faster CPU speeds and substantially different resolutions and screen sizes.  All of which are capable of around 14M raw triangles per second as a theoretical max, while reality seems to suggest a polygon budget around 30K textured polygons per frame as realistic.  Will post some real world tests later on to confirm reality.

iPad 2


Now the newest kid on the Apple block, the iPad 2.  Basically a beefed up, scaled down, make me look at my existing iPad 1 in disgust version of the iPad.  Stats:

  • 10” 1024x768 screen
  • 16/32/64GB storage
  • 512MB RAM
  • 1 GHZ Dual Core Apple A5
  • Power VR SGX543MP2 GPU


So, take an iPad, make the form factor better, round off the annoying edges, smack on a camera at the front and back and you have an iPad 2.  Well… that and speed up the GPU by an order of magnitude and double the number of CPU cores!  This thing is a beast compared to the iPad/iPhone 4, scary the differences spec wise.  Theoretical max of 64M polygons/second, puts it at about 4 times faster than the GPU in the original, to say nothing of the fact you now have two cores.  In reality, you are probably looking at a polygon budget around over 100K per frame. 

So, right after the iPhone4, iPad and 3GS started to look like a great common baseline to target, the iPad2 comes along and throws a hell of a monkey wrench in the mix.  Hands down, as a gaming device, the iPad 2 is in a different league than all earlier devices.  You can choose to support all of them, but I am already seeing a number of complaints in the app store from iPad users where an app is made for iPad2.  Its interesting to watch reviews, where half are glowing 5 star reviews (iPad 2 owners) and the rest are 1 star complaints ( iPad 1 owners ).  If you really are pushing the limits, you may want to target the iPad2 exclusively.  That said, doing so shrinks your target market by a huge volume.




Phew…. that’s it for PCs, Macs and Apple portables… now on to the wonderful world of Android.






Top Selling Android Phones on

Name Chipset RAM Screen Other
NVidia Tegra2 1Ghz Dual Core 1GB 960x540
4 inch
16GB internal storage
HDMI out
5MP Camera
Android 2.3
HTC Inspire 4G 1 Ghz Snapdragon 768MB 800x480
4.3 inch
4GB internal storage
8MP Camera
Android 2.2
HTC Thunderbolt 4G 1 Ghz Snapdragon 768MB 800x480
4.3 inch
8GB internal storage
8MP Camera
Android 2.2
Motorola DROID X 1 Ghz TI OMAP 3630 512MB 854x480 8GB internal storage
8MP Camera
Android 2.1
T-Mobile (LG) G2x NVidia Tegra2 1Ghz Dual Core 512MB 800x480
4 inch
8GB internal storage
8MP Camera
Android 2.2
HTC Evo Shift 4G 800 Mhz Qualcomm MSM7630 512MB 800x480
3.6 inch
2GB internal storage
5MP Camera
Android 2.2
Slide out keyboard
Samsung Galaxy S 4G 1 Ghz Samsung Hummingbird 512MB 800x480
4 inch
1GB internal storage
5MP Camera
Android 2.2
HTC Droid Incredible 1 Ghz Snapdragon 512MB 800x480
3.7 inch
8GB internal storage
8MP Camera
Android 2.2
Samsung Epic 1 Ghz Samsung Hummingbird 512MB 800x480
4 inch
0 internal storage
5MP Camera
Android 2.2
Slide out keyboard
TMobile (Google) G2 800 Mhz Qualcomm MSM 7230 512MB 800x480
3.7 inch
4GB Internal storage
5MP Camera
Android 2.2
Slide out keyboard


Other Android Devices of Note

Name Chipset RAM Screen Other
Sony Xperia X10 1Ghz Snapdragon 384MB 854x480
4 inch
0 internal storage
Android 2.1 (1.6 shipped)
8MP Camera
I own this phone and Sony Ericsson should burn in hell
Motorola Xoom NVidia Tegra2 1Ghz Dual Core 1GB 1280x800
10 inch
32GB internal storage
Android 3.0
TMobile Hero ( G1 )
528Mhz Qualcomm MSM7200A 288MB 480x320
3.2 inch
0 internal storage
5MP Camera
Android 1.5
Slide out keyboard
Motorola Droid 600Mhz TI OMAP3430 256MB 854x480
3.7 inch
0 internal storage
5MP Camera
Android 2.1
Google Nexus S 1 Ghz Hummingbird 512MB 800x480
4 inch
16GB internal storage
5MP Camera
Android 2.3


As you can see, there are a great many phones, but in the end the hardware is pretty standardized.  If you are creating a phone of any technical complexity you can probably forget the first generation of Android phones like the G1, frankly they are pretty terrible. 

Of the installed phones, most of the phones shipped in 2009 and much of 2010 have a 600Mhz to 1 Ghz, with 256-512MB of RAM.  OMAP, Snapdragon and Hummingbird are easily the most common CPUs.  Of the install base, the majority of phones in peoples hands these days fall into this group.

As to phones being sold these days, 512MB of RAM and the 1Ghz CPU’s seem to be the norm, with dual core Tegra’s being more and more common on high end phones and in the tablet space. 

Now time to dive into each chipset with a bit more detail. 

Lets start with the monster in the group, the newish NVidia Tegra 2.  It is a dual core ARM Cortex-A9 running at 1 Ghz.  Integrated is a NVidia ULV GPU with 4 pixel shader and 4 vertex shader cores  ( by comparison, a Radeon 9800 had 4 vertex cores ) running at 330mhz.


Anandtech summarize things nicely with this benchmark.

When it comes to raw rendering, the Tegra2 is really top of the class.  I do find the iPhone4’s performance extremely confusing however.  That the 3GS is almost 3x superior to the iPhone and iPad seems extremely wrong.

As you can see though, in the Android world, most Android phones regardless to chipset, preform fairly consistently by generation.

In the end, I am targeting the iPad/iPhone/3GS/mid-upper range Android phones with my game.  Why?  Because they are capable enough, sold well enough and frankly… those are the phones/devices I own! Winking smile


AppGameKit Studio

See More Tutorials on!

Month List