Runtime Evolution for Online Gaming

1
Runtime Evolution for Online Gaming

• Student Julian Lei Zhu
• Supervisor Dr. Graham Morgan

2
Introduction

• Online gaming scenario
• players may participate in virtual worlds that
  are persistent in nature
• Massively Multiplayer Online Role-Playing Games
  (MMORPGs)
• Players behaviours, interactions with gaming
  platform
• More level of game challenges, experiences to
  attract and retain players
• more players relates to more revenue
• Cash in investment for business venture

3

• Attracting players to an MMO is not
  straightforward
• advertising campaigns
• retaining players
• ensuring the longevity of a game business venture
  
• MMO itself
• continue to provide new and challenging scenarios
  
• players participation
• periodically introducing new content
• all content , persistence
• So, the content of a virtual world an MMO
  supports will definitely increase, over time

4

• Such an increase in content will require
  additional world maintenance
• a highly evolving, persistent, virtual world
• a correctly functioning
• always available simulation
• This approach has resulted in the management of
  change in an ad-hoc manner and severely limits
  the ability to introduce far reaching change
  while ensuring the correctness of a simulation.
• A failure free approach to runtime maintenance
  and adaptability for distributed applications
• MMOs
• a highly visual view of the problem
• timely requirements
• player-to-player interactions
• application maintenance

5

• Problems
• MMO maintenance and adaptability in the context
  of evolving game play
• change the rules that govern gaming scenarios
• Reason
• by changing rules one can create quite diverse
  gaming environments
• that changing the rules is considered a very
  challenging aspect of MMO maintenance, as rules
  are encoded throughout the implementation
• Successful tackling of this problem will promote
  the runtime diversity, and longevity of MMOs

6

• Background
• Persistent virtual world implementations
• Server based
• control the provision of realities
• maintain player interest
• restrict participation to subscribed players

• a players console
• Holds a sub-set of game state
• Message exchange
• Via server, allowing interaction and record game
  state

7

• A gaming scenario
• collection of rules, governing a game
• content
• associated players
• Our work
• changing the rules of one gaming scenario
• not the content nor the number of players
• create additional gaming scenarios
• Changing the underlying rules governing a virtual
  world is considered the most challenging aspect
  of game evolution in MMOs (as opposed to simply
  adding content).

8

• players to navigate ships between ports
• evolve an economic market, trade, cargo
• a requirement to modify the artifact ship to
  enable the carrying of cargo
• The new concept of trade will require
  modification to the rules governing the virtual
  world itself
• not sufficient to just add content
• Existing content (ships, ports) must also be
  altered to enhance them with the ability to
  participate in trade.
• 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.

9

• 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

10

• 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
• Existing content cannot be changed appropriately
  to accommodate new content.
• Fundamentally, all existing approaches severely
  limit content evolution in favor of safety and
  the programming burden is immense.
• The thought that the actual rules governing a
  gaming scenario may be altered has not been
  considered. Rules are left alone

11
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

12

• 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.

13

• 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)

14

• Different 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
15
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.

16
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)

17

• 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
18

• 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.
19
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.

20

• 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.