Tuesday, May 02, 2006

Perkplot!

I've been thinking. Corvus has been thinking, too. We've been thinking about the same things. He's thinking "Honeycomb will save us!" Well, I've got a hammer called "Perkplot", and the problem looks like a nail.

I've been developing the language. It has a few very interesting features that solve some problems I see in Honeycomb (and many other systems which aren't, in fact, Honeycomb).

The biggest problem I have with Honeycomb is that it still requires you, the writer, to carefully script each possible event. That limits your productivity. I wanted my language to allow that level of control, but not require it.

There's a few serious issues with systems for scripting plots "loose", using plot modules. I believe I have solved most of them. There's no "black box" problems, no "disconnected events" problems, no "impossible path" problems. More, it can be linked into the gameplay itself natively, rather than painstakingly scripted.

The downsides? Primarily, it's untested. Maybe I'm missing something. Also, it requires people to think in very strange ways when writing their games.

How does it work?

Okay, this is a semi-graphical interface. But things don't stay where you put them: depending on "where" you are (what you click on, what mode you're in) the graphics reorganize to show what you want to see.

The system is built out of "elements". I don't call them "modules", because that would imply a kind of completion. Elements are pieces of progression. Elements have a number of inputs, a number of outputs, and a number of components. Elements may also be components.

You build your game out of elements. For example, you might have a "date the girl" element. It takes a "romance trigger" input: until some other element outputs a romance trigger, it doesn't fire. When it does fire, it uses two components: a component representing the girl's custom actions (probably interwoven with generic actions for the date), and a component representing the situation (a date on a volcano is somewhat different than a date in a mossy glade). These interact - in ways I'll discuss later (perhaps in a different post, this post is long and it is getting late). Together, they produce a game experience using the IO libraries your game uses (graphics, music, minigames, etc).

Here's the first bit of fun: when an element executes, it leaves outputs for every "important" event, minus any clearly marked as suppressed or plus any specifically stated. This is automatic. These outputs are plunked into the scopes they are most likely to belong in without any help from the designer at all.

Then they can be used to trigger other elements!

This leads to, with minimal programming, peasants actually talking about something happening in the game. Or finding a superweapon raising the power of the enemies. Or anything else. The programming you do can be made to adapt to the exact situation: you only have to program an element for the general kind of event. Or you can program for a specific event. It's really your choice.

Each element is made of constraints, which I'll discuss in another post. But they are kind of complex. Fortunately, elements can be reused from game to game.

So the first games are small and relatively simple. Then, working on those base elements (if the author gives permission), other games of increasing complexity can be made with relative ease. This is important: if you know the problems with semi-automatically generated content, this is critical to alleviating them.

Now, there's a lot of things I haven't talked about, but I think the other critical one is "active elements".

Active elements are elements that want to happen. The way they go about this is they scan any other elements which output the thing(s) they need as inputs. Then they go about trying to offer these elements to the player. Not just one: active elements struggle valiantly to give the player a relatively even choice between two or three, assuming enough elements exist within the same general distance from the current play position.

For example, if the element is "get inside the castle" and it wants to happen, it might notice outputs from "rescue the princess", "sneak in", and "make friends with the court mage" are three options that are all possible to the player in marginally the same amount of play time/difficulty. It therefore finagles the game state such that any of the three can be chosen by the player at a specific moment.

This is done by making those three elements active elements...

:D

Obviously, elements which have the right inputs may not "activate". In many situations, these elements will need a player trigger (such as going to a specific place or choosing a specific thing). Usually, there will be a mini-element whose sole purpose is to tell the player of their opportunities. "The princess is in trouble!" These are forms of input, and in advanced systems an active element may actually conspire to herd the player into the right input using level modification.

Oh, and, as you might expect, the standard Perkplot modification and weighting system would be used by the active elements...

...

Using this language, it's impossible to simply sit down and script a 30-hour game. But you can script a 3-hour game. Then, you can reuse what you've scripted to script the next game much faster and easier. Then, you can use someone else's Townfolk's Adaptive Conversation Engine and script your next game to last 10 hours.

That's what I see in the future.

Also, this system can handle gameplay stuff... I'll explain more later, in a post about the nitty-gritties of the language.

9 comments:

Actually, the Honeycomb Engine™ doesn't require complete authorial control as you're assuming, it merely allows for it. The majority of the game narrative is going to be dynamic and highly reactive to player events.

In fact, the underlying structure which makes the plot graph narration possible will give rise to narrative on its own (and the graph I posted on the site is representative of the writing interface, incidently).

But it sounds like we're on remarkably similar paths and I look forward to seeing what you create!

Hmmm, you never mentioned anything like that in your posts. Well, good, the more people thinking like me, the merrier. :)

The only thing I actually dislike about your Honeycomb Engine™ is the way that whenever you write Honeycomb Engine™ you make sure to put a ™ after each instance of Honeycomb Engine™. I think that putting Honeycomb Engine™ in a post makes the post nearly unreadable™.

I didn't mention it because it wasn't the point of those particular posts. The point was the collaborative nature and discreet storytelling potential of the engine.

At some point in the future I'll talk about the gossip and motivation portions of the engine as well, which are the components which will dynamically drive many events in the storyscape.

In response to your primary dislike I'll say two words, "Legal protection." I won't be derailed by someone trying to yank the name out from under me, but I'd prefer it if I got to keep the metaphoric expression of my design approach.

I dislike the terminology you're using. Element is so generic that it becomes less than useless in this context. You would be better suited with a term that describes the concept your trying to put forth a little better, even if that concept isn't quite perfectly accurate. I suggest Fragment. You generate fragments, and these fragments latch on to other Fragments to form a whole. It makes much more intuitive sense to me.

I can see your web of element/fragments running in the background of a game, and I can see how they can be used to build up a game. But I'm not seeing how they would manipulate the game-state to accomplish their goals. That's too abstract of a concept.

How would they manipulate the gamestate? Given your 'get into the castle' example, you would have the three other fragments 'sneak in', 'rescue the princess' (I'm assuming she's not IN the castle, and hence rescuing her will get you into the castle), and 'befriend the Mage'. These all have outputs that allow you access to the castle, and they're all made active elements thanks to the 'get into the castle' element. But what do they do from there? So far, the only distinction between a regular element and an active element is the ability to make other elements active. What other powers do active elements weild to get achieve their stated goals?

So, a neural net of plot fragments. Each has other neurons that it connects to and that connect to it. Active elements have weighting that favours achieving input. Active elements have to happen but still have to follow the rules of the system. So they make the elements in front of them more desirable (and available) through influence.

For example: Perhaps the mage ordinarily requires that you come to him, and perform certain tasks before you gain his trust. But, as the "Enter the Castle" element puts pressure on the "Befriend the Mage" element to become completed (or available), it becomes easier. Perhaps you have to do fewer tasks. Or he seeks you out to complete the first job. Or some such.

This makes for a fairly flexible plot line... assuming that you have created enough alternative options to allow the elements to actively pursue the player.

Actually, both issues (needing lots of options and modifying the game world) have the same core solution - the language itself! It's actually the core theory the language was based on. I'll have to cover that in another post entirely, it's much too long for a counter-comment. :)

If you two are going to devote your professional energies to drama engine desing you ought ot download the preliminary release of the storyworld dev environment, SWAT(tm), and play with it to get a sense of its approach. I'd love to see some dissemination of your different approaches.