summaryrefslogtreecommitdiffstats
path: root/libtdegames/kgame/libtdegames.html
diff options
context:
space:
mode:
Diffstat (limited to 'libtdegames/kgame/libtdegames.html')
-rw-r--r--libtdegames/kgame/libtdegames.html14
1 files changed, 7 insertions, 7 deletions
diff --git a/libtdegames/kgame/libtdegames.html b/libtdegames/kgame/libtdegames.html
index 94656f36..417ce9b2 100644
--- a/libtdegames/kgame/libtdegames.html
+++ b/libtdegames/kgame/libtdegames.html
@@ -59,8 +59,8 @@
The exchange of moves and other information is done using the class <em>KMessageServer</em>.
An object of this class is a server that waits for connections. Someone who wants to take part
- in the game has to connect to this server - usually using an internet socket connection. He does
- this by creating a <em>KMessageClient</em> object. This object connects to the message server.<P>
+ in the game has to connect to this server - usually using an internet socket connection. This is
+ done by creating a <em>KMessageClient</em> object. This object connects to the message server.<P>
The transfer of data is realised by subclasses of the abstract class <em>KMessageIO</em>. One object
of this class is created on the client side, one on the server side. Different types of networks can
@@ -84,8 +84,8 @@
The KGame objects are by default all equal. So the usual approach will be that every KGame object will
store the complete status of the game, and any change or move will be broadcasted to the other KGame
objects, so that they all change the status in identical ways. Sometimes it may be necessary (or just
- easier to implement) that one KGame object is a <em>game server</em> (i.e. he is repsonsible for everything,
- he coordinates the complete game and stores the game status), whereas the other KGame objects are
+ easier to implement) that one KGame object is a <em>game server</em> (i.e. repsonsible for everything,
+ coordinating the complete game and stores the game status), whereas the other KGame objects are
only dumb stubs that are used to contact the <em>game server</em>. You can implement both approaches
using the message server structure. If you need to elect the KGame object that shall be
the game server, you may e.g. use the one that has the KMessageClient that is the admin of the message
@@ -119,8 +119,8 @@
<b>Scenario 2: network game, started by one player</b><P>
- If one user is bored of playing alone, he can open his game for connections from the outside world.
- He listens to a TCP/IP socket port (i.e. a number between 0 and 65535). Other players can create
+ If one user is bored of playing alone, they can open their game for connections from the outside world.
+ The game listens to a TCP/IP socket port (i.e. a number between 0 and 65535). Other players can create
KGame objects of their own and connect to this port. They need to know the IP address of that computer
and the port number. This situation will have this structure:
@@ -184,4 +184,4 @@
<!-------------------------------------------------------------------------------->
</body>
-</html> \ No newline at end of file
+</html>