jeena/GGS-report
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

language changes in 1.3

Browse source
This commit is contained in:
Jeena Paradies 2011-05-11 18:03:59 +02:00
parent 140d3f547d
commit 997ce8b6c4
1 changed files with 20 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

47
report.lyx
View file

@ -1078,8 +1078,8 @@ The word
generic
\emph default
in the name of the GGS implies that the system is able to run a very broad
range of different code, for instance code wrote in different programming
languages, besides a broad range of different game types.
range of different code, for instance code written in different programming
languages or code written for a broad range of different game types.
To support this, a virtual machine (VM) for each
\emph on
game development language
@ -1115,48 +1115,41 @@ textbf{VM}}{Virtual Machine}
\begin_layout Standard
No hard limit has been set on which languages can be used for game development
on the GGS, but there are several factors which decide the feasibility
of a language:
on the GGS, but there are several factors which should be taken into considerat
ion when deciding the feasibility of a language:
\end_layout
\begin_layout Itemize
How well it integrates with Erlang, which is used in the core the GGS system
How well it integrates with Erlang, which is used in the core the GGS system?
\end_layout
\begin_layout Itemize
How easy it is to send messages to the virtual machine of the GDL from the
GGS
How easy it is to send messages from the GGS to the GDL VM?
\end_layout
\begin_layout Itemize
How easy it is to send messages from the GDL VM to the GGS
\begin_inset Note Note
status open
\begin_layout Plain Layout
Add more like threads, events, etc.
How easy it is to send messages from the GDL VM to the GGS?
\end_layout
\end_inset
\begin_layout Itemize
Is it possible to sandbox every game with a context or something comperable?
\end_layout
\begin_layout Standard
Internally, the GDL VM needs to interface with the GGS to make use of the
Internally the GDL VM needs to interface with the GGS to make use of the
helpers and tools that the GGS provides.
Thus an internal API has to be designed for use in interacting with the
GGS.
Thus an internal API has to be designed to make the GDL VM to be able to
interacti with the GGS.
This API is ideally completely independent of the GDL, and reusable for
any GDL.
\end_layout
\begin_layout Standard
The communication with gaming clients has to take place over a protocol.
Ideally a standard protocol should be used, in order to shorten the learning
curve for developers, and also make the system as a whole less obscure.
A large challenge during this project is to decide whether an existing
The communication with the gaming clients has to take place with help a
protocol.
Ideally a standard protocol should be used in order to shorten the learning
curve for developers and also make the system as a whole less obscure.
A major challenge during this project is to decide whether an existing
protocol can be used, and if not, how a new protocol can be designed which
performs technically as desired, while still being familiar enough to existing
developers.
@ -1168,10 +1161,10 @@ A great deal of work is devoted to make the GGS
reliable
\emph default
.
This includes ensuring that the system scales well, and to make sure it
This includes ensuring that the system scales well and to make sure it
is fault tolerant.
In order to facilitate scalability, we need a storage platform which is
accessible and consistent among all of the GGS, this is also investigated.
In order to facilitate scalability the GGS needs a storage platform which
is accessible and consistent.
\end_layout
\begin_layout Section