Today, most computer games are written using a procedural design. These programs include function calls and state variables to maintain their activity. As games become more advanced, these programs become bigger and require more programmers. This necessitates a group of managers to watch over the process and insure that state variables are consistent.
Recently, Object Oriented Programming became a catch all for complex projects. Languages such as Java, which are intended to be platform-less, have given OO a boost. OO programs, though, still require someone to watch over the project in detail to be sure that contracts are maintained. Also, the programmers of these must include accessors for their individual state variables so that other coders can reference them, or they are forced to make them universally accessible, turning the system towards a procedural configuration again.
Functional programming has long been used for AI routines, and some other programs. Large applications, such as emacs, have been written in LISP, a functional language. There is a game, Abuse, available for Unix systems, that was implemented almost entirely in LISP. All these projects, however, neglected the full power of functional programming by using some of the procedural shortcuts available in LISP.
This project will be developing a game application, based on Games Workshop's
Talisman, in the functional style. The idea behind this project is to
determine the feasibility of using a functional language, specifically ML,
for an application of this size and nature.
The first goal will be to develop a base for the game, consisting of
a board, players, and actions that occur. Later goals include a more complex,
and comprehensive, set of players and actions.
The system is being developed on Unix/X-Windows systems, as there are not as many API hooks to be utilized in any method of coding. This necessitates moving the creation of a clear and comprehensible interface to the coders, instead of using a pre-developed one and modifying. This should, in effect, mean that the design and writing would be that of a full application.
If time permits, and interest is found, some members of the group may implement versions of the game, in the same environment, under the other programming paradigms (procedural and OO).
The project will be implemented in SML (WHICH VERSION SML/? NJ?). GUIs will be implemented from ML and XMotif libraries.
The functional requirements for this project will be divided amongst the major categorizations, as shown in the schedule.
Nonfunctional requirements will be divided up as follows:
Dan and Jon decide they wish to play Talisman one evening. They start the program that Jon has on his workstation, which Dan has never seen before. In only a couple of minutes Dan has, with prior understanding of the game itself, understood the interface and is ready to play. Jon has, meanwhile, taken his first turn after setting up Characters.
Ross and Carla have both played the game before, but have never actually had the time to do very much. They sit down and begin to play. Ross soon encounters a Space and draws a Card that neither of them have encountered within the computer game before. [Hmmm ... Has Jon been working on it again?] Because they have encountered other Cards before, they have no trouble determining what they need to do, even though this Card involves more action on their part. [Dragons? He put creatures in? I thought we were still trying to fix the Bags o' Gold! When did we do attacks?]
Helen decides that she wishes to play a really long game, so she forces Jon, Ross, Carla, and Dan to come over to play with her. [But we played in the LAST two examples! *whine*] After playing for a while, Helen decides that she's ready to show off her new code, and so she attacks Dan's Character. By simply following the attack code written [See Example 2 :) ] she has implemented cruel and vicious special attacks, and Dan's character falls in a bloodbath [all his].
Jon laughs at his downfall, shortly before Carla's new Spell [special Card, not currently planned] code reduces his Character to a pile of ashes.
Ross, meanwhile, has learned that playing Talisman can be dangerous to the health. He exploits code written by himself and Dan to enter the second level of the board, and wins the Game.