I. Abstract

This paper presents general information regarding jLodeRunner project (found at http://jloderunner.sourceforge.net ). It intends to be a java remake of the classical Lode Runner game. In addition, it will be a test-bed for various game AI and mobile agents techniques.

II. jLodeRunenr Request for Comment

This version of ‘Lode Runner’ (LR) is a Java variant of the classical well-known game with the same name. Beside basic (classical) features, here will be included some more team multiplayer variants. I will enumerate them at the proper moment.

1. The game:

The game is played on a map, entirely visible on the computer monitor (i.e. no scroll is needed). There are a number of (usually) 4 black men and (usually) 1 white man. In this version of jLR these numbers may vary, function of the team play, the map’s size/complexity etc. Below, I will name the black players’ crew the black team and the white players’ crew the white team. Note that the white team may be formed from only one man.

2. The map:

On a map, we can find:

-         Breakable bricks

-         Unbreakable bricks

-         Golden boxes

-         Horizontal ropes

-         Vertical ladders

-         Black men

-         White men

3. The goal:

The goal of the white team is to pick-up all golden boxes, while the black team’s goal is to catch the members of the white team.

4. The rules:

Any man can move in one of four directions: up, down, left, right.

-         It will move up and down if he is on a ladder.

-         It will move left and right if it is on a ladder, on a brick or hanged on a rope.

The map has a constant gravitation force (it will not vary). So, a man will begin to fall, once it doesn’t have something to stay on (any kind of brick, a ladder) or to hang of (the rope).

In the original game, the black team moves a little bit slower than the white team. In this version this detail is to be discussed.

The white man can break the brick in front of him with a hit of his leg. This brick becomes a empty map cell for a specific amount of time (it will be constant in all game, for ex. 5 seconds). After this period, it will transform itself back to “the old brick”. The transformation process will last about ½ seconds. If, while this happens, there is a man, from any of the two teams, in that place (the place where was a brick, it was broken by white and now it “comes back”) it will be killed.

If someone (white or black) steps on a broken brick, then:

-         For white team, the man will fall as if there is nothing underneath.

-         For black team, the man will stay “caught in brick” for an amount of time (this

            time will be significantly smaller than the timer of the brick).

Sometimes, such a situation may happen:

1)      The brick is broken at time t (it will come back after 5 sec-s)

2)      The black man falls into it at time t + 3 (it must stay “caught in brick” for 3 sec-s)

3)      The time of the brick expires and the black man, caught in it, will be killed. The same may happen to a white man only in that small period of ½ sec-s (while the brick “comes back”) he is falling through a broken brick.

5. Features:

In the classical game, there were 4 or 5 black man, guided by computer AI, and 1 white man, which is the human player’s hero. In this jLR, we will include such playing variations:

1)      The white team is guided by AI and the black team is guided by human 

player/players (network or local). A human player will move only one hero at a time, but he can change the hero he is focused on, to move another team member. Computer AI will guide the rest of the human team’s heroes, unselected at that moment by one of human players.

2)   The goal of the white team, ruled by human players, is to collect all golden boxes

and to have at least one alive team member in the end (they may sacrifice one of the team’s member to achieve a goal).

3)   Some other playing features, not mentioned here, but which may appear in the future.

III. Game Design Architecture

1. Introduction

Design Patterns describe a classical design problem, together with the core of the solution to that problem, in such a way that you can use this solution a lot of times over, without ever doing it the same way twice.

The purpose of a framework is to make up a reusable design for a specific type of software. A design patterns based Object Oriented Framework is a powerful tool because it encapsulates the whole power of reusability, scalability and flexibility of OO architectures.

Coming from here, the jLodeRunner framework is being build as a full-fledged foundation for writing software applications, starting from computer games and rising to Artificial Intelligence test beds.

2. Design and Patterns applied

The framework comprises of a <Central decision and Synch. Engine> and multiple <Local game engines>, implemented as Facades (or some kind of Moderators) design patterns. (see the Use Case diagram).

The backbone of the framework is the Model – View – Controller architectural pattern. In implementation we have:

3. Class collaboration scenario

The main scenario that takes place each timer tick is as follows (see Sequence Diagram)

  1. The client engine broadcasts the i-th timer tick (Publisher - Subscriber pattern).
  2. The client engine collects decision from all hosted agents.
  3. The client engine sends back to <Central Decision Engine> a small decisions packet.
  4. The <CDE> collects ALL arrived packets, forms a BIG decision packet and broadcasts it to all <Client Engines>.
  5. Each <Client Engine> notifies and updates its map.
  6. Each agent, registered as a MapChanged event listener, receives and updates its internal state according to the decisions made in the system.
  7. The screen is being repainted.

4. Advantages

Such an approach fetches a set of immediate advantages:

a)      The <Client Engine> doesn’t have to bother with the provenience of the synch. tick.

b)      The <Client Engine> doesn’t make difference between a AiAgent and a HumanAgent.

c)      The <Client Engine> can cache its decisions for further network performance optimization. (implemented using Proxy pattern)

d)      All instances of maps on each instance of network game are being updated simultaneously. This leads to:

e)      All agents in the system update their internal state at the same fraction of time, element that eliminates the need of further network resynchronization.

f)        The screen update triggers on two events:

-         some internal decisions to redraw the screen (i.e. paint some frames per one step)

-         a compulsory, globally taken decision to redraw the screen.

5. Disadvantages

The only noticed disadvantage of such an approach is excessive coupling among engines running on a network. The condition that ALL game instances stay synchronized all the time may lead to some network latencies on a medium to low bandwidth.

6. Design details

The local engines are built such a way, that they never make the difference: the <Central decision and Synch. Engine> is hosted on the same computer (i.e. single player game) or is located somewhere on the network. This facility is accomplished with the help of the Strategy design pattern, which abstracts the source of  timer ticks.

Every agent is endowed with a Finite State Machine (implemented as a classic FSM design pattern). There are several FSM`s (one for each type of AI agent). Every FSM contains a specific set of legal states for that specific agent. When an agent is queried for a decision, the request is forwarded to the internal FSM, which delegates it to the current state of the FSM. Depending on the current state, two types of decisions are returned:

a)      Mandatory decisions, “taken” (in fact served) as natural manifestation of game rules or physical laws.

b)      Rationally taken decisions (user input, AI process of “thinking”).

IV.‘TO DO’-s and further tasks

SourceForge Logo