To coincide with the release of CometsAndCraters I thought I would do a ‘look back’ at the project. CometsAndCraters has been around 9 months in the making and I have to say that at times it has seemed much longer. We created our first game for the Christmas market last year (JingleBalls) but in sales terms it was not a great success but we did make it primarily to understand the process of making an app from end-to-end so from that point-of-view it was very worthwhile although by the time we reached the end of CometsAndCraters we had forgotten most of what we had learned from the Apple process.
We are a team of two, Neil the Designer (Australia) and me the Dev (UK).
The Game
Comets and Craters is a Tower Defence meets RTS. It is a 2D game which can run well over 300 sprites at a time and the performance is very solid. There are no physics in the game and the only movement is a transform on enemy vehicle sprites. Tower movement is made by swapping out sprites as is the tower firing. Vehicles notify towers when they are in range by making a radial scan each time they move from one grid square to another. If a tower is in range and its not burned out and its not already firing at a weaker vehicle (health wise) it will fire at the vehicle that has notified it. The AI is A* which has been cut down to its bare bones and looking for a new path is only called upon when absolutely needed. Each vehicle passes its path to the one behind it unless a new tower is laid or a tower is sold. To get around constantly searching for a path the game goes into auto pause mode when dragging a tower. This means we only have to check for a new path when the tower is placed. Its also a nice feature which allows the player to move the tower around without panicking that the vehicles are going to overwhelm him. I would say the trickiest part was deleting sprites and destroying vehicles as it became a real timing issue. A vehicle could be killed which has a sprite attached to it which shows it firing and another sprite showing its health. The way around this was not to destroy the vehicle object but to move it out of sight then in between enemy phases to delete in a more controlled manner. This also had the benefit of moving a process out of ‘gameplay’ and into a dead time between phases.
Lessons Learned
We wasted the first month and a half believing that we could make a 3D Tower Defence game which ended up by us both realising the performance just was not there, especially with iPhone 1.0. We did get a lucky break at this point because Brady brought out SpriteManager and this firmly planted us into making a pseudo 2D game.
Neil must have made and remade the Atlases a hundred times. We went through the painful process again-and-again and it was not until the final couple of months we got it right. Tying up the Atlases with SpriteManager and DrawCalls is ultra important.
I would say never underestimate what even one extra DrawCall can do to your game.
In future I will start the Save and Resume game option early or at least put the framework in place to manage this and then just add to it as I go along. It took me three times longer than I budgeted to implement a Save and Resume.
Organise the hierarchy is another lesson I learned. In future I intend to suffix each GO with letters that mean something such as rp for runtime parent (a GO that is used as a parent for clones) and so on. My hierarchy got messy very quickly.
Centralise only when necessary. I am now a firm believer that you let objects take care of themselves. CometsAndCraters has a centralised touch class but very little else is centralised.
I probably have too many public vars linking to other scripts which I know will make maintaining this game difficult when I have not touched it for a while.
Copy and Pasting objects in the hierarchy is not your friend. Because of the linkages I messed up so many times with copy and paste and then picking the original to work on rather than the copy which was now sat is several other public vars on scripts (always make from scratch now)
I had to revisit code time and again and realised that tearing it down and remaking it is not a bad thing, sticking to the original code cos it took a while to code is not always the best option.
Test, test and keep testing all the time and I do this on the iPod as the results can be a real surprise you when compared against what you see using the remote.
Going back over old code was a smart thing to do as I developed my experience very quickly I noticed code that was only a couple of months old could be optimised. I would also say that its best to optimise all of the time and not think about it at the end.
Overall its been a great experience. Will it sell? who knows but for sure we are trying to follow all of the good options that have been proposed in here and other forums.
There is a whole set of tutorials on the site (link in sig) under the video tab so you can see how it all hangs together and how the gameplay works. If you have any questions at all on this type of game or any similar 2D game ask away and if I can I will be happy to answer them.
CometsAndCraters FTW 
