1 |
To add to what skuggmodzer0 said, this also is what allows the servers to be essentially relay stations. Clients send in a checksum of a frame to ensure they are synchronized in the simulation; majority decides what is the correct check-sum, other value having players are 'desynched'.
|
1 |
To add to what skuggmodzer0 said, this also is what allows the servers to be essentially relay stations. Clients send in a checksum of a frame to ensure they are synchronized in the simulation; majority decides what is the correct check-sum, other value having players are 'desynched'.
|
2 |
\n
|
2 |
\n
|
3 |
The load-save functionality already allows for full serialization and de-serialization of the state.
|
3 |
The load-save functionality already allows for full serialization and de-serialization of the state.
|
4 |
\n
|
4 |
\n
|
5 |
You
can
save
during
a
replay
and
have
the
state.
That
then
only
contains
the
already
buffered
actions
of
the
replay(
-reader)
.
Either
there
should
be
a
reference
to
the
replay,
including
a
pointer
to
the
appropriate
game-frame,
which
is
then
loaded
in;
or
you'd
need
to
buffer
the
entirety
of
future
actions
and
keep
that
within
the
save-file.
|
5 |
You
can
save
during
a
replay
and
load
it,
having
that
state.
|
|
|
6 |
\n
|
|
|
7 |
That only contains the already buffered actions of the replay(-reader). And the gameframe is off.
|
|
|
8 |
\n
|
|
|
9 |
Either there should be a reference to the replay, including a pointer to the appropriate game-frame, which is then loaded in; or you'd need to buffer the entirety of future actions and keep that within the save-file.
|