Even though a game player model is easy to create in a paper, designing a working model for TBS games, especially for the complex ones, is quite a demanding effort
for a novice. It is also a delicate work for an expert to create an optimal one without any helping tools. Therefore, we can assist the model creation with some tools.
The main target to facilitate the design and improve the performance of a player model for TBS games is bettering its decision-making module, where all game de-cisions and game commands are generated. With our use of FS decision making system, we introduce additional features to enhance the design of FS rules in the following subsections.
4.4.1 Modular FS Tables
One of the well-known drawbacks of an FS rule-based system is the exponential growth of its table size. The size of an FS table equals to the multiplication between a number of degree of membership (DOM) states from each input variables. For example, an FS table with three inputs contains eight rules at a minimum, with two DOM states in each input variable (i.e. LOW & HIGH). However, with five DOM states in each input (i.e. VERY LOW, LOW, MEDIUM, HIGH & VERY HIGH), the table size rises up to 125 rules (= 5×5×5) rapidly.
To determine a fine decision for a strategy game, we need to consider a substantial number of input conditions, each with numerous DOM states. The size explosion problem is unavoidable when constructing such an FS decision-making system. One gigantic FS table is not easy to create and quite tricky to maintain.
To solve the problem, we iteratively split the game decisions into several smaller missions. Each mission concentrates on a single job and retains its own FS table, which we call an FS modular table. The output of the table is either a game decision or a pointer to another table. The whole connected tables, from one to others, establish a hierarchical structure of modular tables. A series of fuzzy reasoning must be computed before reaching the final decision.
The modular FS table drastically reduces the table size by dividing a huge FS table into small connected modular tables. A lot of FS tables, each with a few inputs, are easier to create and maintain than an extremely large one with considerable inputs. We can modify an FS modular table of a single task with a minimum effect to the others. Similarly, the extension of the existing modular table is convenient.
The modular design also makes the underlying logics behind the overall decisions more understandable.
Figure 4.5 shows an example of our implementation of FS modular tables in
1
SHIELD
SHIELD
ENERGY KLINGON
EXISTS SHIELD
AVAILABLE STARBASE
REPAIRABLEDECISION
LOWYESNOYESTO_STARBASE
LOWYESNONOATTACK LOWYESYESYESset_shield_energy()LOWYESYESNOset_shield_energy()
LOWNONOYESTO_STARBASE
LOWNONONONAVIGATE LOWNOYESYESTO_STARBASE
LOWNOYESNONAVIGATE
HIGHYESNOYESTO_STARBASE
HIGHYESNONOATTACK HIGHYESYESYESATTACK
HIGHYESYESNOATTACK
HIGHNONOYESTO_STARBASE
HIGHNONONONAVIGATE HIGHNOYESYESTO_STARBASE
HIGHNOYESNONAVIGATE
NA VIGA TE
WEAPON
AVAILABLE ENERGY
LEFT TIME
LEFTDECISION
YESHIGHHIGHTO_KLINGON
YESHIGHLOWTO_KLINGON
YESLOWHIGHTO_STARBASE
YESLOWLOWTO_KLINGON
NOHIGHHIGHTO_STARBASE
NOHIGHLOWTO_STARBASE
NOLOWHIGHTO_STARBASE
NOLOWLOWTO_STARBASE #12345678910111213141516
A T TA CK
KLINGONS
HIDDEN_ALL TORPEDO
AVAILABLE PHASER
AVAILABLEDECISION YESYESYES torpedo_to_klingon()& phaser_to_klingon()
YESYESNOreveal_klingon()
YESNOYESphaser_to_klingon()
YESNONOTO_STARBASE
NOYESYES torpedo_to_klingon()& phaser_to_klingon()
NOYESNOtorpedo_to_klingon()
NONOYESphaser_to_klingon()
NONONOTO_STARBASE 2#1234567
83
#
1
2
3
4
5
6
7
8
Figure4.5:ThreeoutoffivemodularFStablesusedinStarTrekgame.TwoFSrulesintheATTACKtable(topright)usethemulti-outputdecisionfeature.Theyareindicatedbythe“&”symbolinthedecisioncolumn.
the decision making of Star Trek game. The output from one table may lead to an evaluation of another table. Each table represents a module that is responsible for one game action. In the figure, the decision in SHIELD table can lead to an ATTACK or a NAVIGATE when the SHIELD is already set.
4.4.2 FS Table Reevaluation
Occasionally, when playing a video game, it is possible for a game environment to make mistakes and give us wrong information. The FS decision-making system may compute a faulty decision due to an incorrectly inferred game state. In a worst-case scenario, when our player model keeps holding the same faulty decision, the game environment may stall due to no game progress.
To advance the game from the halt, we have to discard this faulty decision and re-evaluate the table without poor output decisions. The FS table re-evaluation activates automatically when a decision generates an invalid command feedback due to unexpected game events or wrong command arguments. In this case, the FS will be re-evaluated with the faulty decision disabled. This ensures us a new decision from the calculation.
To handle the repetitive case when the new decision is still faulty, we repeatedly disable it and re-evaluate the table until a good decision comes out. If all decisions in the table are faulty, we navigate up in the table hierarchy to disable the faulty output table then recalculate for the next working decision.
ATTACK
KLINGONS HIDDEN_ALL
TORPEDO AVAILABLE
PHASER
AVAILABLE DECISION
YES YES YES torpedo_to_klingon()
& phaser_to_klingon()
YES YES NO reveal_klingon()
YES NO YES phaser_to_klingon()
YES NO NO TO_STARBASE
NO YES YES torpedo_to_klingon()
& phaser_to_klingon()
NO YES NO torpedo_to_klingon()
NO NO YES phaser_to_klingon()
NO NO NO TO_STARBASE
1
#
2 3 4 5 6 7 8
Figure 4.6: When a previous decision failed, FS re-evaluation is activated while the previous decision is disabled.
4.4.3 Multi-output decision
When designing FS rules for the FS decision-making system, it might be possible for a couple of decision outputs to be all suitable for a rule. Each of these options usually indicates different action behaviors. In this situation, a rule designer may face a difficult time to select, from these outputs, only one correct decision for the rule.
To assist a rule designer, we allow several output decisions to be expressed in an FS rule. We use an optimization process via evolutionary computation algorithm to, automatically, find out the appropriate option for the rule. Additional information on optimization of multi-output decision is explained in subsection 5.2.4.2.
