Development diaries - December 2010 archive

01/12/2010
Had a talk with Nick and we agreed on a scheme to create the spritesheets and define each sprite animation and coordinates correctly. He will revise his spritesheet creation tool accordingly.

I also started working on a level manager that will load level definitions from an xml file.

No commit yet

03/12/2010
Finished the level manager, now the game can support many stages and levels. For performance reasons I chose to define enemies, spawners, explosions, effects etc per stage, and load them upfront. Also per stage takes place tilemap loading to avoid delays between levels. Every time a new level is about to begin the GameLayer is cleared and corresponding sprites/spritesheets are attached to it again. Since nothing is really created between frames the whole thing should be quite fast.

Nick delivered a really good tool for spritesheet creation which exports, apart from a png spritesheet, an xml file with all sprite definitions as well. It even supports animated sprites in the same xml file. I will have to alter the way we define and load enemies and stuff but it is well worth it.

No commit yet.

06/12/2010
Nick created two spritesheets that contain all game sprites (one for normal blending and one for additive), and I modified the game to use those to define the game entities. Spritesheets and sprite frames are now defined in xml files and are dead easy to alter and customize. To facilitate spritesheet management I added a Spritesheet manager which we can use to register and attach spritesheets to the game layer. The spritesheets are created per stage and reused by all the stage’s levels.

I also added stage and level definition externally through xml files. Committed everything back to repository. Additive blending on laser bullet sprites make them seem a bit faint, I will have to talk to Nick about that. Do we really need additive blending there? Also the sprite textures probably need a small padding in the spritesheet, I see artifacts on the borders of the sprite.

We have all that wonderful game technology in place, lets hope we will also have a game...

07/12/2010
Explored the additive blending issue a bit more, it seems that a {GL_ONE,GL_ONE} blending function works ok after all, it was me not interpreting the visual results correctly. In the process I found out that xcode apparently premultiplies alpha to color before sending the a PNG texture to iphone. It does that because there is no space in VRAM to store the alpha value. This is something to keep in mind. I also added the functionality to specify flipping of sprites in the xml files. We need this because some laser bullets (from player weapons to be more specific) point upwards in the texture and this conflicts with the general mechanism to create and orient bullets. Probably easier to fix that in code than re-create the spritesheets.

09/12/2010
Talked to George about level design, we should have the first levels any time now. In the meantime we had to change plan with our source repository provider. I did a test commit, it still works fine. By the way of the test commit I added support for horizontally flipping of sprites, specially needed for flipping the bullet sprites. I also tried using nearest neighbour sampling on the sprites as suggested by Nick some time ago. I can’t say that I like the visual impact it has, I can clearly see the aliasing along the sprite edges as well as texture “waves” on the sprites. Deactivated for now.

10/12/2010
With the new spritesheets we needed a uniform way of handling sprites and animations so I added a new SpriteAnimation class that does just that. So now game entities do not have to deal with sprite animation at all, it all happens automagically!

I also started implementing weapons effects (the weapon fire). I used the existing Explosion class for that and it works perfectly. Committed changes to the repository.

Still waiting Nick’s new Spritesheeter with padding around sprites. Now there seem to be artifacts at the edges of each sprite.

14/12/2010
While waiting for the new spritesheets, I trimmed one pixel along the perimeter of each sprite frame, in code, and the artifacts went away. Maybe we can go with that solution after all? I also noticed that the explosions in the mockup where larger, so I added the functionality to set the explosion scale in the xml file. Explosions are now much more impressive. Finally, I implemented a few other weapon effects, it is really a breeze now with the specification-through-xml system in place! No commit at this time.

15/12/2010
Added player definition through xml files to make it comply with the data-driven scheme we are using. I also added a few more effects. It seems that making GameEntity derive from CCSprite wasn’t such a good idea after all. I should have decoupled entity visualisation from the entity itself. As it is now it is a bit restrictive and it doesn’t easily allow me to combine multiple sprites per entity, as in the case of bonus items. We have gradually shifted towards a component-based approach in the game anyway, the only cacophony is the inheritance from CCSprite. The Sprite should be just another component of the entity (like animation etc). Committed all recent changes.

Kostas Anagnostou