Merge branch 'master' of github.com:jeena/GGS-report

report.lyx

@@ -739,7 +739,7 @@ key "Armstrong03"
 
  downtime in a year.
  The level of instability and bad fault tolerance seen in the game server
- industry would not have been accepted in the telecoms industry.
+ industry would not have been accepted in the telecom industry.
  This level of instability should not be accepted in the game server industry
  either.
  An unavailable phone system could potentially have life threatening consequence
@@ -751,50 +751,43 @@ s, leaving the public unable to contact emergency services.
 
 \begin_layout Standard
 Moving back to the gaming industry.
- The main reason to develop reliable servers are monetary, it is important
- for game companies to expand its customer base.
- Reliable game servers are one improvement that will create a good image
- of a company.
+ The main reason to develop reliable servers is a higher revenue, do archive
+ this it is important for game companies to expand their customer base.
+ Reliable game servers will create a good image of the company.
  In general the downtime of game servers is much higher than the downtime
- of telecom system 
-\begin_inset Note Note
-status open
-
-\begin_layout Plain Layout
-Citation needed...
-\end_layout
-
-\end_inset
-
-.
- The structure of the system is similar in many ways and it should be possible
- to reuse solutions from the telecom system to improve game servers.
+ of telecom systems evenso the overall structure of the systems is similar
+ in many ways.
+ It should be possible to learn and reuse solutions from the telecom systems
+ to improve game servers.
  
 \end_layout
 
 \begin_layout Standard
 In the current state game servers are developed on a per-game basis, often
  this seems like a bad solution.
- Developers of network game need to understand network programming.
- A way to change this is a generic game server which gives the game developers
- a server which they implement their game towards.
+ Developers of multiplayer games need to understand network programming,
+ which above all be a problem for small companies and indipendent game developer
+s who often lack expertise in that field.
+ A way to help them in the competition would be to offer a generic game
+ server which gives them a environment in which they can implement their
+ game in.
  This approach would not only make it easier to develop network games, it
  would also allow games in different programming languages to be implemented
  using the same server.
 \end_layout
 
 \begin_layout Standard
-Some factors key to the development of GGS have been isolated.
- Many of these come from the telecom sector.
+Some key factors to the development of the GGS have been isolated.
+ Many of these are found in the telecom sector too.
  The factors are 
 \emph on
 scalability, fault tolerance 
 \emph default
-and being 
+and a 
 \emph on
 generic
 \emph default
-.
+ nature.
  These terms are defined below.
 \end_layout
 
@@ -847,8 +840,8 @@ dependability
  as intended at a given point in time.
  Fault tolerance is the property of a system always to follow a specification,
  even in the presence of errors.
- The specification could take the form of error handling procedures which
- activate when an error occurs.
+ The specification could define error handling procedures which activate
+ when an error occurs.
  This means that a fault tolerant, dependable system, will have a very high
  probability of functioning at a given point in time, and is exactly what
  is desired.
@@ -994,7 +987,7 @@ A database server can also be seen as an application server.
 \end_layout
 
 \begin_layout Standard
-One purpose of this thesis is to investigate how we can make a game server
+One purpose of this thesis is to investigate how one could make a game server
  as generic as possible.
  Some important helpers are discussed, such as abstraction of the network
  layer, data store and game specific features.
@@ -1002,19 +995,19 @@ One purpose of this thesis is to investigate how we can make a game server
 \end_layout
 
 \begin_layout Standard
-As an aid in discussing the theoretical parts of the GGS a prototype has
- been developed.
+A prototype has been developed in order to aid the discussion of the theoretical
+ parts of the GGS.
  The prototype does not feature all the characteristics described in this
  thesis.
- A selection has been made among the features, and the most important ones
+ A selection has been made among the features and the most important ones
  have been implemented either full or in part in the prototype.
 \end_layout
 
 \begin_layout Standard
-The choice of implementation language for the prototype of the GGS was made
- with inspiration from the telecom industry.
- The Erlang language was developed by the telecom company Ericsson to develop
- highly available and dependable telecom switches.
+The choice of the implementation language for the prototype of the GGS was
+ made with inspiration from the telecom industry.
+ The Erlang language was developed by the swedish telecom company Ericsson
+ to develop highly available and dependable telecom switches.
  One of the most reliable systems ever developed by Ericsson, the AXD301
  was developed using Erlang.
  The AXD301 has possibly the largest code base even written in a functional
@@ -1027,7 +1020,8 @@ key "Armstrong03"
 
 .
  The same language is used to develop the prototype of the GGS.
- Usage of Erlang in the GGS is discussed in further detail in section 
+ The usage of Erlang in the GGS is discussed in further detail in section
+ 
 \begin_inset CommandInset ref
 LatexCommand ref
 reference "sec:The-usage-of-erlang"
@@ -1035,50 +1029,12 @@ reference "sec:The-usage-of-erlang"
 \end_inset
 
 .
- Chapter 
-\begin_inset CommandInset ref
-LatexCommand vref
-reference "cha:Implementation-of-a"
-
-\end_inset
-
- provides a description of the prototype developed for this thesis.
-  
-\begin_inset Note Note
-status collapsed
-
-\begin_layout Plain Layout
-We could go on and on about erlang..
-\end_layout
-
-\end_inset
-
-
 \end_layout
 
 \begin_layout Section
 Purpose
 \end_layout
 
-\begin_layout Standard
-\begin_inset Note Note
-status collapsed
-
-\begin_layout Plain Layout
-The purpose of the GGS project.
- What is the purpose of creating a fault tolerant server, why is it generic,
- and what good does it do to have a scalable system? In the background,
- we should give the motivations behind creating this software, but here
- we should outline why the software is needed.
- This section should be shortened, and the bulk of the text should be moved
- to theory or background.
-\end_layout
-
-\end_inset
-
-
-\end_layout
-
 \begin_layout Standard
 The purpose of creating a generic and fault tolerant game server is to provide
  a good framework for the development of many different types of games.
@@ -1095,20 +1051,20 @@ Fault tolerance is important for the GGS to create a reliable service.
  Going back to the telecom example, the purpose of creating a reliable telecom
  system is to allow calls, possibly emergency calls, at any time.
  Should the telecom network be unavailable at any time, emergency services
- may become unavailable, furthermore the consumer image of the telecom system
- degrades.
+ may become unavailable, furthermore the consumer's image of the telecom
+ system degrades.
 \end_layout
 
 \begin_layout Standard
 Returning to the game industry, emergency services will not be contacted
- using a game server, however an unavailable server will degrade the consumer
+ using a game server, however an unavailable server will degrade the consumer's
  image of the system.
  Consider an online casino company.
  The online casino company's servers must be available at all times to allow
  customers to play.
- If the servers are unavailable, customers cannot play, and the company
- loses money.
- In this scenario, an unavailable server can be compared to a closed real-world
+ If the servers are unavailable customers cannot play and the company loses
+ money.
+ In this scenario an unavailable server can be compared to a closed real-world
  casino.
 \end_layout
 
@@ -1122,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
@@ -1159,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.
@@ -1212,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