After almost six months, since the last year's 2 days Hellenic Game Developers Conference that was held during the Athens Digital Week, Space Debris appeared to this year's The Philosophy of Computer Games event at Athens, Greece in April.
This time, Kostas Anagnostou, Game developer and Adjunct Lecturer in Videogame Technologies spoke about the "Data driven game development - Empowering the artist". This time the presentation was more technical and described the concepts behind the development of Space Debris.
The main idea is that the programmers instead of concentrating on the game mechanics themselves they develop a kind of player that is able to reproduce whatever is feeded more like a music or video player but this time data is the game itself.
The speach can be found here.
Saturday, March 31, 2012
Development diaries - February-March 2011 archive
27/03/2011
Restored asteroid field functionality. It didn’t work because its spritesheet was not registered with the SpriteSheetManager. It took me all morning to track this down. We really need more Assert mechanisms in the code... Took an update from the repository, we now have definitions for almost everything in the game! The game crashes though because some sprites are missing from the spritesheets, flimsy content pipeline... I’ll have to use Nick’s tool to recreate the spritesheets.
22/03/2011
Fixed a game crash bug, it was due to wrong memory allocations. I also closed some old bugs which had long been fixed.
25/02/2011
Added a temporary menu to the game with background music. I also fixed some graphics glitches at the screen boundaries.
09/02/2011
I tried running space debris on the iPad. The whole process required nothing more than setting the iPad as target and building the game! Everything worked normally, even the UI! on the scaled output. Onay the graphics looked a bit blurry due to the filtering. I wonder if there is a way to do the scaling manually and turn off filtering.
08/02/2011
After setting up my new apple account and license and my new MacBook, I am ready to pickup space debris development from where we left it. I have set up Xcode and svn as well, did a test build of the game and all work fine. We are ready to roll again. :-)
Kostas Anagnostou
Restored asteroid field functionality. It didn’t work because its spritesheet was not registered with the SpriteSheetManager. It took me all morning to track this down. We really need more Assert mechanisms in the code... Took an update from the repository, we now have definitions for almost everything in the game! The game crashes though because some sprites are missing from the spritesheets, flimsy content pipeline... I’ll have to use Nick’s tool to recreate the spritesheets.
22/03/2011
Fixed a game crash bug, it was due to wrong memory allocations. I also closed some old bugs which had long been fixed.
25/02/2011
Added a temporary menu to the game with background music. I also fixed some graphics glitches at the screen boundaries.
09/02/2011
I tried running space debris on the iPad. The whole process required nothing more than setting the iPad as target and building the game! Everything worked normally, even the UI! on the scaled output. Onay the graphics looked a bit blurry due to the filtering. I wonder if there is a way to do the scaling manually and turn off filtering.
08/02/2011
After setting up my new apple account and license and my new MacBook, I am ready to pickup space debris development from where we left it. I have set up Xcode and svn as well, did a test build of the game and all work fine. We are ready to roll again. :-)
Kostas Anagnostou
Saturday, February 5, 2011
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
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
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.
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
02/11/2010
Started implementing Nick’s effects. I also found a promising XML library (http://www.tbxml.co.uk/TBXML/TBXML_Free.html ) 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.
03/11/2010
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.
05/11/2010
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.
08/11/2010
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.
09/11/2010
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.
10/11/2010
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.
11/11/2010
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.
15/11/2010
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.
16/11/2010
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.
19/11/2010
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).
22/11/2010
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 http://slick.cokeandcode.com/demos/hiero.jnlp 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!
23/11/2010
Worked on the Virtual Joystick UI also adding icons for lives and shield bar. Committed changes for game designer to approve!
25/11/2010
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.
29/11/2010
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
Started implementing Nick’s effects. I also found a promising XML library (http://www.tbxml.co.uk/TBXML/TBXML_Free.html ) 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.
03/11/2010
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.
05/11/2010
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.
08/11/2010
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.
09/11/2010
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.
10/11/2010
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.
11/11/2010
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.
15/11/2010
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.
16/11/2010
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.
19/11/2010
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).
22/11/2010
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 http://slick.cokeandcode.com/demos/hiero.jnlp 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!
23/11/2010
Worked on the Virtual Joystick UI also adding icons for lives and shield bar. Committed changes for game designer to approve!
25/11/2010
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.
29/11/2010
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
Friday, November 19, 2010
Development Diaries - Designer's cut
27/7/2010
Two months after the project initial start (28/5) and almost one and a half after the actual kick-off (19/6) the things go smoothly but somehow late. It is not a full-time project nor it could be because all the members should work for a living and fun cannot feed a family.
At least we have a clear plan now, some concepts to start with, a game engine (thanks to Kostas work) and some people to contact for the graphics and sound. I had left the site behind in order to finish the design.
Today, I will rebuild the latest code commit from Kostas since he found the issue that caused troubles to me and finish the latest design documents before I start the level design.
The target is to have some the first levels delivered by the middle August for the artists to start working with and deliver level by level till the middle of September in order to have something playable in October.
Though the first month spent on discussions and organisation issues, the second month can be called the design month (for me) since the game design takes some form at last.
That’s for now, let’s finish some task or Kostas will start crying out loud once again ;-P
3/8/2010
The previous weekend (31/7-1/8) I managed to upload a series of files regarding shoot-em-up games including: a. the available smups for iPhone and retro smup games features to consider, b. a document with various internet sources about this kind of games and c. a couple of documents with images from articles and posters of smup games.
Based on the above mentioned research, I finalised the Design overview document and the first Game Levels Design (backbone layout and draft content). I uploaded both documents today and I continue to finish the latter the soonest possible in order artists have something to work with.
Following the given deadlines in Pivotal Tracker it seems I'm somehow behind on schedule but I'm optimistic about that and I will catch-up the artists. Only artists for music and sfx are needed to complete the team.
The following days, I also start uploading some scanned drawings (only those I feel confident with) that cannot be considered as concept art but they give the general notion of the levels. I try hard to put my hand on TileMap editor, too, but I know artists find it more relevant to work with...
4/8/2010
I downloaded the latest repository version and build it. Also, I did a 10 minutes sketch based on the game and some more organisation of docs and updates to some of them. That’s all for today ;-)
Hopefully, several issues will be discussed with Kostas tomorrow in person through Skype of-course.
6/8/2010
Another full-time job for Space Debris design resulted to the final Design Guide document for artists and designers to start building the game levels, a project that should finish near the middle of September leaving almost a month for putting all together and for tuning.
Nevertheless, I built the latest commit (#16) from Kostas to get an idea of the cocos2d engine limits and have a conversation with Nikos the following we as we agreed. We managed to arrange a Skype conference for Monday night, so, we will see how it will go.
Mike and I had a thorough discussion regarding the game design, too.
13-15/8/2010
Although Kostas criticises publicly my lack of commitment to the project ;-) and still I get no offense on that ;-) I did the following:
First of all I added some more docs like the Common/Sites one for links reference, then I prepared the blog site to start writing about the game. Then, I created a Facebook page and set a twitter account/page, something not difficult but time consuming. Also, I made some extra to Rotten Fish Games site like Facebook “like” button and a “twitter-follow” link icon.
I left the Game Guide and SVN for the second day 14/8 (Saturday morning) whatever time I wake up. I will update the PivotalTracker stories accordingly. Also, a new technical document uploaded in GoogleDocs to offer a more comprehensive view of the iPhone development capabilities and limitations. Finally, I will post something in the blog to start communicating the project.
24/8/2010
Yesterday, after a Skype call with Kostas, I started describing weapons and movements to complete the Game Guide in that extend. I bought an iPod Touch 32 for 2 players tests of related code.
I started downloading SDK 4.02 since I updated my iPhone OS and now XCode does not build the project.
1/9/2010
I just finished some additional design for weapons and ships including weapons and movements. Now, there seem to be everything to go ahead development. It took me a couple of days among with some TiledMap levels for testing and some code for Facebook and 2-players that I’m going to upload shortly.
I am on vacations mode but I intend to have everything done by tomorrow before I meet with Kostas in-person for a thorough issues discussion for the game. I am also going to build the new commit #31 as Kostas informed me about.
3/9/2010
After a short trip to Kerkira[Corfu island] I have some changes to apply to the game design and concept that does not affect the overall effort, though.
6/9/2010
I got some keys for FB app and I integrate the FB post code with Graphs API to a single project with a button in order to be inserted in the game. Also, I test a small portion of GameKit p2p code with the two devices. Finally, I apply the agreed chagnes with Kostas the other day about the game.
25-28/9/2010
First of all I tried to catch-up the development I had missed the last few weeks. I had a discussion with Nikos, some documents update, Pivotal Tracker and a new post in the blog site to keep the hype on.
I also submitted game in the GamesCon just in case. IGF will follow shortly and finally IndieFund (so-so). Finally, I will try to upload FB code (already got an AppID) and GameKit implementation.
Because of the latest iOS update I had to download 2.64GB of XCode the we (25-26) and since I use Forthnet as internet provider I had to try more than three times to get a verified and valid package to install... it took me till Monday morning (27/9).
Who said iPhone development is a piece of cake? It reminds me the Java moto: “write once play everywhere” - God saves us!
1-31/10/2010
The whole month was spent discussing issues with Kostas and Nick about the game. No real work by my side except the preparation for the 3rd Hellenic Game Developers Conference (HGDC) and some organisation with the team.
Georgios Chiotis
Two months after the project initial start (28/5) and almost one and a half after the actual kick-off (19/6) the things go smoothly but somehow late. It is not a full-time project nor it could be because all the members should work for a living and fun cannot feed a family.
At least we have a clear plan now, some concepts to start with, a game engine (thanks to Kostas work) and some people to contact for the graphics and sound. I had left the site behind in order to finish the design.
Today, I will rebuild the latest code commit from Kostas since he found the issue that caused troubles to me and finish the latest design documents before I start the level design.
The target is to have some the first levels delivered by the middle August for the artists to start working with and deliver level by level till the middle of September in order to have something playable in October.
Though the first month spent on discussions and organisation issues, the second month can be called the design month (for me) since the game design takes some form at last.
That’s for now, let’s finish some task or Kostas will start crying out loud once again ;-P
3/8/2010
The previous weekend (31/7-1/8) I managed to upload a series of files regarding shoot-em-up games including: a. the available smups for iPhone and retro smup games features to consider, b. a document with various internet sources about this kind of games and c. a couple of documents with images from articles and posters of smup games.
Based on the above mentioned research, I finalised the Design overview document and the first Game Levels Design (backbone layout and draft content). I uploaded both documents today and I continue to finish the latter the soonest possible in order artists have something to work with.
Following the given deadlines in Pivotal Tracker it seems I'm somehow behind on schedule but I'm optimistic about that and I will catch-up the artists. Only artists for music and sfx are needed to complete the team.
The following days, I also start uploading some scanned drawings (only those I feel confident with) that cannot be considered as concept art but they give the general notion of the levels. I try hard to put my hand on TileMap editor, too, but I know artists find it more relevant to work with...
4/8/2010
I downloaded the latest repository version and build it. Also, I did a 10 minutes sketch based on the game and some more organisation of docs and updates to some of them. That’s all for today ;-)
Hopefully, several issues will be discussed with Kostas tomorrow in person through Skype of-course.
6/8/2010
Another full-time job for Space Debris design resulted to the final Design Guide document for artists and designers to start building the game levels, a project that should finish near the middle of September leaving almost a month for putting all together and for tuning.
Nevertheless, I built the latest commit (#16) from Kostas to get an idea of the cocos2d engine limits and have a conversation with Nikos the following we as we agreed. We managed to arrange a Skype conference for Monday night, so, we will see how it will go.
Mike and I had a thorough discussion regarding the game design, too.
13-15/8/2010
Although Kostas criticises publicly my lack of commitment to the project ;-) and still I get no offense on that ;-) I did the following:
First of all I added some more docs like the Common/Sites one for links reference, then I prepared the blog site to start writing about the game. Then, I created a Facebook page and set a twitter account/page, something not difficult but time consuming. Also, I made some extra to Rotten Fish Games site like Facebook “like” button and a “twitter-follow” link icon.
I left the Game Guide and SVN for the second day 14/8 (Saturday morning) whatever time I wake up. I will update the PivotalTracker stories accordingly. Also, a new technical document uploaded in GoogleDocs to offer a more comprehensive view of the iPhone development capabilities and limitations. Finally, I will post something in the blog to start communicating the project.
24/8/2010
Yesterday, after a Skype call with Kostas, I started describing weapons and movements to complete the Game Guide in that extend. I bought an iPod Touch 32 for 2 players tests of related code.
I started downloading SDK 4.02 since I updated my iPhone OS and now XCode does not build the project.
1/9/2010
I just finished some additional design for weapons and ships including weapons and movements. Now, there seem to be everything to go ahead development. It took me a couple of days among with some TiledMap levels for testing and some code for Facebook and 2-players that I’m going to upload shortly.
I am on vacations mode but I intend to have everything done by tomorrow before I meet with Kostas in-person for a thorough issues discussion for the game. I am also going to build the new commit #31 as Kostas informed me about.
3/9/2010
After a short trip to Kerkira[Corfu island] I have some changes to apply to the game design and concept that does not affect the overall effort, though.
6/9/2010
I got some keys for FB app and I integrate the FB post code with Graphs API to a single project with a button in order to be inserted in the game. Also, I test a small portion of GameKit p2p code with the two devices. Finally, I apply the agreed chagnes with Kostas the other day about the game.
25-28/9/2010
First of all I tried to catch-up the development I had missed the last few weeks. I had a discussion with Nikos, some documents update, Pivotal Tracker and a new post in the blog site to keep the hype on.
I also submitted game in the GamesCon just in case. IGF will follow shortly and finally IndieFund (so-so). Finally, I will try to upload FB code (already got an AppID) and GameKit implementation.
Because of the latest iOS update I had to download 2.64GB of XCode the we (25-26) and since I use Forthnet as internet provider I had to try more than three times to get a verified and valid package to install... it took me till Monday morning (27/9).
Who said iPhone development is a piece of cake? It reminds me the Java moto: “write once play everywhere” - God saves us!
1-31/10/2010
The whole month was spent discussing issues with Kostas and Nick about the game. No real work by my side except the preparation for the 3rd Hellenic Game Developers Conference (HGDC) and some organisation with the team.
Georgios Chiotis
Monday, November 15, 2010
Development diaries - October 2010 archive
06/10/2010
Still haven’t found a satisfactory tool for curve creation. Fooled around with cocos2d bezier curve functionality a bit. It seems ok and it allows you to combine many curves to make a long, complex motion. The only trouble is, it is not very intuitive to create bezier curves in code. I found a java applet on the Internet that allows parametrization of cubic bezier curves using 4 control points. http://www.doc.ic.ac.uk/~dfg/AndysSplineTutorial/Beziers.html
Maybe we could use this tool to create a series of bezier curves which would then concatenate in the runtime for complex ship animation?
07/10/2010
Added support for bezier curves for animations. Using this framework along with the java tool below we can work out an animation solution which is data driven. I am still not convinced how intuitive the whole thing is though.
Committed latest build with non-linear animations
13/10/2010
Used Nick’s tilemap, after some formatting to make it adhere to the game’s rules, and it works fine. Just uncomment the related code line in GameLayer.m (method initMapAndEntities). I also implemented the “get me out of here” mechanic, now the player can quickly move her ship out of a tight spot by tapping at the desired target locations. I also added some padding in order for the player’s ship not to touch the screen borders. Does not work perfectly for some boundary conditions must look into this.
I also noticed that CCLabels absolutely kill performance (minus 15-20 fps)! I disabled them for the moment, must look at an alternative to render text to screen. Committed changes with commit #40.
15/10/2010
I had a discussion with Nick concerning how to create the tilemap/game backgrounds. He pointed out that the current implementation (one large image background and a layer for parallax) is not sufficient to create a real “depth” effect. He suggested that the background layer should be completely static, on top of that we could have a set of large sprites for planets and other large objects and finally just a single tileset for structures on planets.
On top of all these we can add a particle effect to convey the feeling of motion. I can see his point, the mockup he has created with GameMaker (which does exactly what I described above) has a much better feeling of depth than the current implementation. Additionally, we will lose a tilemap layer which is always good performance-wise!
I will make some modifications to the code and to the way the game understands the tilemap description. In the meantime I have replaced the placeholder spaceship art with Nick’s spaceships and committed the changes. They look good, although a bit small.
19/10/2010
I have started implementing the changes we discussed with Nick. This entailed a few changes to the way the level is designed in Tiled as we will only have one tileset layer and the rest will be simple object layers for celestial bodies. Almost finished, no commit yet.
On a side note, Tiled is not very good as a level design tool... I would like to be able to see the textures of the objects I add, it is very hard to design a level with empty squares of undefined sizes... Also cocos2d seems to adjust objects positions as it loads them from the Tiled file to account for the change in origin (Tiled is top-left, iPhone is bottom-left), which threw me off for a few moments.
20/10/2010
Finished implementing new background/layer design. Now the parallax and depth effect is much improved and “realistic”. The way we design a level in Tiled has changed as well, see tilemap_test.tmx as an example of how it is done now. Must update Tiled document as well.
Nick suggested we turned off antialiasing (bi-linear interpolation) for as many textures as we can because hand-painted graphics are very detailed and many of the details get lost during filtering. I used nearest neighbour filtering for the player ship and it makes a noticable difference, so I will check other textures as well. Committed everything with commit #42 (i think)
24/10/2010
Started working towards restoring Tiled-game connection after the major changes we did to the way the level is designed. “tilemap_test.tmx” now is quite close to the way the level is specified, although it is missing some definitions for bonuses etc. Currently I have restored weapon, spawner and enemy definitions. Also the speed of the layers and horizontal motion range is specified in Tiled as well.
Committed changes, lost track of the commit no. I must update Tiled-howto to document those changes. Monday I will be off all day, I will continue work on Tuesday.
29/10/2010
Did a few changes to the game including changing the way the camera is handled and improved the grabber game mechanic. The camera is now fixed while the “world” moves beneath it in the Y direction. It is probably easier to understand and specify layer motion this way. The alternative way to create the parallax effect would be to specify each layer’s speed as a percentage of the camera speed (the closer to the camera the layer the larger the percentage).
Also changed the way the grabber mechanic behaves near the screen borders, now the camera moves along the captured debris to allow for more space. When debris are release the camera returns to its original position. Saw the effects Nick created to the grabber effect, they are pretty good! I think the game will be impressive at least graphics-wise when complete.
No commit yet, I have to iron a few things first. Next major update will include the ability to set up entities in XML files external to the Tiled file. And I must start implemented Nick’s effects.
Kostas Anagnostou
Subscribe to:
Posts (Atom)