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.

Comments are, as ever, welcome.