Intro the indie
Half the world’s developers seem to be indie game developers, but I think there is a difference between developers who are already game developers who move to developing games on iOS, and those developers who are already developing on iOS and move into game development.
Based on the current number of games appearing in the store daily (148apps as many as 140 per day), there is a lot of game development going on.
Many of these seem to have been created by indie game developers, obviously indie game developers don’t need an introduction.
I however am coming from a different angle than most developers, a seasoned non game developer with a lot of experience on iOS, shipping my first ‘real’ iOS game (I’m not counting a kid’s game I wrote for a client because that was primarily UIKit and CoreAnimation, and much simpler).
An oft recommended process to starting game development is to:
1. to iterate through making simple games first, and also,
2. to reduce your ambition for the first “real” game.
A few years ago I spent a couple of months making Tetris, Pac-man, Space Invaders, Defender and an early version of Kondrian called IcePhage. These were written for the desktop and in MacRuby. It was relatively easy. IcePhage took me 2 weeks, after having developed the game engine in the earlier games. It wasn’t easier because it was MacRuby, if anything that made it harder because the OpenGL interface was clunky. It was easy because of the vastly greater horsepower of the Mac. I could write everything in direct mode OpenGL – thousands of draw calls were made (though particles were a still challenge), and everything performed fine.
The two major challenges with iOS are:
1. that the devices are relatively CPU and GPU constrained compared to a Mac, and
2. the control mechanism (not the keyboard) has to work on both large and small devices, and that control mechanism is touch.
I spent a lot of time converting IcePhage to a prototype version of Kondrian, most of that time was creating a whole new game engine in OpenGL ES 2.0.
Your own engine vs Unity vs Cocos2D
Roll your own? Or use third party? It probably doesn’t matter which one you choose, you and your game will adapt to the technology. I chose my own engine because I didn’t want to shirk from the hard stuff. Choosing easy solutions in the past, had had negative repercussions for my own development.
I also wasn’t sure that Cocos2D could give me the performance I needed, and as far as Unity is concerned I didn’t want to be:
1. quite so divorced from UIKit (although there are ways to call UIKit, it doesn’t seem that simple – whereas using GLKViewControllers and calling UIKit ViewControllers is no different to normally moving from one UIViewController to another), and,
2. I wanted to stick to Objective C, and leverage code I already had. I ended up using quite a few technologies which I am sure would not have been so easily integrated into Unity, for example MagicalRecord with CoreData, Parse etc.
If I didn’t care about UIKit, for example if I wanted to deliver to other platforms, then I would choose Unity.
Integrating with UIKit
Graeme Devine gave a couple of great talks at WWDC a few years ago (Game Design and Development for iPhone OS Part 1 and 2.).
In those talks he evangelised the use of UIKit in iOS games. UIKit is used in Kondrian for menu screens, Game Center screens, help screens, the pause screen, and the screens involved in creating your own moves/aerobatics. Other UIKit objects were UIBezierPaths, standard UIButtons (with the usual retina and non retina images), UILabels and so on.
In the end there were four different logical sections in the game code:
1. OpenGL Engine & game classes (e.g. sprites like weapons or enemies) which had OpenGL calls in them primarily to setup OpenGL buffers and then to copy data to those buffers during updates,
2. UIKit classes,
3. resource management (see below),
4. the level builder (different app).
Artist and bootstrapping other media
You need to sit next to an artist and somehow (with money or beer) coerce him or her to spend a lot of time on your game, and that time should be as much as possible spent when you are in that same room or office.
It took me a long time (not through lack of effort) to get a designer directly involved in the development process.
When I finally managed to find the right person, it was quite unexpected what an qualitative influence good looking graphics had on development. The quantitative improvement, I expected, not the qualitative.
Pretty much everybody says use programmer graphics to get most aspects of the game finalised. However having good graphics gave me not only lots of energy and enthusiasm, but it really felt like I had – so to say – a kind of high quality canvas to create and place ideas upon. Integrating beautiful graphics catalyzed more and more ideas, ideas that when integrated with more nice graphics added to the game significantly. In addition sitting next to the artist to prototype the art was so much more productive and efficient than sending a brief to somewhere far away artist. We were 10 times faster and created 10 times better graphics, sitting next to each other.
⁃ “wait if you put that curve there – it will look like a dragon! cool! Can you make it an ice dragon or a fire dragon.. what happens if you give it emerald eyes instead of blue?”
The iteration times are so much faster too.
⁃ “those blue arena tiles are cool – but the barriers don’t blend – can you give me a barrier with blue outlines?”
(1 minute later blue edged barriers are in my dropbox).
Game play evolves through iteration
When it comes to game development, there is a common aphorism that your game play must be in place before you even start coding, even to the extent that a prototype should be fun if made from cardboard. I think this is ridiculous. With such a scheme I would never have bothered finishing the game.
There seems to be a bit of old style Waterfall development philosophy in the game community. However I found low ceremony iterative development created better and better game play. Going in directions i couldn’t have imagined. The game play evolved just like functionality in any other home grown app (i.e. not a contracted app for someone else). In addition different parts of the game, as they iterated, had a big effect on game play – e.g. controllers iterated, environment types iterated, physics iterated (e.g. the player swoops because the velocity gets redirected by the players angle), and so on, all played a part in driving game play.
Another example, is the main differentiator of Kondrian, which is the “create your own combat moves” paradigm. In a certain melee you might swoop twenty or thirty times in and out of enemy range. The pre-programmed moves idea came a long time after I had finished the game engine, level builder, story and lots of play testing. It just popped into my head while sitting in an audience at a conference, I never would have had this idea with a paper version of my game.
My belief is that you have to work on the canvas for a while before the great ideas come. You have to trust yourself that you will iterate, adapt and create innovations that you can’t imagine at the start of development.
I enjoyed creating the story of Kondrian, most of the story does come out – if you read the log in the game, but its not absolutely necessary for the player to understand. For me the story was a great framework on which to build the rest of the game. Lots of ideas came from the image of a castle floating in another dimension, where the castle is really like a mechanical analogue of a cell, with requisite viral invaders and pathogens, defensive phages, mitochondrial engines, and Kondrian himself lurking in the centre of it all, waiting for the player.
Here is a quick rundown of the technical aspects of the game
• I used GLKViewController for managing the OpenGL view – gives easy setup (fps, etc), pausing, and integration with other UIViewControllers,
• I used two GLSL programs which seem slightly faster and more efficient than GLKBaseEffects. One program for the background tiles – where no colour attribute is necessary, and one for all the rest,
• I used 5 VAO/VBOs – for tile layer, sprite layer, particle layer, controller layer and text layer,
• Each layer gathered up all the sprites or particles that it has to draw in the next frame (those sprites that are on screen, visible and valid) and then copies to the appropriate VBO,
• The layers are created once having the maximum possible vertices, but only those sprites which are valid and onscreen are copied to the respectiveVBO,
• All sprites (which are 6 vertices – making a square) are created at startup in a resource controller.
• You ask the resource controller for a sprite – it gives it to you and makes it valid, when you no longer needed it is returned to the appropriate pool and made invalid,
• The resource controller was the most important change in the engine, it made adding and removing game entities, moving between levels which have different numbers of sprites super easy,
• Two texture binds – sprites&tiles and text bitmap.
• Created in photoshop exported to 4 main texture atlases managed by TexturePacker . Atlases for iPhone, iPhone retina, iPad, iPad retina, though I had to split one of the atlases for iPhone4 and earlier because of memory constraints.
• The text bitmap font – Gunship was exported with GlyphDesigner.
• Sound effects – a mixture of free and purchases sounds from many sources.
I treat the tiles a bit like a UITableView, there are a limited number created, dependant on screen size, and when they go offscreen they are moved to the other side of the screen, reset with appropriate textures.
• Use this excellent book http://www.amazon.com/Programming-Game-Example-Mat-Buckland/dp/1556220782. It helped not only with AI but with some of the physics.
• I heavily used GLKVectors, not because they are faster (they often aren’t faster than normal trigonometry) but because they are a much higher level way of manipulating vectors, angles etc, GLKVectors just clicked after reading Matt Buckland’s book above.
• For performance reasons I only use the AI when within a certain distance of the player
• I created different behaviour using different constant values(e.g. individual aggression factor, group aggression factor, available manoeuvres, barriers and walls) depending on type of sprite.
Getting the physics realistic looking, involved primarily playing around with acceleration and velocity to make a nice smooth flight without jerky movement. For example in non retina if the velocity eventually rounds to an amount which changes every frame despite constant acceleration (e.g. 10,11,10,11) the ship will not move smoothly. The biggest influence on this is the frame rate – which we get from the GLKViewController. However it can be all over the place (regardless how much work is being done), and contrary to theory, it looked better to set the frame rate to 1/60 if for some reason the GLKViewController asserted that it was close to 1/60 but not quite.
Theory says that if the frame rate drops then the velocity divided by the time delta should counter the slow down and we should get constant speeds. That might work in principle if your frame rate is moving say between 30-60 – but with a range of 58-62 – it was better to set the time delta to be always 1/60 otherwise motion was not smooth. Not smooth enough for me anyway.
Sprites only collide when on screen, and use simple rectangle intersections.
Sprite wall collisions however are not a simple rect intersect, each corner of a sprite is calculated to have a row and a column, given the height and width of a tile size(and thus barrier).
Then you check the tile matrix (2D C array) whether for a given row and column there is a barrier there- and if so – revert to previous position. In Kondrian its much more complicated, because I try to preserve x or y velocities sometimes – but thats the more or less it for all moving sprites including particles.
particles are old school linked lists, and are not manipulated in vertex shaders a la Erik Buck (a good reference by the way Learning OpenGL ES for iOS), mainly because the particles bounce off walls, but possibly in future games I may want the particles to change textures,
A couple of years ago there was a talk at WWDC suggesting using UIGestures with OpenGL.
Its actually pretty easy to do and if the views that the gestures are attached to are invisible, it doesn’t seem to have a significant impact on performance.
2D performance on iOS has different issues than 3D, blending is needed much more in 2D has a much bigger impact on performance than other OpenGL calls. You see this impact especiallywith particle systems, thousands of particles all blending on top of each other is a necessary 2D effect.
In the end much of OpenGL ES performance profiling was primarily about trying to get iPad1, iPhone4 and iPod Touch 4G to perform well.
There is a lot of angst and anger around on the web about these devices and their lack of OpenGL ES performance.
Apart from having a generally efficient OpenGL ES engine and reducing the number of tiles to draw (which is challenging since the tiles are actually rotated 45 degrees), in the end I reduced the number of particles in explosions, and removed some of the effects for those slower devices. Another option would have been to go down to 30FPS for the slower devices – but I couldn’t stand the less than super smooth motion of the ship at 30FPS.
I created a quick a dirty level builder to create levels and I would export them manually (via iTunes). A better way would be to store the map on a server so that the game can download the new or updated maps.
For testing purposes I tended to play a lot at the start or end of the game, so I had to seed low level maps with weapons or monsters, that wouldn’t normally be there. This was so that it wasn’t necessary to play through the whole game (which I estimate would take minimum 12 hours) to test various weapons.
I had some influential people retweet my release messages (thanks!), it made little impact on sales (which are yet to pay off the cost of sound effects). The quality of your game (or at least how you judge the quality) has little impact on uptake. there are many games on the store which have had large success, which I personally think aren’t as good as Kondrian. Thus my conclusion is that a good game will not by itself get you sales.
There are many other blogs out there talking about to try and improve app discoverability regardless of whether you make a game or not , I’m just going to say its hard to get noticed. Contacting influential bloggers is apparently important, but since very few reply its hard to learn marketing lessons there.
- tie in with a brand
- build 10,000 followers first
- build up an app review site – then review your own app
- make money some other way and do it on the side for fun, thats what i did, though it still dragged me in and used up a huge amount of my time.
Conclusion – have fun
As you might guess from the above, creating a game required way more effort than many non-game apps would, and it usually requires a lot more investment from an artist.
I personally think that using UIKit into your game allows you to leverage your UIKit skills and more quickly create an environment that your game can sit in. Once you are happy with your engine, resource manager and asset pipeline, its much easier to concentrate on the game itself, game play, AI, effects and so on.
However the biggest challenge in creating a game is that every day (as of this writing) there are 140+ games entering the AppStore every day. Even the highest quality game is not going to get noticed with out some innovative marketing. As far as I can tell the best way to do that is to befriend a well known game blogger, buy them a beer and coerce them to review your game positively (thats my next step anyway).
One thing that is really important is that when you play your game, you look it at and go “Wow! I made this!”, it has to be fun and you should feel like you created a work of art.
I have actually created and published games before, an iOS kids game (Core Animation) and a long time ago half a dozen infotainment games using Marcromedia products (C++ plugins anyone?). But Kondrian is really the first major “proper” game from start to finish of my own making.
What was a surprise to me that when making my own game, was that when I had to go back to “normal work” to pay the rent, how much I missed the game programming! Its really great fun tinkering with AI, trying out different control schemes, creating a new weapon with requisite OpenGL effects. Its one of the most fun and rewarding development projects I’ve worked on. So encourage you to go out and try it – if only to experience that fun.