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
No comments:
Post a Comment