Added some comments and correction to 3.3
This commit is contained in:
parent
40e067ea22
commit
c2b3afce0a
1 changed files with 44 additions and 10 deletions
54
report.lyx
54
report.lyx
|
@ -3308,25 +3308,59 @@ name "sec:Communication-with-external"
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
A game launched on the GGS is run with help of a virtual machine.
|
A game launched on the GGS is run within a virtual machine.
|
||||||
For each programming language supported, there is a virtual machine that
|
For each programming language supported, there is a virtual machine that
|
||||||
interprets it and an interface for communication between the GGS, the game
|
interprets the game.
|
||||||
and the players playing the game.
|
Furthermore an interface for communication between the GGS, the game and
|
||||||
Callbacks written in Erlang are registered to the vm for the interface
|
the players playing the game must be present.
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
The reason for the GGS requiring a communication channel between the game
|
||||||
|
VM and Erlang is in part because the GGS makes heavy use of callbacks.
|
||||||
|
Callbacks written in Erlang are registered to the VM for the interface
|
||||||
to work.
|
to work.
|
||||||
It is only with the help of the interface that the game developer can access
|
It is only with the help of the interface that the game developer can access
|
||||||
the game state and share data between players.
|
the game state and send messages between players.
|
||||||
The interface provides access to three objects called World, Player and
|
The interface provides access to three objects called
|
||||||
Localstorage.
|
\emph on
|
||||||
|
world
|
||||||
|
\emph default
|
||||||
|
,
|
||||||
|
\emph on
|
||||||
|
player
|
||||||
|
\emph default
|
||||||
|
and
|
||||||
|
\emph on
|
||||||
|
localstorage
|
||||||
|
\emph default
|
||||||
|
.
|
||||||
The game state is safely stored in a database and retrieved for manipulation
|
The game state is safely stored in a database and retrieved for manipulation
|
||||||
by a call for the World object.
|
by a call for the world object.
|
||||||
Interaction with the players is done the same way using the Player object
|
Interaction with the players is done the same way using the player object
|
||||||
instead.
|
instead.
|
||||||
The Localstorage is a convenient way to store globals and other variables
|
The localstorage is a convenient way to store globals and other variables
|
||||||
seperated from the game state.
|
seperated from the game state.
|
||||||
Unique id:s called gametokens are generated for hosted games so that they
|
Unique id:s called gametokens are generated for hosted games so that they
|
||||||
are not mixed up.
|
are not mixed up.
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
\begin_inset Note Note
|
||||||
|
status open
|
||||||
|
|
||||||
|
\begin_layout Plain Layout
|
||||||
|
TODO: Go in to more detail about how the world, player and localstorage
|
||||||
|
objects are implemented.
|
||||||
|
Also discuss localstorage and how it derives from the webstorage standard
|
||||||
|
in detail.
|
||||||
|
This is a great point on how we try to follow standards.
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue