Gamescrafters – Fall 2006 Gamesman++ Rethinking the Gamesman Core

David Eitan Poll

Fall 2006 Fall Gamesman++ 2006

Introduction Gamesman – Game-independent Automatic Move/position-tree Exhaustive-Search, Manipulation and Navigation

Gamesman is and has been at the core of the Gamescrafters project. Originally written by Dr. Dan Garcia, Gamesman has provided a C-based framework for the expression of abstract strategy games, allowing them to be solved, analyzed, and played. Through the years, Dan and his Gamescrafters have expanded Gamesman, developing various modules for solving and analyzing games as well as adding a plethora of games to the system.

Gamesman has been an incredible piece of software, but much of its expansion was not and could hardly have been planned for. As a result, its expansibility is becoming limiting and cumbersome. Gamesman++ is an effort to rethink the design of Gamesman from top to bottom to make it the best software for two-person abstract strategy game theory research, analysis, and application.

This document will outline the goals and propose solutions and features for the revamped system. Future documents will go into further detail regarding the actual design of the system, broken down by feature.

Throughout this document, the original version of Gamesman will be referred to as Gamesman Classic.

ii

Fall Gamesman++ 2006

Table of Contents Introduction ...... ii Table of Contents ...... iii Commitment ...... 1 Breakout ...... 1 Model Overview...... 1 Gamesman Runtime (GR) ...... 2 Gamesman Framework (GF) ...... 3 Gamesman++ Core Classes ...... 3 Solvers ...... 3 Games ...... 3 Positions ...... 4 Moves ...... 4 Hashers ...... 4 Data...... 5 Gamesman Built-in Libraries (GBiL) ...... 5 Gamesman Built-in Modules (GBiM) ...... 5 Gamesman Shells (GS) ...... 5 Gamesman Test Framework/Libraries (GTFL) ...... 6 Gamesman Documentation (GD) ...... 6 Goals ...... 6 Gamesman++ Meta...... 6 Brainstorming Results ...... 6 Gamesman Runtime (GR) ...... 7 Brainstorming Results ...... 7 Gamesman Framework (GF) ...... 7 Brainstorming Results ...... 7

iii

Fall Gamesman++ 2006

Gamesman Built-in Libraries (GBiL) ...... 8 Brainstorming Results ...... 8 Gamesman Built-in Modules (GBiM) ...... 9 Brainstorming Results ...... 9 Gamesman Shells (GS) ...... 9 Brainstorming Results ...... 9 Gamesman Test Framework/Libraries (GTFL) ...... 11 Brainstorming Results ...... 11 Gamesman Documentation (GD) ...... 11 Brainstorming Results ...... 11 Design ...... 12 Deciding on C++ ...... 12 Proposed API...... 13 Gamesman Framework (GF) ...... 13 Gamesman Runtime (GR)...... 14 Scenarios and Pseudocode ...... 15 Shell Hits Runtime for Tier Solving, Playing, and Analysis of Bagh Chall ...... 15 Runtime initializes a solver ...... 16 Loopy Solver uses dependency on Inverted-Tree Solver and a Game ...... 16 Gamesman++ Developer Scenarios ...... 17 New game ...... 17 New Solver ...... 17 GUI Creation ...... 18 Customization of the Console Input ...... 18 Plan of Attack ...... 18 Conclusion ...... 19

iv

Fall Gamesman++ 2006

Commitment From now on, (and ideally), adding a feature to Gamesman should not require a change to the core, nor should it break any old code.

Breakout In the past, Gamesman has been divided mainly into three branches:

 Core o All solvers o Game engine o Common libraries o Basically, everything but the games and GUI  GUI  Modules o All of the games

I propose that we begin to think of Gamesman as being more granular, breaking out the core into a variety of pieces and clearly drawing lines regarding the purposes of each component. Note that these divisions are conceptual and not necessarily part of the actual structure of the design (although they probably are).

Model Overview Shown below is a graphical overview of how the pieces of the model proposed fit together. The two pivotal pieces for allowing Gamesman++ development to continue are the Gamesman Framework (GF) and Gamesman Runtime (GR), as well as a rudimentary Gamesman Shell (GS). For more details about what the pieces in this diagram mean, read the sections that follow.

1

Fall Gamesman++ 2006

Gamesman Runtime (GR) Formerly part of the core, the Gamesman Runtime (GR) would provide a variety of very specific services. The hope is that this component would rarely be changed by programmers, just interacted with. GR would be responsible for setting up the environment for running, solving, playing, etc., within Gamesman, and would have control over the flow of Gamesman execution.

GR would not, however, be involved in any UI development (console or otherwise), nor would it be responsible for providing classes from which to build Gamesman. Rather, its job is merely to be the glue that pulls all of the pieces of Gamesman together into a coherent and functioning application.

2

Fall Gamesman++ 2006

Hypothetically, GR could function almost completely alone (with some added means of presentation), but it wouldn’t be able to do very much without augmentation from the rest of the parts.

GR is also responsible for making ready the elements of the framework based upon the declarations they have made about themselves. The most important example of this is fulfilling of dependencies for modules and solvers. Given a set of modules and libraries to load, the runtime should be able to determine an acceptable order of execution for the solvers based upon their declared dependencies.

Gamesman Framework (GF) The Gamesman Framework (GF) would contain all of the libraries necessary for extending Gamesman. Any time one wants to make a module, solver, or otherwise write against an extensibility point in Gamesman, this is where they would start. All base classes and interfaces go here, and it is through the GF that we will be able to specify what it means to be a part of the Gamesman system. The goal in this piece of the system is not to rewrite Gamesman’s functionality, but rather to provide the tools necessary to plug Gamesman’s functionality into the GR.

Gamesman++ Core Classes GF will be comprised of a set of interfaces and classes from which GBiL and GBiM will be derived. These classes must be general enough to represent all of the situations proposed in the brainstorms. As a result, we tried to boil Gamesman down to just a few core classes. They have minimal, if any implementation, and provide the abstraction for the pluggable components of the system. All of these classes are derived from a component class of the system which allows them to declare dependencies on other core class derivatives and to declare attributes about themselves. The three main types in GF are described below.

Solvers Solvers are basically the verbs for our system. These are the components that do the various computations in the system. The traditional examples of solvers have been the Loopy Solver, the Tier Solver, and others of this ilk. The new Solver abstraction is broad enough to include newer concepts such as the Open Positions Solver, Analysis Solvers, and even the AI that takes a position and game solution database and chooses appropriate moves.

Games This abstraction is not dissimilar to modules in Gamesman Classic. Games are essentially the rules for our system. The game provides the backbone on which the solvers might operate. Again, games must have minimal implementation requirements in order to scale to whatever new challenges come our way. Some of the new ideas for types of games that Gamesman Classic does not currently support are those that are not perfect-information, single player games, multiplayer games, etc.

3

Fall Gamesman++ 2006

Thanks to the abstractions that Gamesman++ will feature, the we can finally do away with being continually forced to hash and unhash positions based upon game implementation. Instead, we can pass around abstract data types that can represent such things, providing savings due to overhead, and simplifying the transactions that must occur to make a game work. This will also encourage good practices for Game developers, such as implementation of GPS. Another highlight of this new system is that for the first time, a valid hash function will not be required to play a game, which allows for a more incremental (and testable) development process. The following classes will be mapped to individual games or types of games (as opposed to the entire Gamesman++ system, as all of the other framework classes have been).

Positions At last, Gamesman++ will support unhashed positions natively. These objects will represent the state of a Game (whose turn it is, the pieces on a board, etc.). It will no longer be necessary to limit a game’s size just because a hash cannot be created to express everything in 32 or 64 bits, and the overhead of decoding complex hashes at every step can finally be avoided.

There is also room here for abstractions, such as square, two-player, dart-board position, which can all share a common implementation and make life simpler for New Gamers.

Moves Like positions, moves no longer will need to be passed around as hashed values. There’s overhead to be paid here, and it’s much more difficult to code against an abstract hash than to work directly with an object-oriented abstraction of a move. Just as with positions, we can abstract moves for certain types of games away, allowing us to create standards for representation of moves for common game classifications.

Hashers Hashers are a concept new to Gamesman++. Because we have removed the requirement for a hash to make the game function, we can support multiple hash methods, each with their own purposes or benefits. Hashers might hash moves or positions (who knows what kind of solvers will emerge in the future?), and might provide different implementations for various solvers’ requirements. The clear benefit of this model is illustrated clearly in a recent change made to Gamesman Classic to add Tier solving. The Maximization system (a.k.a. Tier-solving) requires a hash that is very different from that of the standard solvers because it needs a tier number as well as a tier-localized hash value for each position. Adding this to the system required significant modifications to the core, whereas with a decoupling of games, solvers, and the core, no modification to the core would be necessary.

4

Fall Gamesman++ 2006

Data Data is by far the most abstract of the core classes in GF. Data classes will provide database implementations and a means for transferring data amongst the various components loaded by Gr. Possible Data implementations include SQL-style databases (with various backbone implementations, such as BPDB), in-memory databases for things such as child-parent associations (inverted game trees).

Gamesman Built-in Libraries (GBiL) The Gamesman Built-in Libraries (GBiL) are where Gamesman actually (finally) gets implemented. Here one can find all of the Gamesman solvers, database tools, and other utilities that will be invoked by the GR. This basically amounts to our standard library of Game Theory utilities, but is designed for growth, so that as new methods or concepts come about, they can be added here without bloating Gamesman. Nearly everything here should be based upon parts of the GF. (Proposed name change: Gamesman Built-in Modules [GBiM])

Gamesman Built-in Modules (GBiM) The Gamesman Built-in Modules (GBiM) are where the multitude of Gamesman games are found. The GBiM is, like the GBiL, the standard set of modules that Gamesman will provide to users or present to the GR. Again, nearly everything here should be based upon parts of the GF, and should be completely independent of anything otherwise. There should be a barrier between the GBiL and GBiM, such that neither is dependent upon the other. Rather, it is the job of the GR to tie the various pieces together, allowing solvers to solve and games to be played. (Proposed name change: Gamesman Bulit-in Games [GBiG])

Gamesman Shells (GS) Formerly the Gamesman GUI, this is where all front-ends to Gamesman belong. Gamesman Shells (GS) are responsible for instantiating, invoking, and configuring the GR, as well as presenting its data to the user. GS can range from Console front-ends to Tcl/Tk front-ends to WinForms or WPF front-ends. The beauty of this is that it completely and cleanly separates the presentation of Gamesman from its implementation, giving Gamesman the opportunity to be UI agnostic. At present, Gamesman has two GS: the Tcl/Tk rich GUI and the Console/Text-based interface. It is with the GS that Gamesman finally becomes an application, rather than simply a group of related libraries.

Gamesman Shells might also include less-obvious applications, such as outputting to a webpage or acting as host/controller or client to a parallelized implementation of Gamesman solvers. Other possible GS include a network host/client, digital paper-based UIs, or BOINC frontends.

5

Fall Gamesman++ 2006

Gamesman Test Framework/Libraries (GTFL) In the past, Gamesman has been almost completely devoid of any testing framework. It is time for this to end. The Gamesman Test Framework/Libraries (GTFL) is responsible for all of our tests of the Gamesman system. It will be invaluable for Gamesman programmers as a tool for verifying correctness as well as regression avoidance. GTFL can take advantage a variety of testing paradigms, from Unit Tests to stress tests. The goal is to provide a thorough test suite for ensuring system integrity and encouraging safe expansion of Gamesman. One might encourage Gamesman programmers to take advantage of Test-Driven Development (TDD) in building modules or other libraries, which would for the first time be feasible and efficient thanks to the GTFL.

The GTFL should have no bearing on how Gamesman functions, but should rather exist as a check that Gamesman is functional and to help Gamesman programmers catch bugs early in the development process.

Gamesman Documentation (GD) In the past, documentation and Gamesman proper have been mostly relegated to their separate worlds. In Gamesman++, an effort should be made (perhaps starting with this document) to have documentation as a required step in the process of development. By formalizing the process from end- to-end, we can ensure quality in all of the components of the system while making it more accessible to future Gamescrafters and whomever else might take an interest in our work.

Goals Below are some of the results of brainstorming the possible directions that Gamesman should be able to go. Gamesman++ should be able to scale to support all of these things, even though they may never actually be implemented or are a long way off. The hope is that by supporting all of these ideas, the system will be robust enough that it will not require much core modification in the future.

Thanks to the members of Fall 2006 Gamescrafters for their contributions to the brainstorm below. I have sorted the brainstorming bullet points into their relevant branches given the new model for Gamesman in Gamesman++.

Gamesman++ Meta

Brainstorming Results  Everything Ludoteka does and more  Everything Red Hot Pawn does and more

6

Fall Gamesman++ 2006

 Everything Zillions of Games does and more. Specifically, it should be easy to allow John Q. Public to add a game, have it confirmed to be bug-free, and available to all. Gamesman Runtime (GR)

Brainstorming Results  Pluggable  Simultaneous Gaming  UI Agnosticism  Data sharing among solvers  Easy addition of new games o Games are fully pluggable o External users might add their own games to the system  Easy addition of new solvers/db strategies o External users might add their own solvers or db formats  Custom Solving (each game may want to contribute a game-specific solver)  Installable (user-friendly install process) Gamesman Framework (GF)

Brainstorming Results  Solver completely separate  Solver independence for results  DB independence for results  N-player games  (this is very low level, but...) Sometimes the possible moves from GenerateMoves don't have to be returned on a linked list, they can actually fit in a char (e.g., Connect-4, there are only 7 possible moves at once -- that can be encoded in the lowest 7 bits of a char). That would save tons of time with malloc/free. Even if that _can't_ be done (e.g., go), then why are we mallocing and freeing so much? If we know the maximum fanout (in Go it'd be 362 = 19x19 + 1 pass) couldn't we be re-using a static array? That wouldn't save memory access but would save the malloc + free costs (which could be high).  Zillions of Games considers 1-player games (puzzles) just as easily as it does board games. The search isn't that different; perhaps we could do the same? 7

Fall Gamesman++ 2006

Gamesman Built-in Libraries (GBiL)

Brainstorming Results  Analysis "Solving"  Ability to have player profiles, keep running history of past games/scores  Open Positions solver  Loopy solver  Interestingness heuristic  Parallel solver (BOINC integration)/Deepa Blue  Distributed Solving (solve on a cluster)  Tier solving  Lots of different database types supported  Partial solving (even within a tier)  Slices  Built-in libraries for common functionality  "Big Game" compatibility  BigInteger support  Network Play  Centralized databases  Ability to play multiple games as one game where you choose which game to make a move on.  Static Eval - AI  What is fun?/interesting?  Easy to add new games by describing the rules in English (Game Factory)  Export and import game trees  Built in comparison to historic games  GPS  Symmetries  Chance of winning given winning player always plays randomly  Player plays from disk database (zero memory PLAYER)  Solver for asymmetric partisan games (solve one part partisan, one part not)  Hybrid solvers  Auto-tierizer

8

Fall Gamesman++ 2006

 Auto-symmetrizer  Win by!  Auto-variant generator  Our Game theory databases available on Google  A small database of "interesting" endgame puzzles for each game, whatever "interesting" means.  For a game with 1,000 variants, which are interesting? Set the computer to the task of analyzing the game trees and suggesting to us which are interesting and which are to be avoided.  Calculate definitive handicaps for hard games like go. 6.5? Our calculations say it should be 8.5!  Hidden knowledge games! I want a perfect probabalistic Twilight Imperium opponent!  Support for bit-range manipulation (to make manipulating positions and moves easier)  Support for Nalimov endgame tablebases  Solvers that hand games the history of moves so that games can respond accordingly Gamesman Built-in Modules (GBiM)

Brainstorming Results  Zillions of games  Optimizing rearranger recursive offset table and w/ renumbering of slots (tighten hash)  Perfect hash for Connect-4  Pen-based on tablets game  Legacy Support (compatible with old games) Gamesman Shells (GS)

Brainstorming Results  JNI frontend: see here for details. This would allow us to support online features for applets (e.g. Autogui)  In-game sounds, background music/game sounds  3D Game Tree visualizations  Online client  Analysis output  Dynamic option configuration  Support for a very wide variety of UI types 9

Fall Gamesman++ 2006

 Auto-GUI generation  Single executable for the main application  Ability to make executables for each game  Smartphone support  SMS position value querying  Internationalization  Downloadable Endgame DB  AI Strategy Summaries  3D GUIs (support for 3D boards)  You should be able to go back in the history, it'll branch  Change opponents on the fly  Change skill level of computer  Slider for randomness (mistakes per move)  Analysis Online  Game Server (provide our game databases to the world, possibly using SOAP)  Post-game expert analysis with game icons and moves color coded with a value which you can click to jump to  Network Play  Play Gamesman on cell phone with light clients  Delta remoteness display  Every game Gold and clean with Animations  Resizeable GUI  Transparent PNG pieces with Alpha Layers for beautifully rendered games  Command-line access to all functionality  Human v. Human for games that cannot be solved  GUI Variant Support  Gamesman on a cell phone, locally, and not only on Palm/Windows-enabled smart-phones either!  Instant replays (like Madden)  Amazing Renderman-like 3D Graphics if the user wants (perhaps scripted for instant replays too)

10

Fall Gamesman++ 2006

 "Game of the week" feature on web page where cool game we have is automatically culled from our archives and linked to our front page  Easy-printable "answer keys", like the one we already have for Tic-tac-toe  A Cal-day demo where we have a projector mounted above a white table showing a grid. There's a webcam up there too. As the user places a big, wooden X piece on a square, the computer recognizes it and treats it as a move. The computer responds by virtually placing an O piece on an empty square. This continues until one wins or it's a tie, but the user gets to move against a computer using real pieces.  An easy way to generate the current status of all the games into an html table. Who implements GPS? Symmetries? Maximization? Who still has kDebug turned on?!  Almost zero duplication of effort between game coded in C/C++ and GUI (e.g., Java and Tcl/Tk)  An Apple dashboard App interface to Gamesman  A Vista gadget interface to Gamesman  The 3D visualizer got me thinking about how we might need 4 dimensions for Quarto? Also along these lines, a tool for helping identify symmetries?  Ability to save a game in the middle of play to restart later, or for the purpose of replaying the game.  Variable sized boards for the Auto-UI generation (i.e. TileChess)  In-game sounds, background music/game sounds  Ability to have player profiles, keep running history of past games/scores Gamesman Test Framework/Libraries (GTFL)

Brainstorming Results  Stress testing  Unit testing  Regression testing  Comprehensive suites of tests  Standardized way of testing all of our Gamesman components

Gamesman Documentation (GD)

Brainstorming Results  Everything documented and integrated into the system

11

Fall Gamesman++ 2006

 Clean code + well documented  WWW Polished  Common Strategies and Key Positions tutorial  Compiles in Visual Studio  Complete documentation for every aspect of Gamesman++  Gamesman for Dummies  How-to's for everything you can do with the system and the APIs  Improved documentation and support for context switching

Design

Deciding on C++ Among the most significant design decisions that had to be made regarding Gamesman++ was the language in which it would be written. Many things were kept in mind as we considered:

 New Gamescrafters should be able to begin developing without much experience. The extent of what they know may be as little as Scheme and some C.  There are significant benefits to moving to an Object-oriented language such as C++, JAVA, or C#, especially in modeling many of the abstractions we use in Gamesman Classic.  Gamesman relies quite heavily on speed to get things done, so whatever language is used should have an acceptable, minimal speed penalty over C.

With these and other points in mind, and after consulting with veteran Gamescrafters, we came to the decision that C++ was the way to go. Below are some of the reasons:

 Taking advantage of legacy code from Gamesman Classic is far easier in C++ than in other languages we considered because C++ is roughly a superset of C.  As a result, new Gamescrafters can slowly transition from their more comfortable C world into that of C++.  The model that we use, especially in our implementation of GR, allows us to minimize the many C++ nuances that new developers would have to deal with (dynamic vs. static casting, etc.), as we can let the runtime take care of it for the module developers.  C++ is fast, especially when compared to other Object Oriented languages like JAVA or C#  We are able to address most, if not all, of the issues mentioned above, as well as the new design of Gamesman in Gamesman++ using a C++ implementation.

12

Fall Gamesman++ 2006

Proposed API In order to begin development on Gamesman++, two pieces of the system need to be in place. The components are GR and GF. From these two pieces, the rest of the system can be built, allowing larger- scale development of new features, as opposed to reimplementation of old ones.

Gamesman Framework (GF) Below is a proposed API for the Gamesman Framework. Note that much of this is subject to change, but should provide a starting point for development of Gamesman++.

Most of the methods here are self-explanatory. The most confusing new concept here is that of a “Connection”. In Gamesman++, a connection acts both as a descriptor of a dependency or product abd as a bucket in which the Runtime will place or look for this data. Most likely, this would be a templated class, and the Runtime would deal with all of the dynamic casting that must occur so that the consumer of the resource need not be concerned with these complicated nuances in C++. 13

Fall Gamesman++ 2006

Connections consist of a Type, a value (the bucket, waiting to be filled by either the module when this connection is a product, or the Runtime if this is a dependency), and a set of attributes. The runtime must ensure that the attributes on the Connection are met so that a dependency can be filled, and the attributes on a product connection serve as a contract that the module must fulfill. See the scenarios that follow this section for examples of how this would be used.

Gamesman Runtime (GR) GR is not so much about its API as the fact that it needs to act as a middle-man between the Shell and the various modules. There is no doubt that as GR is actually implemented this API will expand, but what follows is a very early idea of what this might look like.

GR provides functions for loading modules and gaining access to resources from things outside of the system. There is a relatively clean separation of Shell and implementation in this model, as the Shell can only access the actual modules via the Runtime. At no time should the Shell be calling, for example, “Solve” on a solver. Instead, it should make the Runtime kick off this process, as the Runtime will attempt to fill all dependencies with loaded modules and determine an order of execution to ensure that this is possible.

14

Fall Gamesman++ 2006

Similarly, if a Shell wants to get access to data that has been produced, it would either look at available resources or navigate directly to the module that produced it and examine the contents of its connection. From the Shell’s perspective, the available resources after running is like an inbox for data and other useful byproducts of the process. The image that comes to mind is the machine that makes Everlasting Gobstoppers in Charlie and the Chocolate Factory. The shell adds the ingredients and pushes a “Go” button, some stuff happens behind the scenes, and the Shell gets everlasting goodness out.

Scenarios and Pseudocode

Shell Hits Runtime for Tier Solving, Playing, and Analysis of Bagh Chall Expected Sequence of Events (from Shell):

1. Instantiate Runtime 2. Load relevant modules 3. Modify attributes of modules 4. Begin solving 5. Get game module and AI module for playing

Runtime * rt = new Runtime(); //1 rt->loadModule(TierSolver); rt->loadModule(BaghChallGame); rt->loadModule(AnalysisSolver); //2 rt->enqueueSolver(rt->getModule()); rt->enqueueSolver(rt->getModule()); //3, nothing may be necessary rt->doSolving(); //4 BaghChallGame * bcg = rt->getModule(); //5 AISolver * ai = rt->loadModule(AISolver); //2, 5 ai->setAttribute(AISolver::INTELLIGENCE, AISolver::PERFECT); ai->setAttribute(AISolver::POSITION, bcg->getStartPosition()); //3 rt->enqueueSolver(ai); rt->doSolving(); //Use the product of the AISolver to implement logic in the Shell, etc.

15

Fall Gamesman++ 2006

Runtime initializes a solver Expected sequence of events (from Runtime::enqueueSolver, assuming solver already instantiated):

1. Get the instance of the solver 2. Ensure dependencies are fillable a. If necessary, move it down the queue of tasks or insert other loaded modules to fulfill requirements b. Attempt to fill optional dependencies c. Load any non-loaded, required modules into the runtime 3. Wait for doSolving call to actually call solve method a. At this point, actually fill dependencies. If new dependencies have been added, try to resolve, and if unresolvable, throw an exception or return false.

Pseudocode omitted because it is mostly algorithmic for changing the priorities of the solvers.

Loopy Solver uses dependency on Inverted-Tree Solver and a Game Expected sequence of events (from the static initializer of the Loopy Solver):

1. Add game dependency 2. Add dependency for completed InvertedTreeData 3. Add product connections

Connection * c1 = new Connection(); c->setAttribute(COMPLETE, TRUE); Connection * c2 = new Connection(); this->dependencies->add(c1); this->dependencies->add(c2); Connection * c3 = new Connection(); c3->setAttribute(COMPLETE, TRUE); this->products->add(c3);

(from the solve function):

1. Grab game and inverted tree from dependency buckets a. Note that the contract between the runtime and solver dictates that dependencies will be filled before solve() is called. 2. Proceed with solving as usual, using a Hasher and other Game functions 16

Fall Gamesman++ 2006

3. Fill the “value” field of product connections (including a COMPLETE StrongSolutionData object)

Pseudocode again omitted because of focus on solving algorithm and redundancy with previous example. The only thing that will be new is the assignment of some instance to the “value” field of the connection.

Gamesman++ Developer Scenarios Now that much of the design has been fleshed out, it is worthwhile to look at how various developers in Gamescrafters will approach the system to accomplish their tasks.

New game When a Gamescrafter goes to add a new game to the system, these are the steps he will need to take:

1. Document the game that is about to be implemented 2. Create a new Game, inheriting from the various abstract classes/interfaces that have been defined in GBiL. 3. Implement the game a. Create/Re-use a Position class b. Create/Re-use a Hasher class c. Create/Re-use a Move class d. Implement the options required by implemented interfaces 4. Update Shells (how to do this is shell-specific) to be aware of the game.

For the most part, the process of creating a new game will not change (this is what we want). The flexibility of those individual games is much greater than in the past (no inherent requirements for hashing, 2-players, etc.).

New Solver When a Gamescrafter goes to add a new solver to the system, these are the steps he will need to take:

1. Document the solver that is about to be implemented. 2. Create a new Solver, inheriting from the framework class, and implementing any necessary interfaces 3. Create new Data objects (if appropriate ones don’t already exist) for dealing with and passing around the data this solver will produce. 4. Declare dependencies and products 5. Implement the solver a. Write the solve() function 17

Fall Gamesman++ 2006

b. Use any data from dependencies necessary to get the job done c. Take advantage of Game details (also received through dependencies) 6. Modify existing shells to be aware of and use the new solver

Addition of new solvers is where we really see the gains from moving to Gamesman++. In the past, adding radical new solvers forced us to make big changes to the core. Finally, we can do this without touching the core or running the risk of breaking code that has not declared itself to be compatible with the new solver.

GUI Creation When a Gamescrafter goes to add a new game-specific GUI to the system, these are the steps he will need to take:

1. Document the GUI that is about to be implemented, especially with regard to the data it requires from the game module itself. 2. Develop the GUI using whatever tools are preferred (as long as you can hook in to C++, you’re set). 3. Add code to initialize the runtime with the appropriate games and solvers.

The GUI creation process is basically the same as creating any Shell for the system. It can be as complex or simple as desired, as long as it takes the necessary step to kick things off with GR.

Customization of the Console Input When a Gamescrafter wants to customize console input, all of his changes will be made to the Shells. Games can declare their own preferences (through attributes), which a Shell might read after the game has been initialized, but any changes outside of the core functionality of Gamesman++ will be made to the appropriate Shell. We should, when we develop a Console Shell, standardize this process, making it simple for games to add options and accept input.

Plan of Attack What follows is a proposal for beginning the process of building and proofing Gamesman++:

1. Write GF and Core classes 2. Implement GR 3. Develop a simple Console Shell 4. Implement 1, 2, …, 10 5. Implement a simple (non-loopy solver) 6. Demonstrate that 1, 2, …, 10 can be played and solved 18

Fall Gamesman++ 2006

7. Add Achi (a loopy game) to the system, as well as a loopy solver. 8. Implement an analysis or open-positions solver, demonstrating a functioning dependency system. 9. Develop a legacy adapter for Gamesman Classic games, allowing them to be brought used by Gamesman++ 10. Begin gradual development and reconstruction of anything lost in the transition.

With a concerted effort, I think we can have a good prototype in place early next semester (steps 1-6), with the goal being that step 10 is reached by the end of next semester.

Conclusion Gamesman++ is a dramatic revision to the core of Gamesman Classic. It will hopefully allow Gamesman to continue to grow and adapt to the new Game Theory tools we develop as they become available. From now on, we should develop with the goal of expansibility, meaning that preserving a solid Object- Oriented model will be vital. The lesson of Gamesman Classic is that keeping to general implementations (adapting to any two-player, perfect information, abstract game) can be a very powerful tool, and that we can leverage this power not just with regard to games, but to solvers and various other components of the system as well.

Thank you for your interest and support for Gamesman and Gamescrafters. We can look forward to the fruits of our labors toward Gamesman++.

19