Thursday, February 7, 2008

In Whole--More or Less

This is a really long post. I offer it, because it is what this blog is about--collecting ideas for games in general and Munchkin in particular. What is follows is the proposal that I submitted just about 3 years ago. I still like the idea. The design seems, in retrospect, confused--but not without virtue. The schedule was a farce--I've omitted it, but I'll tell you that everything was supposed to happen in a semester, which it did not. The background has advanced; Firemox (or the Magic Project) would be a a more current example of what I'd like to achieve. I don't know what I thinking with the Agile/XP comment--I think that the words were intoned in a voodoo sort of way; I think that I meant that it would all happen fast. Here it is:

Master’s Project Proposal: 8-16-05

An Implementation for Munchkin

Student: Kevin Becker
Faculty Advisor: Stephen Houser
Project Time: Fall 2005


Abstract

The purpose of this project is the implementation of a card-based strategy game. Card based strategy games have the general quality that the rules of the game are delineated on the cards. This lends mutability to the normally static nature of a game’s rules; over the course of a game, rules are added with the inclusion of cards into the play and removed form the rule-set with the removal of cards from play. The goal is to create a generalized core structure for player interaction with the rule-set, which would accommodate the introduction of new rule-sets. The general design approach will be an Object-Oriented analysis together with an analysis of applicable Design Patterns. The implementation will follow Agile programming practices.

Introduction

The game to be implemented is Munchkin by Steve Jackson Games . Munchkin is a light-hearted parody of fantasy role-playing. One of the characteristics of rules that govern play (of Munchkin in-particular, and card games by Steve Jackson in general) is novelty of interaction. This aspect of novelty occurs in card distribution: most of the cards in the deck (of about 80) are unique, and in rule application; a card may refer to an attribute contained by only a couple of other cards in the deck.

Although Munchkin is a stand-alone game (all of the rules , and cards come in one box and are playable without further expansions), two expansions have been released, and Munchkin is compatible with three other similar games released by Steve Jackson Games.

The use of design patterns promotes reuse by component composition and loose coupling objects within a software system to manage design and system extensibility. Component composition employs composite objects to vary object structure and behavior. This can be contrasted with a focus on the primary use of inheritance to provide variation between similar types of objects.

This approach is highly applicable to the implementation of a game like Munchkin. The complicated nature of the rule-structure would quickly become unmanageable for a procedural or a tightly coupled Object-Oriented approach. Decoupling of game objects and mediating interaction between objects reduce the complexity of and increase the flexibly of individual game components.

System extensibility is achieved through the reuse of existing light weight components and the ability to vary the construction of existing composite objects with the introduction new component classes.


Background and Related Work

Most of the card-bases games online are collectable games. Collectable card games (CCGs) periodically release new batches of cards for use with the previously released cards. Further, most companies focus on a single game. Most similar to this project are two smaller enterprises: CCG Workshop and GCCG.

CCG Workshop is an online gaming community the client is called the gatlingEngine. The client is an interpreter for a proprietary markup language and scripting language. The scripting language is supposed to allow the automation of any rule event, “However, there are a handful of games available to play that are completely automated.”

GCCG is open-source project hosted by sourceforge written in C++, has a lot of focus on network architecture and card trading. It is meant to be a generic system for CCG's. There does not seem to be implementation for the interaction of the rules described on individual cards, but rather on layout and legal deck composition.

Neither GCCG nor CCG Workshop seem to focus on rule-structure as the starting point in design. Both appear to focus on managing a collection of cards, chat and trading, and network infrastructure. The rules of the games that are played are left to the players understand and follow at their discretion. The focus of this implementation is to begin with a complete and flexible rule structure upon which further layers can be built.

Design Approach

The nature of cards based games is mutability. Turn-order may change; phases (the sub-component of a turn) may be played out of turn. The general rules of the game may be over-ridden by cards, which are brought into play; these rules in turn may be modified by new cards that are played.

Given the dynamic rule-system, which governs play, it follows that object-orientation throughout the implementation would be appropriate. Some examples of how game concepts will translate into Design Pattern structures could include:

Turns as Visitors,
Mediator of Rule application,
Composite Rules,
Elemental Rules as Flyweight,
Card Attributes as Flyweight,
Actions as Command.

The primary activity will be mapping game structures and activities into a framework of Design Patterns. With a solid representation of the game in place, higher level abstractions can be developed.

An arbiter, which mediates between player actions and game-state effects can be designed and implemented. This arbiter (the Game Master or GM) can disallow player actions, which are contrary to the rules. The GM can also observe the game-state to delineate legal actions which could be taken.

If the Game master is extended to allow roll-back of actions, this would provide a ground to look-ahead for the effects of a potential action. Above of the Game Master layer Agents can be implemented. Using the Game Master to delineate potential actions and choosing among available options.

Development Methodology

The development phase of this project will be based on the following principles: short iterations, Test Driven Development, simplicity, and flexibility. These principles are largely from the XP/Agile development methodology.

Specific practices will include:

XP / Agile: rapid iterations, consistent metaphor, coding standard, continuous integration.
TDD: no code without a testing strategy, refactoring.
Design Patterns: flexible, extensible, top-down complexification.
Programming by intention (self-commenting, cohesive, loosely coupled)

The GM (described above) is an essential aspect of this project. The support structure for agent implementation is also a root goal of the project. Since these two attribute of the game implementation are fundamental, they should be present from an early iteration, and allowed to evolve together with the game structure.

Over the course of implementation, the system will evolve. Although iterations are delineated in the working schedule, the development process will be somewhat more fluid. Integration and refactoring are central to the Agile methodology.

[Schedule Omitted]

References

http://www.sjgames.com/munchkin/game/
http://www.sjgames.com/
http://www.sjgames.com/munchkin/game/img/rules.pdf
http://www.sjgames.com/errata/munchkin.html
http://www.ccgworkshop.com/
http://www.ccgworkshop.com/gEngine.overview.jsp
http://www.ccgworkshop.com/faq.jsp “Are the games automated?”
http://gccg.sourceforge.net/
http://xprogramming.com/xpmag/whatisxp.htm

Fowler, M., Beck, K..
Refactoring : improving the design of existing code. [Chapter 4.]
Reading, MA : Addison-Wesley, 1999

Shalloway, A., Trott, J..
Design patterns explained: a new perspective on object-oriented design.
Boston, Ma. : Addison-Wesley, 2002


That was it. What's happened in almost 3 years? More reading, a lot of code, some writing. And now I am going to start pulling it together and figure out just where I am.

No comments: