topnav
masthead

Series Info...#33: What a StoryBuilder Can Do

by Shannon Appelcline

May 10, 2001 - When Gareth decided to bow out of the Skotos Several, as he discussed in "Fading Signal", he listed one of his reasons as the fact that some programming was required to produce a game, contrary to his beliefs when he initiated the project.

The concern was a valid one and, coupled with a request I received just days later which asked me to explain what exactly you can do with our StoryBuilder Toolkit, led me to this column. I'm going to take this week out to explain the approximate shape of what StoryBuilders can currently do at Skotos in the hope that it'll provide people considering proposals with a good understanding of needs and abilities.

And, I plan to revisit this column once or twice a year, to keep you all appraised of how we're doing on our Toolkit goals.

Before I get going, though, I want to define my terms. I'm going to be talking about our four major tools for StoryBuilders. The first is our web-based interface called The Tree of Woe. The second is SAM, which is a mark-up language primarily used for descriptions. Finally, I'll be talking about BILBO, a simple programming language, and LPC, a complex one.

And with that...

The Web-based Interface

The core of the Skotos StoryBuilder Toolkit is a web-based interface. It's called the Tree of Woe, both because its clunkiness made us sad in earlier versions and because it tended to slow the actual game down when it was used (Whoaaa!). It's getting better!

Woe contains a listing of all the objects in a game. This includes the things you'd expect to see, like people, objects, monsters, and room. It can also include somewhat abstract things like tip files, help files, and even our bug logs. There are also a number of "Generic" and "Ur" objects in Woe – these are objects that represent Platonic ideals; you use them as templates when you create your own objects, modifying them to suit the very specific instance you're creating. For example, you might take an Ur oaken table and then create a specific oaken table that has a carving on it.

When you call up an object in Woe, you have the ability to edit a wide variety of information in the object. In general, you don't have to know any programming to do this. You just check the right boxes, type in the appropriate beautiful text, or, in a few cases, enter pointers to other objects.

Here's the general attributes that you can currently set in Woe, for a concrete object:

  • What "Ur" or "Generic" object your object is descended from.
  • A number of miscellaneous properties like "edibility", "potability", "transparency", etc.
  • Specific information related to bulk.
  • Specific information related to our combat, clothing, and container systems.
  • Specific information related to our unreleased crafting system.
  • Initial properties.
  • Notes for other developers.

(I'll explain properties more in a minute... they're important.)

In addition to all of that general information, you can also enter information on specific details in an object. Each object has a "prime" detail, which is the general description of the object, but descriptions of numerous other details are also possible. For example, if you have a sword, the prime detail would describe that sword overall, while other details might describe the hilt, the blade, and the pommel.

The following attributes can be set for details of concrete objects:

  • Names (nouns) and adjectives for the detail.
  • Prepositions that may be used with the detail, for our prox system.
  • Brief, glance, look, and examine descriptions for the detail.
  • Exits in the detail which lead to other rooms.
  • Keys which are required to use the exits in the detail.
  • The map image that appears when you enter the detail (used only on prime details of rooms)

And that's it!

However, it's quite a bit of information. If you use the developer interface you'll find that you can very easily describe a fairly normal room, person, or object that doesn't necessarily do anything interesting.

(Abstract objects, like those aforementioned help files can also be edited by simple text forms... they just have different values for you to set.)

Properties: I promised I'd take a moment to explain properties, so let me do that before I move on. Properties are quite simply variables that you set to specific values. The only catch is that they live inside objects. Thus, for example, all of the players have skills which are stored as properties. Likewise, each players has a "virtual room" property which defines where he appears when he opens the appropriate guest room door. The follow command, the Marrach Watchmen's drag command, and the precedence system for honored guests are all other examples of uses of properties.

Properties have two purposes: to link in to existing systems and to link in with SAM or BILBO code which a StoryBuilder might have created.

Web-based Systems

If you've read our StoryBuilder documentation you'll know that it's our eventual goal to allow a non-programmer to produce a very interesting game without resorting to coding. We're not there yet, but we're definitely on our way.

We expect first implementations of powerful in-game systems to be done in LPC or BILBO, but as they reach maturity we plan to link them into our web-based developer system. StoryBuilders will then be able to dynamically choose which systems they want to include in their game and modify basic variables inside the developer interface to set up these systems as they desire.

Systems which already have links to our StoryBuilder Toolkit include: the Grand Theatre (Marrach) combat system; our recently released skill system; our unreleased influence system; our alteration system; and our unreleased crafting system.

The skill system offers a pretty good example of how we're integrating systems into the StoryBuilder Toolkit. On a single page you can: modify the times required for study and "study recovery"; change the default names of the ten levels for skills; add new categories of skills; and add new skills within those categories.

Really, I suppose, you can modify the teaching system right now, because what those skills actually do is embedded in other parts of the game. But, it's an excellent start. As we develop more games and have more external developers working we'll continue expanding these hook-ins to our systems. An external developer will never be able to access our most advanced systems in innovative ways without programming, but in the next year or two he'll be able to do a lot.

SAM Tags

Even before we get into true programming there's one way to really spice up the descriptions and other information that you might be entering into the Tree of Woe. It's SAM, short for Skotos Active Markup. With SAM you can make text dynamic.

At the simplest level, you can make text slightly random like this:


  You see a {red|fearsome|scary} Bug-blatter Beast of Traal.

At different times this could produce different messages:

  You see a fearsome Bug-blatter Beast of Traal.
  You see a red Bug-blatter Beast of Traal.
  You see a scary Bug-blatter Beast of Traal.

SAM gets much more interesting when you use true-false tests. For example, you could put SAM into the description of a plant to check whether a viewer had the healer skill. If they did they might get the additional information: "This plant is very poisonous". Or you could write secret messages on houses, only available to people who know the Hobo code. Or you could only provide street names to people familiar with a town (or those who have read the signposts!) Or you could give different descriptions of a mug of beer depending on how much has been drunk.

But wait, there's more. SAM not only slices and dices, but you can also use it to set properties. Thus, you might set a "cursed" property on a player who looks upon a sacred idol that they're not supposed to. (Then, in other places, you could check for that cursed property, and have players see weird things as a result.)

The basic idea of SAM remains the same, however. You can use it to produce dynamic text based on either random or arbitrary reasons. You can also use it to set properties which may later influence other dynamic descriptions (or other systems within the game).

The BILBO Language

SAM on top of the developer interface can allow you to, fairly simply, create semi-dynamic text, detailing people, places, and things in interesting ways. And, you'll have the ability to easily access our more mature systems. But, what if you want to do more? That's where our programming languages come in

BILBO stands for the Built-In Language Between Objects. It's the simple programming language that we make available to all StoryBuilders. We've tried to give BILBO a simple and intuitive syntax. It uses line numbers, kind of like BASIC.

As you might guess from the name, BILBO is a language that allows objects to do neat things. You build BILBO scripts into objects and then make then respond to certain verbs. For example, the gifts given out around the Winter Ball – such as goblets that filled when you tapped them or cloaks that changed colors when you rubbed a clasp – were built using BILBO.

BILBO isn't intended to be used for complex systems. (We actually built the Alteration System using it, but it's inefficient.) BILBO is intended to give objects unique and interesting behaviors. We've built magic items with BILBO. We've used it to create our second generation of CNPCs over in Galactic Emperor: Succession. We even used it for that kissing curse that circulated around the Castle many moons ago.

(BILBO, you see, has some neat features. It's built into the properties of an object, and it can actually infect other objects with the same or different code. The kissing curse wrote BILBO code into the kissee whenever the "kiss" verb was used.)

So, overall, BILBO is limited for the big stuff, but cool for individual quirks.

The LPC Programming Language

And that's really all we intend to offer to most StoryBuilders: the Dev Interface + SAM + BILBO. It'll be enough to produce games with the same general systems as our existing games, full of dynamic descriptions and interesting objects.

But, we realize that the occasional star programmer might want the ability to do a little more. We actually have another language called LPC which is the core upon which all of our games are built. You can do pretty much anything in LPC, but you'd need to be a very skilled C programmer to do so (mostly because you'd have to understand our entire code base).

Eventually we'll be opening up some LPC functionality to StorySmiths, a super-class of StoryBuilders, but for not it's by invitation only.

The Current State of the Art

So, you're getting ready to write a proposal... and, please note, we are taking proposals again and would love to hear from you... and you're trying to figure out what exactly this all means.

Right now, you could easily create the following types of game at Skotos without needing to program at all:

  • A plot-driven game like Castle Marrach.
  • A game centered around player interaction or conflict.
  • A Stage which depended on StoryTeller oversight.

Moving toward a game with less emphasis on socialization and more emphasis on independent play would take some doing, but currently a programmer could:

  • Implement puzzles using some combination of SAM and BILBO.
  • Implements CNPCs of low-to-medium sophistication.
  • Use the Grand Theatre dueling system and use BILBO scripts to determine what happens for victory or loss.
  • Create an arbitrary list of skills to be learned and taught.
  • Use BILBO scripts or SAM to create simple responses to skills.
  • Use BILBO scripts to create neat and interesting objects.
  • And lost of other things that depend upon the creation of variables (properties), the analysis of those variables or other factors (BILBO), and the dynamic output of data (SAM).

We're currently working on some important systems which will dramatically increase the number of things that StoryBuilders can take advantage of, among them crafting, influence, and new combat systems. As the year proceeds we'll be getting this linked in better, I'm sure.

So that's the state of things on 5/10/01. We'll revisit this in 6 or 12 months.

But I'll be back here in 7 days!

your opinion...