This is the second test game for the delay-based multiplayer system.
TODO before the MP test session:
I am tempted to make a Pokitto multiplay game like this 
A very good thing is that it is still a 2d game. Also the delay-based MP might suit quite well for a car game.
IS that a real game? I like the art style.
[edit] - Nope, followed the link… just assets.
I love these types of top down racing games. Would love to see one on the Pokitto.
I needed to scale it to 33% so it do not look as sharp as it could (looks sharper on the HW), but I am quite happy with the result.
For the online car race I will try to hide the 200 ms local input delay by using visual cues. When accelerating, I will immediately start animating the dirt and smoke particles, but actually start accelerating only after 200 ms. That is done for the local player’s car. In the remote end the car starts to accelerate right away when the key event comes. It is already 200 ms late then.
The same thing when turning. I will first only turn the tires (and maybe also the car) but the movement direction changes only after 200 ms.
I am not used to make 2d racing games. The steering is kind of weird as e.g. the right arrow turns to the car to the clockwise direction. That is ok when going up, but counter-intuitive when going down. Well, luckily you get used to it quickly.
looks good!!
(Moved above posts from the generic delay-based MP topic under this new topic)
On the other hand, having a smoother looking road would require significant amount of tiles just for one corner. Even if the tile size would be 32x32 as below and the middle line of the road removed.
That is 12 individual tiles for one corner, 43 for the full circle. The total limit in the Pokitto API is 256 different tiles.
Also having a bigger tile size (compared to 16x16) makes the collision detection to the road edges harder and more frequent.
I was thinking about an option to use even bigger tile size, 64x64, even if each tile takes about 4kb of memory (I am using the TAS mode, 8-bit colors).
The collision checking problem could be handled by saving a collision mask for each tile bitmap. The mask would be one 16-bit value, where each bit tells if that specific (16x16) section of the tile is blocking or not, like this:
If the mask bit is 0, we do not need to do a collision check. If the mask bit is 1, the system should do a pixel-by-pixel collision check between the car bitmap (or just the 4 corner positions) and that 16x16 bitmap section of the tile.
No collisions yet, but scrolling 64x64 tiles is working
How about something crazy with the palette, where you’d limit the palette to 127 colours, duplicate it and draw your gfx in such a way that safe backgrounds are in the lower half and obsticles are in the upper half.
That is a good idea for a pixel level collision detection.
You could easily have one half greyscale to tell if it works correctly, then colour it once your sure.
Otherwise another method is to simply have 1-bit masks representing collision points. If you feel confident in limiting the number of colors though then the palette trick is a good way of doing it.
what do you intend to do with the collision system? the response, that is?
Either the collision mask or the color values Whichever is easier and good enough. I am now doing the multiplayer part and delayed controls. I will think more about the collisions after that.
I probably need another kind of tileset (16x16).
