diff --git a/report.lyx b/report.lyx
index 87f8dc0..1add106 100644
--- a/report.lyx
+++ b/report.lyx
@@ -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