Intro
Rokky is Boulder Dash/Repton clone for Agon Light written in eZ80 assembly.
It's kind of quick made releases(to be honest it's based on my older attempt of making similar game but it was for Jupiter Ace).
I've simplified game logic but keep all basic rules in place.
I'll try make several articles that will describe from highest level of abstraction to implementation hacks.
Our game world's rules
Let's describe what rules will exists in worlds of our game and what we must implement to get our game(I think every game is just simulation of small world that have special "physics laws").
Our world will have simple rules:
Our world exists in two dimensional celled(tiled) space
In our world exists several kind of things: emptiness, some kind of ground, rocks, crystals, walls, ghosts and our hero
We have gravity that can move every tile per one time period down but only rocks and crystals
Ground can be destroyed only by character or explosion
Our character can walk freely on 2 axis(gravity doesn't affects he) except he meets walls or rocks
Our character can move rock only in horizontal space by pushing and only if there nothing on the way of rock
Ghosts walking from side to side and if they meets any barrier they changing direction
Ghost can kill our hero by touching him
Ghosts and hero can be killed by falling item and any death produces explosion.
Explosion cannot destroy walls and crystals
When hero collects all gems he moving to next level
All our world can't be large that 32x23 cells(fits on single screen)
How our world lives?
As any world our world have life cycle(in our sources it's in rokky.asm file).
Every time cycle of our world begins from moving ghosts from one point to another(if it's possible).
Next we trying process gravity(gravity.inc file) one item one by one. Crystals and after all rocks.
Third step - processing explosions. It's simple and just via proximity step exploded area becames to emptiness area.
After all this steps we processing our player(player.inc) - we checking contols and moving character to specified directions.
Last mandatory step - checking are we ready for getting to next level(and if we collected all gems - moving us to it).
But what we need for making our world not only simulation but game?
We need controls for our player and we need rendering of our world.
Our world is represented with small(736 bytes) buffer. Every byte represents single world's cell. First rendering of world(before starting of game loop) working by rendering tile by tile - every tile.
In simulation steps we'll update only required sections of screen(every write data to map will produce updating tile on screen).
Why don't update entire screen at once? Cause it requires sending really large count of data. In non optimal way will upload to VDP 11 kilobytes just for redrawing map. It isn't fast.
Main rule for making optimal code - don't do what you can skip.
What next?
In next article we'll start talking about implementation.
We'll init our video mode and upload bitmaps to VDP and render map.