The intelligent game designer: Game design as a new domain for automated discovery


Published on

Designing video games is commonly understood to be a creative task,
drawing on a designer's talent, inspiration, and personal experience.
The last ten years have seen multiple calls from the design community to
produce reusable knowledge about the structure of games and the design
process itself. These designers would like to establish a standardized
language and libraries of design patterns so that the next generation of
designers can benefit from the best of past generations. The
realization of such a move can be read as a transition from thinking
about game design as a playable-artifact creation process to a science
of play in which we might see the designer's goal as discovering new
gameplay structures and their production of concrete games as a side
effect of this process.

Thirty years ago, a similar-yet-disconnected thread of research in
artificial intelligence was just being born. First marked by Doug
Lenat's AM (an “automated mathematician”), discovery systems aim to
automatically produce new and interesting knowledge. Such systems
contrast sharply with the then-popular expert systems which applied
fixed libraries of “expert” knowledge to various tasks. Discovery
systems, which have commonly operated in the domains of natural science
and mathematics, are now seen as distant ancestors of contemporary,
statistical machine learning techniques which find extensive application
in a wide array of industries. Contrary to the current emphasis on the
optimal learning statistical descriptions of data, some recent
developments in machine learning, specifically combined abductive and
inductive logic learning systems, are bringing the production and
revision of structured, symbolic knowledge back into focus.
Simultaneous research in computational creativity is making inroads into
modeling the creative process and the production of creative artifacts.

This is the question I aim to answer: If we squint a bit to see game
design as the science-of-play that some designers imagine it to be, can
we build a discovery system that really works in the domain of game
design? Can we build an intelligent game designer?

In my thesis proposal I lay out a plan to build an intelligent game
designer that learns from the process of game design, including the
observation of human players, and exports newly discovered design
knowledge. This will require an operationalization of game design as an
automatable, scientific process and a detailed re-synthesis of the
creative design of expressive artifacts as a knowledge-seeking effort.

  • Very cool idea.Thank for your presentation with inovative ideas.
    Are you sure you want to  Yes  No
    Your message goes here
  • Really interesting idea!! Good luck.
    Are you sure you want to  Yes  No
    Your message goes here
  • Continue the discussion here:
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Any time a machine does something creative or intelligent we quickly redefine the activity or definitions of intelligence/creativity so that “machines still aren't creative”.

    But what about game design?
    At the intersection of so many different fields, how much would we have to write off so that machines still aren't creative?

    How far can we push it?
  • A challenge! (and an inspiration)

    We’ll meet this quote again towards the end.
  • Big words, details soon.

    Sounds unrealistic?
  • Why me? Personal interests and experience.

    Why now? New developments in logic programming and games research at EIS.

    Also helps: so much of game design is mediated by computers, no hardware required (beyond human players to consume)

    Ok, now for the real proposal…
  • Experience sharing: You, the human designer, apply the knowledge yourself

    Code sharing: You trust the computer to apply little chunks of the knowledge on your behalf

    Nearly-automated: System applies nearly all of the knowledge on its own and can contribute some back to you. My project lives here
  • SML: a bit too sterile and domain-independent to help my project.

    Disco: discovering symbolic knowledge; do produce experimental artifacts, but nothing you’d put in a museum

    Art: produce amazing artifacts, but don’t roll this into a knowledge-production effort

    Mash together: Learning is focus (focuses on audience reactions), artifact creation as a side-effect
  • Unpack these questions in next few slides

    Expressive domains: visual art, music composition, etc.
  • As opposed to “games” in “mathematical game theory”

    What does a game look like that fits these?
  • Here’s a real game that satisfies those constraints. (I didn’t make this one)

  • What is a non-intelligent game designer? Maybe just a generator that doesn’t learn.

    Knowledge comes from actions, not gradient-descent external goodness judgments (as you might in a IGA).

    It has to still look like a game designer when you look under the hood.

  • In machine composition of musical pieces, machine is only expected to produce MIDI data.
    Raw composition can be played directly, but a skilled human orchestra is needed to bring out the true nature of the composition to an uninitiated audience.
  • An answer to the high-level question should entail answers to the low-level questions.
  • What do all of the game design words mean in discovery?
  • Look at the requirements for answering the questions
  • Fairly standard layout
  • These topics are covered in the doc. I’ll just highlight a few examples in each category.
  • My designers should explore high-level designs, by producing computational prototypes and testing these by itself and its human test subjects (“friends”).

    Unfortunately, game design textbooks aren’t very clear about how these processes work, but I’m not the only one to complain here.
  • Read the quote. Sorta sounds like the Buchanan quote from the preface.

    Other well-known calls for more structure are listed, proposing…
    formal languages,
    collections of rules,
    and libraries of design patterns.
  • ALL: create, share and apply informal game design knowledge
    Tracing the evolution of game mechanics in match-three games through history

    Design knowledge discussed in game studies are on-level for consumption by human designers, but machines can’t use it.

    If we want code-level knowledge, we have to look somewhere else…
  • ALL: programs that work with code-level game design knowledge to some degree, producing games or parts of games

    (focus some EIS research, Nelson)
    Built a system that reasons over thematic references using a common sense knowledge base to come up with re-skinnings of games that make sense.

    Game design is about more than generating games; games must be played.
  • GGP in general:
    Ability to play arbitrary games (automated play testing?)
    Formal logical representations (not friendly, but still proves the tech behind them is working)
  • Strongly related: I’ve got a designer that could use some help prototyping its rule systems.
    However my designer also has to do a lot more (that knowledge production stuff, you know)
  • I have more than a distant, academic understanding of computer games.

    Yup, I’ve made some games myself.
  • Game designers don’t general keep notebooks or publish knowledge the way scientists have been doing for hundreds of years. So turning game design into an automated discovery domain will require a extrapolation from my own experience.

    S&L provide a rich vocabulary for describing the scientific discovery process.

  • There are a lot of systems, just a sampling here.
    GT worked in graph theory, assembling graph construction rules and conjecturing properties of all graphs built by those rules.

    Modern components are tools that perform some kind of knowledge production, but they don’t do it under the discovery banner – I’m gunna use these to my own discovery system.

    Enough discovery, how about creativity?
  • We’ll see a system by Rob Saunders in a second. His theory relates novelty of artifacts to expectations of individuals in a society.

    Too many different models of creativity to keep track of, so I made my own, but more on that later.
  • These are all really cool systems that produce outputs that are quite interesting to look at; but none of them really have a symbolic understanding of audience reactions.

    In DCM several little agents share genetic art pieces, each agent developing personal aesthetics based on experience of their own work and others.

    Ok, enough related work…
  • Next up: my own research experience, my prior work
  • TM generates abstract art in response to sensed activity in a home. Designed for long-term (two-month) viewing experiences – it lives with you.

    Context-free design grammars provided detailed control over local geometric constraints in images.
    Image analysis was required to understand and control global/emergent/gestalt compositional properties.

    Learning a model of the environment as a way to keep images relevant suggested to me there might be a deeper connection between learning and expressive domains.

    Next: research involving games
  • I created the BIPED system which aims to provide equal support for machine and human play testing of light-weight prototypes.

    Designer describes game in our declarative programming language, and the system effectively compiles it into a formal rule system and a human playable prototype with sound and graphics.

    The system provides a means to pose formal questions to the formal rule system and allow un-assisted play of the playable artifacts.

    Fundamentally, its all about harvesting play traces from formally described games.
  • Drillbot 6000: demake of the Flash game “Motherload” by Xgen Studios.

    UI: yellow tokens sit on green spaces connected by gray lines while music plays and timers tick down.

    Box on right is a “play trace” generated by the system. Designer can apply constraints and look for traces that exhibit those or prove that none exist.
    Next: details of the logical representation for games
  • Fragment of the game defining bit of game state, the position of the robot, parameterized by all positions on the map.
    Movement events (up/down).
    Trigger logic (moving changes position).
    Initial conditions.
  • UI bindings map state and events in the abstract game world to the board-game-like interface.

    A space for every place.
    A token for the robot (which doesn’t actually exist at the rule level but has a position that is easy to visualize).
  • Great stuff in exchange for encoding your rules in a logical format.

    Highlight induction results: Symbolic traces are easy to use in ILP to come up with rules that summarize how the player acts in the game world.
  • I created a basic rule set generator for a subset of the language used in BIPED.

    Outputs are pretty boring, but it proves the technology works (building game at an assembly-language level). Now it just needs some better definitions to work with.

    Get higher-level constructs through discovery!
  • I’ve done some non-automated/manual discovery in game design myself, at the same level I want my designer to work.

    The design pattern is a slightly abstracted view of the code that was used in a particular game. Because it depends on symbolic constructs, this design pattern can be used by machines.

    I created this pattern, but I want my designer to discover more by analyzing old games and using tentative design patterns to build new ones.
  • At this point I have…

    An expressive logical representation for games
    A rich tool for getting feedback on the design game prototypes.
    A proof-of-concept generator.

    A reference for how I, personally, go about game design using these tools. Now to string it all together!
  • A systems level above the symbol/program level.

    Systems are agents composed of goals, actions, and bodies of knowledge. They follow a principle of rationality that says “if an agent has knowledge that one if its actions will lead to one of its goals, it will select that action”.

    In expressive domains like game design, the designer’s actions allow it to manipulate artifacts that interact with a local environment, independent of the agent.
  • Meta-theory helps us pull apart a game designer’s knowledge.

    Game level: deals with how games are constructed and the complete space of logical possibilities they allow

    Play level: Introduces instances of play (game-and-player pairings), allows reduction of possiblities to only those that are reasonable for that player to consider

    Design level: Knowledge that relates game and play level knowledge to designer actions and intentions
  • Actions are organized by the kind of knowledge they produce.

    If design-level actions produce design-level actions, then maybe designers do them because their goal is to discovery new design-level knowledge.

    This is the main conjecture of my KLAoGD
  • Much more nuanced details on this conjecture on the document.

    Important: relates knowledge-production to creativity through the sense of rationality in the knowledge level.

    This last conjecture is exactly the motivation behind my whole “intelligent game designer” project!
  • Design tools are all of the bits of software that gets used in the design/discovery process but doesn’t really embody a theory of design or discovery. Whereas the core discoverer is building data structures that literally refer to games and players: things in the domain of game design.

  • Operational knowledge: tells the system how to go about doing discovery (including experimental design, prediction, anomaly detection, theory revision, etc.) and interface with its surroundings
    Artifact library: catalog of every game or play instance (or any kind of trace) that it has ever seen
    Design theory: accumulated knowledge which has been discovered from experience
    Discovery notebook: holds knowledge pertaining to partially completed operations, partially formed theories, and agenda details
  • A production systems is a flexible architecture for AI systems that makes it easy to organize a system’s symbol-level implementation according to its knowledge-level view – remove direct access to control structures like loops in exchange for being able to plug in new modules declarative and procedural knowledge.

  • The mapping is far to detailed to cover here. Overview in the proposal doc.
  • Tentative representation schemes:

    Games know how they were constructed.

    Player models can may be parameterized by game elements, so the rules that define a player might have instructions for producing certain views on the state that aren’t part of the rules. Also, internal state and events.

    Play instances are pairings of game and player representations, but there may be some choices to be made in the pairing (such as which avatar the player thinks they are controlling), so these are recorded as well.
  • By building a richer design theory, the system can build larger, coherent games in fewer steps. Good design patterns will provide the base for accurate predictions of trace contents whereas bad patterns won’t.
  • Now we’ve seen how I’ll implement the knowledge the system might have, what about those actions? The hat and the claw?
  • Both kinds of actions have been prototyped in my past experience developing logical games and extracting patterns from them, they need to be programmed as production rules now.

    Constructive design actions map to grammar-like implementation like my current generator.
    Trace harvesting has been proven in BIPED.

    Conjecturing and new knowledge will be a mix of heuristic and inductive techniques (some will use ILP)
    Explaining old artifacts in new terms an abduction process (maps to ALP)
    Verification and proof is a simple matter of deduction in standard LP
  • Most of these tools exist, but they need an interface in terms of the production rules.

    Not dependent on Mark’s research, but collaboration is nice.

    That’s the whole system!
  • Might sound unrealistic at a high level, but I have a detailed schedule past the end of the talk if you have questions.
  • Epilogue: one last thing before I finish
  • Knowledge built directly from design experience

    Assembly of new mechanics, player constructs, and trace predictor the system will systematically change its assumptions.

    If I can explain creative production in expressive domains in terms of discovery, then generic discovery components should make for the start of cross-domain creative discovery systems.
  • And that’s my thesis. Proposed.
  • The intelligent game designer: Game design as a new domain for automated discovery

    1. expressiveintelligencestudio UC Santa Cruz The Intelligent Game Designer: Game Design as a New Domain for Automated Discovery 29 July 2009 Adam M. Smith
    2. expressiveintelligencestudio UC Santa Cruz PREFACE
    3. expressiveintelligencestudio UC Santa Cruz Preface  Game design is clearly a creative activity.  I claim a machine can do it.
    4. expressiveintelligencestudio UC Santa Cruz Preface  Bruce Buchanan (in AAAI-2000 Presidential Address) says of existing creative systems…  they do not accumulate experience, and thus, cannot reason about it;  they work within fixed frameworks including fixed assumptions, and criteria of success;  they lack the means to transfer concepts and methods from one domain to another.
    5. expressiveintelligencestudio UC Santa Cruz Preface  My “intelligent game designer” is all about turning experience into communicable knowledge (producing games along the way).  But how?  Operationalize game design as an automatable scientific process.  Re-conceptualize creative design of expressive artifacts knowledge-seeking effort.
    6. expressiveintelligencestudio UC Santa Cruz Why is this realistic?  Why me?  Game development  Generative art  Why now?  Fresh tools  Abductive/Inductive logic learning  Automated debugging for logic programs  Fresh formalisms for games  Event-calculus  Recombinable mechanics
    7. expressiveintelligencestudio UC Santa Cruz INTRODUCTION Context Research Questions Proposal Outline
    8. expressiveintelligencestudio UC Santa Cruz Perspectives in Game Design  Experience sharing (informal knowledge, words)  Textbooks, forum posts, and technical talks  Code Sharing (formal knowledge, code)  Procedural content generation, drama management, game engines, and miscellaneous middleware  Nearly-automated Systems  Peer or design buddy?
    9. expressiveintelligencestudio UC Santa Cruz Perspectives in Learning / Creativity  Statistical ML / Computational Intelligence  Structured data in, predictive model out  Discovery systems  Data must be drawn out by experiment  Predictions should be consistent with rich, domain- specific, background knowledge  Creative art systems  Artifacts are like exquisite experiments, results ignored  Leverage highly nuanced audience model, often fixed  Domain-aware, creative discovery systems  Learning is the focus, artifact creation as side-effect
    10. expressiveintelligencestudio UC Santa Cruz Research Questions  Function:  How does an intelligent game designer function?  Implication:  What does such a system imply for the relationship between discovery and expressive domains?
    11. expressiveintelligencestudio UC Santa Cruz Function: “games”  Recognizable as “video games”  Focusing assumptions:  Single-player  Real-time  Mechanics-heavy  Abstracted representation  Minimal setting
    12. expressiveintelligencestudio UC Santa Cruz Example “game”: Dyson “Remotely command semi-autonomous self-replicating mining machines to take over an entire asteroid belt.”  Single-player  Real-time  Mechanics-heavy  Abstracted representation  Minimal setting
    13. expressiveintelligencestudio UC Santa Cruz Function: “intelligent”  Learning from experience  Knowledge production as a function of past design and discovery actions  Documentation as proof
    14. expressiveintelligencestudio UC Santa Cruz Function: “game design”  Game design: the informed construction of rules systems and supporting logic required to produce playable games  OK if playable games are a little rough, some human polish might be needed
    15. expressiveintelligencestudio UC Santa Cruz Implications: Game Design  What does _____ mean in game design?  Discovery?  Conjecture?  Experiment (environments, observations, instruments)?  Verification?  Proof?
    16. expressiveintelligencestudio UC Santa Cruz Implications: Discovery  What does _____ mean in discovery?  Prototyping and play testing?  Publishing a game?  Games vs. abstract state progression systems?  Expressive goals?  Fun?
    17. expressiveintelligencestudio UC Santa Cruz Research Questions Revisited  Function:  How does an intelligent game designer function?  Need to build a system!  Implication:  What does such a system imply for the relationship between discovery and expressive domains?  Need some theories to generalize!
    18. expressiveintelligencestudio UC Santa Cruz Outline  Related work  Game design  Discovery and creativity systems  Prior work  Interactive generative art  Logical games  Elementary discoveries in game design  Proposed work  Theories  Systems  Experimental validation  Time line
    19. expressiveintelligencestudio UC Santa Cruz RELATED WORK Textbook game design A call for structure Game studies Artificial intelligence Models of discovery Discovery systems Computational creativity Generative art
    20. expressiveintelligencestudio UC Santa Cruz Artifacts  Design documents  Prototypes  Paper  Computer-assisted  Computational  Complete games Processes  Concept development  Design  Prototyping  Play testing  Self-testing  Testing with friends  Testing with target audience  Tuning  Marketing Textbook Game Design
    21. expressiveintelligencestudio UC Santa Cruz A Call for Structure  “Not enough is done to build on past discoveries, share concepts behind successes, and apply lessons learned from one domain or genre to another.” – Doug Church  Formal Abstract Design Tools (Church 1999)  400 Project (Barwood 2001)  The Case for Game Design Patterns (Kreimeier 2002)
    22. expressiveintelligencestudio UC Santa Cruz Game Studies  Swap Adjacent Games to Make Sets of Three (Juul 2007)  Patterns in Game Design (Bjork 2005)  Game Ontology Project (Zagal 2005)
    23. expressiveintelligencestudio UC Santa Cruz AI: Game Generation  EGGG (Orwant 2000)  Automated Puzzle Generation (Colton 2002)  Towards Automated Game Design (Nelson 2007)  An Experiment in Game Design (Togelius 2008)  Rhythm-Based Level Generation for 2D Platformers (Smith 2009)
    24. expressiveintelligencestudio UC Santa Cruz AI: General Game Playing  GGP: getting machines to play arbitrary games well given only the rules and a little bit of time to practice (evolved from AI chess)  Game Description Language (Love 2006) describes games as state transition systems in datalog.
    25. expressiveintelligencestudio UC Santa Cruz AI: Game Design Assistance  Parallel research by Mark J. Nelson at EIS  Goal: create a game-design assistant that helps designers prototype their rule systems  Gist:  Let the machine comment on formal issues  Reachability, exploits, indirect constraints  Let human players comment on soft issues  Engagement, fun, hesitation
    26. expressiveintelligencestudio UC Santa Cruz Personal Game Design Experience Drive-by CTF AjaxWar Katamari Damacy Text Adventure the.discrete.gardender Sequence Sleuth Troy fusepuck T++ others I’ve forgotten…
    27. expressiveintelligencestudio UC Santa Cruz  Two common domains:  Natural science  physics, chemistry, genomics, virology  Mathematics  graph theory, number theory  Two common goals:  Explain historic discoveries  Produce new knowledge  Unifying vocabulary for discovery: (Shrager and Langley 1990)  Knowledge structures  Processes Models of Discovery
    28. expressiveintelligencestudio UC Santa Cruz Early Systems Discovery Systems  Modern components  Abductive and inductive logic learning  Inductive process modeling  Statistical-relational learning DENDRAL (Feigenbaum 1965) AM (Lenat 1977) BACON (Langley 1977) Refinements EURISKO (Lenat 1985) CYRANO (Haase 1987) GT (Epstein 1988) HR (Colton 1999) Graffiti (Fajtlowicz 1988)
    29. expressiveintelligencestudio UC Santa Cruz Theoretical Models  Conceptual spaces (Boden)  Domain, individual, field, interaction (DIFI) (Feldman)  Curiosity (Saunders)  Perceptual Creativity (Colton)  … Aspects  Artifacts  Processes  Expectation  Emotion  Socialization  Novelty and value  Generate and test loop  … Computational Creativity
    30. expressiveintelligencestudio UC Santa Cruz Creative Art Systems  AARON (Cohen)  NEvAr (Machado)  Digital Clockwork Muse (Saunders)  EMI (Cope)  MINSTREL (Turner)  The Painting Fool (Colton)
    31. expressiveintelligencestudio UC Santa Cruz Recap of Related Work  Game Design  Textbook + Call for more structure  Game studies + AI  Discovery and Creativity  Models of Discovery + Systems  Computational Creativity + Systems
    32. expressiveintelligencestudio UC Santa Cruz PRIOR WORK Tableau Machine Logical game design Game generation Elementary discovery in game design
    33. expressiveintelligencestudio UC Santa Cruz Tableau Machine  Experience formalizing an expressive domain  Generate-and-test  Design grammars  Image analysis  Learn long-term patterns in sensor data to stay relevant
    34. expressiveintelligencestudio UC Santa Cruz BIPED: Computational support for play testing game sketches
    35. expressiveintelligencestudio UC Santa Cruz Example Game: DrillBot 6000 happens(mine(a1),0). happens(drain,1). happens(drain,2). happens(trade,3). happens(mine(a2),4). happens(mine(a0),5). happens(down_to(a),6). happens(mine(corpse),7). happens(mine(c0),8). happens(down_to(c),9). happens(down_to(f),10). happens(up_to(c),11). happens(up_to(a),12). happens(down_to(c),13). happens(down_to(f),14).
    36. expressiveintelligencestudio UC Santa Cruz Logical Game Programming pos(base). pos(a). pos(b). pos(c). … game_state(position(P)) :- pos(P). game_event(up_up(P)) :- pos(P). game_event(down_do(P)) :- pos(P). initiates(down_to(P),position(P)) :- pos(P). terminates(down_to(_),position(Prev)) :- holds(position(Prev)). initially(position(base)).  Movement mechanic from DrillBot 6000
    37. expressiveintelligencestudio UC Santa Cruz Logical User-Interface Programming  UI bindings in DrillBot 6000 ui_title(’DrillBot 6000’). ui_space(P) :- pos(P). ui_space(inventory). ui_token(db6k). ui_location(db6k,P) :- holds(position(P)). ui_triggers(ui_click_space(P),down_to(P)). ui_triggers(ui_click_space(base),refuel).
    38. expressiveintelligencestudio UC Santa Cruz Capabilities  Syntactic properties  Design validation  Semantic properties  Trace harvesting  Rule set debugging  Win-ability verification  Reachability analysis  Uniqueness verification of puzzle solutions  Testing a game before you ever make a UI  Induction on semantics  Player-model construction
    39. expressiveintelligencestudio UC Santa Cruz Game Generation  BIPED-tech is great for testing game ideas, but who generates them in the first place?  Need a “design grammar” for games  Propositional game generator experiment  Generation of rule systems is feasible.  Needs higher-level building blocks:  Multi-clause rules  Multi-rule mechanics  Higher-level mechanics
    40. expressiveintelligencestudio UC Santa Cruz “Movement between underground caverns” in Drillbot 6000 % positions (caverns) pos(base). pos(a). pos(b). pos(c). % links (drillable routes) link(base,a). link(a,b). link(a,c). % event preconditions possible(down_to(Dst)) :- holds(position(Src)), link(Dst,Src). … A general “network navigation” design pattern at the code level  Setting: predicate room(R)  State: location(R) such that room(R)  Setting: doorway(R1,R2) such that room(R1) and room(R2).  Event: move_to(R) is possible only if room(R) and you location adjacent room, as judged by doorway  … Elementary Discovery in Game Design
    41. expressiveintelligencestudio UC Santa Cruz Recap of Prior Work  Tableau Machine  Logical game design  Game generation  Elementary discovery in game design
    42. expressiveintelligencestudio UC Santa Cruz PROPOSED WORK New Theories System Architecture Experimental Validation Timeline
    43. expressiveintelligencestudio UC Santa Cruz Reviewing the Knowledge Level
    44. expressiveintelligencestudio UC Santa Cruz A Game Design Meta-Theory
    45. expressiveintelligencestudio UC Santa Cruz A Knowledge-Level Account of Game Design  Agents  Designers!  Actions  Game actions  Play actions  Design actions  Goals  Discovery of design-level knowledge
    46. expressiveintelligencestudio UC Santa Cruz Reflexive Creativity  My conjecture on creativity:  Creativity is the rational pursuit of curiosity that results in a surprise.  Mash up some theories:  If game designer aim to discover…  And discovery is way to satisfy curiosity…  Maybe creative game designers make games to help them discover!
    47. expressiveintelligencestudio UC Santa Cruz System Overview: Exterior
    48. expressiveintelligencestudio UC Santa Cruz System Overview: Interior
    49. expressiveintelligencestudio UC Santa Cruz Symbol-level Implementation  Implement as a production system  Facts, rules, and a rule engine/executive  Operational knowledge:  Fixed rule set  Design theory:  Mutable rule set, Mutable fact-base  Artifact library:  Append-only fact-base  Discovery Notebook  Mutable fact-base
    50. expressiveintelligencestudio UC Santa Cruz Operational Knowledge  Remember those scientific knowledge structures and scientific processes? I’ve translated them to game design.  Layered mapping:  Scientific knowledge structures and processes  Game design knowledge structures and processes  Data structures and operations  Production rules and facts
    51. expressiveintelligencestudio UC Santa Cruz Artifact Library % entry for an generated sequel to DrillBot 6000 game(db6k_mk2, [ construction(expand_map(drillbot6000)), rules({BIPED-compatible rule set}), design_annotations(expand_map_seed(12391))]). % a player model player(energy_hog, [ construction({prodution rule used to produce this player}), rules({internal state, predicate transformers, BIPED-compatible play-hook clauses}), design_annotations({…})]). % entry for an instance of play play_instance(pairing23423,[ game(db6k_mk2), player(energy_hog), pairing_rules({choices the system had to make to glue the player to the game}).
    52. expressiveintelligencestudio UC Santa Cruz Design Theory  What-is knowledge  Design patterns (named and detailed game and play structural elements)  Recall the “network navigation” pattern  Trace predictors  “If the game contains pattern X, then Y should be found in the trace”  How-to knowledge  When-to-always and when-to-never perform certain design actions under certain conditions
    53. expressiveintelligencestudio UC Santa Cruz Raw Design Theory Examples % a movement mechanic mechanic(movement_between_rooms(R,D),[ dungeon_map(R,D), game_state(at(agent/1,R)), game_event(moves_to(agent/1,R)), {trigger logic} ]). % player’s view of the game state as a player character player_construct(pc_avatar(PcPred),[ binder(pc_avatar(PcPred)), pc_avatar(Pc), pp_mapper(in(Pc,X),out(X))]). % trace property predictor trace_implication(happens(victory,T2),happens(boss_kill,T1)) :- T2 <= T1, mechanic(boss_kill_victory). % how-to designers_never(game_apply(expand_map),game_apply(expand_map)).
    54. expressiveintelligencestudio UC Santa Cruz Discovery Notebook  Starts empty  Contains  Outstanding experiments  Expectations  Agenda  …  General working memory  Usage dictated by operational knowledge
    55. expressiveintelligencestudio UC Santa Cruz Actions:  Design actions:  Manipulate game, player, and play instance models  Solicit a game or play trace from an automated tool or a human player  Discovery actions:  Propose new game, player, and play instance structural elements or production constraints  Look for examples of new patterns in old artifacts  Verify (prove?) trace predictors
    56. expressiveintelligencestudio UC Santa Cruz Design Tools  Design validator  Gameness-check  Trace-finder  Human player trace harvester  Logical debugger  Misc. statistical-relational learning tools  Potential add-ons from Mark’s research:  Alternate trace-finding back-ends  Query suggester and answerer  Rule visualizer
    57. expressiveintelligencestudio UC Santa Cruz Experimental Validation – Q1 How does an intelligent game designer function?  “games” – Ask some players if the machine-designed games felt like real games  Do the players think the games feel real?  “intelligent” – Ask some expert designers to perform some discovery, and record the result (using same tools).  Does my system rediscover it?  Did my system discover something beyond it?  “game design” – Ask some expert designers to design some games and record the result (using same tools).  Does the designer think the games feel real?  Does the system produce the same kind of games?
    58. expressiveintelligencestudio UC Santa Cruz Experimental Validation – Q2 What does such a system imply for the relationship between discovery and expressive domains?  Test the theory by testing the systems designed according to it.  Toggle various elements of the architecture to see what is really to blame for the interesting behavior  Need implications in-hand to propose concrete experiments
    59. expressiveintelligencestudio UC Santa Cruz Time Line  Year one: focus on stretching game design into a science- like practice, automation comes at the very end  Summer 2009: play with more manual discovery  Fall 2009: implement scientific knowledge structures  Winter 2010: implement the scientific processes  Spring 2010: integrate the system, close the loop  Year two+: focus on architectural experimentation, system evolution, and generalizing to my theoretical contributions  Summer 2010: plan the dissertation  Fall 2010: perform the experiments  Winter 2011: synchronize experimental results with plan  Spring 2011: dissertation writing  Summer 2011: final polish and defense
    60. expressiveintelligencestudio UC Santa Cruz Recap of Proposed Work  Improve upon some new theories  Implement system according to proposed architecture  Validate my intelligent game designer in experiments  Generalize from working system to more general theories
    61. expressiveintelligencestudio UC Santa Cruz EPILOGUE Revisiting Buchanan’s criticisms
    62. expressiveintelligencestudio UC Santa Cruz Epilogue  Bruce Buchanan (in AAAI-2000 Presidential Address) says of existing creative systems…  (1) they do not accumulate experience, and thus, cannot reason about it;  (2) they work within fixed frameworks including fixed assumptions, and criteria of success;  and (3) they lack the means to transfer concepts and methods from one domain to another.
    63. expressiveintelligencestudio UC Santa Cruz THANKS Thesis proposal: PROPOSED
    64. expressiveintelligencestudio UC Santa Cruz Detailed First Year Plan  Summer 2009  Flesh out first system architecture (mostly complete)  Perform manual discovery with the raw tools and representations (already started)  Produce example outputs  Document the manual process  Fall 2009  Implement knowledge structures  Games, player, play instances, trace predictors  Structural elements (setting constructs, mechanics, player predicate transformers)  Perform manual discovery with richer representations  Winter 2010  Implement processes  Drivers/scripts for external tools  Action sequences (“get a trace, then induce a player model”)  Heuristic processes selection (“try verifying a trace prediction”)  Perform manual discovery using large-scale processes as the individual move  Spring 2010:  Write up preliminary view of game design as a scientific domain (with structures and processes in-hand)  Plan expert and player evaluations  Create minimal closed-loop system  Theory goes in, improved theory comes out; also, games were produced  Improve system by building larger scale processes
    65. expressiveintelligencestudio UC Santa Cruz Detailed Second Year Plan  Summer 2010  Write up initial results and architecture of integrated system  Perform final literature review  Game design, discovery, and generation in expressive domains  Digital media (and other fields outside my own) for reference on expressive artifacts  Formulate initial implications between discovery and expressive domains  Design experiments to test implications  Produced detailed dissertation outline  Fall 2010  Carry out experiments  Winter 2011  Reconcile experimental results with theory, adjust claims  Start dissertation writing  Spring 2011  Dissertation writing  Clarifying experiments  Summer 2011  Final polish and defense