Guidelines 3

Avoid Grind
The amount of inspiration I took from Echo Bazaar is nearly embarrassing. While I had the idea with splitting up a story into Actions before I saw it there, the Stat/Item-abstraction I use is directly taken from their game, and I have taken liberty with quite a few other neat things from them. Yet there is one thing in EB which I hate. It's not just slightly grindy, the later stages of the game literally revolve around redoing the same actions dozens of times. Since you can only do 10 actions per hour, and only 40 per day, I've spent more than a real week on grinding one of my stats from 70 to 80, which was insanely boring, and made me quit the game despite its interesting writing. Of course, it makes sense for them from a business point of view, because you pay them real money to get more actions. It's the not-quite-so-old MMO problem that a drawn out game will just earn you more than something short and sweet like Portal 2.

Still, I cannot help but feel that this is their one big mistake, where they sacrificed a great game design for money. I find repetition boring. And I believe I am not quite the only one. This brings me to my engine and what kind of games I would like to see. There is nothing wrong with writing an Action called "Go to the Gym to train", but it should not be required to do it seven hundred times to continue with the story. I have tried to implement my engine in a way to prevent this from happening. Whenever you receive some exp through a reward, it will reduce it by a cumulative 20% for every time you have already seen this reward. You can manually deactivate this feature by setting @repeat="infinite" if you have to (such as an exchange of two values, where you don't want it to scale, but rather keep it perfectly identical).

At first, one might think that this increases the amount of grinding necessary, but that is not true. At a cumulative 20% decrease, the exp received drops to negligible amounts very quickly, which means anyone playtesting will quickly understand that this is not the way to do it. In essence, I try to highlight the designer's mistake so it can be fixed.

Guidelines 2

Some more guidelines.

Gradual Change

One of the most annoying tropes of RPGs is "you have been taken prisoner". We all know it, and we can probably all list a dozen games or so that do it at one point or another. All your stuff gets taken away, and it feels as if you are starting from the beginning again. Now why does that bother us so much? Because it invalidates all that we have done up to that point. It is oh-so easy for a game designer to just write "money := 0", and it feels exactly as unfair as it is easy to program. While this is the most obvious example, there are smaller ones too: Whenever a script ignores what you have done up to this point and just executes whatever it wants, we feel cheated. The issue is actually quite simple and has a lot to do with how we perceive our world: We never just "lose all our money", we always lose a certain amount, and if we had more, then some of it is left over.

I have given in slightly and added functionality which allows writers to set stats and items to certain values, no matter what they were before. But I highly discourage it. Let me offer an example as to why. Imagine the player is offered the choice of having his character convert (partially) to a cyborg. One version offers you these three choices

1. Only do some superficial replacements.

2. Replace about half your body.

3. Replace as much as you can with technology.

The other version only gives you the option of replacing your eyes, or not doing so. But if you chose to replace them, you are offered a few more parts, such as arms and legs. And when you do that too, you can then replace everything except your brain. 

I find the second version to be much more compelling for a couple reasons:

• If the player chooses the first version's third option, he essentially wants all three, yet only sees the third. Which means its text will probably be either redundant or incomplete.
• There is a lot more mystery and curiosity involved when you cannot see all choices up front and wonder how many there will be.
• You get a taste of what is to come. Which means it is a lot easier to convince the player to do something slightly risky by offering something neat up front, and then teasing with the follow-up.
• You cannot go too far for lack of knowing what the differences will be. Sure, you can regret making the choice (which is fine), but you don't get asked a question like "do you want a lot?" to which you inevitably would ask "how much is a lot?" 

To sum up, the second version is more mysterious, appeals more to your curiosity and at the same time, it is clearer. It is quite astonishing how much better it ends up being. And in games, what happens when we are confronted with version 1? We circumvent it by saving, testing all versions, then loading, and choosing the one we liked most. Bad game design does not get more obvious than "the player loads the game four times".

This is my primary reason for not having had any functionality to set stats to fixed values, and I still believe it is neither necessary nor a good thing.

Guidelines, Basics.

As there are now people using my engine, I think it is time that I write about the design guidelines I think should be applied.

Syntax

• Stat and item names should only consist of letters, numbers, underscores and spaces. Anything else might break something.
• Currently definitely reserved are # [ ] | ¬ @ = > <  
• If you want to put > or < in your texts, write "& g t ;" or "& l t ;" (without the spaces) as usual for escaping these two characters in XML. If you use the editor, it will take care of this.
• File paths should use /, not \

Interesting Failures

This is a huge pet-peeve of mine. Everyone who has played RPGs on the computer will agree with me: They are all quite linear. Some of them are the purest of railroads (Bioware), others only slightly less so (Bethesda), yet they usually only have a single ending. Or rather, they all have two endings, of which you get to see one all the damn time. It's called "game over screen". Technically, that is an ending. The problem is, it's the most uninteresting ending there is. Some older games tried hard, and had multiple game over screens, which would explain what happened after you died at that specific point, but that still is far from what would be interesting. The point being, that failure in games is completely unheard of. As GlaDOS puts it: "If at first you don't succeed, you fail."
Either you win every single encounter (except those which you lose during a cut-scene) you ever get into, or you have to load and try again. 

Isn't it jarring how surreal that is? Our lives are all but dominated by our failures, yet we continue, we soldier on, and often, it's not much of big deal. People flunk their university exams, but they do not stop existing. They still get a job. They still have kids. And they still fail hundreds of times more. Often, failures are more interesting than successes. People care more about Apollo 13 than about any other of those missions, because it was such a close call, and so much went wrong.

Dear writers, I ask of you: Whenever you write an Action, ask yourself if you can make it a challenge instead, and whenever you write a Failure, try to make it as least as interesting as the success.

Slippery Slope versus Rubber Band

Those two terms are quite common nowadays when talking about game design. I'll give a very brief summary, Sirlin (always worth a read!) has a long essay on the topic for the interested. The first one means that when you are losing, it makes you lose harder. The prime example is any RTS (such as Starcraft or C&C): When you lose a base, you have less money to build units with, to defend your other bases, so you are even more likely to lose more bases. Or Dota: The more enemy heroes you kill, the more experience your hero gets, which makes him more able to kill enemy heroes. If overdone, this ends up with the first hit deciding the match.

Rubber Band means that whenever you are behind, the game helps you catching up. Mario Kart is the most obvious one: Not only do items mostly work against the people in front of you, some of them are exclusively designed so: The blue shell always hits whoever is currently in front, and you can only get lighting bolts if you are far back. Even Starcraft offers Rubber bands: Small armies are generally easier to use, suffer less from splash damage, and it is a lot easier to defend two bases than it is to defend five bases. But if overdone, winning becomes a matter of luck. Imagine a racing game where everyone who is behind gains a 100% speed boost. Who is going to win? Whoever can get in second place a few seconds before the finish line, and use that huge speed boost to win. 

But games written with this engine are not competitive, so they actually do not suffer much from excessive Rubber Banding. I would go so far as to say that huge boons (and a chance to recover) when everything is going to hell make for a much more satisfying story than a slow and painful death. Or in short: All challenges should give out at least as much exp for failures than for successes. If you succeed, that is your reward. You don't need a ton of extra exp on top of that. But if you fail, you usually end up with some disadvantage. To make it sting less, add a good helping of exp.

I tried to implement mechanics into the engine which make it easy to design good games, and hard to design bad ones. The one I want to mention here is the @level="15" stat-reward. Instead of giving out a fixed amount of exp, it will reduce the amount of exp given by a cumulative 20% for every level above 15. The amount given equals exactly enough to go from 15/0 to 16/0. The idea being that you should add this to every failure, and you can guarantee that the player will always keep up with the difficulties, yet not surpass them easily, because it will rubber-bound him back down (yet of course, level-15 exp is quite a lot if you are below level 15).

Alpha 11

Just a minor update. Apparently, the versions up to now crash or just don't work at all when fed invalid XML, and generally behave badly when the XML does not exactly contain what is expected. If someone wants to write something by hand without using the editor (and since the editor does not support every single option perfectly that can make sense), this can easily happen. While the Alpha-10 update will not magically get broken content to work, it will at least recover gracefully from many problems, and log them in the Debug view.

In addition, there is new feature, which was explicitly requested. It is now possible to have conditions in texts (but only in reward texts, not in titles or anything else), and to refer to other text ids. You can now also declare a naked text-node with an id, and then refer to it from anywhere else by its id. Note that the id must always start with a #.

[Determination<13|I'm afraid!]
[Reflexes > 99|incredible, not]
[Luciditiy = 1|Whuuuut?]
[Trauma@Crippled|Oh shit I am crippled]
[Gender¬Male|I ain't a man]

They can be a bit fickle when spaces are used, so I suggest not using any at all in the conditions (except for those that cannot be avoided, when a stat-name has a space in it, for example). It is possibly to do something like [a>3|[b>3|Hello]] for very complex choices, although generally speaking, if you catch yourself writing more than a handful of them, you might want to split your Action into more than one and differentiate by Requirement instead.

There is no post for alpha 10, because I've written two releases before I had this post finished.

New Look

Just to show how it looks right now:

In other news, Alpha 9 released, which offers this new center column for the stats, and demonstrates a new style (which can be changed on the fly).

Changelog

• Scroll bars for long texts
• Fading effects
• Style
• Stats pane
• xml-layout for chances has been slightly redesigned (though the editor cannot do chances anyway right now).
• Bugfixes
• Better defaults for many options

As usual, it can be found in the download section, you will need the two files starting with "alpha9" and the adobe air installer (bar to the right). Opera has issues with .air files, use some other browser.

Alpha 8

I have been really busy writing code and implementing features I want (or some people have actually requested). The editor works much better and can do nearly everything now (except for Chances). In addition, there is now the possibility of skinning the application during execution. You can just write something like a style-sheet and have that applied like any other event. This has two consequences: One, people can now theme their games. Two, it is even possible to change colours and pictures during play. As a simple example: You can bathe the UI in a green jungle while the player is in the jungle, and then switch to a clean blue/white interface when they enter a space station. I think when used well, this will do wonders for immersion.

Lastly, I have nearly tripled the amount of demo game. The reason is simple: The editor makes writing it so much easier and comfortable, one can just type away without spending a ton of care on the XML-format. The (very significant) time spent on creating the editor seems to pay off. I believe I actually spent more time on the editor than on the engine itself.

Lastly, I fixed how folders behave. No longer do you have to bother with writing in the application directory (a hassle on Windows 7, a near-impossibility on OS-X), instead you can just freely chose your working folder.

Oh, and there is Save/Load functionality.

The download can be found at the usual spot:
http://www.wuala.com/Kdansky/StoryTellingEngine/

Motivation!

A few people have shown interest in using my work, which has motivated me to spend another few hours polishing and adding features.

The files can be found (as usual) here:
http://www.wuala.com/Kdansky/StoryTellingEngine/

You will require both the alpha7_story.air and also the zip file with the demonstration data. Install the application anywhere you like except at your C:\Programs\ folder, or else the editor won't be able to edit the files, and unpack the zip inside the same folder. There will be a proper data folder at some point.

I also highly recommend looking at the documentation if you want to write your own content. The editor takes care of all the XML, formatting and validating, but it is still very helpful to know how the internals work to figure out how to do something.

Note: Opera seems to muck up .air files because it falsely believes they are .zips. It has been known to do that with .jar files too. The only work-around I know is to use another browser.

As for an incomplete change log:

• Save/Load functionality (1 Save slot for now)
• The editor has received a better layout (especially on large screens, go full-screen for maximum effect)
• Some forgotten parameters (chance, pass, crit, botch) have been added to the editor
• Empty textboxes should now always result in the correct behaviour
• As usual, many bugfixes. Apparently, challenge difficulty has been broken in many cases.

The Editor

Finally, after a long period of writing a lot of code without being able to share the results, I have a big (actually, gigantic) update for my StoryEngine. It's the in-game editor. While playing, you can just click on the small new  Button labeled "edit" and directly enter edit mode. All the complex XML is parsed and shown with a pretty GUI, and you can click buttons to add rewards and such!

Actually, it's rather ugly, but serviceable. Getting everything to show on a limited screen was a big challenge, because Actions can be very complex beasts.

Some things could be more convenient, such as auto-completion of item names, but I had to force myself to write most of the rather boring GUI code, and didn't want to wait until I had all the neat features that I would like to.

The Compile-button will show the XML that is generated from the GUI. This was mostly for me to debug with. When you save, the program will store the data from the GUI directly in the file that the action is from. In case the id was changed, it will create a new action with this id. Note that it will not yet appear during play, because the engine only loads Actions at program launch.

Caveats and known issues and bugs:

• Not all features are yet supported. Some of the more complex (like chance modifiers depending on requirements) are not visible at all.
• It is of questionable visual appeal.
• Only actions can be edited, no locations, stats, items or rules. On the other hand, actions are about 99% of all content, and the other things are so damn simple that the lack of editor should not matter. As an example: locations pretty much come down to a triplet of name, description and picture.
• Stuff is very untested.
• It is not required to know the XML schema to be able to use it, but certainly a big advantage.
• Icons do not load.

Due to issues with my usual download, here are two less practical links:

http://www.filesonic.com/file/1611116784/alpha5_story.air

http://www.filesonic.com/file/1611116794/storyv5.zip

The v4 XMLs should be pretty much compatible though, I've fixed a few bugs at best.