Synchronous and asynchronous game engines

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

Post Reply
dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Wed Jul 21, 2010 7:58 am

Holger wrote:(which is due to the synchronous nature of the EM engine).
(The native Supaplex game engine does not have this behaviour, as it is asynchronous like the R'n'D engine ...
who invents this garbage?

the game logic of all boulderdash-like games is:
a finite state machine http://en.wikipedia.org/wiki/Finite_state_machine
using synchronous sequential logic http://en.wikipedia.org/wiki/Sequential ... tial_logic

other than that, to say a game engine is synchronous or asynchronous is meaningless.

User avatar
Holger
Site Admin
Posts: 2904
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Wed Jul 21, 2010 8:42 am

> 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.

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Fri Jul 23, 2010 8:53 am

>> 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.
>









> Therefore this property is a fundamental difference of these two types of BD-style game engines.

it has already been established that these engines are equivalent. your conclusion is false. your classification is meaningless. next!

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Sat Jul 24, 2010 7:54 pm

The classification between step-based and non-step-based movement is not meaningless. It is the difference between being able to move the player immediately when a direction key is pressed ("asynchronous movement") and having to wait until the beginning of the next movement "step" ("synchronous").

When we say "synchronous" and "asynchronous," we are talking about movement. If all movement is synchronous, it all happens at the same time: each element is at its starting tile at once, and each element arrives at its destination tile at once.

The terms "synchronous" and "asynchronous" can also be used in a more low-level context, such as whether a game's engine is single-threaded or multi-threaded. That is not the context that Holger was referring to when he brought up the distinction between the Emerald Mine movement system and the Supaplex movement system.

I admit that to clarify the context, it is probably better to say "(a)synchronous movement" or "(a)synchronous movement engine" than just "(a)synchronous engine" or "(a)synchronous game engine" when distinguishing between types of movement handling.

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Sun Jul 25, 2010 8:02 am

what you call "step" is actually a clock signal http://en.wikipedia.org/wiki/Sequential ... tial_logic
in Emerald Mine the clock signal is 6.25Hz, which is a relatively slow reaction time for a computer game, so "movement when the player presses a direction key" feels sluggish.
in rnd the clock signal is 50Hz, which is a typical reaction time for a computer game, so "movement when the player presses a direction key" feels immediate.
however, in both engines and indeed all boulderdash-like games, "movement" occurs only on a clock signal.

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Sun Jul 25, 2010 3:58 pm

I agree that movement occurs only on these clock signals (50 Hz in Rocks'n'Diamonds).

When I said "step" I was referring to the time it takes to move from one tile to an adjacent tile at normal speed. This time is 0.16 seconds in both Rocks'n'Diamonds (default: 1 step = 8 clock cycles) and Emerald Mine, allowing for 6.25 moves per second.

The difference in the Rocks'n'Diamonds movement engine (and some other engines) from the Emerald Mine engine is that a single move takes longer than a single clock cycle (called a "frame" within R'n'D). This means that one object could start moving while another object is somewhere in the middle of the 8 frames (by default) of its movement from one tile to another.

Because the two elements given in this example would not start and stop moving on the same clock cycle, their movement is "asynchronous." This would not be possible in the Emerald Mine engine because a single move takes only a clock cycle. As Holger said, "you never have two moving elements at different moving positions 'between tiles'." The distinction between these two types of movement engines make it worthwhile to classify them.

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Sun Jul 25, 2010 4:47 pm

in rnd, consider a 'tile' as 4x4 pixels, in a world of 32x32 pixeled graphics objects. objects appear to take up one 32x32 square, but actually occupy sixty four 4x4 'tiles'. now all objects are at exactly one 'tile' position and there is no 'between tiles'.

in Emerald Mine there are objects that take more than one clock to reach the next 'tile'. the drip takes two clocks to fall one spot. the quicksand takes four clocks for a stone to sink in, and two when it falls out.

in Emerald Mine there are also objects that move two tiles in one clock. the player going through a door does this. gems falling through magic wall also goes double quick.

the distinction becomes blurred when you consider these things.

i submit that '(a)synchronous movement' is technically incorrect, but much more acceptable than "(a)synchronous game engine"

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Mon Jul 26, 2010 1:39 am

OK, I think that I agree with everything you said in your last post and now understand better what you are saying. Yes, the distinction is blurred when you consider that objects can move at different speeds besides one step per clock cycle (like the player and several other elements in Emerald Mine). And yes, the terms "synchronous" and "asynchronous" are used loosely to convey a certain idea.

If a Rocks'n'Diamonds custom element is set to move at the speed "even faster" (50 steps per second), one move would equal one clock cycle and that would also be called "synchronous" movement using the loose definition.

But I am having trouble thinking of a more specific/accurate term to use to describe the distinction. The important difference is that in Emerald Mine, the player and most moving elements (falling rocks and emeralds, bugs, spaceships, etc.) move at the clock speed; in Rocks'n'Diamonds, the clock speed is almost always much faster than any moving elements including the player.

Post Reply