Old design notes

I am transcribing here entries from two notebooks:

• “Collected Algorithms (& Other Notes)” started 21 May 1981
• “Ideas & Thoughts / NOTES” started 17 Dec 1981

I only have a few entries from the first one, which really does have mostly algorithms, either in pseudo-code or implemented in some specific language (anyone need a binary search in 6502 assembly?). The second notebook has something over 20 pages of notes.

The notes mostly refer to my work on the multiplayer play-by-phone game project from the 1981-82 timeframe, as descibed in the previous sections and in the Archives main section. While most of them predate SunDog, they show the design work that Wayne Holder & I were doing together before FTL Games ever came into existence.

What I personally find most fascinating about these notes is that Wayne and I pretty much independently came up with the basic principles of object-oriented programming several years before I, at least, ever heard of it (which I first did in 1985 when doing an article for BYTE on a Smalltalk implementation release by Digitalk for the IBM PC, forgetting what was in this notebook). It’s not surprising, since we were trying to develop an approach to simulations, and OOP itself started the same way, with the SIMULA language in 1967. But it was eerie to pick up my notebook and realize what we had done.

My editorial insertions and corrections are [in brackets]. Words underlined in the original notebook are either italicized (for titles or emphasis) or in boldface (for definitions). I’ve done a bit of other editing for formatting purposes.

excerpts from “Collected Algorithms (& Other Notes)”

[entered 2 dec 81]

Some thoughts on AI game research

I would like to do a series of articles on using AI techniques in writing computer games, especially wargames. [Note: I actually did this, in part, with the “Silicon Cerebrum” columns in Computer Gaming World back in the early 1980s.] One area of research involves moving across terrain, which (by using a hex grid standard) can be dealt with in terms of graph algorithms. Areas involved include:

• goal definition, including decomposition into subgoals
• weighting techniques for decision making
• application of operators
• minimax/alphabeta cutoff
• learning
• tree searching
• and other thoughts (OGRE)

I would like to design & implement a real-time solitare wargame based on OGRE. Movement would be continuous & simultaneous; firing would be simultaneous as well, with the hex grid implied rather than actually shown. Within the basic time unit, all units could move up to their full allowance & fire once (and then must wait on time unit before firing again). The OGRE could fire each of its weapons once during that same time span. Movement should be synchronized so that ranging & firing can also be synchronized. Long courses should be able to be plotted. Defending units should be grouped into attack forces so that all units in a given force can fire simultaneously.

[Eric Robison, a game designer at 3DO made the following observation [11/27/00] about this entry when it appeared on my bfwa.com website 15 years ago:

“Do you realize that in the…”and other thoughts (OGRE)” section, you outlined the basics of the real-time strategy (RTS) genre? That puts it a good 10 years before such ideas reached the public :)”

Actually, I hadn’t thought of that at all. But I suspect there were a lot of us who were all having similar ideas; we just lacked sufficient hardware. ..bfw..]

[enetered 7 dec 81]

Data flow diagram for play-by-phone game

[omitted for now]

[entered 9 dec 81]

File organization for a play-by-phone system

For each game session underway on the system, there will be 5 files:

<game id>.MOV contains the moves of the N players involved in that game. Internal structure may be game dependent.

• <game id>.MAI contains electronic mail for communications between the players, and between the players and the system
• <game id>.STA contains status info for each of the N players
• <game id>.DAT contains the “universe” for the game session
• <game id>.USR contains <user id> and <password> info for each player. Also contains semaphores to control access to the game files.

The semaphore information in <game id>>USR is organized as follows for each player:

semaphore 1 bit. 0 means the player’s data (move, stat, mail) can be accessed & that the user can log on. 1 means the opposite.

semaphore code 7 bits. This code is to identify who has set the semaphore bit and why. For example, the system might block access for the following reasons: updating a game turn, insufficient funds in account, end of game, suspect attempt to “break and enter”. For a simultaneous multi-player game, each bit (of the total 8 bits) might represent a player who can long on (or some such thing). Maybe not.

..bfw.. 9/dec/81

Play-by-phone: object-based interactions

Concept: the game universe consists of a collection of objects. Each object has aspects (indication conditions) and levels (indicating quantities). Furthermore, an object may consist of component objects and may itself be part of a composite object. Objects are grouped into types, e.g., a person, a city, a planet, a spaceship, a fleet. Generally speaking, component objects will not be of the same type as the composite object to which they belong. They will, however, share certain attributes; most notably, they will (for game purposes) be tightly clustered in space and time. Thus when component objects become separated in space/time, they will cease to be part of the same composite object, and new composite objects may have to be formed. Likewise, distinct objects may join to form a new composite object, and a composite object may ingest another object (which, if it is a composite object itself, may or may not keep its identity as a composite object; if it does not, then it dissolves).

Player access to information about objects will be game-dependent. Typically, a player will own one or more objects. This allows him/her to issue commands to those objects and to examine their aspects and levels. He may also attempt to gather information on other objects. He may even try to influence the action of objects that he does not own. Ownership of an object may change during the course of a game, and objects may be independent, i.e., not owned by any player.

A player who owns a given object may write a script for that object for a given gameturn. The script consists of a chronological sequence of commands, with conditional qualifiers available to allow the object to react to different situations.

Besides object status, the player will need a history of events that transpired during a given game turn. Again, the amount of information will be limited to that which could be collected [through] channels available to him.

..bfw.. 10/dec/81

contents of “Ideas & Thoughts / NOTES”

Some thoughts on combat under an object-based system (OBS)

When two or more objects engage in combat, some sort of script is needed for each to follow — something like the robot programming in Muse’s Robotwar. I’ll use the example of two starship fleets fighting each other in some setting. If I control Fleet A, then I must tell that fleet under what circumstances it should fight Fleet B and under what [circumstances] it should flee. Furthermore, I could instruct Fleet A to use certain tactics in response to specific maneuvers by Fleet B. The success of a given maneuver could be based on the qualities of the component ships — crew & commander experience, damage, fuel, ammo, maneuverability, and so on — so that you have two fleets, each carrying out its own maneuver with some percentage of effectiveness and with some strength of firepower. Combat results based on maneuvers chosen, effectiveness in carrying it out, range, type, and strength of firepower and targets implied by the respective formations of the fleet. The question, of course, is how does one write combat orders?

..bfw.. 17 dec ’81

Basic ideas and definitions of object-based systems

The game universe consists of a collection of objects within a conceptual framework. Each object is of a particular type, such as “planet”, “fleet”, “ship”, “person”. It will have aspects, such as “location” or “owner”, which will describe certain qualities. It may also have levels, such as “population” or “number of ships”, which will describe certain quantities. Additionally, it may have relationships, which will describe its interactions with other objects. Finally, it will have a script to guide its actions during a given game turn. Processing a game turn consists of executing the scripts of the objects, handling the interactions between objects, and updating the aspects, levels, and relationships as necessary.

An object may consist of component objects and itself may be part of a composite object. Generally speaking, component objects will be of similar or identical types, while the composite object they form will be of a different type. They will also share certain attributes; most notably, they will tend to have the same owner and will usually share the same (general) location in space.

After a game turn has been processed, the player will want to access two bodies of information for each object he/she is interested in: its status (the current value of its aspects, levels, and relationships) and its history (which will include the actual portions of the script executed). If an object is not given a script for a given game turn, it merely sits idle, consuming whatever is necessary and taking only limited action in case of an attack. If a player is delinquent in his/her payments, then the objects he/she controls readily surrender to any attacking force.

..bfw.. 18 dec 81

Revised data-flow diagram for play-by-phone game

[Omitted for now]

..bfw.. 21/dec/81

Object script syntax and semantics

Two important features must be a part of object script syntax. First, it must be simple, straightforward, and foolproof enough that a player with low computer experience will not be handicapped by it. Second, it must be powerful enough to allow sophisticated use by experienced players. Thus we must put optional control structures into the language, structures which need never be used but which are available if desired.

At first thought, it seems that a script can be written as a chronological sequence of commands, each executed [in] its proper turn. At second thought, it would seem that there are two types of commands: those carried out in a sequential order (move to another star) and those invoked in specific circumstances (if attacked then flee). Finally, it would seem that all commands could be of the conditional type, with sequencing brought about by making each command conditional upon the completion of the previous command. I am not sure which is the best way to go. It seems that, for a more advanced game, “standing orders” are necessary for handling interactions between objects. A classic example is the meeting of two (or more!) combat groups. Combat is typically resolved in a series of rounds, usually ending with surrender, flight, or destruction. It would be nice to give a fleet orders outlining when it should do each. Even nicer would be combat orders, specifying certain manuevers and tactics to use.

..bfw.. 22/12/81

Script processing (gameturn update)

Players view status reports and submit scripts once each game turn. The game processor then performs a game turn update by executing the objects’ scripts. To do this, the game turn is subdivided into steps, each representing a unit of time. For example, if a game turn represents the passage of 1 year within the game, the game steps might represent 1 day, 1 week, or 1 month. The more steps per game turn, the higher the “fidelity” of the simulation and the greater the overhead (more processing, longer object histories, etc.). The game turn update procedure is roughly as follows:

read in all of the objects with their scripts
FOR step := 1 TO stepmax DO
-- FOR each object executing a command that ends on this step DO
---- update status appropriately
---- mark as not currently executing a command
-- FOR all objects interacting with other objects DO
---- resolve interactions as much as possible
---- update status appropriately
-- FOR each object not currently executing a command DO
---- IF there exists an allowable command in that object's script THEN
------ mark object as currently executing a command
-- FOR each object currently executing a command DO
---- update status appropriately
-- IF conditions lead to premature termination of command THEN
---- mark as not currently executing a command

..bfw.. 23/12/81

Object script processing — game step definition

The algorithm for script processing will be affected by the duration of the game step compared to the duration of interactions. If the game step is short enough for an interaction to occupy most of it, then an object undergoing an interaction will not be able to start a command during that step. In fact, a decision will have to be made regarding an object’s ability to withdraw from interactions. For example, an object could immediately withdraw and start a command that step; it could participate for one step (an minimum?) and then start a command the following step; it could participate for a number of steps and then (voluntarily) withdraw; or it could be forced to participate each step until certain conditions are met and then (and only then) start a command the following step.

If, on the other hand, game step duration is long compared to interaction duration, then an object could interact and start a command in the same step. There is a temptation here to subdivide the step itself, allowing multiple rounds of interaction each step. I think that I would prefer a short game step, though, where each object can either conduct one “round” of interaction and start one command (which will end no sooner than the start of the next game step). I think there should be somewhere from 1 to 100 game steps per game turn, with the number of steps/turn being directly proportional to the complexity of the game and the “length” (in game time) of the game turn.

..bfw.. 28/dec/81

Status report generation — history file

During the processing of a game turn, a history file is kept to show what happened to each object during the course of a game turn. One approach is to make this file consist of fixed-length string records with the following format:

<object> <step #> <location> <command or interaction> <other appropriate info>

With this format, the file can be sorted on the first two fields (actually, just the first one may be sufficient), producing a chronological history for each object. Information might include who owned the object and who observed it. This information would determine who would be able to read what portion of an object’s history.

..bfw.. 29/dec/81

Idea for a book or series of articles

Most software engineering texts I have read tend to deal with developing software in a large environment, i.e., at a job. What about a book (or series of articles) dealing with software engineering for the solitary programmer? Or for small groups? The book would be aimed at people developing software on personal comptuers and would be geared toward the problems faced in working alone or with one or two other people. Emphasis would be placed ont he difficulties faced for different languages & operating systems, etc.

..bfw.. 30/dec/81

Some ideas on simultaneous but distinct games in the same universe

It should be possible to run simultaneous, non-equivalent games in the same “universe”. The game that a given individual plays would depend simply upon what objects were under his control, since that would [determine] the set of possible scripts he could write. When a player selects a game, he is given a set of objects, a certain amount of information specific to his situation, and (perhaps) certain goals to guide him in his efforts. He then develops 3 things: a growing body of information, control over more objects, and relationships with other entities (players and/or daemons). He uses these to pursue his goals or he may even change his goals. How do you define success?

The problem I see is that faster turn-around is needed for players working on “lower” levels. One solution is to define a minimum game turn period (1 week, for example) such taht any command or interaction can take no less than that, and then update the game every 24-48 hours. Scripts are trimmed as processed, and history files are kept for the last n game turns. That way, a player can write a large script and let it run for a while, or he can check in every game turn to see how things are going, to modify current scripts, and to write new ones.

This setup would require a pricing structure that would encourage players to minimize connect time. There should be a base per-game-turn cost with one free call-up per game turn. Each additional call-up should cost one game turn. Also, there should be a time limit or timeout (15-20 minutes?) — as before, the first is free, and each add’l one costs one game turn.

..bfw.. 5 jan ’82

Running game-related programs at the user station

It would be nice to have some means whereby computer owners could download data (and possibly software) from the central system and run some real-time modules of The Game, e.g., an Adventure-like exploration or some sort of interactive fleet combat. The problem to be dealt with is data integrity, i.e., if data is downloaded, will it be uploaded in some revised form to the host system? If so, can tampering/cheating/eavesdropping be prevented? Because connect time will be at a premium, a direct line probably can’t be maintained. The immediate solution is to not let the player send the database back, but to have it be a source of information for him/her (requiring some work to get it out).

Object definitions

I have been doing some thinking as how to define objects. My first effort has dealt with trying to isolate those factors that need to be defined for all objects. The four (4) that seem to be universal are:

FACTOR DEFINITION STORAGE
TYPE what the object is 1-2 BYTES
ID a unique numeric ID 2-3 BYTES
OWNER who owns it (player, demon, unowned) 1-3 BYTES
LOCATION where it is 2-8 BYTES

The rest could be stored as encoded bytes, with either internal (tag fields) or external (table-drive) decoding. I think I prefer internal decoding, because it allows objects of the same type to be of different lenghts & compositions. Table-driven processing could then require a certain field and search the tag fields for it.

Interesting thought: with encoded objects and table-driven processing, the interpretation of objects and history would depend upon user interface routines. What would happen if you could impose two completely different but internally consistent interpretations upon the same game universe? Suppose one set of players thought their game dealt with ancient Earth, while the others thought they were out among the stars? Could be very interesting.

An excellent suggestion from Wayne: the location field of a component object should point to the composite object to which it belongs. More generally, if one object is in or on another object, its location field should indicate that other object. That way, if a number of objects (people, whatever) are in a ship, their locations are automatically “updated” whenver the ship’s position is updated.

..bfw.. 15/jan/82

FLASH! Using internal encoding of information (tag fields) for objects, limited information can be generated by making a copy of the object and eliminating whatever tag fields the player has no right to know. Or, if necessary, the fields can be modified to represent a vaguer (?more vague?) level of knowledge.

..bfw.. 15/jan/82

Possible test implementation

For a test implementation (up to 255 objects, up to 7 players), let’s define an object as follows:

[Sketch showing a box with four sub-boxes–TYPE, OWNER, PREV, NEXT–and the rest of the box just labelled “TAG FIELDS”]

The file would consist of 256 records of 128 bytes each. Record 0 would be the file headers & contain the AVAIL pointer. The file is initiated with all values set to 0 except for PREV and NEXT. These are used to form a giant linked list.

When an object is created, the record that RECORD(0).NEXT is pointing at is used and all pointers updated. If an object needs additional space, another blank record is pulled and linked to that object’s last current record. For a non-blank record, and value of 0 = [null] in PREV and NEXT.

If an object is destroyed, it is linked back between RECORD(0) and RECORD(0).NEXT. Occasional garbage collection would be nice (for within objects), and there might be reasons for sorting the AVAIL pointers or even the whole file.

Here are some possible tag field formats:

[diagram deleted for now]

..bfw.. 18-19 jan ’82

Business approach

Don Ewing [of Creative Computer Systems] called yesterday (in response to a letter) to say that CCS is still interested in funding Wayne & I in PBP development, though they only have $4-5K to work with right now. After talking with Wayne last night, I am tentatively considering the following approach:

• CCS buys a development system (though I may act as purchasing agent)
• Wayne & I develop a small scale model system (not Ralph’s game) to serve two purposes:
  • to test the feasibility of some of our PBP ideas
  • to show CCS a working system so as to justify further investment
• if CCS is satisfied w/out demo system, then we can negotiate an agreement for development of a full-blown system
• if CCS is not satisfied, then they retain the hardware system, and Wayne and I write off any time spent in development
• in any case, Wayne and I retain full rights to the software we develop until such time as we sign an agreement or agreemetns surrendering any of those rights
• at time of delivery of the hardware development system, a deadline will be set for delivery of the prototype system software. If a working system is not delivered by then, then CCS will have the option of cancelling the project and taking back the hardware or setting a new deadline

20-jan-82 ..bfw..

Business approach

Wayne and I met for a few hours last Thursday night (21/jan/82) to discuss how to approach our play-by-phone development. After a bit of discussion, we reached the following conclusions:

• the amount of funding & support that CCS is offering us isn’t sufficient to warrent committing ourselves to work for them.
• it is questionable whether any amount of funding would be worth it.
• we need to maintain flexibility and freedom so that:
• we can follow our own ideas;
• we can ignore PBP development to work on other projects (e.g., The Word);
• we can market it ourselves, if feasible
• we’re not really sure how much we can trust CCS to back us fully.

The upshot is that I wrote Ralph & Don this morning and told them (nicely) that Wayne & I didn’t want their backing for now,though we may be interested in it once we have what we feel is a marketable product. Below is a copy of the letter. [letter omitted for now]

..bfw.. 25 jan ’82

Object classes

[and here is one of my all-time unwitting understatements in print:]

It might be helpful to group objects into classes, such as ships, persons, installations, etc. That way, commands and relationships can be defined using general classes, rather than exhaustive lists of objects (which would need to be updated whenever new types of objects are introduced). For really sophisticated systems, a set of bits could be used to indicate certain mutual attributes; for example, all objects capable of combat might have the same bit set. For given verbs, then, the subject and/or the object would be required to have certain bits set (or cleared). That would make for smaller command tables plus eliminate most of the table updating that would be necessary when new object types are introduced. A list of possible attributes might include:

• able to attack
• able to be attacked
• capable of holding persons
• capable of intra-system movement
• capable of inter-system movement

and so on.

26 jan ’82 ..bfw..

Command context and persona development

One of the ideas that Wayne and I have been kicking around deals with representing players as persons (a type or class of object). A given player’s persona would then be responsible for issuing commands to the objects that the player owned. This would involve the notion of context. A given person’s ability to issue commands would depend upon where he/she is and the available lines of communication. First, if that person is enclosed by an object he/she controls, then he/she inherits the command set of that object and can issue, as a personal command, any command capable of being carried out by that object. This principle can be applied through several layers of enclosure. The key here is that the objects are closely joined in space & time and that the commands be unambiguous (or what if they’re not? Some interesting possibilities…). Second, to issue commands to an object that is separated from the person by space and/or time, some means of communication is necessary. If the object is able to be talked to instantaneously, then it is as if the object were present locally, and both commands and status are communicated immediately. Otherwise, some sort of time delay must be built in, both in sending commands and receiving status reports. This could provide some wonderful headaches for the players. I believe that it also requires two other developments. The first is the ability to issue contingency scripts to objects, in order to allow them to react to events or circumstances at any point during the execution of their regular script. The second is the creation of objects representing scripts and status reports, so as to model their propagation through space and time. Indeed, a general model for the representation and transmission of knowledge will need to be developed.

27 jan ’82 ..bfw..

Syntax of scripts / macro procedures / learning / hidden factors

No matter how I look at it, it looks as if we’re going to have to define our own “programming” language for the users to define scripts with. Some of my many thoughts concerning this include:

• it should have a powerful means of expressing conditionals
• it might be wise to have a “macro” or “procedure” capability
• a BASIC-like flavor wouldn’t hurt (or would it? Why be mediocre?)
• control structures should be straightforward (REPEAT..UNTIL, WHILE..END)

The more I think about it, the more I like the idea of macros/procedures, especially with regards to contingency scripts. This would make it very simple to write, say, one general contingency script for a given type or class of objects (e.g., ships or colonies). It would also make it very simple to change the contingency script for all these objects. Perhaps a given player could maintain a file of macros/procedures which his objects’ scripts could then reference. Indeed, that file would represent the player’s accumulated experience and wisdom, since he would tend to stick with “tried and true” techniques in these. Another benfit of the macro/procedures would be an ever-increasing complexity and sophistication in script writing. In fact, if we were to examine all the players’ files on a regular basis, we could probably create some highly “intelligent” demons which would simply switch between different contingency scripts according to circumstances. In a very real sense, the players would be “teaching” their objects how to act.

The questions that arise are:

• How do we keep the game from getting “too easy”?
• Would a [current] player with a set of well-developed scripts have an unfair advantage over a new player? If so, how do we balance it?

I think the answer to both of these questions is to give the objects “hidden” attributes, i.e., aspects and levels that affect performance but which the player cannot directly monitor. In some respects, these might represent cultural or biological influences. Thus, if I capture a ship or installation manned by beings of a different culture than the one I am used to, I may have a very difficult time controlling it with my well-developed scripts. An even-more-insidious idea is to simulate changes within a culture by changes these attributes in objects I currently control. Slow changes could represent the natural evolving of a culture, while sudden, sharp changes would model social revolutions and could even cause me to lose control of some of my objects. If you really wanted to make things difficult, you could make it spread from place to place. Lots of possibilities….

29 jan ’82 ..bfw..

Additional thoughts on previous entries.

Attribute bits

It seems that a lot of the attribute bits would be dedicated to signalling the ability of a given objects to execute a particular command. I would like them to be a little more flexible/informative so as to allow new commands to be added w/o worrying about expanding the attribute list. This means that we’ll need to do a lot of thinking about a comprehensive set of attributes.

Test bench

Wayne suggested a “test bench” approach to script development, i.e., using station software to test out a script before sending it to the host computer. I think it’s an excellent idea. To make it more fun, you could allow players to pit objects against one another, thus making a two-player game out of it. I can see a few areas of concern, though. First, if we download actual object descriptions, we will need to filter out any “hidden” factors, lest clever players inspect the disk files (or memory) and decipher them. Second, this will require distributing our command resolution tables. I really don’t think that’s a problem, but we’d better be sure.

Perhaps a solution to both problems is this: distribute a “test bench” system complete w/command tables that do not take hidden factors into account. The users use the software to create objects of varying attributes and relationships. They can then generate a setting for the objects and test out the scripts. This avoids releasing any information the players shouldn’t have. If they wanted to do testing with “the real thing”, we could provide an interactive environment for that (at extra cost).

1 feb ’82 ..bfw..

Test bench

Wayne brought up the idea last night of a player using gathered information along with the test bench program to try out certain plans before actually committing to a move. For example, he might simulate an attack on a particular fleet, using information gathered by whatever means, or he might try several different production schedules for a given planet to see which fits his needs the best. Of course, since these run-throughs wouldn’t take the “hidden factors” into account, their results wouldn’t be exactly the same as in the “real world”.

Limits to power

One question raised in the Wednesday group meeting last week was, “What if everyone wants to be emperor?” One solution is to make it naturally very difficult for everyone to be emperor. How? By designing the game so that it is nigh well impossible for a single player to run an entire empire for very long. I tend to think that the very nature of the game system will do this. As a person controls more and more objects, he will find it harder and harder to keep track of them and to keep their scripts current and effective. He may be able to keep it up for a little while, but his empire will be very susceptible to internal difficulties and external attacks. His only real solution: recruit other players to govern portions of his empire. Of course, then he faces the problems of rebellion and secession by disloyal subordinates. Which means that he is going to stay emperor only as long as he can hold off those seeking his power. Thus we would have a marvellous recreation of real life.

How does a leader keep the loyalty of those under him/her? How does he keep them happy enough so that they don’t turn on him or start their own empire? I guess that depends upon what the subordinate wants and what the emperor has to offer. The emperor might offer the following:

• resources (money, food, supplies, people)
• objects (ships, colonies, worlds, etc.)
• power (goes w/having more objects under your control)
• freedom (more latitude in how he runs his objects) (and what he does with them)
• glory (can come w/power & freedom) (publicity?)
• game turns (pay for his movements)

2 feb ’82 ..bfw..

[These next three paragraphs all anticipate actual issues in modern MMORPGs]

Multiple-character players

Wayne raised the issue of a given person (or group of persons) entering the same universe as multiple characters. Couldn’t’ this coordination of efforts give that player an unfair advantage? Probably, though I’m not sure “unfair” is the right word, since the player(s) would be paying for the extra characters. In fact, a player might want to make one of his/her other persons his chief subordinate (his “hand-picked heir”) so that this other person can step in, in case of the “death” of his main person.

Coordinate reference

One technique to make cooperation harder would be to set up different coordinate axes and reference points for each “empire” (i.e., sovereign world). Basically, each independent world would consider itself the origin of a 3-axis cartesian coordinate system. The axis orientation would vary from system to system. That way, a player randomly re-entering a universe that he is already playing in would have a pretty difficult time locating his alter ego.

Moving

A thought: databases could be “separate” by space, i.e., each database might represent a globular cluster or the arm of a spiral galaxy. That way, players could actually “move” between databases, but the large “distance” would eliminate almost all interactions between them (i.e., the databases).

3 feb ’82 ..bfw..

Play-over-the-phone (POTP) games

Wayne & I have been discussing ideas for computer games between two or more players conducted over phone lines. Some of our ideas include:

a software protection scheme. Each copy of the software contains a unique identifier which it sends to the other machine(s) on a regular basis. The software will not work if it receives its own identifier over the phone lines from another system. This would hinder someone from buying a single copy and giving copies to all his friends to use, but it would not keep him from making backup copies. Of course, if they bought two copies and gave everyone a copy of each, then any two players could play.

an idea for real-time multiplayer games. Conference calling will probably become a more popular option for home phone systems. This would allow three (or more) players to be on the phone simultaneously. Would it be possible to develop a modem-based protocol to allow them to talk to each other?

a Robotwars-like game, for over the phone play. A player develops his robots, army, fleet, or whatever, and then he calls up an opponent. Their forces are pitted against each other as they look on. A variant of this could use a third computer as the “referee” and host for the actual battle. The players would get back status reports and would have a limited ability to issue orders.

11 feb ’82 ..bfw..

Ideas for Silicon Cerebrum column for CGW

[by now, I was writing this column, which focused on AI techniques for computer games, for Computer Gaming World]

One of the fundamental problems of writing an intelligent game-playing program is developing effective decision-making algorithms. Take, for example, the task of moving a single unit in a wargame. First, the SC [i.e., the computer opponent] must have an overall goal it is working towards, typically defined by the victory condition of the game. These may be very sharply defined (as in OGRE) as a single goal or a number of alternative goals, or they may be fairly general and achievable in a number of ways. The overall goal is typically broken down into a number of sub-goals, and so on, until individual units can be manipulated toward some specific goal. If a number of units are involved, then some coordination of actions will probably be needed so that several units can act towards a common goal. Where issues such as distance, terrain, stacking limitations, and range are involved, care must be taken to properly select destinations and routes for each unit.

22 feb ’82 ..bfw..

PBP language syntax

Wayne bought the computer game RobotWar, and he and I have spent a number of hours playing it. A number of reflections are in order:

the language used is simple (BASIC-like) but surprisingly effective. The main feature that Wayne & I would like to see is an “ON <condition> <statement>”, which would make some concerns easier to handle. The language should help to give us some ideas for our own system.

Forrest Johnson [editor of The Space Gamer] feels that something smacking of programming will not go over very well. I’m not sure I agree, but a menu-driven optional version (a program generator!) will not hurt at all. Indeed, this might be a good way to “sucker” people into programming.

I see the language as combining the best features of a number of different languages (Pascal, FORTH, BASIC). I do NOT think that it should be (visibly) stack-oriented, since most users couldn’t cope with stack visualization. By allowing functions & procedures with (simple) parameters and “ON <condition>” clauses, and by implementing IF-THEN-ELSE, FOR-DO, WHILE-DO, and REPEAT-UNTIL statements, GOTO-based programs could be avoided (*needed: EXIT clause for procedures, loops *).

since both the allowable commands and the accessible values are object-dependent, script verification would need to take place within the context of a given object and, indeed, with the context of the space/time location that the object finds itself in.

above everything, the syntax should be simple.

25 feb ’82 ..bfw..

SCRIPT SYNTAX

[A set of “railroad” syntax diagrams for the script language syntax, defining plan, plan body, script, script header, script body, and statement.]

25 feb ’82 ..bfw..

SCRIPT SYNTAX (CONT.)

[some more syntax diagram, covering expressions and identifiers]

9 march ’82 ..bfw..

(CONT.)

Above is a fairly simple syntax for a general script language. A number of the definitions –<cfunction>, <ifunction>, <command>, <tag id>–are context-specific, i.e., they must be defined in terms of <object id>. The other undefined terms (such as constant, plan id) just haven’t been defined yet.

Some limits: nesting levels (plans calling plans), recursion (none?), # of condition slots (5? 10? varying? depends upon object?).

10 march ’82 ..bfw..

OGRE

Got a letter from Steve today about OGRE. I think I’d like to do it. I need to get a copy of the game and think on it for a while.

(? march ’82 ..bfw..)

[“Steve” is Steve Jackson, of course; OGRE is one the classic game designs of all time, a futuristic wargame played on a board the size of a legal sheet of paper, with one of the players commanding only a single unit: the OGRE, a giant cybernetic tank (think Keith Laumer’s BOLO series). Steve approached me about doing a computer version, but we couldn’t agree on royalty terms.]

REBIRTH

[This was a backstory setup for a game design of mine that never when any farther]

It was both ironic and eerie that Sol should produce the two dominant races in this arm of the galaxy, human and jin, each adapted to an environment deadly to the other. Yet is was undoubtedly their close proximity that made them dominant, for each helped the other to the stars. It was the unique blend of Terran and Neptunian technology and thinking that produced the stargate, opening up the galaxy to two aggressive races, two races that did not get along very well together. Yet necessity forced cooperation, for stargate operation and maintenance involved tasks that one race could do well and the other could not. Every system settled by one had to be settled by the other, and planetforming became the order of the day. Still, the tension between jin and human was constant, and often erupted into intrasystem war. When this happened, stargate operations ceased, and the abrupt cessation of vital trade usually forced a quick end to the war. And so the jin-human sphere of influence grew.

Then, in the early 27th century, rumors grew among jin that the humans had perfected a technique allowing them to operate stargates by themselves. The humans denied the rumors, but were not believed. Strong political and religious movements sprouted among the jin, calling for a holy war against the humans. As the cry went forth from system to system, the humans got very nervous. A human-only stargate had been developed, but it was so unstable as to be useless. Nevertheless, the jin had found out about it–and were angry indeed.

Most empires tak a long time to crumble. The Jin-Human Federation collapsed in a matter of weeks, as jin in each system destroyed the stargates and launched a war upon their human neighbors. The human worlds, though, had not ignored the warning signs. They were ready for the jin. The wars in most systems resulted in the collapse of both civilizations. The long night had begun.

9 june 82 ..bfw..

To the Stars!

[Another game design idea, possibly for the play-by-phone system. Sounds a bit like Sid Meier’s Alpha Centuari, which came out 16 years later. 🙂]

An idea for our game system: a phased approach to interstellar expansion. The first game would involve colonization — Earth fleeing from an invading race or an imminent disaster (bad star?) — and would give each player a unique and richly detailed solar system to settle. But before he (or she) goes there, he must select crews & equipment for his colonization effort. Then, in sort of a “system dynamics” approach, he must develop a successful colony, based on exploration, resource management, and growth. If a colony fails, the player will have to start from scratch, i.e., re-form his colonizing team and once again approach the virgin world. (N.B. The original disk must be write protected, but not copy protected. The player must make a copy of the program onto another disk in order to play it…using a special copy program provided with the master disk. In fact, booting the master disk invokes the copy program. When a colony fails, the world is destroyed.)

Climate and seasons should be simulated, as well as natural disasters, illnesses, etc. Native flora & fauna should be somehow included. Planets should move in their orbits, as should moons. And all should have databases. Habitablity costs are needed. The colonists have very high tech stuff, as a lot of hand waving can be done. The warp engines, however, were a one-shot affair, though they can be stripped for parts.

(And they should be looking for alien artifacts. An alien installation was found on /Phobos/, one which appeared to have been deliberately designed to be found…and understood. Translations indicated that life on Earth was a result of incredibly advanced genetic engineering, and that the same had been done on myriad systems…)

11 jun 82 ..bfw..

WDB

[WDB = world data base, my effort to figure out how to model and simulate a world]

I’ve been getting ahead of myself a little in designing the world data base (WDB). I’m getting overly involved in the minor-hex problem [mapping smaller hexes within larger ones]. I need to work on modeling the planet within the system. This includes the following:

• star type, with attendant information
• orbital parameters
• axial tilt and period of rotation
• modeling terminator [the night/day edge] and seasons on planetary surface

17 jun 82 ..bfw..

WDB

I find myself torn between two desires: wanting to increase detail and wanting to reduce storage requirements. Here are some of the ideas I’ve had:

insure some upper limit of major and minor hexes by requiring a certain number or percentage to be open ocean hexes (i.e., with no islands, etc.). A reasonable amount would be 50% ocean; in addition, there would be ocean hexes with minimal detail, such as a few islands or a small portion of the mainland.

This, of course, would reduce storage to less than 50% of the theoretical maximum.

[You can tell I’m writing this in 1982, when both RAM and disk space were precious commodities.]

Wayne & I have talked about using generators to create large areas of identical terrain minor hexes. One idea I’ve toyed with works as follows:

• specify the terrain type
• specify the starting hex
• following with a sequences of 3-bit values:
• 0 = end of sequence
• 1-6 = next hex of some terrain type
• 7 = all six hexes are of some type

..bfw.. 18 june ’82
simple objects

A simple approach to modeling general objects in adventure-type games might be to come up with a list of 16 possible attributes that some object might have. Each object then has values for each of those attributes, though most objects will not have signficiant values in all 16 (or 8 or 32 or whatever). More generally, the attributes might vary from object class to object class (i.e., attribute #3 for a starship is different from attribute #3 for a car), or we could get back to the tag field concept.

..bfw.. 25 jun ’82

BATE

[at this point, I’m now VP of R&D at Oasis Systems and head of FTL Games, and I’m working on SunDog. There are only a few entries from my 2 1/2 years at Oasis/FTL, mostly because I was too busy to write anything down]

Last fall [1982], I ran a game of “Freedom in the Galaxy” on one of the local CBBS’s [computer bulletin-board systems]. I called the game “Blows Against the Empire”, though I gave full credit to Avalon Hill and recommended that the players go out and buy copies of FITG. Now, I want to design my own version of BATE. It will follow the same theme (rebels vs. Empire), but it will be specifically designed for play-by-phone use.

THE MAP: BATE will use a 3-D star map and a warp capability along the lines of SunDog. Jumps will be instantaneous…or maybe they won’t. Rebels need greater mobility, so Imperial fleets will take longer to move through space. Or, better still, the larger ships will make shorter jumps. Whatever. Anyway, a 3-D map with real solar systems and real worlds.

THE OBJECTIVE: as in Star Wars, et al., the rebels wish to overthrown the Empire, while the Empire wishes to crush the rebellion.

THE PLAYERS: each player starts out as an individual (good, Webster, good). I will need to design an Imperial hierarchy and a rebel nucleus. I’ll also need an appropriate set of characteristics. No Jedi/Imperial knights.

ACTIONS: FITG has an excellent system — “missions” — for handling this. I don’t want to copy them, but I’ll be hard pressed to come up with something better.

GAME TURNS: here’s where I throw out FITG completely. With asynchronous moves from multiple players, ordering [of game turn steps] is impossible. Here are some ideas:

• 3 updates each week (Tues, Thurs, Sat)
• combat is resolved according to standard orders
• players are pretty free in describing their actions

..bfw.. 29 april ’83

[As it turned out, I had little time to run a BATE play-by-phone game, since I was spend long hours getting SunDog finished for debut at the West Coast Computer Faire in March, 1984.]

BATE, cont.

I swore that I would not re-start BATE until I had my own BBS. The question is, what should the user interface look like?

SIGNON: A brief logo, followed by user id prompt (N=none). If user, then game id, then password.

BATE – action points

A key component in “Blows Against the Empire” is that of action points (APs). A player has a certain number of action points to expend each turn. These represent not only what his (or her) character can attempt, but also what those units under him (or her) control. The number of APs allocated to a specific task represent effort going into it. Generally speaking, then, the greater the # of APs devoted to a task, the greater its chance of success. Increases in power are shown as greater #s of APs to be used each turn.

[This, of course, was a common concept in many paper-based war/RP games at the time and is very common in today in computer games.]

As problem w/APs is that they require some bookkeeping on the part of the player. As with SunDog, the game should be as painless as possible. So how do we resolve this?

[undated except for “Copyright (c) 1983 by Bruce F. Webster” at top of page]

[a gap here; the notebook picks up 5 years later, in 1988, four years after leaving FTL Games]

BATE

An object-oriented approach to universe simulation may be effective, especially when embedded in a procedural language, such as Objective C. What I am yet unclear on is how best to implement the hierarchy of component/composite objects.

The basic component of a universe is a star. Its mass, luminosity, spectral type, etc., determine the flavor of its solar system. A planet can send messages to the star (and other planets) to determine orbital updates, solar radiation, etc. On the other hand, we may not want/need too much detail or fidelity, if it bogs things down.

..bfw.. 16/3/88

SunDog II: Old Scores to Settle

apparent goal: find who murdered your uncle

means: database research, public records, questioning of individuals, news reports

concept: modeling of personality

factors: logic, emotion, greed, altruism, love, hate, indifference, courage, cowardice
some factors can temporarilty (or permanently) override others
decisions made on basis of factors – threshold of vecotrs – closest fit?
influence decisions by influencing factors – catastrophe modeling?

concept: moving toward goal

set of goals – broken down into PERT chart of subgoals

lots of tasks/goal – indication of other goals that they lead to

state nodes (flip-flop, gradient, catastrophe, permanent) – “plug” into goal states or influence other states

*key: identifying logical connections between state nodes (source of research)

logical connections can change over time (treaties, diplomatic relations, trade agreements)

[undated]

BATE

In Sun Tzu’s The Art of War, he spends his first chapter on “Estimates” (which Griffith says also means “reckoning”, “plans”, or “calculations”). The entire chapter reads like the description of complex weighting functions & decision tables — both proactive and reactive.

Here are the five major factors in determining who will win:

• moral influence (tao): popular support, moral, etc.
• weather: impact on operations & personnel
• terrain: distances, maneuvering room
• command: the general’s attributes:
  • wisdom: tactical skills
  • sincerity: integrity, honesty, even-handedness
  • humanity: concern for others, love for mankind
  • courage: willingness to risk
  • strictness: discipline
• doctrine: organization, control, promotion, supply routes, provisioning

He says that you can determine the victor based on the following seven factors:

• which ruler has [more?] moral influence
• which general is the better commander
• which army has better use of nature [weather?] and terrain
• which troops are stronger
• which army has better trained officers & men
• which adminsters rewards and punishments “in a more enlightened manner”
• which army is more disciplined & effective (“regulations & instructions are better carried out”)

What Sun Tzu doesn’t give is information about how to quantify these values and how to weigh them with respect to one another.

Sun Tzu then gives guidelines as to how to respond to the enemy’s situation and your own; the guiding principle is “all warfare is based on deception”.

• when capable, feign incapacity
• when active, feign inactivity
• when near, appear far away; when far away, appear near
• lure the enemy in (by, for example, disorder), then strike
• defend against concentration; avoid strength
• anger his general & confuse him
• pretend inferiority & encourage his arrogance
• keep him under a strain and wear him down
• when he is united, divide him
• attack when he is unprepared

[undated]

SunDog
03aug92 (mon)
2311 pdt
at work

I had dinner last night with Jerry & Roberta Pournelle [ink changes from black to blue] and I’m going to change pens. Anyway, the subject of SunDog came up. Jerry felt I should push ahead and do a SunDog follow-up. He noted that there are people today — eight years after the game was released — who still remember it fondly. Why? Because it avoided many of the sins of its day. Instead of being a “railroad” game, it provide[d] the user w/an open-ended universe. Instead of text & typing, it was entire joystick controlled, and had its own system of windows, icons and menus. Its major flaws: not enough storyline and too much attention to detail (e.g. you had to literally stop to eat and sleep).

So, re-doing SunDog now, what sins of today would I avoid? First, the player should need no [external] bookkeeping — the character’s computer system should literally log every piece of information and allow the user to recall it. Likewise, the user should have basic computer functions — notes, database, spreadsheet, calculator — at his fingertips. Equipment should be highly intelligent and programmable.

Second, the emphasis should be on consequences, power, and morality. Planet and system simulation is passe — how to simulate local politics is the real challenge. What if the player has to spend (deepsleep) time in prison? What if the local coast guard is in cahoots w/the pirates? What if they are the pirates?

Third, stories must be woven about the player. These stories must illustrate moral or philosophical principles, with key non-player characters (NPCs) illustrating the appropriate virtues and vices. Themes of sacrifice, service, nobility, and perserverance must arise.

Fourth, the universe must live on its own, with events going forth even as the player ponders his next move. NPCs should have goals & agendas, and the means to attempt to carry them out.

Here, then, is the SunDog trilogy:

SunDog: Frozen Legacy
SunDog II: Old Scores to Settle
SunDog III: Blows Against the Empire

..bfw..

15jan93 (fri)
1756 pst
work
(Pages on CMB)
[Pages offices on Clairemont Mesa Blvd]

A discussion on BIX (BYTE Information Exchange, a teleconferencing system originally set up by BYTE Magazine, but now owned by General Videotext) about computer game design, as well as a recent effort to make photo-copies of all my old Space Gamer and Silicon Cerebrum articles, has started me thinking about SunDog again.

While I want to avoid the “second system” syndrome (over-engineering it), I also want to rethink all assumptions. The original SunDog was written for a very limited system (64kb of RAM, 140kb floppy drive) — given current technology,

[and that’s where the entry–and the entire journal–ends]

 

Copyright © 1981, 1982, 1983, 1988, 1992, 2015 Bruce F. Webster. All rights reserved.