Background

The Delver engine is an engine used to create role playing games for the Macintosh. Besides providing an immersive user interface experience and a rich graphical rendering of the world, there is also a very flexible scripting system used to create a very deep, interactive world. So of course, people want to have access to the editor to allow them to create their own games using the Delver engine. Before we go into depth as to why this isn't going to happen, we will describe, in more detail, what the various parts of a game using the Delver engine contains (which might be interesting reading even if you don't care about the whole editor release stuff).

Engine

The core engine is written in C++ (with some assembly language written libraries) and provides the following services:

UI Management

The engine provides all the Mac interface - manipulating windows, dialogs, controls, menus, etc... It also provides a binding between windows and underlying scripting objects. Most importantly, it handles the user interaction with the various windows and connecting them to messages sent to the scritping interpreter as well as the world model interface (for example, it provides a way to track dragging an object from one window to another to pick it up).

World Model

The world is composed of a map with a large variety of objects ("props") on it (which is loaded from the storage management layer). It represents everything that is seen in the current area - all the walls, all the furniture, doors, etc... It is currently based on a static "level" model, where the world is broken into a number of discreet maps, all independant from each other (relatively speaking), and the entire level (map and props) is loaded into memory at one time. In the future, this will evolve into a "virtual" world, where small parts of it will be loaded into memory as needed.

World Model Interface

This part of the engine handles things like moving the main character, as well as providing behaviours for non-player characters. This includes path finding, and general "time slice management". When an item is picked up from the UI layer, this layer translates it to sending messages to the appropriate game objects, as well as handling the actual manipulation of the actual prop to make it move from being at coordinate X,Y to be inside item A. This layer also provides information for the UI managements such as knowing that this items is a "counted" item (and needs to show a count number below it).

Storage Management

All data for a game is stored in a special format (not resources) which allows for rapid access as well as the ability to interface with a memory cache. For example, the scripting code is paged into this cache as needed, and automatically released. This caching system is essential to the operation of the game, and will be utilized more heavily in future versions for the world model data (which is currently stored in a statically allocated area).

Scripting Object Model

There is an underlying object model and message passing system for the various props found on a level. There are actually a number of different classes of objects, such as "Character", "Monster", and "Item", as well as less tangible things that don't directly map to props, such as "Zone", "Room", and "Skill". Understanding how all these are related (for example, you can covert a Character to an Item, but not all items to Characters, and a Character to Monster, but not a Monster to a Character) is key to designed a scenario. There are also a set of messages that are passed from the World Model Interface layer to these various objects (for example, when you talk to a person, the "DoTalk" message is sent to the Character object corresponding to that person).

Objects not only have methods associated with them for message handling, but they also have properties (sort of like a class variable). Various properties include an objects weight, if it can be taken, if it can be wielded as a weapon (and if so, how much damage it does), etc...

Scripting Interpreter

The scripting interpreter is actually composed of two parts. There is the actual interpreter itself, which is called to deliver messaages to various objects by the World Model Interface Layer, as well as system calls that made from the interpreted code back to the various other layers of the system (such as "PlaySound"). The interpreter handles the message dispatching, and then performs byte-code interpretation for the resulting code. It interacts with the storage management layer to load in method code, as well as other potential storage accesses (such as getting a string from a string table). The system call layer is quite large, and provides simply hooks back from the scripting layer to the rest of the game. That part also provides the binding between the scritping object model and the actually data found in the world model (for example, when you as for the x coordinate of a Item, this is the part that actually looks it up in the world model).

View Rendering

This is actually the oldest part of the entire system. It takes the world model and produces view that is seen by the player. It handles things such as line of sight, lighting conditions, prop display layering (so a plate is always visible on top of a table, instead of underneath it). It also provides an interface for the UI Management layer to translate mouse coordinates to specific objects (so it can tell what you are pointing to with the mouse).

Audio Support

The audio support layer provides both music and sound support (primarily from system calls from the scripting layer). This includes stereo localized sounds (complete with panning for moving objects) using Ambrosia's Sound Tool. It also plays MIDI based music using QTMA support in QuickTime.

Scripted Game Data

There is a great deal of information stored in the game data - this is the stuff that is edited by the "DelvEd" editor. This includes:Just about everything not defined in Engine is defined via scripts. This includes combat resolution, role playing rules (such as character advancement), as well as all the object behaviour, conversations and the like. Even what music is played when you enter a level is controlled by these scripts (an "Enter" message is sent to the Zone object corresponding to that, and that method then calls the "PlayMusic" system call).

Application Wrapper

There are a few things that aren't handled by either the engine or the game data scripts. These include the basic startup of the application, opening the appropriate data file, quitting, loading, saving and reverting a character, and the whole character creation process. This is all currently handled by a couple of C++ files, though eventually this will all be factored off into either the engine or the data (but at this point it isn't, so there is no way to change the character creation process by just changing the game data).

"So released "DelvEd" already..."

Let's look at some common arguements on why the editor should be release:
"It would be cool if I could make my own scenario"
Then learn programming and spend a year or two writing your own game - nobody's stopping you.
"No one will buy it/it will kill the replay factor"
This is a common one - let's look at a few other popular games. Realmz and Exile (1-3) and Taskmaker are three of the most popular RPGs currently available for the Macintosh, and the lack of a scenario editor doesn't seem to have hurt the popularity of either of them (yes, I am aware that there is an editor for Realmz currently planned for release). OTOH, SwordDreams and SwordDreams 3D both have scenario editors available for registered users, but that doesn't seem to have increased the popularity of them. In general, none of the really popular role playing game on any platform has a scenario editor available, and gosh, that didn't seem to be such a big deal.
"But there are level editors for lots of other games, and all the add-ons levels have added a lot to the game"
Those games are also things like first person shoot-em-ups, and arcade games. Notice that Myst doesn't have a level editor.
"All the add on levels is what made Doom popular though"
Doom was very popular before user levels came out.
Furthermore, let's look at some arguements on why to not release an editor, many of which will be explained in painstaking detail below:As you can see from the above description, there is more to a Delver based game than just making a new data file using DelvEd - one needs to actually make a new application. This point is somewhat moot, since most people can probably live with the existing character creation model, and eventually these restrictions will be removed. However, it is more than just drawing some maps and putting object on them - even assuming that you keep all the existing artwork and objects, at the very least you'd want to re-write the conversation and other descriptions. This is still a very time consuming process (if it weren't, Cythera would have been released a long time ago).

Let's look at the various steps required to create a good game using the Delver engine, in no particular order:

Once all that is done, you need to test it, re-test it, and then test it some more. Total time: a minimum of six monthes (more like 1 person year for everything except testing).

So the question becomes: "Do you (or you and a couple of creative friends) have six monthes to a year to spend full time on this?"

"OK, maybe not, but I'd still like to maybe make a smaller thing, or enhance the existing Cythera data"

Let's take a look at now from our point of view. The current state of the editor is that it works well enough for me to use it (it doesn't usually freeze up my machine much anymore, but it still happens). The current state of documentation on how to design new objects, characters, etc... is nearly non-existant (the syntax for the scripting system is well documented, though there are some errors, but that's about it - definitions for what the various bits here and there do aren't).

For general consumption, the editor would have to basically be re-written. That would take a minimum of 6 monthes of my full time to do it (since I'm the only one who knows how the game engine works and what to edit in it, as well as how an editor needs to work since I'm the only one who has created a scenario). During that six monthes, I'm not enhancing the engine for future version - and this is a very important point, for which I will digress for a minute.

Future versions of the engine

I plan to add a number of features to the underlying engine, as well as make changes to the general interface and storage system. All of these will cause incompatible changes between different versions of the engine. Each game I make, however, will be tied to a specific version of the engine. For example, when a new game comes out with major engine enhancements, older games will not be re-written to use the new engine. There will probably still be bug fixes, but the old game will still be the old engine - the return on investment will not be worth the time spent re-writing it to use the new engine.

Since development is based on a "one game per engine" model (at least until the engine has all the features and capabilities I want), this would mean that a new editor would have to also be released for each new game. This adds those six monthes to every future release.

And, besides time spend for releasing the editor, time has to be spent polishing up the documents so they contain all the information need to create a new game - if this step is screwed up, the amount of time spent supporting it becomes astronomical (which is again, time not spent making the next version).

"Well, then just release everything as is, and say it is unsupported and be done with it"

Interesting approach, but even as "unsupported" there will still be a flood of questions coming in (most usually beginning with the lines "I know this is unsupported, but if you've got time I've got a couple of quick questions, and I'd really appreciate it..."). Suppose that people even are able to figure out how to make new scenario - what are the chances that the average scenario is going to be any good. Or for that matter, without support from myself, that any of the scenarios will be great (since some of the more sophisticated things like synchronizing shedules with external events is tricky at best). And let me digress for another second on a techinical issue.

Script to Engine Interface

Messages passed from the engine to the scripts and system calls from the scripts back to the engine are all implemented as a number. For example "DoUse" might be message #4, while "PlaySound" might be system call #32. These numbers, however, are bound to a specific implementation of both the data file and the engine (these numbers are assigned when a specific script file is compiled - there is an editor command to export these numbers as a header file that requires recompiling the engine when they change). Unfortunately, these numbers change far too easily. It is quite probable that some bug fix for Cythera will result in a new interface version - this means that any "replacement" game data from the old version of the game will not work at all with the (slightly) newer engine.

The implication of this, then, is that every scenario writer would have to recompile all their scenarios and re-release them potentially every time a new bug fix for the game came out. A flood of "maybe or maybe not compatible" senario data would be like PC hardward cards (which might, or might not, be compatible with the motherboard/os/other cards you have).

And let's not forget the example set by WorldBuilder.

"So what are the plans?"

At some point in the future (yet to be determined), there will almost certainly be support for third party scenarios using the Delver engine (hopefully there were enough weasel words in that sentence). Note that I'm saying "in the future" - this is not currently in place, and everything will be handled in a case-by-case basis (depending on, among other things, available resources). At this point in time, all available resources are being spent on getting Cythera out the door as soon as possible.

The details of how this will be handled are yet to be determined, but the most likely model would be like developing Mac software in 1984 was like. For those who weren't doing that back then (and I assume that this is most of you), you needed to become a "registered developer", which entailed filling in all sorts of forms just to prove you were serious (and not just trying to get the hardware discount) and handing over a lump of money (the current model is still like that, but there are fewer forms to fill in (I don't believe you need a five-year business plan anymore), and the lump of money is smaller).

So, basically, at some point in the future, if you are serious about creating a new role playing game built around the Delver Engine, and you can prove it, contact us. We will evaluate your proposal, and assuming we like it, we'll come up with a legal contract and work out all the licensing issues. At that point, you'll be working on an Ambrosia project, which means that Ambrosia will be releasing the game, handling the registration for you, do the advertising, and even helping you with the artwork and/or music and sound. Basically not all that different than working on a project with Ambrosia right now, except that there will be the Delver base engine to build on top of, instead of doing all that code from scratch.

This will ensure that the end result has the highest quality for the customers. From your point of view, you get the full support of Ambrosia behind the product to ensure its success. And in the end, everybody wins.