As soon as the coding environment was set up and both programmers started working the necessary version control application found in the Beanstalk on-line SVN(+Git) hosting. That was the correct time to start writing development diaries (a habbit followed by the programmers only of-course) which we believe is good to share with you people. Hope you find them interesting and helpful.
Let's start with Kosta's development diary for Space Debris. At the end, ask any question you want in the form of comments and we reply shortly.
27/07/2010
Today I realised that Xcode has sometimes trouble in finding and committing changes to project.pbxproj which leads to incorrect checkout for other team members. I committed this file by hand, hopefully the other end will manage to build the code now.
I also experimented a bit with Cocos2D particles, I added a particle manager to allow for easy manipulation of explosions. I refrained from creating emitter objects during runtime, I created a pool of emitters which I can easily reuse to add a new explosion effect on screen. The only problem is that particle rendering is a bit taxing, it more than halves framerate for only 3-4 explosions on-screen. Must find the best balance (larger but fewer particles?). It is a bit hard to customize particle systems by hand, should we look for an editor?
Did not commit the particle manager yet.
28/07/2010
Still working on particle system and optimisation. It seems really hard to measure particle performance since it depends on many many factors. Looks like we will have to adjust the particle effects in the end in order to get acceptable performance, according to the context.
I ran an experiment of adding 20 explosions per second (10 spinning particles per explosion, png texture, size varying between 80-220, and some other tweaks ) and in Release Cocos2D can do about ~40 frames per second (in game environment, with enemies and background). Sounds capable enough.
I am also preallocating the emitters (50 of them) and adding them to the layer during init. I have read about another method of using one emitter for each explosion type which should be faster, when we run out of fps I will dig it up (requires a few changes to the cocos engine which I would like to avoid if possible).
I am now working on a system that will allow combining of particle systems in order to produce more complex particle effects for explosions.
29/07/2010
Completed work on particles, I added a ParticleEffect class that allows the combination of any type of ParticeSystems to create complex effects. As a test I created a complex explosion of fire and sparks, it works fine. There are some fps issues when many effects are rendered on screen simultaneously, will have to look upon them in the near future (see yesterday diary entry). I also added a ParticleManager class to make managing of particle effects easier.
I also did a quick hack to try pointer-finger control instead of virtual joysticks. For the moment the player ship autofires anytime the player touches screen. Seems that touch sampling on iPhone is much lower than 60Hz which produces a jerky motion of the player’s ship. I had to add interpolation between old and new positions to make ship motion a bit smoother. To switch between the old and new control system one must comment out/in the #define FINGER_CONTROL on top of file PlayerGameScene.
Committed the new features back into svn (commit No 11).Next I will create a complete level (with enemies at predefined positions) with TiledMap and attempt to load it in game.
30/07/2010
Today I worked towards loading a complete level from Tiled Editor to the game. First I created an EnemyManager class to manage the different EnemySpawners that will be placed throughout the level. Next I created a level in Tiled Editor, adding and customizing various EnemySpawner objects using the two enemy types currently supported (Cargo and Fighter). Using named parameters one can add any information to the spawner object in Tiled. Its copy and past functionality is useful for fast object creation - copy and tweak it. Also it seems that objects placed on the map can have dimensions apart from position.
This can be useful when creating triggers. Looking good, the only thing that troubles me is how to preallocate and add the enemy objects to the game. There will eventually be quite a few EnemySpawners on the map, each one having 10-20 enemy objects (maybe more). This can amount to more than 300 sprites. Which is faster, preallocating them and adding them to the Cocos2D scene during level initialisation or preallocating them and adding them to the scene as needed? On the other hand, how many sprites will be on screen at the same time, 20, 30, 40 at most? Maybe I could create a pool of sprites and reuse them for different enemyspawners. My next task will be to perform tests to find out which solution is more efficient and flexible.
George, since I know you’re reading this, how did you find the pointer-finger player ship control?
Kostas Anagnostou
No comments:
Post a Comment