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
Friday, November 19, 2010
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
Friday, November 12, 2010
Development diaries - September 2010 archive
01/09/2010
I restored bullet collisions with enemy ships. In the process, I simplified the way BulletManager manages bullets, now a new bullet entity is created when needed. When the bullet expires, it is removed from the bullet array. This method is simpler and hopefully the fact that I create new CCNodes in the runtime won’t tax the game too much... George will have to test on the 3Gs and report on that. I also tried 40x40 as the player ship size and it looks better. We should probably go with this size.
Committed everything with commit #31.
14/09/2010
Working towards introducing touch UI to the game. Now UI layer logic is completely separate to the game layer and it is very easy to switch UI layers in the runtime. I also introduced a separate Camera class to handle camera logic more easily. The camera object can be attached to any game entity and will follow its motion (left-right that is, it always moves upwards). Once touch UI works, I will implements the asteroid grabber game mechanic.
15/09/2010
Implemented a first version of touch control. Player ship motion was bit shaky, so I added a filter to smooth out sudden movements. It is not good enough though because it takes into consideration the previous position only. Must revise this method later.
I also started work on the debris grabber weapon. The weapon will grab any specified game entity, even enemy spaceships. The grabber weapon has to be a new class, its logic and use is completely different to the regular laser weapon. Still it will be data driven and customised by level designer in Tiled map editor.
16/09/2010
Finished the first version of grabber weapon. Not tested it yet though!
18/09/2010
My tendency to decouple everything and eliminate dependencies between code modules did not pay off as expected this time. My initial idea was to abstract the UI into different layers and provide a set of methods to communicate user actions (swipe, tap ect) to the game layer as numerical values and displacement vectors. This made UI very abstract, the game layer would handle the player ship and weapon logic and ideally should make UI switching (between touch and virtual joystick) easy.
On the other hand it made communication between UI layer more complicated than it should be. Considering this, I gave player ship and weapon control to the UI layer, increasing the dependency but making weapon usage much easier. UI layer switching is still possible, it is just that the weapon logic is contained in the UI layer than the game player.
21/09/2010
Did a massive commit of all the changes of the past 2 weeks (Commit #31). It includes the collector weapon mechanics, separate layers for UI logic (touch and virtual joystick) and the and new improved Camera class. The Grabber weapon is now usable (although not yet data driven). Single tap triggers asteroid grabbing, dragging on screen and releasing finger releases the grabbed asteroids causing mayhem. Grabber triggering is a bit inexact for the moment, will fix on next iteration. Also missing is some better feedback of grabbing the asteroids (currently they just change color...).
Some UI testing will now show if this mechanic is any good. George?
23/09/2010
Had a discussion with Nick on tilemap sizes, he believes the smaller the tile size the better (more detailed) the backgrounds will look. During the discussion an idea came up that we could potentially use very small tile sizes to design the background, but eventually “bake” them into larger tiles and pass them to the game. The baked tilemap tile size would have to be 128x128 to fit current game world dimensions.
Following this I made 3 separate tilemaps, one with 16x16 tile, one with 32x32 and one with 128x128. The total world size was the same. The tilemap contained nothing else (except for the parallax layer), no enemy definitions etc.
With a 16x16 tile size, the game achieved about 10fps. With a 32x32 tile the game achieved about 35fps. With a 128x128 “baked” tilemap, the game whizzed by at 60fps on iPhone 3G! It seems that the game, due to the tile size, is vertex bound and reducing the number of tiles helps a lot! It seems that baked tilemaps is something worth considering. In this case, we would need two layers for the background (excluding the parallax layer), each having a 1024x1024 “backed” tileset. The first background layer would cover the bottom half of the game world and the other the top half. Will have to discuss with Nick wether it is preferable (or possible) to do the baking offline or during level loading.
I also improved the touch detection for the collector ship. Committed everything (including the test tilemaps and some changes I had to make to the code to cope with missing entity definitions) with commit #33.
28/09/2010
I implemented the baked tilemap idea. The game can now take a tilemap of any tilesize and convert it to a tilemap of 128x128 tilesize. This gives a huge speed boost as the actual tilesize becomes smaller. I managed increase the original 10fps for a 16x16 tileset to 60fps with the baked tiles! This allows Nick to create the tilemap using any tile size (in theory down to 2x2).
It takes some time to create the baked tilemap during level loading, hopefully it won’t be too bad in the end. Also I still haven’t implemented the baking of the parallax layer.
Tip: The CCNode camera position refers to the bottom-left corner of the screen. I lost a couple of hours trying to solve a silly bug caused by this...
30/09/2010
I tried baking the Parallax layer which we specify in the Tiled file as well and the framerate took a hit from 60 to 35 fps. Nothing a simple visibility culling can’t fix. To implement all that functionality (as well any number of tile map layers in the original Tiled file) I created a new tilemap class SDTileMap which is responsible of baking the tilemaps, updating (scrolling them), doing the visibility checking. The framerate raised again close to 60fps.
I additionally implemented the reverse grabber mechanic as discussed with George. Now the player taps the playship which in turn grabs any asteroids in the neighbourhood and “freezes”. Then, by dragging, the player can slingshot the asteroid to the direction she chooses. I also added better feedback to all that grabbin and draggin (not pretty but it works for now).
Committed everything with commit #35 and am awaiting George to try the new version of the grabber mechanic as well as report on the framerate on his 3Gs (although it can’t be less than the previous commit).
Kostas Anagnostou
I restored bullet collisions with enemy ships. In the process, I simplified the way BulletManager manages bullets, now a new bullet entity is created when needed. When the bullet expires, it is removed from the bullet array. This method is simpler and hopefully the fact that I create new CCNodes in the runtime won’t tax the game too much... George will have to test on the 3Gs and report on that. I also tried 40x40 as the player ship size and it looks better. We should probably go with this size.
Committed everything with commit #31.
14/09/2010
Working towards introducing touch UI to the game. Now UI layer logic is completely separate to the game layer and it is very easy to switch UI layers in the runtime. I also introduced a separate Camera class to handle camera logic more easily. The camera object can be attached to any game entity and will follow its motion (left-right that is, it always moves upwards). Once touch UI works, I will implements the asteroid grabber game mechanic.
15/09/2010
Implemented a first version of touch control. Player ship motion was bit shaky, so I added a filter to smooth out sudden movements. It is not good enough though because it takes into consideration the previous position only. Must revise this method later.
I also started work on the debris grabber weapon. The weapon will grab any specified game entity, even enemy spaceships. The grabber weapon has to be a new class, its logic and use is completely different to the regular laser weapon. Still it will be data driven and customised by level designer in Tiled map editor.
16/09/2010
Finished the first version of grabber weapon. Not tested it yet though!
18/09/2010
My tendency to decouple everything and eliminate dependencies between code modules did not pay off as expected this time. My initial idea was to abstract the UI into different layers and provide a set of methods to communicate user actions (swipe, tap ect) to the game layer as numerical values and displacement vectors. This made UI very abstract, the game layer would handle the player ship and weapon logic and ideally should make UI switching (between touch and virtual joystick) easy.
On the other hand it made communication between UI layer more complicated than it should be. Considering this, I gave player ship and weapon control to the UI layer, increasing the dependency but making weapon usage much easier. UI layer switching is still possible, it is just that the weapon logic is contained in the UI layer than the game player.
21/09/2010
Did a massive commit of all the changes of the past 2 weeks (Commit #31). It includes the collector weapon mechanics, separate layers for UI logic (touch and virtual joystick) and the and new improved Camera class. The Grabber weapon is now usable (although not yet data driven). Single tap triggers asteroid grabbing, dragging on screen and releasing finger releases the grabbed asteroids causing mayhem. Grabber triggering is a bit inexact for the moment, will fix on next iteration. Also missing is some better feedback of grabbing the asteroids (currently they just change color...).
Some UI testing will now show if this mechanic is any good. George?
23/09/2010
Had a discussion with Nick on tilemap sizes, he believes the smaller the tile size the better (more detailed) the backgrounds will look. During the discussion an idea came up that we could potentially use very small tile sizes to design the background, but eventually “bake” them into larger tiles and pass them to the game. The baked tilemap tile size would have to be 128x128 to fit current game world dimensions.
Following this I made 3 separate tilemaps, one with 16x16 tile, one with 32x32 and one with 128x128. The total world size was the same. The tilemap contained nothing else (except for the parallax layer), no enemy definitions etc.
With a 16x16 tile size, the game achieved about 10fps. With a 32x32 tile the game achieved about 35fps. With a 128x128 “baked” tilemap, the game whizzed by at 60fps on iPhone 3G! It seems that the game, due to the tile size, is vertex bound and reducing the number of tiles helps a lot! It seems that baked tilemaps is something worth considering. In this case, we would need two layers for the background (excluding the parallax layer), each having a 1024x1024 “backed” tileset. The first background layer would cover the bottom half of the game world and the other the top half. Will have to discuss with Nick wether it is preferable (or possible) to do the baking offline or during level loading.
I also improved the touch detection for the collector ship. Committed everything (including the test tilemaps and some changes I had to make to the code to cope with missing entity definitions) with commit #33.
28/09/2010
I implemented the baked tilemap idea. The game can now take a tilemap of any tilesize and convert it to a tilemap of 128x128 tilesize. This gives a huge speed boost as the actual tilesize becomes smaller. I managed increase the original 10fps for a 16x16 tileset to 60fps with the baked tiles! This allows Nick to create the tilemap using any tile size (in theory down to 2x2).
It takes some time to create the baked tilemap during level loading, hopefully it won’t be too bad in the end. Also I still haven’t implemented the baking of the parallax layer.
Tip: The CCNode camera position refers to the bottom-left corner of the screen. I lost a couple of hours trying to solve a silly bug caused by this...
30/09/2010
I tried baking the Parallax layer which we specify in the Tiled file as well and the framerate took a hit from 60 to 35 fps. Nothing a simple visibility culling can’t fix. To implement all that functionality (as well any number of tile map layers in the original Tiled file) I created a new tilemap class SDTileMap which is responsible of baking the tilemaps, updating (scrolling them), doing the visibility checking. The framerate raised again close to 60fps.
I additionally implemented the reverse grabber mechanic as discussed with George. Now the player taps the playship which in turn grabs any asteroids in the neighbourhood and “freezes”. Then, by dragging, the player can slingshot the asteroid to the direction she chooses. I also added better feedback to all that grabbin and draggin (not pretty but it works for now).
Committed everything with commit #35 and am awaiting George to try the new version of the grabber mechanic as well as report on the framerate on his 3Gs (although it can’t be less than the previous commit).
Kostas Anagnostou
Wednesday, November 10, 2010
Development diaries - August 2010 archive
02/08/2010
Still working towards loading a complete level for Tiled into the game. It is almost there, it needs a bit of ironing... Additionally we need to determine what properties will be specified for each object in the Tiled editor, as well as create some predefined animations for the enemy ships. Looking good so far.
Still haven’t looked into texture specifications and other stuff for the artists. Hopefully I’ll do this tomorrow.
03/08/2010
The game is now data driven! Enemy (spawner) objects are positioned and customized with data loaded from the Tiled Editor map file. Committed changes and new files (Commit #13). It still needs some testing but the main functionality is there. Have to discuss with George what parameters the designer needs to set for each object.
I also added some texture specifications to the Cocos2D engine doc. We still need to determine the actual texture/sprite sizes for the game.
04/08/2010
Changed EnemySpawner and tilemap import to take number of Enemy Ships in each wave and not time-to-live. I feel that this is a more intuitive way to set the wave, must check with George at the next Skype Meeting.
I also did some game code profiling today, I’ve already caught a silly bug. According to Shark (profiling tool provided by MacOS) the tilemap is very expensive, since it takes about 50% of the game time (updating and rendering), if I am reading it correctly. To be more specific rendering costs ~30% of the total time. An the rest 20% is CPU tilemap update and draw call overheads.
Currently the tilemap is 1500, 32x32, sprites which use minimal OpenGL state change and a SpriteSheet for texturing purposes. So rendering should be quite cheap one would think. I have read in forums that it is beneficial to break the tilemap up into smaller tilemaps during loading and use them instead of a single large tilemap. Maybe I will have to look into this.
06/08/2010
As requested by our game designer I added a “heavy” level to the game. The tilemap had 90x20 tiles (32x32 pixels) each, which meant double-width screen. In order to accommodate this I had to add a camera to the layer in order to allow the player to “scan” the whole level. Apart from the background tilemap I added an additional (parallax) one with some planets.
It should move at different speed to the background one but it does not at the moment. Finally I added an Enemy Layer with 24 spawners generating enemies at various rates. Also, I made all enemies shoot the player (although not kill it) creating a bullet rain almost throughout the level. Particles explosions (fire+sparks) remained as they were. To top it up, I added background music to the game.
Although this set -up is not realistic, it nevertheless stressed cocos2d quite a lot. There are times, when the screen is full of enemy sprites, bullet rain and explosions that the frame rate can drop as low as 20 fps. A final note, the new camera stuff broke the UI sprites, although one can still navigate and shoot lasers using the same areas (bottom-right and left). I committed everything back to SVN with commit #16.
There are a bunch of optimisations I have in mind to speed things up in terms of raw rendering power. First I will batch enemyship rendering at least per enemyspawner, or more. Particle explosions can be sped up as well using fewer draw calls to render them. Finally the tilemap should be split up into smaller ones, to allow for visibility culling. This should send smaller drawlists to the GPU and hopefully make the expensive tilemap a bit faster.
10/08/2010
Converted enemy ships to use a SpriteSheet (one for each enemy type) instead of individual textures, in order to make them render all in one draw call (batch rendering). Benchmarked the 30 first seconds of the “heavy” level, it seems that total scenegraph update time goes down from 1940ms to 1340ms and total rendering time goes down from 7350ms to 5390ms. It does make a difference, although this level is not representative of a real level as it has way too many enemy ships. Every little helps though. Eventually I will do the same for the bullets as well. The tilemap will be trickier though.
I also reduced the camera viewport in order to prevent the player ship to be hidden from the UI controls. Now there is space at the bottom of the screen to add the virtual joystick, life bar, weapon selectors etc. Committed everything with Commit #18.
12/08/2010
I changed the layout of the Game Design guide in order to make it more playership centric and in the process I created even more work for George. :-). We need thorough descriptions of each playership type, weapons and upgrades since we should start implementing those feature soon.
I also reworked scene and layer layout of the game in preparation for the implementation of the menu system. As a test, I added a simple menu with a few options (only one works). I also added a NetworkManager class for George to play with. Committed with commit #20.
Still haven’t worked on the TiledMap protocol document, hopefully I will do this tomorrow.
16/08/2010
Started to gradually add new classes for the game objects described in the design doc. Soon enough I got lots of similar classes. Extension through inheritance for some many similar objects seems rubbish, I am contemplating using composition, or at least some data-driven way of creating the game objects.
I’ve also started working on the Tiled how-to guide, in order to specify a protocol of creating the game level and reading them into the game.
18/08/2010
Updated game with George’s submission to SVN and it builds fine. So as long as he doesn’t touch the project file, it should be ok to develop code collaboratively even if we have different SDK (most of the time at least).
I put the Tiled how to guide on hold until I decide how to design and implement the various the game entities in code. Inheritance becomes quite inflexible ofter some subclassing since the number of classes grows a lot and it is not easy to combine object behaviour.
A very interesting alternative is component systems, which uses composition instead of inheritance. While very tempting and flexible, I do not know how fast this approach is, especially on the iPhone... Yet there are some games that use this architecture (Dungeon Siege, Munchee’s Oddysey) as well as game engines such as Unity. Maybe there isn’t a significant impact on performance after all.
Finally, I added initial functionality for debris as well as changed the code file directory structure. Committed everything with commit #23. I hope SCM picked up the folder changes...
19/08/2010
Worked on an upgradable weapon system... weapons are now individual entities that can be attached to player ship or enemy ships. I also added a separate PlayerShip class to better manage the player’s ship. No commit yet, I will refine and commit tomorrow.
20/08/2010
Added upgradable weapons as well as a bonus system to the game. The player’ ship can now upgrade the weapons according to bonus items created in Tiled Editor. Added a bunch of classes and managers to perform said functionality (Commit #25).
23-24/08/2010
Worked towards making the game data driven. Now, enemyTypes and spawners are defined in Tiled. I also removed any extra classes for Enemies, all enemies will now be of type EnemyShip. As a test I added a new tilemap which defines a new enemyType named SlowFighter and it works fine.
In terms of triggering enemy spawners, I removed the need to define a trigger since it was not very intuitive to understand how large it should be. Instead, I now only use the spawner location to specify when the enemyspawner should start spawning. In order to keep the spawning process invisible to the player, I slightly move the spawner upwards along with the viewport in order to always remain just out of sight. It works fine this way and is much easier to place enemyspawners in the world
Also, speed in now measured in pixels per second. Finally I made the game use a “real” camera, in the sense that now the camera moves relative to the background which remains static. Committed everything with commit #27. Next I will work towards making weapons definition data-driven as well as enemyship animations which are now fixed.
25-27/08/2010
Data-driven bliss! Enemies, enemyspawners and weapons/bullets are now defined in Tiled and subsequently created in code. Weapons are now game entities that can be assigned to any space ship (enemy or player). The only thing that is not data-defined yet is enemy animations since we haven’t decided how they will be implemented.
Also camera scroll speed can now be set in Tiled as well, as a property (CameraSpeed) to the background layer. With the latest commit (#29) i have broken bullet collision and bonus items, will fix with next one.Finally I have added the interceptor ship created by Nick to the game, it is not that bad, although it feels a bit small!
I have second thoughts about the way I have implemented the various managers of the game entities... Fearing that creating new cocos2d nodes every time I need a new enemyship or bullet etc I have created pools of entities that I never delete but reuse each time I need a new object... This now seems unnecessarily complex...
According to cocos2d best practices, creating new nodes every frame is possibly expensive, but we hardly create new enemy ships or bullets every frame... maybe a simpler solution of keeping an array of “live” entities and releasing them when not need is preferable. The problem is that I don’t have the time to test this...
Anyhow, the need for programmers becomes less! Long live designers!
Kostas Anagnostou
Still working towards loading a complete level for Tiled into the game. It is almost there, it needs a bit of ironing... Additionally we need to determine what properties will be specified for each object in the Tiled editor, as well as create some predefined animations for the enemy ships. Looking good so far.
Still haven’t looked into texture specifications and other stuff for the artists. Hopefully I’ll do this tomorrow.
03/08/2010
The game is now data driven! Enemy (spawner) objects are positioned and customized with data loaded from the Tiled Editor map file. Committed changes and new files (Commit #13). It still needs some testing but the main functionality is there. Have to discuss with George what parameters the designer needs to set for each object.
I also added some texture specifications to the Cocos2D engine doc. We still need to determine the actual texture/sprite sizes for the game.
04/08/2010
Changed EnemySpawner and tilemap import to take number of Enemy Ships in each wave and not time-to-live. I feel that this is a more intuitive way to set the wave, must check with George at the next Skype Meeting.
I also did some game code profiling today, I’ve already caught a silly bug. According to Shark (profiling tool provided by MacOS) the tilemap is very expensive, since it takes about 50% of the game time (updating and rendering), if I am reading it correctly. To be more specific rendering costs ~30% of the total time. An the rest 20% is CPU tilemap update and draw call overheads.
Currently the tilemap is 1500, 32x32, sprites which use minimal OpenGL state change and a SpriteSheet for texturing purposes. So rendering should be quite cheap one would think. I have read in forums that it is beneficial to break the tilemap up into smaller tilemaps during loading and use them instead of a single large tilemap. Maybe I will have to look into this.
06/08/2010
As requested by our game designer I added a “heavy” level to the game. The tilemap had 90x20 tiles (32x32 pixels) each, which meant double-width screen. In order to accommodate this I had to add a camera to the layer in order to allow the player to “scan” the whole level. Apart from the background tilemap I added an additional (parallax) one with some planets.
It should move at different speed to the background one but it does not at the moment. Finally I added an Enemy Layer with 24 spawners generating enemies at various rates. Also, I made all enemies shoot the player (although not kill it) creating a bullet rain almost throughout the level. Particles explosions (fire+sparks) remained as they were. To top it up, I added background music to the game.
Although this set -up is not realistic, it nevertheless stressed cocos2d quite a lot. There are times, when the screen is full of enemy sprites, bullet rain and explosions that the frame rate can drop as low as 20 fps. A final note, the new camera stuff broke the UI sprites, although one can still navigate and shoot lasers using the same areas (bottom-right and left). I committed everything back to SVN with commit #16.
There are a bunch of optimisations I have in mind to speed things up in terms of raw rendering power. First I will batch enemyship rendering at least per enemyspawner, or more. Particle explosions can be sped up as well using fewer draw calls to render them. Finally the tilemap should be split up into smaller ones, to allow for visibility culling. This should send smaller drawlists to the GPU and hopefully make the expensive tilemap a bit faster.
10/08/2010
Converted enemy ships to use a SpriteSheet (one for each enemy type) instead of individual textures, in order to make them render all in one draw call (batch rendering). Benchmarked the 30 first seconds of the “heavy” level, it seems that total scenegraph update time goes down from 1940ms to 1340ms and total rendering time goes down from 7350ms to 5390ms. It does make a difference, although this level is not representative of a real level as it has way too many enemy ships. Every little helps though. Eventually I will do the same for the bullets as well. The tilemap will be trickier though.
I also reduced the camera viewport in order to prevent the player ship to be hidden from the UI controls. Now there is space at the bottom of the screen to add the virtual joystick, life bar, weapon selectors etc. Committed everything with Commit #18.
12/08/2010
I changed the layout of the Game Design guide in order to make it more playership centric and in the process I created even more work for George. :-). We need thorough descriptions of each playership type, weapons and upgrades since we should start implementing those feature soon.
I also reworked scene and layer layout of the game in preparation for the implementation of the menu system. As a test, I added a simple menu with a few options (only one works). I also added a NetworkManager class for George to play with. Committed with commit #20.
Still haven’t worked on the TiledMap protocol document, hopefully I will do this tomorrow.
16/08/2010
Started to gradually add new classes for the game objects described in the design doc. Soon enough I got lots of similar classes. Extension through inheritance for some many similar objects seems rubbish, I am contemplating using composition, or at least some data-driven way of creating the game objects.
I’ve also started working on the Tiled how-to guide, in order to specify a protocol of creating the game level and reading them into the game.
18/08/2010
Updated game with George’s submission to SVN and it builds fine. So as long as he doesn’t touch the project file, it should be ok to develop code collaboratively even if we have different SDK (most of the time at least).
I put the Tiled how to guide on hold until I decide how to design and implement the various the game entities in code. Inheritance becomes quite inflexible ofter some subclassing since the number of classes grows a lot and it is not easy to combine object behaviour.
A very interesting alternative is component systems, which uses composition instead of inheritance. While very tempting and flexible, I do not know how fast this approach is, especially on the iPhone... Yet there are some games that use this architecture (Dungeon Siege, Munchee’s Oddysey) as well as game engines such as Unity. Maybe there isn’t a significant impact on performance after all.
Finally, I added initial functionality for debris as well as changed the code file directory structure. Committed everything with commit #23. I hope SCM picked up the folder changes...
19/08/2010
Worked on an upgradable weapon system... weapons are now individual entities that can be attached to player ship or enemy ships. I also added a separate PlayerShip class to better manage the player’s ship. No commit yet, I will refine and commit tomorrow.
20/08/2010
Added upgradable weapons as well as a bonus system to the game. The player’ ship can now upgrade the weapons according to bonus items created in Tiled Editor. Added a bunch of classes and managers to perform said functionality (Commit #25).
23-24/08/2010
Worked towards making the game data driven. Now, enemyTypes and spawners are defined in Tiled. I also removed any extra classes for Enemies, all enemies will now be of type EnemyShip. As a test I added a new tilemap which defines a new enemyType named SlowFighter and it works fine.
In terms of triggering enemy spawners, I removed the need to define a trigger since it was not very intuitive to understand how large it should be. Instead, I now only use the spawner location to specify when the enemyspawner should start spawning. In order to keep the spawning process invisible to the player, I slightly move the spawner upwards along with the viewport in order to always remain just out of sight. It works fine this way and is much easier to place enemyspawners in the world
Also, speed in now measured in pixels per second. Finally I made the game use a “real” camera, in the sense that now the camera moves relative to the background which remains static. Committed everything with commit #27. Next I will work towards making weapons definition data-driven as well as enemyship animations which are now fixed.
25-27/08/2010
Data-driven bliss! Enemies, enemyspawners and weapons/bullets are now defined in Tiled and subsequently created in code. Weapons are now game entities that can be assigned to any space ship (enemy or player). The only thing that is not data-defined yet is enemy animations since we haven’t decided how they will be implemented.
Also camera scroll speed can now be set in Tiled as well, as a property (CameraSpeed) to the background layer. With the latest commit (#29) i have broken bullet collision and bonus items, will fix with next one.Finally I have added the interceptor ship created by Nick to the game, it is not that bad, although it feels a bit small!
I have second thoughts about the way I have implemented the various managers of the game entities... Fearing that creating new cocos2d nodes every time I need a new enemyship or bullet etc I have created pools of entities that I never delete but reuse each time I need a new object... This now seems unnecessarily complex...
According to cocos2d best practices, creating new nodes every frame is possibly expensive, but we hardly create new enemy ships or bullets every frame... maybe a simpler solution of keeping an array of “live” entities and releasing them when not need is preferable. The problem is that I don’t have the time to test this...
Anyhow, the need for programmers becomes less! Long live designers!
Kostas Anagnostou
Monday, November 8, 2010
Development diaries - July 2010 archive
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
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
Friday, November 5, 2010
What the game is about!
Since we have said a lot about how we build the game let's take a break and discuss what is the game about among with some screenshots of the beta version. Have fun!
Game Story
It’s 2052AD and the Global financial crisis remains unresolved. Poorer countries made futile attempts to revive their economy by selling islands and other parts of the land to richer countries. Richer countries had nowhere to turn to for help. The situation was critical, with a Third World War looming.
That’s why when an Alien Federal Bank offered to buy Earth for a massive amount of gold and solve everyone’s economic problem for ever, Humanity jumped at the opportunity without paying any real attention to the fine print of the deal. And the deal was that the Aliens can use the Earth for garbage disposal.
50 years later Earth is brimming with alien garbage. Garbage is everywhere, on land, sea, air and even space making life on Earth impossible. People tried several times to escape this hell but the thick layer of space debris that orbit the planet makes any attempt to escape futile.
Time is running out for Humanity and people have to make one last effort to resist the Alien invasion by forming small teams to penetrate the thick layer of space debris and fight the Aliens off our Solar System. You are the leader of such team.
Desperate times call for unlikely heroes. Cleaning garbage has never been so honorable!
The Game
Space Debris will look and feel like a retro arcade game. A “scrolling shooter” has some traditional elements that characterise the genre like top-down viewed vertical scrolling action, specific levels and “Bosses” that are enormous in size and difficult to win.
Space Debris is both a game with classic favor and a wholly new and addictive game in its own right. The concept is simple: playing alone or with a partner survive and clean the mess (space debris).
The pace is fast and furious and the tone anything but serious. The focus here is on a fast-paced action/arcade game that is all about immediate and engrossing gameplay for mass-market and hardcore gamers alike.
The full game will offer 3 Stages with 5 Levels each which combined with difficulty levels available will lead to a total of more than 3h gameplay if the game-over message does not appear in between. 8 types of weapons, 4 levels of weapon upgrades, 2 destructive powers, 15 bosses to fight with in each difficulty option and much more are in this game.
Let's have a brief overview:
Game Modes
Challenge
In this selection of Challenge mode you get the collector vessel and using the debris manipulation mechanism provided you have to survive the alien attacks. Having to play with collector vessel this mode is considered more difficult than the other available modes since you are not able to use the combined weapons but only the suitable for that ship.
Co-operative
With each player having independent view of each level map, one gets the interceptor and the other the collector ship to play with. Each player can use each vessel’s unique weaponry to send alien hordes back home. Driven by two minds instead of one players benefit from both fighter vessel firepower and debris manipulation technique to achieve maximum score results.
Classic
It is game’s single player mode using the combined interceptor fighter and collector vessel to one ship. Player can choose from all available weapons from both craft types to fight back the enemies or clear the path from space debris or do both things at the same time. Although, player is free to explore all the level areas it is impossible to get the maximum score with this play mode.
Difficulty
Each mode can be altered more by a number of factors like difficulty settings. The first option limits the available weapons to the bare minimum, the second one removes also any power-up from levels and the third increases the speed additionally for Hard, Alien and Impossible settings respectively.
Ships
The ships in Space Debris are near future crafts with advanced alloys and integrated ethereal/organic elements. The different types of ships also allow the implementation of different gameplay for each type of ship which uses different weapons leading to extra fun for players.
Weapons
A variety of weapons are available to chose from but the most interesting are the Collector type ones since Grabber, Freezer and Blaster are able to manipulate asteroids and other debris to send aliens back home.
Georgios Chiotis
It’s 2052AD and the Global financial crisis remains unresolved. Poorer countries made futile attempts to revive their economy by selling islands and other parts of the land to richer countries. Richer countries had nowhere to turn to for help. The situation was critical, with a Third World War looming.
That’s why when an Alien Federal Bank offered to buy Earth for a massive amount of gold and solve everyone’s economic problem for ever, Humanity jumped at the opportunity without paying any real attention to the fine print of the deal. And the deal was that the Aliens can use the Earth for garbage disposal.
50 years later Earth is brimming with alien garbage. Garbage is everywhere, on land, sea, air and even space making life on Earth impossible. People tried several times to escape this hell but the thick layer of space debris that orbit the planet makes any attempt to escape futile.
Time is running out for Humanity and people have to make one last effort to resist the Alien invasion by forming small teams to penetrate the thick layer of space debris and fight the Aliens off our Solar System. You are the leader of such team.
Desperate times call for unlikely heroes. Cleaning garbage has never been so honorable!
Space Debris will look and feel like a retro arcade game. A “scrolling shooter” has some traditional elements that characterise the genre like top-down viewed vertical scrolling action, specific levels and “Bosses” that are enormous in size and difficult to win.
Space Debris is both a game with classic favor and a wholly new and addictive game in its own right. The concept is simple: playing alone or with a partner survive and clean the mess (space debris).
The pace is fast and furious and the tone anything but serious. The focus here is on a fast-paced action/arcade game that is all about immediate and engrossing gameplay for mass-market and hardcore gamers alike.
The full game will offer 3 Stages with 5 Levels each which combined with difficulty levels available will lead to a total of more than 3h gameplay if the game-over message does not appear in between. 8 types of weapons, 4 levels of weapon upgrades, 2 destructive powers, 15 bosses to fight with in each difficulty option and much more are in this game.
Let's have a brief overview:
Game Modes
Challenge
In this selection of Challenge mode you get the collector vessel and using the debris manipulation mechanism provided you have to survive the alien attacks. Having to play with collector vessel this mode is considered more difficult than the other available modes since you are not able to use the combined weapons but only the suitable for that ship.
Co-operative
With each player having independent view of each level map, one gets the interceptor and the other the collector ship to play with. Each player can use each vessel’s unique weaponry to send alien hordes back home. Driven by two minds instead of one players benefit from both fighter vessel firepower and debris manipulation technique to achieve maximum score results.
It is game’s single player mode using the combined interceptor fighter and collector vessel to one ship. Player can choose from all available weapons from both craft types to fight back the enemies or clear the path from space debris or do both things at the same time. Although, player is free to explore all the level areas it is impossible to get the maximum score with this play mode.
Difficulty
Each mode can be altered more by a number of factors like difficulty settings. The first option limits the available weapons to the bare minimum, the second one removes also any power-up from levels and the third increases the speed additionally for Hard, Alien and Impossible settings respectively.
Ships
The ships in Space Debris are near future crafts with advanced alloys and integrated ethereal/organic elements. The different types of ships also allow the implementation of different gameplay for each type of ship which uses different weapons leading to extra fun for players.
Weapons
A variety of weapons are available to chose from but the most interesting are the Collector type ones since Grabber, Freezer and Blaster are able to manipulate asteroids and other debris to send aliens back home.
Georgios Chiotis
Wednesday, November 3, 2010
Stage 1 out of 3
Since the first days of September two professional artists, Nikolaos Larin (Graphics/SFX) and Vicky Fysika (Music) joined the team along with three more expert advisors namely Michael Fragos (Game Design), Dimitris Fragkos (Graphics) and Christos Arapis (Promotion and Video production). The following months since the last post were somehow bussy to catch-up the deadlines, so, this post took a little more to be written.
Regarding the game, it is near the beta version release nowadays and ready to be given to beta testers ready to play it in various Apple's devices from iPhone(1) to iPhone 4 and iPod touch. The iPad version of the game will follow shortly the other devices submission to Apple's AppStore.
Among other time consuming activities, the team participated in the 3rd Hellenic Game Developers Conference (HGDC), 9-10 October during the Athens Digital Week event in Athens, Greece. The majority of the team members not only were among the organisation commitee but gave individual speeched during the two days of the HGDC. Also, Rotten Fish Games collectively made a presentation of the indie-business model that follows for building a game from concept to market the second day of the Conference.
So, being in a productive rush, the last two months were spent creating the necessary artwork like ships, bad-asses, mini-bosses, bosses, weapons, special effects, backgrounds, logos, UI, sound effects, music scores and whatever else is needed for this game. The design took a decisive turn early in September but the overall concept remained intact: the game still introduces two kind of ships but instead of the all-time classic shoot'em up mode with lasers, beams and plasma charges the main mode introduces the asteroid-management mechanics gameplay in the single player option.
Nevertheless, the late introduction of the artists in the team, caused some code implementation changes to support unexpected artwork challenges but the work pipeline suffered the least. The ideas introduced especially for the graphics lead to overall improvements of the game but especially to the frame rate in older devices that suffered low fps some times. This result supports greatly the necessity to work in a team of professionals that exchange common field knowledge. However, we went our tools usage a step further introducing Dropbox in our collection.
More about the game will be reveiled during the beta phase starting in a few days and the developers' diaries will follow shortly to offer an idea of the challenges met during the development of the game. In between, the Rotten Fish Games presentation for the 3rd HGDC will be explained as well in more details in the team's official site.
Georgios Chiotis
Regarding the game, it is near the beta version release nowadays and ready to be given to beta testers ready to play it in various Apple's devices from iPhone(1) to iPhone 4 and iPod touch. The iPad version of the game will follow shortly the other devices submission to Apple's AppStore.
Among other time consuming activities, the team participated in the 3rd Hellenic Game Developers Conference (HGDC), 9-10 October during the Athens Digital Week event in Athens, Greece. The majority of the team members not only were among the organisation commitee but gave individual speeched during the two days of the HGDC. Also, Rotten Fish Games collectively made a presentation of the indie-business model that follows for building a game from concept to market the second day of the Conference.
So, being in a productive rush, the last two months were spent creating the necessary artwork like ships, bad-asses, mini-bosses, bosses, weapons, special effects, backgrounds, logos, UI, sound effects, music scores and whatever else is needed for this game. The design took a decisive turn early in September but the overall concept remained intact: the game still introduces two kind of ships but instead of the all-time classic shoot'em up mode with lasers, beams and plasma charges the main mode introduces the asteroid-management mechanics gameplay in the single player option.
Nevertheless, the late introduction of the artists in the team, caused some code implementation changes to support unexpected artwork challenges but the work pipeline suffered the least. The ideas introduced especially for the graphics lead to overall improvements of the game but especially to the frame rate in older devices that suffered low fps some times. This result supports greatly the necessity to work in a team of professionals that exchange common field knowledge. However, we went our tools usage a step further introducing Dropbox in our collection.
More about the game will be reveiled during the beta phase starting in a few days and the developers' diaries will follow shortly to offer an idea of the challenges met during the development of the game. In between, the Rotten Fish Games presentation for the 3rd HGDC will be explained as well in more details in the team's official site.
Georgios Chiotis
Subscribe to:
Posts (Atom)