Runtime Evolution for Online Gaming

1
Runtime Evolution for Online Gaming

• Student Julian Lei Zhu
• Supervisor Dr. Graham Morgan

2
Introduction

• Online gaming background
• Massively Multiplayer Online Role-Playing Games
  (MMORPGs)
• Players behaviours, interactions with gaming
  platform
• More level of game challenges, experiences to
  attract and retain players
• Cash in investment for business venture

3

• Less cost, more margin for game industry, how?
• New series games development
• Totally fresh
• Attract players quickly
• Large amount of cash in for commercial ads and
  game development
• New challenging scenarios development
• New recruits for game itself update, maintenance
  and support

4

• Difficulties for resource servers to deal with
• Frequent requirements from players
• Players interactions in real time distributed
  MMO application
• Aim to achieve
• New ways for maintenance
• Abstract rules to govern gaming scenario rather
  than simply update or manage numbers of artifacts
  or weapon points.
• A failure free approach to runtime maintenance
  and adaptability for distributed MMO applications.

5
Description of the problems and work

• Sever based persistent virtual world provide
  alternate realities to maintain player interest.
• Restricted participation to subscribed players.
• Players console, interactions, game state.
• Processing resources to deal with
• Game state player interactions
• Increasing players numbers
• Server side scalability

6

• Our new gaming scenario
• Game content
• Associated players
• A collection of rules
• Problems
• 1) Consistency of the virtual world must be
  maintained for all players (this is a shared
  experience)
• 2) The evolution of game play may not have been
  realized at game design/implementation time.
• 3) No forward planning for a particular type of
  game play scenario is feasible.

7

• In our research we identified changes required to
  content and rules. Changing content, although
  difficult and still a challenging research
  problem may be achieved.
• However, changing the rules is a challenge that
  our research clearly shows to be almost
  impossible if such rules are not easily
  accessible, even though rule change may bring
  about the most significant game play evolution.
• Advantages with changing rule
• Create and govern diverse gaming environments
• Encoded throughout the implementation
• runtime diversity and longevity of the
  applications

8

• Second Life, by Linden Lab
• Innovative aspect players can create content
  which can be traded.
• Emphasis in current approaches has been placed on
  content creation and minor modification
• Fundamentally, all existing approaches severely
  limit content evolution in favor of safety and
  the programming burden is immense.
• Rules are left alone

9
Identify the Approach and its justification

• Rule change may be possible if achieved with the
  appropriate toolset
• Should be available to be used in scalable
  enterprise solutions over the Internet
• Should be applicable for online game development

10

• Rule Engine
• Widely used in E-commerce, Insurance industry,
  Server side middleware, for business oriented
  system
• By separating the business logic from other
  aspects of application implementation one may
  alter business rules without a requirement to
  manually update a number of code fragments within
  the application tier of the server side.
• Identifiable Manipulative
• This has proved successful in the development
  process as rules that were not determined
  accurately at design time could be tailored (or
  even created) even after a system has gone live.

11

• Origination
• Initially carried out in AI research community.
• Expert system
• Business Rule Management System
• Most interest to MMO developers are those found
  in distributed systems middleware solutions,
  JBoss Rule Engine
• Approach
• First step evaluate the appropriateness of
  utilizing a rules engine for use within gaming
  environments, we consider a simple scenario.
• A board game that resembles the well known game
  of noughts and crosses (slightly different for
  the game evolution)

12

• Two gaming scenarios
• Three same pieces in a row to win
• Board size is bigger and the winning line
  achieved by spelling the word OXO or XOX

Possibilities for constructing varying different
gaming scenarios are, in theoretical terms,
infinite. (Grid size, winning word length,
winning word pattern, etc) Our challenge is 1)
Separate rules from other source code 2)
Implement using JBoss Drools (rules) 3) Vary game
by changing rules 4) Never alter Java code
13
Exemplification of our approach

• Three parts of the system
• Clients Interface to the game, allows players to
  place their pieces on the game board
• Server Receive information from clients to
  update the model representing the gaming arena
• Rule engine evaluate every move and indicate an
  outcome
• Invalid the move is deleted and state rolls
  back
• Progression the move progresses the game
  state
• Winning the move wins the game
• Finish no more moves possible.

14
Programming

• For comparison, we now consider a rules based
  approach using the rule engine and one where the
  rules are encoded within Java.
• Assume the grid is 4x4
• A brute force approach for clarity, to search for
  particular winning pattern
• public boolean isGameWon (int player)
• // check all columns whether 4 same symbols exist
• for (int x 0 x lt 4 x)
• int count 0
• for (int y 0 y lt 4 y)
• if (dataxy player)
• count
• if (count 4) return true
• // shows part of the Java code used to identify a
  winning
• //row of 4 pieces the same. Two further pieces of
  code were written
• //to determine the identification in the other
  directions (row and diagonal)

15

• rule "Win by the catercorner"
• When
• mainStatus ArrayofSymbolStatus(
• playerholder ! -1,
• x x,
• y y,
• playerholder playerholder)
• alarms ArrayList
• (
• size gt (RuleCommon.SUC_NUM_OF_ROWS_COLS
  - 1)
• )
• from collect(
• ArrayofSymbolStatus(
• playerholder playerholder,
• x gt (x -RuleCommon.SUC_NUM_OF
  _ROWS_COLS 1),
• x lt x,
• x1 x,
• y (y - x1 x)))
• Then

Assume winning pattern XXXX, when an X is placed
on this 55 grid at the position of 5 1, this
rule will check its rest cater-corner neighbor
symbols to identify the existence of rest three
same symbols. The line 14 means to pick up the
objects with same playerholder, which can be X or
O, value 0 or 1. Line 16 is to define the minimum
value of x axis. In this case, the winning
pattern should be same pieces placed on 2 4,
3 3, 42 if the first symbol is placed on
5 1, So line 15 should be xgt2 and shouldnt
be on the same position, xltx. Line 18 will find
out all the possible positions that met the
conditions. If the size of the collection found
is equal or more than 3, then the game status
will be to set to winning
16

• rule "Win with the same column"
• when
• mainStatus ArrayofSymbolStatus
• (playerholder ! -1, x x, y y,
  playerholder
• playerholder)
• alarms1 ArrayList(size1 size)
• from collect(ArrayofSymbolStatus
• (playerholder ! -1,
• playerholder playerholder,
• x x,
• y gt y,
• eval((y - y) 2 0),
• y lt (y
• RuleCommon.SUC_NUM_OF_ROWS_COLS - 1)))
• alarms2 ArrayList(size2 size)
• from collect(ArrayofSymbolStatus
• (playerholder ! -1,
• playerholder ! playerholder,
• x x,

Assume an X is placed at the position 4 3,
this rule file will detect existence of winning
line pattern not. If its set XOX,
RuleCommon.SUC_NUM_OF_ROWS_COLS is 3. Line 4
declares the current Xs information, x 4, y
3, playerholders value is X, not null. The
alarm1 in line 6 is to scan, within that column,
how many symbols with the same X value exist, and
y-y mod 2 equals to zero. In this case, it will
check position at 4 5. If an X is found,
size1 will be 1. alarm2 is set to check on
position 4 4. If the playholder !
playerholder, which is originally an X, then it
means a O is found in that column. size2 will be
1. Line 24 returns a Boolean true when XOX is
located.
17
Current conclusion and future work

• The work presented here, although in its early
  stages, demonstrates that rule engines can ease
  game evolution
• This is achieved by allowing developers to safely
  upgrade, delete or create rules governing a
  simulation during runtime. There is no need to
  alter actual program code. The separation of
  rules from other aspects of implementation has
  proved beneficial in this respect.
• The work carried out is the realization that
  optimization of rule execution is now removed
  from the ad-hoc approaches of game developers to
  the rule engines themselves.

18

• Other thoughts
• One may argue that optimization achieved by a
  programmer specifically with the problem in hand
  may return more optimum solutions. However, this
  assumes that the game play scenario has actually
  been thought of during the initial construction
  of program code.
• Optimization while updating existing code during
  runtime is difficult for any programmer to
  achieve safely and correctly.
• Changing the underlying rules governing a virtual
  world is considered as challenging aspect of game
  evolution in MMOs. An interesting avenue for
  future work would be to provide some tool to aid
  in determining how rule dependent a piece of code
  should be in a large MMO games.