Friday, December 31, 2010

Season greetings

Have a Happy and Prosperous New Year!

Let the 2011 be the next best thing in our lives :-)

The Rotten Fish Games team.

Monday, December 6, 2010

Development diaries - November 2010 archive

Started implementing Nick’s effects. I also found a promising XML library ( ) to try with the game. We need some way to specify weapons and other stuff externally to the game and Tiled does not seem like the best option to me. I also asked Nick to create spritesheets of all related textures to reduce loading and rendering times.

Extracted all enemies/weapons/animations/explosions/spawners definitions from Tiled to separate xml files which will be referenced from Tiled. This will make creation of next levels much easier and also level designing with Tiled is much easier as well.

I had a brief discussion with Nick about what information we need in the xml files, from a designer/artist perspective, so we are doing good. Next I started integrating TBXML to the game to load the xml files, this will keep me occupied for tomorrow as well. No commit yet.

Large commit today, I added support for entity definition (currently enemies, spawners and weapons) through xml files. I did a quick test with an armed enemy and several spawners and it works fine. The purpose of Tiled is now to spatially place the enemies on the level and not define them which makes level design more flexible. I also added support for animated sprites and arbitrary directions for enemy bullets. Added Vicky’s music to the game, it sounds fine! Finally I added Virtual Joystick UI for visualisation purposes only, it is not fully functional yet. Actually one can use the menu to select between touch and virtual joystick UI.

I have asked Nick to create the spritesheets of all game sprites. Next I will start implementing weapon and other effects. Explosions will also be defined with xml files. Animation definition through xml files is still pending as well.

Worked towards making animations data driven, they can now be defined in xml files and used by reference when creating the spawners. The system is really flexible, one can build any combination of enemy/enemy spawner and animations just be changing the xml files! Currently only simple “straight” and “hunt” animations are supported, but support for any number of bezier curves is almost complete as well. To implement the animations I created an Animation class and Manager which are responsible for entity motion. Any Game Entity can conceivably be driven by the Animation system. It follows a “component”-like approach where an entity that does not have an Animation object is static. In order to bind the method that calculates the entity motion, according to animation type, to each entity I used callbacks (or ObjC’s version of them).

ObjC’s support for callbacks seems a bit lacking and cumbersome, I had to use selectors that require all arguments to be NSObjects (or derive from it). So I had to convert even primitives types to objects to work with this approach. I wonder whether I should stick with good old C-style function pointers, although I believe they do not work with class methods. Anyway this works more or less. Another idea to avoid converting primitives to objects and back is to create a context which all selectors will use. I make a mental note to try that is the future.

No commit yet.

Added support for cubic bezier curve animations which can now be specified through xml files. The game can now combine any number of curves to create animation paths of any shape. Cocos2D already supports bezier animations through CCActions (i.e. the update is out of my control), but I wanted more control and a unified way of updating all kinds of animations, so I rolled out my own bezier curve solution. The system is very flexible, the only problem is that we have to use that Java tool for curve creation which is not the most friendly way.

Committed everything back to the repository.

Implemented “Invade” and “Storm” modes of enemy spawning. The spawning mode is now specified through a parameter in the spawner definition xml file and is a property of the EnemySpawner class. I also created the “Spiral” animation mode using bezier curves. Not an easy task with the available java tool. Aren’t there any better bezier curves editor I wonder? Finally I added 3 additional modes to sprite rotation while animating, the “Curve” which specifies that the enemy ship faces the direction of the animation curve, the “Player” which specifies that the enemyship will always face and (shoot) the player, and the “None” which makes the enemyship to point downwards at all times (while changing its position). This mode is a property of the Animation class. No commit at this time.

Changed the enemy definition system so as to support multi-part enemies. Each part can be destroyed separately and can have its individual animation (for example Rotation). The part animation is different to the wave animation which is referenced in the spawner. Also the part animation passes through the Animation system as normal, so I can conceivably use any animation defined in the animations.xml file to animate a part. The new enemy definition system can be used to create turrets and other enemies with many components.

Committed all changes to SVN.

Altered the bonus system a bit so as to conform with the game design requirements. Each weapon will have three levels of damage which are specified in the xml definition file. Every time the player grabs a weapon upgrade bonus a check is made whether the player already uses this weapon. If yes, the game will increase the weapon level (ie bullet damage), else it will create and attach a new weapon to the playership. The designer can create and add a bonus item to the game in two ways, by defining it in the bonus definition xml file and then either reference it in Tiled (placing it anywhere on the level directly), or adding it as part of an enemy spawner definition. In such a case, when the player kills all enemies in the specific wave, the bonus item becomes available and can be collected.

The way the bonus system is implemented is by creating a base Bonus class which inherits from GameEntity and specifies position and animation, and then for each type of Bonus I create a subclass which only specifies how the bonus item affects the playership. The Bonus clone method when called, will return a specific Bonus item, according to the Bonus type specified in the xml file. The system is similar to the way different Animations are applied to each entity, only it does not use callbacks.

I also tried nick’s spritesheets, they work ok. We had a discussion with nick on the need to specify the rectangles for each game entity in a separate file and not in the main entity xml definition to allow for rapid iteration of the spritesheets. I will implement this at some point when time allows.

Committed everything back to the repository. There are a few minor things what I have to add to the bonus system, will do this tomorrow.

Finished bonus system, it is now functional. Only the various bonuses as defined in the design document remain to be implemented. I also refactored the weapon system a bit to make it more abstract between the two generic types of Weapons we support (laser and grabber). Finally I restored player laser functionality and collision with enemy ships. We are on a roll now, almost all main functionality is in place. We are still missing the new explosion effects created by nick and some other eye candy. We also need a simple audiomanager to assist  sfx playback.

No commit today.

Implemented the various bonus types as per gdd. As a shortcut, each captured Bonus object returns a bonus type (and data if needed) to the playerShip which is responsible to apply the bonus to self. It is much easier to handle bonuses that what (easier to implement, that is).

Seeing that CCLabel is too slow for rendering text to the screen (dynamic text that is, apparently it is ok for static text), I tried CCBitmapFonts which loads a bitmap font from disk and uses that. To create the font image I used the Hiero java tool The tool works ok and can build character sets for the game (it even allows you to specify which characters to include in the charset) and is supported by cocos2d natively. The only problem is that the font bitmap seems flipped horizontally and needs adjustment before using it in the game.

I also worked on the Virtual Joystick UI a bit, it seems that the actual Virtual Joystick is a bit large, I will have to talk to George and Nick about that.

Committed everything, quite a large commit!

Worked on the Virtual Joystick UI also adding icons for lives and shield bar. Committed changes for game designer to approve!

Implemented all 4 combination of player type-UI mode, that is collector-touch, collector-virtual joystick, laser-touch, laser-virtual joystick. I used a quick and dirty solution of subclassing the main UILayer class in to 4 classes, one for each combination. Each subclass differs mainly in the way it handles the “touch begin” and “touch end” events. There is probably a neater way to implement this but I am running out of time!

I also implemented the title-screen animation as specified by Nick and a basic 2-level menu to select ship and UI mode. Cocos2D Actions are very handy in such cases since they allow building of fairly complex animations easily. Cocos2D Menu System is also pretty good, it even allows for images for menu buttons.
Also implemented a game context singleton class to store all user selections and make it easy to share them with various game classes.

Committed everything and awaiting George’s feedback on usability.

Added support for Nick’s flickbook explosions and an explosion manager to make spawning them easier. Since explosions is something that will be used a lot, I preallocated 50 of them (maybe 50 is too many, I will have to adjust their number later), set them them as inactive and when it comes to creating one I run through the list and reuse the first inactive at a new position. Explosions derive from Game Entity and go through the game’s entity system as normal. Currently only one type of explosion is supported.

I have to talk to Nick about how we will define the sprite coordinates in spritesheets so as to finalize sprite animations.

Committed latest changes.

Kostas Anagnostou