This is a summary of the process of developing the game Kondrian.
You can see more on Kondrian here, or on iTunes here
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).
This post has been sitting in the wings for at least 4 months. I delayed the posting until the Kondrian release.
One More Thing
Mid 2012, I attended the One More Thing conference.
One of the nice things that came out of this conference was some nuggets of wisdom from Kepa Auwae, he also had a very dry sense of humour.
Kepa is one of the founders of RocketCat Games.
Kepa’s stressed that his business strategy is always in flux, that RocketCat Games are always experimenting. They try to improve their business, by trying different things. One of his most interesting comments, was the description of a simple business model for game developers, which is actually known to us all.
Kondrian is on the App Store!
Here is the iTunes link Kondrian on the App store
And the website link: Kondrian website
Press kit: Presskit
Home grown Press release:
(with the help of GLKit)
There are many ways to do this, its often used in paint programs.
Philip Rideout’s iPhone 3D Programming has a way to do it in C++, but its hard to abstract the method from the code.
There is a nice article written here which gives the method I used.
In my case the lines are temporary exhaust lines – so I don’t need to bake the lines into a texture as the above solution does.
The method just draws line segments from point to point as rectangles. Each line segment is a sprite which is rendered which ever way you render your OpenGL sprites.
Here is a picture of a ship emitting an exhaust – that uses the code below – the ship is moving very fast – so the sharp angles don’t matter so much.
And below is the code I wrote to do the lines:
The development of my game Kondrian is coming to an end.
Here is a miscellany of what I think we’re useful lessons, each too small to warrant a blog post:
- Each of the levels in Kondrian can be 100 x 100 tiles wide. It’s simple enough to only draw the tiles when they are on screen, but I also created a scheme a bit like UITableviewCells in a UITableview in order to conserve memory. There are in fact only about 200 tiles (depending on whether its an iPhone or iPad) created, and they are reused when they go off screen. Reusing usually involves giving the tiles the appropriate texture for a tile potentially appearing onscreen in the direction that the player is moving.
All sprites (and the vertices, indices, VBOs VAs) are created at startup.
When a sprite is needed it is de-queued and enabled, only enabled sprites are updated and drawn. No on the fly malloc-ing or creation of gl buffers.
Here’s a recent quote by Anna Marsh on Games Brief:
The key thing is that documentation produced needs to focus on being a practical manual for the team to work on, minus any marketing gloss. To make a comparison with architecture: During the planning phases of a building an architect might prepare Photoshop visualisations with happy pedestrians and sunny skies to show the public and financiers what the final building will look like. But they’ll also prepare far more precise blue prints, plans and technical documents for the actual builders.
Later in the article:
The more experienced the designer writing the documentation, (probably) the less changes you’ll need to make in development.
Humans look for ways to simplify things, often creating models in order to help them achieve things without being destroyed/distracted/confused by the complexity of an undertaking or a system.
Some famous game developer whose name I cannot remember (sorry about that whoever you are), said recently at a conference; that the AI of your game “enemies” can be a major part of the success and differentiation of a game. I don’t think you can instantly create great AI, it takes a lot of work, and for me its still “work in progress”.
So, I’ve been working on AI lately with the help of this excellent book as a reference.
This book is really good, not only for AI but also for anything to do with game movement.
Reading this book, suddenly made vector and matrix calculations make sense. And once they make sense its hard to use normal trigonometry again.
Below are some macro’s I’ve built with the help of the book.
This is part seven of a series on making iOS games.
Getting collision behaviour right, can take some time.
For me it meant working on two things:
- An algorithm for finding collisions and making sure that that algorithm does not take too long
- working out the right behaviour post collision
This is part six of a series on making iOS games.
With hundreds or thousands of particles on the screen, a particle effect is a great way to bring your frame rate precipitously down. There are so many different aspects of the particle engine that can effect performance.
Michael Daley has a whole chapter on this (see resources below – and he is right – its a big time sink).
I started off just extending the normal sprite classes which I created in the game template (which I talked about in the last post in this series), and then gradually moved to including more and more optimisations.
I (like everyone else) pre-create a number of particle engines, so that the expensive operation of memory allocation does not have to happen during the game, more as a precaution, than something I’ve rigorously tested with the profiler in Instruments.
Point sprites are a common thing to use with particles effects, to try an optimise things. With each particle as a point sprite you dont need to pass as much data to OpenGL, theoretically 1/6 of the data, since you are only passing one vertex per sprite, not two triangles.
In order to use point sprites you need to set the point size in the traditional vertex shader. I couldn’t see any docs on how to manage the point size in the GLKit base effect – this would be something like:
in the normal OpenGL ES 2.0 vertex shader.
So I experimented a bit and created a particle engine using the usual OpenGL ES 2.0 vertex and fragment shaders to do point sprites, and the same (as the game template in the previous post) GLKit base effect for the other sprites such as the player, background tiles etc.