> who invents this garbage?
Calm down, please... ;-)
> the game logic of all boulderdash-like games is:
> a finite state machine [...] using synchronous sequential logic
For the theory of finite state machines, that's fine. I'm talking about something different here, and I'm sure that it's not too hard to understand.
> other than that, to say a game engine is synchronous or asynchronous is
> meaningless.
I have explained this for some times now in this forum (here at
http://artsoft.org/forum/viewtopic.php?t=279 , for example), but I will explain it again:
The game engines of BD and EM are of a kind I'm calling "synchronous game engines", because all game object actions and movements happen in a synchronous manner. For example, objects in the EM engine can not move at every frame, but only at every eight frames. (Of course one can argue that there is only one "game frame" plus seven "delay frames", but the fact is that every object is at exactly one playfield tile at a given time.) So all moving game elements internally always move to the next tile in one single step, and they all move at the same of eight frames if they move, and you never have two moving elements at different moving positions "between tiles".
On the other hand, the game engines of SP and R'n'D are of a kind I'm calling "asynchronous game engines" because all game object actions and movements can start at every single game frame. As a result, different game objects can be at different movement positions at a certain frame, which makes object interactions far more complicated than in a synchronous game engine.
Therefore this property is a fundamental difference of these two types of BD-style game engines.
*edit*
It seems that I'm not the only one using these terms to describe tile-based game engines; see here:
http://forum.caravelgames.com/viewtopic ... icID=26505
Excerpt:
A bit of background: there are essentially three kinds of movement in grid-based puzzle games. The first one is step-based, thus the objects "snap" from one grid square to the next. Since this is easiest to code, it should come as no surprise that many puzzle games use this.
The second is smooth. Instead of snapping, the objects move animatedly to the next square. However, they are still always in exactly one square, it just looks better.
And the third is asynchronous, which is to say objects move individually, and temporarily occupy two squares. This is what SubTerra does.
In the latter two games, if we were to use diagonal movement, a rock would pass partially through another rock. So instead, rocks roll sideways, then down. Incidentally, the same thing happens in Supaplex, which is why you can pull off the "two rocks balancing trick".
An example for the first kind of movement (step-based) is BoulderDash.
An example for the second kind (step-based, but smooth) is Emerald Mine.
An example for the third kind of movement (asynchronous) is SubTerra, or Supaplex, or R'n'D.