#15: Welcome to the Twenty-First Century

by Shannon Appelcline

January 4, 2001 – I'll admit it, I'm a math geek. Though I know full-well that the average person using the Gregorian Calendar counts the 21st century as beginning in 2000 – and though I know full well, as a writer, that words are defined by how people use them – for me the new century started three days ago, on 1/1/1. Without Y2K looming over the turn of the year it wasn't quite as exciting – but I can feel the difference now. As of three days ago, we're in the age of cyber implants, quantum computers, and nano constructors. If we live out the next hundred years, we'll see an age where scarcity is abolished, where computing peripherals expand mankind's intellect tenfold, and where the political landscape of the world mutates in ways to make it unrecognizable from what we see today.

Those are my predictions for the twenty-first century.

But What About Y2K?

That was the science-fiction reader and writer in me getting out of hand. What I really wanted to do this week was look backward, not forward, at the past – at what the last year has brought us.

I've already detailed the history of Skotos and Castle Marrach and that's really what we've done over the last year. This week, however, I'd like to take a slightly different route, and share with you a few of the Roads Not Taken from the last year: things that we thought about, but didn't do. Revision Control (1/2/00)

The first record I can find of a Road Not Taken dates back to the second day of the year 2000. A letter from our lead engineer talks about revision control, not necessarily the most exciting subject, but a good place to start this week.

For those of you not skilled in computer speak, revision control is a method that you can use to back up old copies of something that you're editing. Say you had a paper that you were working on, and you started it on Monday, then edited it on Tuesday, and then polished it on Wednesday. Each of those days of work would be saved as a different version (v1.0, v1.1, v1.2) and you could easily go back to any day's work or examine the modifications that were done between any two days. Don't like your v1.2? No problem, just revert to v1.1.

Revision control is something that we'd use to help out our StoryBuilders – to create the best game development environment possible. It would serve us really well within our game because we could use it for all of our objects (people, locations, objects). It would be terrific for normal happenings in the Castle: if we wanted to decorate the Dining Hall for the Poet's Convocation, we could write a new description, then just revert when we were done. In addition, it's a great aid for preventing errors. We've deleted numerous objects accidently and have wished that revision control was available.

This was all to be connected to a Quality Control system, where people could review items before new versions were released to the public and bugs could be directly linked to relevant objects. You've seen a start of this system, with our "bug" and "idea" commands, and we do have comment fields associated with our objects, meant to be used for QC, but that's as far as we've gotten so far.

Like a lot of our great ideas, revision control (and quality control) has gotten delayed due to work required for critical systems.

Status: Delayed.

The Vortex Game (3/2/00)

We've had a number of games that haven't made it. One of them was Vortex, which appeared in our original business plan as one of our first three games, along with Alvatia and Golden Gate: 1849. (No Castle Marrach, you'll note.)

Vortex was to be a totally different type of game: a textual game where you had constrained choices. Sort of like a choose-your-own adventure book, but much more dynamic because a computer is controlling the whole thing. We had a name for this type of game – Serials – derived from the fact that you only needed to play for a little bit each day (15-30 minutes tops).

One of our game designers even wrote up a sample screen:

It's mid-morning (local time) on Thursday, June 12th, 2234. The suns are shining in the sky over the New Columbian Vortex Gate Terminal; weather reports call for increasing cloudiness, and light showers on the coast later in the day. You arrived at the nearby city of First Landing yesterday, spent too much money last night, and woke up a bit late. After cleaning up, packing, having breakfast, and checking out of your lodgings, you headed over here on the monorail.

The Terminal Facility is the above-ground portion of the Vortex Gate complex on New Columbia – the actual Gates are built in a cavity two miles underground. Storage facilities, regular and quarantine residences, a small commercial district, and a tall pair of office buildings are gathered about the shaft-car station. A white line on the southern horizon is the orbital elevator. Greenery, walkways, monorail pylons, and fountains all contribute to the 'up scale office park' feeling you get. A few hurrying people, with serious expressions and professional wardrobes, are the only pedestrians; nobody seems to be paying attention to the carefully-produced landscape.

You can visit the Storage Facilities, the Residence Towers, the Commercial District (for shopping), the Office Towers, the Monorail Station, or the Gate Terminal; or, you can hang around here in the Terminal Gardens. Your computer phone is currently connected to the New Columbia planetary net.

Status: Shelved.

The Skotos Client (5/17/00)

In May we started writing up an RFQ for the Skotos client. That's a Request For Quotation, which is a document that you send out asking people to bid on a project. It was for the ActiveX/Alice client, which you're using if you're running Windows and Internet Explorer.

Our RFQ detailed a client that was very ambitious. It was to include a set of panels that could be docked to each other on the fly, making the client totally configurable. One player might have just two panels, for the text input and the text output, while another might have those two, plus a map window, plus an inventory window, and a third player might have all of those, along with a set of icons which could be used to output macros and a sixth panel which displayed the contents of the current room.

And all of those panels could be arranged in any way that a player saw fit.

But wait, there's more. Each of those panels would be full of rich text: bolds, italics, colors, and hyperlinks, all of which would be user configurable as well. Want to see whispers to you in red? Want to make output from somewhat you don't like gray, and thus nonobtrusive? No problem.

When all this was done, we wanted to release a subset of our client to the free MUD community. Codename: SkotFree. The idea was to give a little back to the community that we've drawn lots of ideas from.

Suffice to say, though we do have a very nifty ActiveX client, it isn't this nifty yet, and if you do the math, you'll see why. We were looking for an engineer in May; we needed a client four months later. Not nearly enough time.

Status: In Progress.

The Cleanup System (5/25/00)

From pretty early, we realized that there was a need to clean up all the mess that gets created in games. Here's what I wrote about the problem in May, tongue firmly in cheek:

Players mess things up. It's how the world works. You make a nice, pristine castle, with all the chairs, tables, iron maidens, and cutlery in just the right places and players come along and move the things around. Pretty soon you want to have a feast, and there's not enough silverware, and you embarass yourself in front of the Queen, and then there's nothing to do but jump off the Castle walls.

The cleanup system is intended to prevent that.

Cleaner Requirements:

• Cleaners Must be able to pick up objects.
• Cleaners Must know not to pick up items that have recently been dropped.
• Cleaners Must be able to look up where the object originated.
• Cleaners Must be able to find a path back to where the object originated.
• Cleaners Must be able to put objects where they belong, in the correct position.
• Cleaners Must be able to deal with the room being in a different configuration than the original.
• Cleaners Should have their descriptions change for what they're carrying.
• Cleaners Should be able to pick up multiple things.
• Cleaners Should be able to queue a list of things to return in the most efficient manner.

The basic idea is that cleaners pick up objects (but only if they've been sitting there for a while), "know" where they came from, walk back to that origination point, and put the object where it belongs. There are issues if the origin room has changed: say there was a pillow on the throne, and someone's nicked off with the throne too. When they're carrying stuff around, cleaners' descriptions should change appropriately.

Cleaners shouldn't just pick up one object and then run away. Ideally, they should pick up stuff till their capacity is full. Otherwise, they might keep going until a route is done, a set time period elapses, or some other criteria is met. A cleaner should then construct a list of where he has to go to deposit things, and do so in the most efficient manner. If he sees more things to pick up on the way, he should do so.

Status: Implemented in a lesser form.

Galactic Emperor (6/19/00)

We've long had the concept of Stages at Skotos. These would be short-duration games where players take on the roles of existing characters and try and achieve their goals in a very constrained environment. They'd be like LARPs (Live-action Role-playing games), but run over a computer. Our first thought regarding Stages, dating back to the design of the original Castle of Romance, back in 1999, was that we'd create environments (a passenger liner in the 1920s; an old spooky Castle; a cave in the Neolithic) and that StoryTellers would create stories to run in those places.

By June, we were still pretty comfortable with that basic concept, but we decided that we'd need to offer a little more direction, to show how Stages could be run. So, we contacted Mike Young, a LARP designer who runs some of his games at local conventions, and negotiated to buy one of his games, so that we could translate it into a Stage. That was to be Galactic Emperor: Succession, which was to run in November 2000. This was Design #1.

By the time we were getting close to November we'd determined that Galactic Emperor would need enough special systems built for it that it would be a waste to run it as a one-time Stage. Thus, we came up with a new design, where it could run every week. We were also bouncing around ideas for a simpler resolution system, where lots of things (ships, troops, personal combat, intrigue) could be done via one mechanism. We came up with the idea of using a collectible card mechanism inside the game. Players inside Galactic Emperor would duel with cards which portrayed their various resources. We even came up with a name for the entire class of games – which by now you'll realize is something that we like to do. Galactic Emperor was to be our first Arena. This was Design #2.

As November turned into December we decided to move Galactic Emperor back a few months, so that we could do it right. We also determined that the whole card mechanism was just too Out Of Character, and in any case we'd developed a programming language called BILBO which would make it easy to resolve lots of different types of conflict. So, we tossed out the CCG idea, and reverted to the original, more complex, mechanisms found in the LARP, but decided to hold on to the idea of Galactic Emperor running on a weekly basis. That was Design #3, and is the design that we're currently working on building.

Status: Mutated.

The Future (12/31/00)

As you've no doubt seen, most of our Roads Not Taken fell into the first half of the year. There are two good reasons for that: for the last half of the year we've been trying to fulfill the promises made during the first half; and we don't know which things we're working on now might become Roads Not Taken.

As I've written this up, I've seen a few rules that I've talked about before, and I'd like to reiterate them for future StoryBuilders: Your ideas will mutate; you'll find that you have to let go of some of your initial ideas in order to produce a game; and you may have to implement some things in lesser forms.

Go with it. Creating games is a constantly evolving process.

Status: Ongoing.