Unsynchronized events: Difference between revisions

From EDukeWiki
Jump to navigation Jump to search
New page: == Staying in sync in multiplayer game == '''Unsynchronized events''' are not synchronized in multiplayer game as they are usually triggered only a local computer so the CON code doesn't ...
 
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Staying in sync in multiplayer game ==
== Staying in Sync in a Multiplayer Game ==
(This article is also relevant to [[demos]], which work much the same way.)


'''Unsynchronized events''' are not synchronized in multiplayer game as they are usually triggered only a local computer so the CON code doesn't have to work the same way on different computers. These events usually are display related or have effect only on the current computer.
'''Synchronized events''' are always triggered on all computers at the same time and under the same conditions, triggered on specific in-game situations. '''Unsynchronized events''', however, are usually triggered on only the local computer so the CON code doesn't have to work the same way on different computers. These events are usually display-related or affect only the local computer.


'''Synchronized events''' always triggered on all computers at the same time and at the same conditions. These events triggers on specific ingame situations.
In order to understand the interaction of random occurrences and unsynchronized events, you need to understand two things:
# [[randvar]] and [[ifrnd]] are '''NOT RANDOM'''. They step through a pre-determined sequence of numbers that appear to be random.
# In multiplayer, very little information is shared between the different computers. Each computer runs an ''almost independent'' instance of the game, sharing only information about the actions of the players. '''They do not share the outcomes of ifrnd or randvar.'''


DO and DON'Ts:<br>
Every time something "random" happens in the game, it '''must happen the same way''' on all of the computers. Since all of them start with the same number and go through the same sequence of numbers at the same times, everything works. But if one computer calls ifrnd or randvar while the others do not, it ends up at a different place in the random sequence. The next time something random happens in the game, it occurs differently on this computer, causing the game to become '''out-of-sync'''. (This isn't even the worst case: Imagine ''each computer'' on a ''wildly'' different place in the sequence, resulting in almost no correlation between what each player sees in the game.)
1. Do use [[randvar]],[[randvarvar]], [[ifrnd]] in '''synchronized''' events.<br>
 
2. Do use [[displayrand]], [[displayrandvar]], [[displayrandvarvar]] in '''unsynchronized''' events.<br>
Unsynchronized events are not guaranteed to happen at the same time, or at all, between different computers in a multiplayer game. Therefore, it is not safe to use ifrnd or randvar in them, because they could end up out of sequence. It is also not safe to do anything affecting gameplay in these events for the same reason. '''[[Displayrand]] is an exception''' because it does not affect the sequence used by the other commands. '''Therefore it is safe to use in unsynchronized events.''' It should not be used in other events because that would cause the same problems outlined above.
3. Do not use [[randvar]],[[randvarvar]], [[ifrnd]] in '''unsynchronized''' events.<br>
 
4. Do not use [[displayrand]], [[displayrandvar]], [[displayrandvarvar]] in '''synchronized''' events.<br>
'''DOs and DON'Ts:'''<br>
5. Do not collect information in '''unsynchronized''' events that later might be used in '''synchronized''' events or actors.<br>
# Do use [[randvar]],[[randvarvar]], [[ifrnd]] in '''synchronized''' events.
6. Do not use local vars(like user options) in '''synchronized''' events. The compiler will warn you about this(note: it won't if a local var is in a state).<br>
# Do use [[displayrand]], [[displayrandvar]], [[displayrandvarvar]] in '''unsynchronized''' events.<br>
7. Do not use gameplay related commands in '''unsynchronized''' events. The compiler will warn you about this(note: it won't if a local var is in a state).<br>
# Do not use [[randvar]],[[randvarvar]], [[ifrnd]] in '''unsynchronized''' events.
# Do not use [[displayrand]], [[displayrandvar]], [[displayrandvarvar]] in '''synchronized''' events.
# Do not collect information in '''unsynchronized''' events that later might be used in '''synchronized''' events or actors.
# Do not use local vars(like user options) in '''synchronized''' events. The compiler will warn you about this(note: it won't if a local var is in a state).
# Do not use gameplay related commands in '''unsynchronized''' events. The compiler will warn you about this(note: it won't if a local var is in a state).


[[Category:Event manipulation]]
[[Category:Event manipulation]]

Latest revision as of 14:05, 4 September 2008

Staying in Sync in a Multiplayer Game

(This article is also relevant to demos, which work much the same way.)

Synchronized events are always triggered on all computers at the same time and under the same conditions, triggered on specific in-game situations. Unsynchronized events, however, are usually triggered on only the local computer so the CON code doesn't have to work the same way on different computers. These events are usually display-related or affect only the local computer.

In order to understand the interaction of random occurrences and unsynchronized events, you need to understand two things:

  1. randvar and ifrnd are NOT RANDOM. They step through a pre-determined sequence of numbers that appear to be random.
  2. In multiplayer, very little information is shared between the different computers. Each computer runs an almost independent instance of the game, sharing only information about the actions of the players. They do not share the outcomes of ifrnd or randvar.

Every time something "random" happens in the game, it must happen the same way on all of the computers. Since all of them start with the same number and go through the same sequence of numbers at the same times, everything works. But if one computer calls ifrnd or randvar while the others do not, it ends up at a different place in the random sequence. The next time something random happens in the game, it occurs differently on this computer, causing the game to become out-of-sync. (This isn't even the worst case: Imagine each computer on a wildly different place in the sequence, resulting in almost no correlation between what each player sees in the game.)

Unsynchronized events are not guaranteed to happen at the same time, or at all, between different computers in a multiplayer game. Therefore, it is not safe to use ifrnd or randvar in them, because they could end up out of sequence. It is also not safe to do anything affecting gameplay in these events for the same reason. Displayrand is an exception because it does not affect the sequence used by the other commands. Therefore it is safe to use in unsynchronized events. It should not be used in other events because that would cause the same problems outlined above.

DOs and DON'Ts:

  1. Do use randvar,randvarvar, ifrnd in synchronized events.
  2. Do use displayrand, displayrandvar, displayrandvarvar in unsynchronized events.
  3. Do not use randvar,randvarvar, ifrnd in unsynchronized events.
  4. Do not use displayrand, displayrandvar, displayrandvarvar in synchronized events.
  5. Do not collect information in unsynchronized events that later might be used in synchronized events or actors.
  6. Do not use local vars(like user options) in synchronized events. The compiler will warn you about this(note: it won't if a local var is in a state).
  7. Do not use gameplay related commands in unsynchronized events. The compiler will warn you about this(note: it won't if a local var is in a state).