Ludocore: A Logical Game Engine for Modeling Videogames

Editor's Notes

• #3: Here is simple statement.Let me build some context around this statement before the bulk of the talk.
• #4: Left: Motherload-- Mining robot, navigating a world, drilling out rocks to recover valuable ore, managing a continually draining energy supply, trade in rocks and refuel only at the top of the mapRight: db6k was created using our game engine with the same core mechanics, but art assets and other details stripped awayNote: Real games designers build prototypes like this as part of the design process for real games (abstract, programmer art, subset of complete mechancs). Making this kind of game as part of an experiment towards designing larger games is what separates prototypes from toy research games.Keep db6k in mind, it will be my running example.
• #5: Quickly building informative models is what Ludocore is all about.Ludocore focuses on automated playtesting, but can be used with human players as well.
• #6: Def: comprehensive software libraries for game developmentIn practice: a collection of code you would have had to re-write for every game, wrapped via an accessible interfaceNOTE: models that you create with L are fed into an answer set solver which produces detailed gameplay traces(no code in this talk)
• #8: S-T (MDPs): misses the major point that games have RULES (some inherently factored rep of dynamic system from which gameplay emerges)GDL: but much easier to specify, still S-T at the core, ultimately designed to learn about (GG)players, not game designsEC: is a logic language for representing and reasoning about actions and their effectsRules: swap in/out, better resonates with how real games are defined – don’t write out a complete trans function, it emerges from rulesCLoI: imperative updates to state variables in game code;So: ec has properties we really want, but missing a game vocabulary and playtesting toolsLudocore: higher level formalism specific to building game models
• #9: Models in our engine are made of components that incrementally build on each other.You could just write an ad-hoc game model from scratch (we did many times!), but this factoring seems to be useful.Fill up this diagram over the next few slides
• #10: Temporal logic: We’ve found it useful to use EC as a base (vs something ad-hoc).Timepoints map to game simulation ticksFluents are conditions that can change over time (subject to CLoI), map to tables of game stateEvents instantaneous occurences, straight-forwardPluggable init/term rules, map to event handling logic in gamesTraces are logs of events and world state over time.Existence of interesting traces and their contents is where the design understanding comes from.TL: can be used to arbitrary systems with state change over time -- but: we focus on modeling systems which could reasonable be described by the code implementing some game
• #11: NOTE: use drillbot examplesState: raw inertial state + computed views + implicit current-time (ex: occupied(Pos) ~ rock(R),in(R,P),holds(present(R),T) ,T=now)Events: conflict (mine and trade) vs. possibility (mine with energy) vs. selectability (trade with empty inventory)Player/Nature: tag subsets of game events as player actions or spontaneous/triggered actions (player’s avatar movement vs. NPC movement)Models: pluggable, selection policies for events (more later)MISSING: scoring, victory conditions (possible to build, but not necessary for most models)PRESENT: structure which supports the our factoring of game models, the dotted-line boundaries
• #12: Given high-powered concepts in the background theory, Db6k is relatively easy to describeState: robot is at position with some energy, rock is presentEvents: mining, moving, refueling (only refuel at base, only move to empty cavern)Consequences: moving reduces energy (and changes position!), refueling restores itNature model: spontaneous energy drain (slow leakage over time, not a player’s move, but keeps happening, blame on nature)S Concepts: non-dynamic, but still critical definitions (how many energy levels there are, energy cost of actions)W Configuration: concrete level design and item specs (cavern network, tagging some rocks as treasure)
• #13: Modeling the game’s rules isn’t enough to produce an informative model.There is a big gap between what is technically possible in a game and what you see during play (conj: game design is all about understanding this gap!). Demonstrating and documenting that gap is an important function of a game model (a play model, really).Asserts: refuel robot is at the base and under half energyForbids: no mining if there are more than 5 rocks in the inventoryDefault model says anything goes. Pile-on to incrementally carve away unrealistic behavior.
• #14: Player model restricted the game model to only realistic gameplay traces.SAs do the same thing, restricting the model to only interesting traces (with interestingness at the whim of the designer).Scenarios: alternative initial conditionsGoals: something that must be true of every trace the model admitsMetrics: compute numerical score for any trace, ask to minimize or maximizeWrap up: this is what it takes to specify an informative model (requires modeling a focused view of some play situation)
• #15: Method: (concretely) Writing a little bit of code- Running our command-line tool
• #16: Initial conditions: robot starts underground with low energy. What can happen next?Final conditions: all rocks are collected at t=10. How did this happen?Partial spec: t=1..20, refueling only happened once (don’t know/care when). How did the robot survive?Event trace at right is actual output from design tools.
• #17: Instead of trying to learn about the dynamic part of your game’s rules. SQs can tell you about the timeless/static parts of the rules.Minesweeper: What placements of mines on the map are consistent with the current visible game state? Puzzle solver in ~100 lines.Wz2100: What building locations and terrain heights are consistent with certain strategic-fairness constraints? We didn’t do this work, but the developers use the same logic tools we do.~ with our engine you could extend this procedural content generation with dynamic, gameplay contraintsThe magic: write down the mechanics for forward simulation and get a puzzle solvers and procedural content generators almost for free
• #18: The Ludocore engine is heavy machinery behind Biped, a dual support prototyping tool we presented elsewhere.Letting a human play the role of an incremental forward simulator is relatively easy (computationally speaking).Human players reveal information that can’t be read from a symbolic trace.
• #19: It can’t say a game is good or bad, but it can the provide objective feedback you need to form your own opinion.Taking this feedback and deciding the next gameplay experiment is what game design is all about.
• #20: Design expectations: structure outside of just the game’s rules is critical for making the model informative. Machine playtesting: respects documented assumptions about real player behavior. Using logic for PCG? Come to my talk tomorrow at 11!