Early morning post of this week in gamedev!
ZX Spectrum 48K
After implementing support for floating bus –that at the end works in all models, with fall-back to vsync; useful for clones and inaccurate emulators–, I continued adding features to the engine:
- Tweaks to the jump and gravity.
- Collision detection for the enemies, so the player can lose lives and die.
- Pick ups, that will be an important component in the game (key/door puzzles).
- One special pick up: “the blaster”. I’ve decided to replicate the behaviour I used in Castaway, so the blaster needs time to charge between shots. In Castaway that was to hide a limitation of the engine, but in this game I like it because it adds strategy!
- And, of course, lots of fixes (with new bugs introduced, probably).
Some of these features were difficult to implement. This is the first time I’m working with a XOR engine –the sprites are drawn using the XOR function, and erased applying the same function with the same exact sprite–, and works well, but it is tricky to add or remove entities mid-loop.
At the end the solution was clean: I just needed to adjust the process by adding an extra draw or erase when I add or remove an entity mid-loop. For example: when the player uses the blaster, the game loop expects the projectile sprite to be there to be erased before drawing the next frame, so I have to perform one extra draw so there’s something to erase.
This is done sometimes out of sync, or waiting for the floating bus if is a big change –for example: erase an enemy that is being destroyed and draw the first frame of the explosion–, and in general the result is very nice. Not completely perfect when the drawing happens on the top of the screen, but this is one of the cases where aiming for perfection wouldn’t be useful.
Currently I only have implemented the “extra life” and the blaster pick ups, and any other is just added to the inventory –not really, is just drawing them in the HUD–. I added support for persistence via a bitmap, so those items don’t respawn and I can check for the specific bit as a flag to see if the player has collected that pick up.
For now the enemies respawn when you leave and re-enter the screen, but I may experiment with some ideas. For example: the enemies’ respawn could be conditional, making the game a bit more interesting and opening the door to some exciting game design.
I’m trying to decide what I’m going to do with the game map. I started using a basic 8-bit per tile map with compression, like in Brick Rick (for the ZX Spectrum), because it is easy and allowed me to progress with the engine, but the screens use a bit too much memory. That wasn’t a problem with Brick Rick because I was aiming to the 128K models, but this game is 48K.
I have used different approaches in different projects, so at this point I don’t think I’m going to find anything ground-breaking that I haven’t used before. It is more about deciding that I’m going to be happy with the restrictions the encoding will introduce. For example, Kitsune’s Curse uses packing with 4-bit per tile plus some programmatic definitions of the map, with the downside of having to define tilesets of 16 tiles –not the end of the world, but makes level design a bit harder–.
I have some ideas that are a variation of what I used in Brick Rick (for the Amstrad CPC this time), but I’m not too excited because it is an encoding that would make using tiled less nice, although it could reduce the maps about 50% compared with current memory wasting encoding.
Meanwhile, the game doesn’t have a name yet. It is more and more likely that it will be a sequel –or prequel?– to Castaway, so perhaps I should use the name I had planned for that: Starblind.
More MSX RPG
I have started exploring a bit of code for that crazy idea of making a CRPG –which I guess is more a western role playing game than a classic JRPG; oh, labels!–.
Currently I have a nice menu system, but I’m struggling with the MSX1 restrictions; and I don’t want to use MSX2. Which is not a complete waste of time, because I’m getting to the conclusion that I should focus on what is that the MSX can do, and then implement the mechanics I want for the game.
Later on I could get the core of the engine and, perhaps, use a different 8-bit system to implement the game I had in mind initially. But that sounds like a project for next year, so we will see!