A TWO-PLAYER VRML MOBILE GAME
Zhu Bo, Loh Kok Keong
School of Computer Engineering
Nanyang Technological University
Nanyang Avenue, Singapore 639798
E-mail: [email protected]
Keywords: VRML, Java, Blaxxun Technology, Artificial
Intelligence (AI).
Abstract
This research project explores the feasibility of developing a
two-player mobile game using Virtual Reality Modelling
Language (VRML) and Java Technology. The basic
environment of the game is constructed in VRML and then
converted to multi-user version based on Blaxxun Platform
Technology. Two players of the game are designed to be
capable of shooting each other in order to gain victory. One
computer-controlled robot is added to provide some artificial
intelligence as well as enhanced human-computer interaction.
This paper focuses on the bot intelligence design.
1 Introduction
3D computer games are always at the centre of public focus.
In the new millennium we witnessed a prevalence of Javaenabled mobile phones. As technology advances, people
demand more features from the previously simple handsets
with merely talking and SMS capabilities. In order to match
the market demand as well as conducting feasibility research
on real-time 3D Internet games using Virtual Reality
Modelling Language (VRML), we decided to develop a twoplayer VRML Mobile Game with Java technology.
2 Design and Implementation
2.1 General bot behaviour design
The design of the general bot behaviour is that it can hide
itself from the player. The VRML world used consists of 16
identical houses. Among those are three decision points
which are placed in the centre of three houses that form a
triangle. Once the bot senses it’s found by any of the two
players, it will choose a route to flee. If it encounters any
player when moving, it will try to attack the player. However,
due to time constraint and various unforeseen technical
difficulties, the bot attacking feature was not implemented.
Figure1: Layout of the VRML world.
Figure 1 illustrates the layout of the world we are using. Each
circle represents a house and the number assigned to the
circle is used in the bot movement animation algorithm. The
three circles with letter ‘D’ are decision points. Whenever the
bot is discovered by the player, it will try to hide itself again
by moving from one decision point to another. As each house
contains both front door and back door, the program
controlling the bot will determine which door the player is
coming from and thus instruct the bot to move away through
the other door when the player is sufficiently close.
Figure 2 shows the rendered scene of the actual VRML world
seen on the computer screen. As mentioned previously, the
sixteen houses are identical. One advantage of such
arrangement is that it would be difficult for the player to keep
track of the current location in the scene with respect to the
starting position. In this way, the player cannot easily find out
that the bot is actually moving among three decision points
and all other houses are just intermediate steps.
Figure 2: Screenshot of the VRML world.
For the image of the bot, a freely available 3ds max source
file is chosen and converted to VRML format. The bot image
is shown in Figure 3.
Figure 3: A spaceship bot.
2.2 Bot route design
consideration during route implementation, which will be
discussed shortly.
In VRML, object animation is controlled by time sensors and
position interpolators. Time sensor generates events as time
passes which can be used to drive continuous simulation and
animation. Position interpolator linearly interpolates among a
list of 3D vectors that enables accurate modelling of
animation path. Therefore every segment comprises one time
sensor and one interpolator. As for the list of 3D vectors
required to control object position, they are all supplied by
the author. One short program using proximity sensor and
Java EAI (External Authoring Interface) was written to
record the position coordinate values of the player during
player movement. Proximity sensor generates events as long
as the player is inside a bounding-box specified in the
proximity sensor definition and is moving. Those
continuously generated events are passed to a Java applet
through Blaxxun Contact Java EAI. After that the applet
records all the passed coordinate values and outputs them to
the screen. Finally the result values can be used to control
object animation. Listing 1 shows a simple segment 1 – 2.
Listing 1:
DEF ts_1_2 TimeSensor {
cycleInterval 3
}
DEF pi_1_2 PositionInterpolator {
key [ 0.0 0.037037037 0.074074075 0.11111111
0.14814815
0.18518518
0.22222222
0.25925925
0.2962963 0.33333334 0.37037036 0.4074074 0.44444445
0.4814815 0.5185185 0.5555556 0.5925926 0.6296296
0.6666667 0.7037037 0.7407407 0.7777778 0.8148148
0.8518519 0.8888889 0.9259259 0.962963 1.0 ]
Figure 4: Bot Movement Route.
Figure 4 illustrates the six routes by which the bot can travel:
Route 1 – 8:
1 -> 2 -> 3 -> 4 -> 8
Route 1 – 14:
1-> 13 -> 14
Route 8 – 1:
8 -> 7 -> 6 -> 5 -> 1
Route 8 – 14:
8 -> 12 -> 11 -> 10 -> 14
Route 14 – 1:
14 -> 10 -> 9 -> 5 -> 1
Route 14 – 8:
14 -> 15 -> 16 -> 12 -> 8
The six routes cover all sixteen houses in the VRML world.
Each part of the route is considered as a segment, e.g. 1 - 2.
Among all the segments involved, three are shared, which are
1 – 5, 8 – 12, and 10 – 14. Shared segment requires special
keyValue [ -31.985022 1.6571616 31.069212, -31.979012
1.65741 30.757261, -31.956211, 1.6583524 29.573675,
-31.933052 1.6593096 28.37152, -31.903196 1.6605437
26.821808, -31.875748 1.6616782 25.397074, -31.85018
1.662735 24.069822, -31.825092 1.663772 22.767565,
-31.797113 1.6649283 21.315334, -31.772554 1.6659434
20.040571, -31.747467 1.4984803 18.738314, -31.723824
1.4994576 17.51104, -31.699217 1.5004747 16.233776,
-31.673697 1.4761283 14.909021, -31.647646 1.4772052
13.556772, -31.634192 1.646802 12.179395, -31.637594
1.6478391 10.876899, -31.656242 1.6488342 9.627084,
-31.71264 1.6500497 8.100692, -31.773705 1.6510856
6.7996297, -31.846966 1.6521212 5.499192, -31.920103
1.6531566 4.198748, -31.962374 1.654251 2.8244247,
-31.99754 1.6553077 1.4973905, -32.032032 1.6563445
0.19534734, -32.04632 1.656774 -0.3441795, -32.046333
1.6567744
-0.34460458,
-32.046333
1.6567744
-0.34460458 ]
}ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
ss
DEF si_1_2 ScalarInterpolator {
key [ 0 1 ]
keyValue [ 1 0 ]
}
field SFNode brain USE brain
url [ "vrmlscript:
// state == false means route 8-14
function route_request_8_14(value, time) {
Segment 1 – 2 can be reused no matter what the moving
direction is. That means the same set of data can be used
when the bot is moving either from 1 to 2 or from 2 to 1. In
the case of movement from 2 to 1, a scalar interpolator should
be used to invert the value passed out by time sensor so that
the last key value in the position interpolator is regarded as
the first key value and the first as the last.
if (value == false) {
if (state != false) {
// if state remains the same, no need to
change the routing
state = false;
change_route();
2.3 Bot route assembly and dynamic route switch
}
Now that we have all the segments as building blocks, we can
start to assemble the route. A route is basically a collection of
segments such that the end of the first segment is the start of
the second segment. Let’s take route 1 – 8 as an example.
Route 1 – 8 is composed of four segments: 1 – 2, 2 – 3, 3 – 4,
and 4 – 8. Whenever a time sensor runs and stops, it will
generate an event signalling the completion of running. That
event is used to trigger another time sensor. Time sensor
ts_1_2 triggers ts_2_3, ts_2_3 triggers ts_3_4, and ts_3_4
triggers ts_4_8. The initial triggering of the route is done by
the control applet. The applet keeps track of the instantaneous
positions of two players and chooses a route in the hope that
the bot can avoid meeting neither of them.
route_switch_finished_8_14 = false;
There’s one obscure fanout problem inherent in this design.
VRML language was designed to be routing of events
generated by various entities. The time we reuse an existing
segment, events generated by the time sensor of this segment
are inevitably routed to more than one entity, which can cause
simultaneous triggering of two segments. The behaviour of
objects under such condition in VRML is undefined. To walk
around this problem, route-switch node is introduced to
dynamically change the routing of events using VRML script
interface. One example of such dynamic event routing
alternation is illustrated in Listing 2.
Listing 2:
DEF route_switch_10_14 Script {
eventIn SFBool route_request_8_14
eventIn SFBool route_request_14_1
eventOut SFBool route_switch_finished_8_14
}
}
// state == true means route 14-1
function route_request_14_1(value, time) {
if (value == false) {
if (state != true) {
// if state remains the same, no need to
change the routing
state = true;
change_route();
}
route_switch_finished_14_1 = false;
}
}
function change_route() {
// false enables route 8-14
if (state == false) {
Browser.deleteRoute(ts_10_14,'isActive',
Route_14_1, 'set_Active_10_9');
Browser.deleteRoute(ts_10_14,
'fraction_changed', si_10_14, 'set_fraction');
eventOut SFBool route_switch_finished_14_1
Browser.addRoute(ts_10_14, 'isActive', brain,
'set_Active');
field SFBool state FALSE
Browser.addRoute(ts_10_14,
field SFNode ts_10_14 USE ts_10_14
‘fraction_changed', pi_10_14, 'set_fraction');
field SFNode si_10_14 USE si_10_14
print('In route_switch_10_14: switch to route
8-14');}
field SFNode pi_10_14 USE pi_10_14
field SFNode Route_14_1 USE Route_14_1
// true enables route 14-1
else if (state == true) {
Browser.deleteRoute(ts_10_14, 'isActive',
2.4 Java control applet
si_10_14, 'set_fraction');
Knowing the power of Java programming language, Java
applet was used in favour of Java Script in implementing the
bot control logic. Since the project is a two-player game, one
player can host the control applet while the other just enter
and play. Loading of applet is determined by several lines of
HTML code with Blaxxun Contact specific information to be
used by Blaxxun Community Server. Listing 3 shows the
HTML code required to run an applet together with normal
VRML rendering.
print('In route_switch_10_14: switch to route 14-1');
Listing 3:
}
<OBJECT CLASSID="CLSID:4B6E3013-6E45-11D0-93090020AFE05CC8"
brain, ’enable');
Browser.deleteRoute(ts_10_14, 'fraction_changed',
pi_10_14, 'set_fraction');
Browser.addRoute(ts_10_14, 'isActive', Route_14_1,
'set_Active_10_9');
Browser.addRoute(ts_10_14, 'fraction_changed',
}"
]
}
Let’s examine the route-switch source code. Without
concerning about VRML language syntax, there are totally
three functions in this script node: route_request_8_14(),
route_request_14_1()
and
change_route().
Function
change_route can be considered as private function used only
by the other two functions. With reference to the bot
movement route in Figure 4, we can see that the above code
deals with the fanout problem in segment 10 – 14. If the bot
travels by route 8 – 14, it will be moving from 10 to 14. Or if
the bot travels by route 14 – 1, it will be moving from 14 to
10. Disabling the event routing of route 14 – 1 while the bot
is travelling by route 8 – 14 or the other way round is what
the above code tries to accomplish. At any time we need to
have one and only one route enabled, so route 8 – 14 was set
as the default one with boolean value FALSE representing the
route. Every time the bot is about to start moving in segment
10 -14, it will refer to the route-switch to ensure that the
proper event routing is established. Attaching a boolean value
to the route also makes multiple travelling in the same
direction possible. As long as the bot moves through the
segment in the same direction, there is no need to change any
event routing. This is achieved by testing the boolean value
“state” prior to the invocation of change_route() and then
setting event routing accordingly.
Browser.addRoute() and Browser.deleteRoute() are two
VRML script interface API provided to dynamically change
the event routing. To disable a route, we need only to break
the chain of event routing. Removing the event routing
between event-out of the shard segment and segment in the
route immediately following the shared segment can satisfy
this requirement. With this approach the events coming out of
the time sensor are going nowhere to affect other entities in
the VRML world. In this way the time sensor fanout is
reduced back to one and the concurrent triggering problem is
eliminated.
ID=browser HEIGHT="100%" WIDTH=100%>
<EMBED
TYPE="application/x-cc3d"
HEIGHT=100% >
WIDTH=100%
</OBJECT>
<applet code="Applet1.class" codebase="." id=vrmlApp
mayscript height="40%" width="100%">
</applet>
<!--needed to retrieve the vrml browser handle in IE3.0x-->
<script language=VBScript>
' Send the browser control object to the applet
Sub window_onLoad
document.vrmlApp.setBrowser browser
end sub
</script>
Note: Microsoft Java Virtual Machine is required to run the
applet.
Listing 4 presents the strategy used by the Java control applet
to select route.
Listing 4: Applet1.java
if (currentPoint == POINT_1) {
// test to see which player is closer to the bot
// true means player2 is closer
// false means player1 is closer
if (calculateDistance(ref1, position1, position2))
position = position2;
else position = position1;
// tell the bot to move away from the player accordingly
if (position[2] > ref1[2])
setRoute(POINT_2);
else setRoute(POINT_3);
}
else if (currentPoint == POINT_2) {
if (calculateDistance(ref2, position1, position2))
position = position2;
else position = position1;
if (position[2] > ref2[2])
setRoute(POINT_3);
else setRoute(POINT_1);
}
else if (currentPoint == POINT_3) {
if (calculateDistance(ref3, position1, position2))
position = position2;
else position = position1;
if (position[2] > ref3[2])
setRoute(POINT_2);
else setRoute(POINT_1);
}
POINT_1, POINT_2 and POINT_3 are three macros defined
in the Java file which represent the three decision points
respectively. Function calculateDistance() compares the
current bot position with the two player positions and return a
boolean value. FALSE means player2 is closer and TRUE
means player1 is closer. The closer player’s position is used
to select the route to another decision point. The selection
strategy is quite simple. If the player is coming from the front
door, the bot will move through the back door, otherwise the
bot will move through the front door.
2.5 Blaxxun SharedEvent
To support the multi-user environment, Blaxxun Platform
specific BlaxxunZone and SharedEvent interface are to be
implemented. SharedEvent is any event that is passed through
the Blaxxun Community Server so that every user of the
multi-user scene can receive the event. This is necessary
because in a multi-user environment, one user’s action should
be reflected on every other user’s screen as long as the user is
connected to the shared scene. BlaxxunZone is like a wrapper
that includes all the SharedEvent defined in the VRML file.
Moreover, since the bot movement is controlled by an applet,
and the applet only runs on one of the player’s machine, all
bot related events must be declared as shared events so that
the control applet can be aware of every action the bot takes
in both side of the game. One side-effect of such design is
that in the worst case, the user’s action against the bot is
firstly sent through the server to the control applet, and then
the corresponding bot action is sent through the server again
to reach the source of the original event. This network trip is
insignificant only if the server response time is fast.
Unfortunately, the average delay time of the Blaxxun
Community Server is around 2 – 3 seconds, which means in
the worst case the user needs to wait about 5 seconds for the
bot to take corresponding response following the user’s initial
action. Such a long delay almost makes the game unplayable,
but finally a solution was devised to partly walk around it.
This will be discussed in detail in the following section.
3 Partial solution to encountered problem
With the significant Blaxxun Community Server delay in
mind, how to handle the bot-user interaction becomes a
problem. Thanks to the fact that we are only implementing
player attack on the bot, we are able to minimize the server
delay effect. In order for the player to shoot the bot, he needs
to be within a certain range and click on the bot to fire. This
range can be the same as that used to trigger route selection.
The clicking behaviour is controlled by a touch sensor
attached to the bot. If the bot is not moving, the touch sensor
is disabled so that the player cannot click on the bot thus
cannot fire. Only when the bot starts moving is the touch
sensor enabled to allow the player to click. As a result, for the
period of server delay, the player cannot attack the bot to gain
a biased advantage.
4 Conclusion
The technologies and hardware available are still not quite
ready for real-time 3D game on mobile phones. Due to
money issues, we did not get a copy of the latest Blaxxun
Platform and developer SDK, which limits the extent to
which we can delve into the Blaxxun Platform Technology.
Time is also a constraint that prevents us from producing a
working game with rich features. However, the experiences
gained and products produced throughout this project will
definitely help future research on related topics.
References
[1] Blaxxun.
Blaxxun
Developer
Information.
http://www.blaxxun.com/developer/, 2003.
[2] The Web3D Consortium. The Annotated VRML97
Reference.
http://www.web3d.org/resources/vrml_ref_manual/,
2003.
[3] Microsoft Developer Network. MSDN Library.
http://msdn.microsoft.com/library/default.asp, 2003.