M5 Pengambilan Keputusan dalam manajemen

DECISION MAKING
PENGANTAR TEORI GAME

PENGERTIAN






Decision
Making
adalah
serangkaian
algoritma
yang
dirancang
dengan
memasukan beberapa kemungkinan langkah
yang bisa diambil oleh suatu aplikasi
Pada game, decision making memberikan

kemampuan
suatu
karakter
untuk
menentukan langkah apa yang akan diambil.
Decision making dilakukan dengan cara
menentukan satu pilihan dari list yang sudah
dibuat pada algoritma yang dirancang.

PENGERTIAN




Algoritma
decision
making
kerap
digunakan dalam aplikasi game
Algoritma decision making dapat juga

diimplementasikan pada banyak aplikasi
lain.

Decision Tree


Keunggulan





Cepat & mudah diimplementasikan, mudah
dimengerti
Modular, Re-usable
Dapat dipelajari  Dapat dikonstruksi
secara dinamis dari observasi dan action di
dalam game

Decision Tree



Problem Setting




Memberi seperangkat pengetahuan, kita perlu
untuk menghasilkan tindakan yang sesuai dari
serangkaian tindakan yang mungkin.
Some actions are triggered by a large set of
inputs
 E.g.

For an ant AI to Evade, it requires player to be <
20 units away, player’s health to be > 50% and ant’s
health to be < 25%. There are 3 input conditions.
 Beberapa kondisi input mungkin lebih signifikan dari
sejumlah input yang ada.
 Computational redundancy


Decision Tree


Problem Setting




Kita butuh suatu metode untuk
mengelompokkan sejumlah input secara
bersamaan pada setiap action
Kita harus mengizinkan input-input yang
signifikan untuk mengontrol output actions
(also non-significant inputs should be less
utilized)

Decision Tree



Decision Tree (DT) dibuat dari kumpulan
decision point yang terhubung.









Tree dimulai dari decision (root)
Setiap decision (dimulai dari root), satu dari
sekumpulan pilihan yang ada dipilih
Pilihan dibuat berdasarkan kondisi yang
dihasilkan dari character’s knowledge/values
Lanjutkan tree sampai tidak ada lagi decision
yang diambil
Setiap leaf (daun) adalah action, yang harus
dieksekusi


Decision Tree


Contoh decision tree dari karakter
soldier
Root

Leaf

Input Conditions
(Decision Points)

Decision Tree


Action karakter ditentukan melalui
urutan decision points

Decisions



Decision di tree harus sederhana




Cek untuk yang bernilai single atau bernilai
boolean (do not normally join inputs with
Boolean logic)

Possible types of decisions and their
data types






Boolean – True/False

Enumeration – Matches one of the given set of
values
Numeric value – Value within given range
Vector (2D/3D) – Vector has length within a
given range (for distance checking)

Combinations of Decisions




Decision tree adalah efisien karena
decision yang sederhana – hanya satu
kondisi pengujian pada satu waktu
Ketika pengujian kombinasi boolean
(AND/OR) diperlukan, beberapa sturktur
tree
dapat
digunakan
untuk

merepresantikannya

Combinations of Decisions




To AND two decisions
together, place them
in series, the 1st
decision needs to be
true to consider the
2nd, in order to get to
action 1
To OR two decisions
together, place them
in series, either 1st or
2nd decision can be
true in order to carry
out action 1


Decision Complexity




In a tree structure, the
number of decisions
that need to be
considered is usually
smaller than the
number of decisions in
the tree
Complexity issue?
Space complexity?
Time complexity?

Branching in DTs







Deep binary DT
The same value (color) may
be checked up to 3 times
Slightly better: Order the
checks so that the most
likely state comes first






Flat DT with 4 branches
Using 4 branches, the
structure is flatter and
requires only one decision
check
More efficient!

Binary Better?


It is still more common to find binary DT
implementations






Underlying nature of codes usually simplifies
down to a series of binary tests (if/else)
Speed savings not significantly better with
higher order branching

Binary DTs are easier to optimize




Many tree optimization/compression
techniques are for binary trees
Learning algorithms usually use binary DT

Performance




DTs (binary) usually take no memory and
performance is linear with the number of
nodes visited
Ideal case  If each decision takes a
constant time and tree is balanced,
performance is O(log2 n), where n is
the number of decision nodes

Balancing the Tree






DTs run the fastest
when trees are
balanced
A balanced tree has
about the same
number of leaves on
each branch
Both these trees
have 8 behaviors
and 7 decisions, but

Balanced vs. Unbalanced
Tree






At its worst, performance of a severely
unbalanced tree goes from O(log2 n) to
O(n)
Although a balance tree is theoretically
optimal, it may not be the fastest tree…
Why is this so?

Maximizing Performance?






Menstrukturkan tree untuk maximum
performance adalah hal yang sulit
dilakukan
DT cukup cepat, sangat penting untuk
squeeze out every drop of speed
General guidelines: Seimbangkan tree
(as balanced as possible), buat cabang
lebih pendek dari yang biasa dipakai,
taruh expensive decision setelahnya.

Random Decision Tree






Random Decision Trees adalah algoritma
yang membentuk serangkaian langkahlangkah yang akan dimasukan kedalam
algoritma decision trees.
Setiap pilihan langkah yang dimasukkan
pada
decision
trees
tidak
dapat
diprediksi
Setiap langkah akan dilakukan secara
acak berdasarkan nilainya

Random Decision Tree






Random Decision Trees pada game “Ninja
Heroes" akan bekerja dengan beberapa pilihan
Jika karakter sedang tidak melakukan kegiatan
maka random decision trees akan bekerja
berdasarkan nilai random yang telah ditentukan
Apabila karakter sedang berada didalam kelas
atau sedang melakukan kegiatan maka random
decision trees tidak dilakukan dan karakter
akan
menyelesaikan tindakannya terlebih
dahulu.

Random Decision Tree


To introduce random choices in a DT,
decision making process needs to be
stable






Rule: If there is no relevant changes in
world state, there should be no change in
decision
Consecutive frames should stay with the
chosen random decision until some world
state changes
Implementation: Allow the random decision
to keep track of what it did last time, so
that it knows the previous choice to take

Random Decision Tree








In the first decision (if not
under attack), choose
randomly to patrol or stand still
Subsequently, continue on with
the previously chosen action
If the parent decision takes the
‘under attack’ choice (a
different branch), get rid of the
stored choice
Repeat…

Random Decision Tree






If the AI continues to do the
same thing forever (because
it is never under attack?), that
may look strange too…
Use a time-out scheme (a
stop timer) to reset the
previous action, and initiate a
new random choice
How about randomizing the
timer as well…? 

Combining DT with FSM




We can replace transitions from a state
(to another state) with a DT
The leaves are the actual transitions to
new states

Combining DT with FSM





Note: If it cannot see the player, the transition
(via the DT) ends, and no new state is reached
Otherwise, it tests for the player proximity and
makes a transition to the “Raise Alarm” or
“Defend” states

Combining DT with FSM







This FSM implements the same thing (as prev. slide),
but without the DT nodes
Now, we have two complex conditions that need to be
evaluated
If the condition involved a time-consuming test (such
as LoS), then adding the DT would be much more
efficient

Rule-based AI






Generally refer to AI systems that
consist of a set of if-then (or if-else) style
rules
Technically, FSMs and DTs are types of
rule-based systems. Rules are used to
handle state transitions and decision
nodes
But more specifically, “rule-based
systems” are also commonly referred
to its usage in expert systems

Rule-based Expert Systems


Common usages/applications in real life:




Medical diagnosis, fraud protection, etc.

Advantage:




Rule-based systems can mimic the way
people think and reason given a set of
known facts and knowledge about a
particular domain
Fairly easy to program and manage (in a
computer application)

Rule-based Systems for
Games


Rule-based systems are useful in
GAMES…






Because knowledge encoded in rules is
modular
Rules can be encoded in any order 
flexible for coding and modifying the
system at a later time

Let’s look at a game example that can
use a rule-based system…

Example: Medieval RTS
game


Technology Tree




An important
element in RTS
games
Shows the links
between units to
train, facilities to
build and resources
to harvest in order to
expand influence in
game

Example: Medieval RTS
game


Aim: Enable the computer opponent to keep
track of player’s current state of technology






By collection of knowledge of the player from
the world state (resources, units, facilities)
“Cheating” and having perfect knowledge will
not give fair and realistic AI behaviors

How to assess state of technology?




Sending scouts to collect information and
observe (just like what human players do)
Make inferences via a rule-based system

Rule-based System Basics


Two main components






Working memory – Stores known facts and
assertions made by the rules
Rules memory – Contains if-then style rules that
operate over the facts stored in working
memory

As rules as triggered or fired,




they can trigger some kind of action (such as in
FSM and DT), or
they can modify contents of the working
memory by adding new information

Rule-based System Basics


Sample working memory
enum TMemoryValue{Yes, No, Maybe, Unknown};
TMemoryValue Peasants;
TMemoryValue Woodcutter;
TMemoryValue Stonemason;
TMemoryValue Blacksmith;
TMemoryValue Barracks;
......



Contains elements that can take any one of the 4 values
Idea: Keep track of the current “perception” of the
player’s state of technology

Rule-based System Basics






Computer can gather facts by sending out scouts to
see if a player has built a temple (for e.g.) Temple
element will be set to Yes.
In another way, we can use a set of if-then style
rules to infer the technology that the player has
(before a scout confirms it)
Example “temple” rule:
if(Woodcutter == Yes && Stonemason == Yes &&
Temple == Unknown)
Temple = Maybe

Rule-based System Basics


Inference can work the other way as well




If the player has been observed to have a priest, it can
be inferred that the player also must have a temple,
therefore, must have a barracks, a woodcutter, and a
stonemason

Example “priest” rule:
if(Priest == Yes) {
Temple = Yes;
Barracks = Yes;
Woodcutter= Yes;
Stonemason= Yes;
}

Rule-based System Basics




You can have many more rules for this technology
tree (More examples in textbook)
The main scheme: To write this set of rules and
execute them continuously during the game (at each
iteration of the game loop or in fixed intervals)




Maintain an up-to-date picture of the player’s
technology capabilities
This knowledge can be used to decide when to
attack/defend, what to build next and make other
tactical/strategic plans

Rule-based System Basics


In reality, developers to not build rulebased systems using actual hard-coded ifstatements







Some types of inferences are hard to achieve
Very inflexible as the rules need to be handcrafted one
by one to strike a good balance among them
Definitely not efficient for future modifications!

Developers often use scripting languages or
shells to create and modify rules without
having to change the source code and

Inference in Rule-based
Systems


Forward Chaining








Match rules (if-parts) to facts in working
memory
If a rule matches, it is fired and its thenpart is executed
Potentially, if more than one rule matches
the given set of facts, conflict resolution
phase required to figure out which rule to
fire
Conflict resolution: Many possible ways –
(1) first matched rule, (2) random rule, (3)
largest weighted rule

Inference in Rule-based
Systems


Forward Chaining


Example
 If

working memory indicates Peasants = Yes
and Woodcutter = Unknown, the rule:
if(Peasants == Yes && Woodcutter == Unknown)
Woodcutter = Maybe;

, matches. So, this rule can potentially be
fired
(depending on which other rules are also
matched)

Inference in Rule-based
Systems


Backward Chaining



Opposite of forward chaining
Match the then-parts, start with
outcome/goal, and figure out which rules
must be fired to arrive at the outcome/goal
 E.g.

Outcome is that the player has Calvary
units. Work backwards – player must have
Blacksmith to have Calvary, player must have
Barracks to have Blacksmith, player must have
Woodcutter to have Barracks and so on.

Inference in Rule-based
Systems


Backward Chaining






So, all the rules required to reach the
outcome are all fired.
Work the logic backward up the technology
tree to the goal
In practice, backward chaining is recursive
and more difficult to implement than
forward chaining

Optimization of RBS


For small rule sets,




For large-scale rule-based systems,
optimization is essential




Forward chaining is fast

Many rules may be matched for firing, so
conflict resolution phase must be optimized 
Rete Algorithm

Write your own scripting language
(instead of 3rd party ones) to reduce
implementation overhead