3
<title>Five-in-a-row v 0.0</title>
8
</i> 0.0 supplementary documentation
10
<h3>Introduction and rules
14
</i> is a two player strategy game. The players
15
are connected via network using CORBA-based RMI/IIOP protocol and
16
make they moves with the help of the Swing-based
17
interface. While playing, the users can also chat.
19
<p>The system consists of the single server and any number of
20
interconnected players. The person, willing to play, starts the
21
client and connects the server. The server redirects call to the
22
partner that has previously connected the same server, also willing
25
<p>The game desk is a field where it is possible to set O's
26
and X'es, one per move. The goal is to get five O's in a row while
27
preventing your partner from getting five X's in a row. Vertical,
28
horizontal and diagonal rows are allowed. The system detects the
29
loss-victory situation on the desk, but currently does not serve as a
30
playing partner, requiring at least two human players for this game.
32
<p>Both players can at any time reset the game (restarting it with
33
the same player) or leave the game (disconnecting). The disconnected
34
player can contact the game manager again, requesting to find another
37
<p>Simple as it is, the application has some features of the typical
38
role playing game that frequently just has more states, actions,
39
possible moves and also provides far richer graphics environment. The
40
game manger serves as a World-Wide-Pub where you can always find a
43
The players can made both unsynchronized (chatting, game reset and
44
leaving) and synchronized (moves) actions. The game state changes
45
while playing, and the set of the available actions depends on the
46
current state. Finally, the mouse and canvas are involved. However
47
using RMI/IIOP machinery allowed to implement all this functionality
48
with just 13 classes (plus 4 generated), all of them being rather
51
This example refers to the standard classes only and must be buildable
52
from your IDE as long as it has any java 1.4 compiler.
55
The used IIOP protocol must ensure interoperability, allowing players
56
to use different java virtual machines and operating systems.
57
The processors may have the opposite byte order.
59
<h3>Configuration and run
61
<p>The game manager server executable class is
62
<i>gnu.classpath.examples.CORBA.swing.x5.X5Server
64
it will print to console the Internet address that must be entered to
65
the client to reach the manager.
67
<p>The client executable class it
68
<i>gnu.classpath.examples.CORBA.swing.x5.Demo
71
<p>The game should run with GNU Classpath
72
0.19 and Sun Microsystems java 1.5.0_04. Due later fixed bugs it will
73
not run with the older versions of these two implementations.
75
<p>The game manager HTTP server uses port
76
1500. Hence all firewalls between the server and the player must be
77
configured to allow HTTP on 1500. The ports, used by the RMI/IIOP are
78
not persistent. GNU Classpath is configured to take ports 1501, 1502
79
and 1503 (the firewalls must allow to use them for RMI/IIOP). The
80
CORBA implementation other than Classpath may use different port
81
values. Unfortunately, there is no standard method to configure the
82
used port range in a vendor-independent way.
86
<p>The game manager is first reachable via http:// protocol (for
87
instance http://123.456.7.89:1500). The simple server at this port
88
always serves much longer string, representing the CORBA stringified
89
object reference (IOR). The
90
<i>Five-in-a-row
92
this reference to find and access the remote game server object.
94
<p>If the server player queue is empty, it simply queues this player.
95
If the queue is not empty, the server introduces the arrived player
96
and queued player to each other as leaves the them alone. When
97
playing, the two clients communicate with each other directly, so the
98
server is just a “meeting point” where the players can
99
find each other. The game server is a console-only application.
101
<p>The initial server http:// address must be transferred to players
102
by some other means of communication (web chat, E-mail, link in a web
103
site and so on). The server writes this address to the specified
104
file, and the client can also take the default value from the same
105
file. This is convenient when all applications run on a single
106
machine, but also may be used to transfer the address via shared
111
<p>The clients are Swing-based GUI applications, capable for remote
112
communication with each other and with the game manager. They have a
113
set of predefined states and switch between these states in
114
accordance to the preprogrammed logic. The client states are defined
117
</i> interface. They are displayed in the bottom left
118
corner of the window and are summarized in the following table:
120
<table BORDER=1 CELLPADDING=4 CELLSPACING=0 WIDTH="100%">
122
<tr BGCOLOR="#ccccff">
123
<th BGCOLOR="#e6e6ff">
126
<th BGCOLOR="#e6e6ff">
129
<th BGCOLOR="#e6e6ff">
132
<th BGCOLOR="#e6e6ff">
143
Partner not accessible
157
Partner not accessible
163
Queued by the game manager.
174
Make move, reset game, leave, chat.
177
The person who waited for another player to come starts
189
Chat, reset game, leave.
192
After the partner makes the move, the state changes to
194
</i>, unless the end of game situation is detected by
206
Chat, reset game, leave.
209
Can be entered with the help of the desk analyzer only.
220
Chat, reset game, leave
223
Can be entered with the help of the desk analyzer only.
237
This should never happen under normal work, but the demo
238
program may be modified by the user.
245
As it is seen, being in one of the states, the client expects to
246
be the partner client in a certain defined state, and both clients
247
change they states in a synchronized manner. Each state has its own
248
set of the available actions and each action either preserves the
249
current state (chat, reset) or changes it following the rules. For
250
this simple example, the state change rules are obvious.
251
<h3>The used RMI-IIOP architecture
253
Both player and game manager servants are derived from the
254
<i>org.omg.PortableServer.Servant
255
</i> and, being servants, are simply
259
<i>POA.servant_to_reference
261
first remote object (game manager) is found using the stringified
262
object reference. No naming service is involved.
264
Where required, the CORBA objects are narrowed into required
265
player and game manager interfaces using method
266
<i>PortableRemoteObject.narrow(org.omg.CORBA.Object object, Class
268
</i>, passing the actual interface of the object as
269
the second parameter. After narrowing, the remote side obtains
270
possibility to invoke remote methods, defined in the interface of
271
this object. After the first remote object is found, other objects
272
can be simply passed as the method parameters. For instance, the game
273
manager introduces another player by passing its reference as a
274
parameter to the method
275
<i>Player.start_game.
277
<h3>Class and interface summary
279
<table BORDER=1 CELLPADDING=3 CELLSPACING=0 WIDTH="100%">
283
<th COLSPAN=2 BGCOLOR="#e6e6ff">
292
The main executable class of the game client.
300
The main executable class of the game manager server.
305
<table BORDER=1 CELLPADDING=3 CELLSPACING=0 WIDTH="100%">
306
<tr BGCOLOR="#ccccff">
307
<th COLSPAN=2 BGCOLOR="#e6e6ff">
316
The game manager interface.
324
Defines remote methods that are invoked by another player or by
325
the challenge server.
333
Defines the states in that the player can be.
338
<table BORDER=1 CELLPADDING=3 CELLSPACING=0 WIDTH="100%">
341
<tr BGCOLOR="#ccccff">
342
<th COLSPAN=2 BGCOLOR="#e6e6ff">
351
Normally generated with rmic compiler, this class represents
352
the GameManager Stub on the client side.
360
Normally generated with rmic compiler, this class represents
361
the GameManager Tie on the client side.
369
Generate with rmic, command line rmic -iiop -poa -keep
370
gnu.classpath.examples.CORBA.swing.x5.PlayerImpl (the compiled
371
package must be present in the current folder).
379
Generate with rmic, command line rmic -iiop -poa -keep
380
gnu.classpath.examples.CORBA.swing.x5.PlayerImpl (the compiled
381
package must be present in the current folder).
389
The chat color code constants, used to indicate who is talking.
397
The JFrame of the GUI client.
405
The manager connects two players into the game.
413
Reads the remote URL.
421
Starts the ORBs, involved into this application.
429
The implementation of the PlayerCommunicator, providing the
438
Manages actions, related to the game rules and also does all
446
<a HREF="http://www.javascripter.net/games/xo/xo.htm">http://www.javascripter.net/games/xo/xo.htm
450
<a HREF="http://www.leepoint.net/notes-java/45examples/55games/five/five.html">http://www.leepoint.net/notes-java/45examples/55games/five/five.html
456
<font COLOR="#b3b3b3">Copyright (C) 2005 Free Software Foundation,
457
Inc. This file is part of GNU Classpath. GNU Classpath is free
458
software; you can redistribute it and/or modify it under the terms of
459
the GNU General Public License as published by the Free Software
460
Foundation; either version 2, or (at your option) any later version.
461
GNU Classpath is distributed in the hope that it will be useful, but
462
WITHOUT ANY WARRANTY; without even the implied warranty of
463
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
464
General Public License for more details. You should have received a
465
copy of the GNU General Public License along with GNU Classpath; see
466
the file COPYING. If not, write to the Free Software Foundation,
467
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
468
Linking this library statically or dynamically with other modules is
469
making a combined work based on this library. Thus, the terms and
470
conditions of the GNU General Public License cover the whole
471
combination. As a special exception, the copyright holders of this
472
library give you permission to link this library with independent
473
modules to produce an executable, regardless of the license terms of
474
these independent modules, and to copy and distribute the resulting
475
executable under terms of your choice, provided that you also meet,
476
for each linked independent module, the terms and conditions of the
477
license of that module. An independent module is a module which is
478
not derived from or based on this library. If you modify this
479
library, you may extend this exception to your version of the
480
library, but you are not obligated to do so. If you do not wish to do
481
so, delete this exception statement from your version.
489
First version written by <a href="http://savannah.gnu.org/users/audriusa">
490
Audrius Meškauskas</a>
added
removed
examples/gnu/classpath/examples/CORBA/swing/README.html
