Posted by: kaising | March 5, 2010

Design Overview – focus on Training Mode

Training Mode (Solo)

Train your creature to:

1. Obey more during training

Locomotion training
     Creatures can easily get distracted during missions if you have not trained them.
     Use items to reward them for coming to the cursor, jumping for certain inputs, etc.
          Perhaps do some ‘classical conditioning’: environment = the command you say;
          also + something you give them to do the action automatically
          Have some indication of how well they will respond?
     In terms of decision tree data
          Conditions = stimulus (key input) + physical environment features + (possibly) mood/creature state/nature
          forcer = resulting action (% chance of doing it increases with repetitions; ‘weight’ attached to that entry in data table)

Item use can improve training… make them more sensitive to it (i.e. more weight to that entry in the table…)

2. Be more powerful in missions/battles

Certain moves can be learned by accomplishing specific goals
     e.g. a fairly easy burning forest level will have puzzles that can be solved to learn weak fire moves
     Learning more advanced moves may have puzzles that require less advanced moves.
          So you can’t just have a new creature with super useful moves right away.
          Only let them take one creature out for training at a time?
     The number of moves a creature is allowed to remember is limited.
          If you want multiple combinations of moves on a creatures, or more than x moves total even, you must raise multiple creatures.
Elemental alignment is affected by the alignment of the training ground
     e.g. a creature trained only in fire and light training grounds may be increasingly strong in fire and light elements, but increasingly weak against water and dark elements.
     For simplicity, have three elements that are each weak against the preceding and strong against the one following it here:
          Air (electrifies water) > Water (douses fire) > Fire (burns oxygen)

Training mode employs machine learning, invests the player in their creatures as they prepare them for combat/missions, and encourages social interaction.

Posted by: kaising | February 28, 2010

Main components:

Training Mode (Solo)
Train your creature to:

1. Obey more during training

2. Be more powerful in missions/battles

Training mode employs machine learning, invests the player in their creatures as they prepare them for combat/missions, and encourages social interaction.

Mission Mode (Solo or Co-op)
This refers to goal-oriented missions, the main features of which are:
1. Public Trophies / Experience (Player growth)
2. Charity objectives
3. Items

Mission mode accomplishments are what advance the player, and also allow charity objectives to be met.

Player Combat & Trade Mode (Co-op)
Players have a variety of standard social gaming options:
1. Trade creatures and/or items
2. Gift items to each other
3. Fight to the death!

Player Combat & Trade Mode is a standard social interaction mode, allowing collaboration and combat.
Interesting take on a card game that can be played with only a few cards, no intentionally bad cards (perhaps relates to a game with a few creatures…?)

Posted by: kaising | February 26, 2010

High-Level Concept / brainstorming

High-level concept: Pokemon-style fantasy, but with actual training and some battle interactivity, and charity-based missions
Consequent features: Greater focus on training one creature at a time, trading gets you something you couldn’t just catch yourself (might not have thought to train it that way, etc.)

Player Goals:
Train creatures through item use and reinforcement
In a sandboxy environment, with random events that offer training opportunities
Items come from level exploration? (reason to replay…)

Time-based sensitivities:
Limit their playtime, keep them wanting more – kick them off right before they accomplish something, and when they return and finish start them on something else.

Creatures need to rest energy / heal wounds between missions
Only let them gain a new creature every so often (luck based?)
Limit trades per week?

Rewards and scheduling:
random encounters?

Posted by: kaising | February 25, 2010

Task 2: Investigate Facebook SDK and Flash Integration

General Infrastructure of a Facebook Game

See chart in Dummies book.
Actually one of the few readily available diagrams of the whole thing.
Useful diagram of callbacks:

Option 0: Adobe Flex Builder

add Developer App to your Facebook account
create a new app
  Application Type = Desktop (launch+debug in Flex Builder), change back later
  API key + Application secret
Adobe Flex Builder
  new one
  install Facebook libraries from Google code page (Adobe dev center)
  Design –> login button drag & drop
  give id=”” in source view
  add a script tag and functions
  login() facebookSession = new FacebookSessionUtil (give api key, etc.)
  don’t include secret in code normally
  deply app –> remove secret
  event listener for waiting for login, connect event

Option 1: J2Play

get friends list, chat, etc. for free
  log into the J2play wiki, log into admin, add game
  url of flash game (already on a server)
  give it to the J2Play site
  tell it which site you want to add it to – it gives you instructions
  need api secret etc. hrm.
add application as normal to Facebook
  make a game
  give API and secret to J2Play
  look at callback URL on facebook — need to sew this into the application
  now can have facebook as a window to your game, with chat, etc.
add toolkit
  go back to J2Play

Option 2: By Hand with PHP

Create new Facebook app via Facebook dev.

“Callback URL: Very important, it’s the URL of the application on your server. That’s the place where you will write your application

Canvas Page URL: Another very important field… this is the URL of your Facebook application… the one you will share. It’s very importat than you choose an URL long at least 7 chars”

Use FBML checked
Application type = website

use provided php code on your server:


Decision tree
  a tree-like model of decisions and consequences, including chance outcomes, costs, and utility
  often constructed by hand
  used in formal decision analysis

Decision tree learning
  decision tree used to map attributes of an item to a classification
  Data mining – extracting patterns from data
  Resulting tree can be an input for decision making process
  aka classification tree, regression tree

Forming decision trees overview
  successive splits based on the current ‘best’ variable
  best may be how well it divides the branch into groups with the same values for that variable

Gini impurity
  measure of how often a random element from the set would be incorrectly labeled –
  sum of P(item chosen)*P(mistake categorizing it)

Benefits of decision trees
  use is easily explainable
  minimal required data priming
  numerical and categorical data can be dealt with
  white box model – categorization method can be translated to Boolean logic
    unlike neural network, which makes a black box
  statistical tests can validate its reliability
  robust – even if assumptions are violated somewhat by true model that generated the data,
    performance can still be good
  efficient scaling – can process a large amount of data relatively quickly

  very simplistic – may miss more complex relationships between attributes
  specifically, only considers one attribute at a time

Algorithm and Game Design

  Use straight-up ID3 to begin with, possibly adding optimizations from C4.5 after.
  From here:
    See below for the attributes to consider.

How do we get the data set?
  Categorize positive and negative feedback from the player.
    This is the feature to categorize on, the value judgment.
  Attributes are the context when the feedback is given.
    A context consists of: action, creature state, target, environment state.
    This is where it must be decided whether the creatures are Black & White – like sims,
      possibly like programmable ‘robots’ to train and then send on adventures,
      or Pokemon-like combatants to direct in battle.
     creature states
       Sim: hungerLevel, aggression,
       Combatant: health, item currently carried, think of some other pet-like things
     environment states
      Sim or Combatant: weather, terrain, night/day
       Sim: attack, pick up, drop
       Combatant: take the Pokemon approach, and have ‘abilities’.
       Sim: others, self, nonliving items
       Combatant: automatic, based on the action you tell it to do.

  Possible compromise: Having stats determined by training, and abilities gained with levels,
    where the ability you gain is based on how you’ve trained it.
    This would allow for training to have a huge impact, but to still have turn-based battle.

Useful Links
   Useful example-based explanation of ID3, entropy formula, and some caveats for actual use.
   ID3 and C4.5 with examples.
   Has a good number of useful links.
  Powerpoint slides, somewhat useful diagrams.

  A good starting point / overview.

  Useful resource for Quinlan’s algorithms; 5.0 is commercial / for sale.

Posted by: kaising | January 25, 2010

Black and White AI / brainstorming

Informal notes and quotes from:
J. Wexler’s “Artificial Intelligence in Games: A look at the smarts behind Lionhead Studio’s “Black and White” and where it will go in the future”, available here.

Key areas to look into:
symbolic attribute-value pairs
e.g. strength of obstructions to walking
rules-based AI (situational calculus) – basic knowledge of objects
decision trees – beliefs about object categories
perceptrons –> desires

“After a creature completes an action to satisfy a certain desire it will look at how well that desire was satisfied
and adjust its internal weight structure accordingly”
e.g. hunger desire – know to eat, but not what

“Richard Evans writes, “A decision tree is built by looking at the attributes which best
divide the learning episodes into groups with similar feedback values. The best
decision tree is the one that minimizes entropy, a measure of how disordered the
feedbacks are. The algorithm used to dynamically construct decision-trees to
minimize entropy is based on (Ross) Quinlan’s ID3 system.””

Posted by: kaising | January 17, 2010

Independent Study Proposal – revised

Independent Study Proposal
(Revised to add Black-and-White-style AI)

Goal: An attractive prototype that demonstrates the basic elements of an original Facebook game.

Having a visually interesting, ‘feature-complete’, and relatively polished client-side demo that could be presented to recruiters will take priority over having the game actually working on Facebook.

Tasks and anticipated time frames:

Task 0: Formulate Initial Design (January)
0.1: Study Actionscript 3.0
0.2: Check out other virtual pets, order a copy of Black & White
0.3: Initial high-level design, draft up proposal

Task 1: Investigate Decision Trees and Quinlan’s ID3 AI system (February 1 – February 7)
0.1: Research Decision Trees
0.2: Research Quinlan’s ID3 AI system
0.3: Diagram out an example of creating and using a decision tree,
in the context of the game
0.4: Design an algorithm for the game to use

Task 2: Investigate Facebook SDK (February 8 – February 20)
0.1: Read through tutorials
0.2: Implement or find source code for a bare-bones application
e.g. sending friends gifts, etc.
0.3: Implement or find source code for incorporating Flash into an application
0.4: Decide on a language to use (if not ActionScript 3.0)

Task 3: Finalize Game Design (February 21 – February 28)
0.1: Design Document, a la CIS 564 and Stone Librande’s class,
Including specific details on the sample mission, specific behaviors, etc.
0.2: Digital concept art
0.3: Get lots of feedback from other people, possibly send to Maxis people,
redesign as needed

Task 4: Implement core client-side code (March 1 – March 20)
0.1: Implement decision trees with Quinlan’s ID3 system abstractly
0.2: Adapt code for the game, decide on specific behaviors and how to train them
0.3: Implement a test creature
0.4: Design and setup basic UI

Task 5: Art Assets (March 21 – March 31)
0.1: Integrate creature ‘model’
0.2: Background art
0.3: Make UI look ok

Task 6: Client-side testing and redesign (April 1 – April 15)
0.1: Get at least three people to play around with it,
reworking the game between each
0.2: Test out a player-vs-player battle with real people, on the same machine
0.3: Compare again to existing Facebook games, and what makes them addictive

Task 7: Implementing a specific mission as a demo (April 16 – April 30)
0.1: Design all specifics of the mission
0.2: Implement a framework to create missions from
0.3: Implement the specific mission
0.4: More playtesting and reiteration

Task 8: Facebook integration (May)
(depending on the findings of the Facebook API investigation, this may start sooner)

Current Design:

Concept: Players each raise one or more creatures, and use them to battle each other for fun and to benefit charitable causes. Raising a creature involves providing positive and negative reinforcement to a system implemented with decision trees. Quinlan’s ID3 system may be used to make the trees as organized as possible (reducing entropy produces better AI).

Conflict: Training creatures is the core task; these customized pets are then used in standard leveling-up missions, player vs. player asynchronous battles, charity missions. Mostly using the trained abilities and resource management, but perhaps some real-time minigames as well.

Incentive: Pokemon-style competition and creature collecting/nurturing appeals to a wide audience. The point of this game is to take the resources this attracts and combine and direct them at positive causes.

Key features: The main technological feature is that the creatures can be trained.
Combat takes elemental alignment and various stats/special abilities of the creatures into account.
Players will be able to trade creatures with other players, or raise them from eggs → hatchling → adult → specialized adult.

If this were turned into a full game, bonus missions, possibly requiring a band of active players, could be released – with holiday themes, etc. Ideally charity missions could be launched as well, where the players battle some real-life issue and all the real money put into the game for that mission goes to actually solving it.

Posted by: kaising | October 3, 2009

board game: brainstorming on win conditions

Win conditions are arguably the single most influential factor in how play should be balanced, so I wanted to work this out before brainstorming on the particulars of combat.

Determining fair win conditions and then balancing combat accordingly is non-trivial, due to the asymmetry of attacker vs. defender. The main exemplary tower defense games I’ve played have been one-player, and some tower defense games continue until the player loses to the computer. It doesn’t need to be equally fair for both sides in that case, but here it does. I expect this part will require a good amount of playtesting before it is balanced enough to be considered actually playable.

Aside from balance/fairness between the players, I also want the game to end at a tense point. Ending at an exciting moment seems helpful in creating a favorable impression of an activity. Also, I want there to be some indication of how far the game has progressed and how close it is to the tense ending, so that there is a gradually greater incentive to keep playing as the game becomes more suspenseful. I’m not sure if all of these things will be accomplished in this roughly two-week prototype, but they are worth considering in this context for educational reasons regardless. Below are some of the win conditions I’ve considered.

Defender: Survive X turns, i.e. keep the attacker’s pieces from reaching the center space.
Attacker: Have a piece reach the center space in X turns.

This idea follows naturally from the general flow of many digital tower defense games, where the player (defender) must keep the attackers away for a fixed amount of time (or a given number of enemies). Having a fixed number of turns also informs the players how close they are to the end of the game.

Defender: Win 3+ out of 5 rounds.
Attacker: Win 3+ out of 5 rounds.

Where a round is an attacker planning out who will go where, possibly inserting some ability for them to tweak their plan in a pre-planned way – and then the defender acting turn by turn to block the ‘wave’ of incoming creatures.  This would mean that the rounds would have to be very fast, so that the attacker remains engaged / invested despite little to no interaction for this period.  The basic difference between this idea with extremely short ‘waves’ and the one above is that this one would wipe the board between ‘waves’/turns, whereas the other one would have persistant board placement.

Defender:  Survive until there is no more mana.
Attacker:  Reach the center of the board before the game runs out of mana.

This system would feature a shared pool of dice; the attacker goes first, and rolls x dice.  The sum is how much mana he has to summon and move creatures.  Then the defender takes the same number x dice and rolls them – this sum is how much mana he has to summon defensive creatures and launch attacks on incoming attackers.

These sets of win conditions are very similar; it is mainly the implied combat and turn-taking mechanic that differentiates them.  I think I prefer the style that the third set would enforce.

Posted by: kaising | October 2, 2009

board game: physicality and visuals

I’m moderately accustomed to the limitations of implementing a game design in code, but less so to implementing one physically in the form of a dice and board game.  The two main issues I think need to be addressed are 1. making a board and pieces that are decently attractive (i.e. not so rough as to be distracting from play) and 2. having the physical movements and mental calculations of the player be reasonable.

The board will start off as a hand-drawn version on printer paper; the form will be eight radii emanating from the center.  Spaces will be either along the radii, where they intersect with concentric circles, or be in the outwardly-increasing-in-size spaces that are created by the radii and the concentric circles.  Testing will determine which seems more likely to result in neat, clear representations of the state of the game.  I’d like to have the final board material eventually be icy-looking Lucite or nice dark wood or something equally clean but attractive.  The dice should go reasonably well with the board and art style of the pieces.

The pieces will need to contain a decent amount of individual information, as I do not want players to have to look up the stats of a given piece in a manual during play, even when they are new to the game.  I was initially thinking of clear damage-counters as pieces, with color-coded numbers underneath them to indicate whatever values are needed.  I think colored glass on Lucite is very nice looking.  However, re-printable cards would be more convenient to create and revise, and also allow more art.  This would allow more of a theme, e.g. dragons.

I think some artwork will really help here.  One very important thing I learned at work over the summer was that visuals are still very important for early prototypes.  Interesting concepts can be overlooked if the presentation is poor, and pretty artwork draws people in (and thus can result in more testers / feedback).  I’m planning on using some artwork from highschool, including some of the images I photoshopped for a card game prototype I made over the summer.  Eight pieces of art seems about right…

Posted by: kaising | October 1, 2009

board game: brainstorming on scaling and reward schedules

Concepts that still need to be incorporated into my board game design include the related issues of reward schedules and scaling.  As a game progresses, the subjective magnitude of the game should of course scale by increasing various components – including difficulty of conflict,  the value of rewards, etc. as was discussed in class today.  In my board game, I think this could be implemented mainly through the killing/defending interactions between pieces, which also ties into the reward/incentive schedule.  I would like to keep the game fairly simple and focused on interactions between attacking pieces and defending pieces that are based on placement – with no spell casting , complex terrain effects, or other mechanics external to these central pieces.

It seems that a successful reward/incentive schedule has different types of rewards, of varied magnitude, that generally feel (to the player) like they increase in value, giving a sense of progress throughout the game and constantly encouraging the player with an opportunity at a reward that seems really great relative to what they are accustomed to in the game (the “just a little further and I can get something even greater than I already have” mentality that can keep people up all night).  Asymmetric player roles makes this require a bit more work.  For now, I’m going to assume that the defender will have more durable and fewer defending creatures, and the attacker will have more fragile but more plentiful creatures, as is common in existing tower defense games like Plants vs. Zombies (so the opposite of a lone ‘hero’ or two attacking a fortress sending out many cheap minions).

For the defender, frequent rewards could be killing incoming opponent creatures.  The magnitude/threat of these creatures should scale, thus scaling the relief (reward) the defender feels as they destroy them.  Or, equivalently, there can be greater numbers of attacking creatures, and the defender must take out larger numbers of them each turn.  Setting down increasingly more powerful (and more persistent) creatures as defense can be a less common but greater reward than defeating creatures.  The attacker’s reward system will be the opposite. Being able to place down expendable attacking creatures and advancing them will be a smaller reward (although the rate of adding and/or the strength of them should be increasing).  Larger and less frequent accomplishments are taking down one of the defender’s creatures, which the defender cannot replenish as often as the attacker.

This means that I will also have to work out an interaction system between the attacker’s pieces and the defender’s pieces that 1. allows the defender’s pieces to destroy more of the attacker’s pieces (probably through the use of projectiles/range attacks) and 2. allows pieces on both sides to become stronger as time progresses.  I’m more concerned about the latter need; the simpler solution just being able to have more of the same pieces isn’t as exciting as gaining new abilities (maybe it could be made more interesting by having more attacking creatures, and the defenders having attacks that take out more of them – which effectively stronger attackers and stronger defenders).

There should also be a currency system that enforces the tendency for the attacker’s pieces to be cheaper to create than the defender’s pieces.  I think I may have the currency be based on die rolls, as dice are required to be the central mechanic of this board game assignment.

« Newer Posts - Older Posts »