09 March, 2013

Amazon EC2

Amazon EC2 webpage creation tutorial

There are a decent number of tutorials about setting up a webpage on Amazon's EC2-cloud, but it still took me a few hours to get everything working. This is my list of steps that were necessary and not entirely obvious.

Setting up the Server

This was incredibly straight-forward. Make an Account, launch a new instance. I chose the Amazon Linux AMI just because I could. I do not have significant experience with Ubuntu or other distributions, and figured going with what Amazon designed for their own service would probably work best. It will generate a keyfile for you, which you should store in an accessible but safe spot.

IP-Adress and Security

Also very simple: Add an elastic IP (create, then attach), and open up port 80 for your instance to the public.

Logging in via SSH

In my case, I am running Windows 7, so all the clever terminal trickery of Linux and OS-X feels somewhat arcane. Install Cygwin (and don't forget to select SSH during its install!), copy the keyfile in its usr-directory so you can find it. It will probably have the wrong permissions, so fix that with chmod 600 keyfile.pem.
The next trick is to know that the user-name of the root account is called "ec2-user" on the Linux AMI.
Finally log in with ssh -i keyfile.pem ec2-user@xxx.xxx.xxx.xxx. 

Installing Apache

At this point, AMI will probably greet you with a list of required security-updates. And a command to do so. The following will be necessary.

[1] sudo -q httpd 
[2] sudo -q tomcat5
To check if httpd is installed and running. It probably is not.

[3] sudo yum install httpd tomcat5 mysql php
Install the usual packages: Apache, mysql, php.

[4] sudo service httpd start
Start the webserver.

[5] sudo chkconfig httpd on
Configuration that restarts the webservice on reboot. Not required, but certainly practical.


Finally, you should be able to connect through your browser to the webpage by means of raw IP-adress, and see a generic Linux AMI Test informing you of your success.


Lastly, the content of the webpage is in /var/www/html. If you are lazy like me, you want to do with with some sort of easy FTP-program. I use Filezilla. Open its server manager, add a new server with the EC2-IP, and choose SFTP as the protocol. That way, you need neither open any ports nor rely on passwords. Don't forget to change the user to "ec2-user" once more, and leave the password blank.
Lastly, go into Filezilla's Settings/Connections/SFTP, and add the keyfile. It will convert it to the format that putty uses. Then you can finally connect, and browse to the folder where the webpages are.

[1] sudo chown -R ec2-user /var/www/html
This will make the ec2-user the owner of the html-file-folder, allowing you to upload stuff.


Forwarding your domain to your new webpage seems easy (though I cannot yet check if it works, as I'm waiting for DNS records to update). You have to start a new "Route 53" service instance from the Amazon AWS management page, and add your domain there. It will then display the nameservers that your domain registrar needs. Note that this service always costs money (half a dollar for my first month with literally zero traffic), unlike EC2 itself, which is free for the first year, and relatively expensive afterwards (around $25 for a 24/7 server).


Actually I prefer Postgres, but I digress. Installing it is easy enough, only two packages (mysql and mysql-server) are required. Start the service (and config for automatic starts on reboot), then launch the very practical script "mysql_secure_installation" and go through all those questions.

Some of the sources I used to puzzle this together:

10 August, 2012

Runebound unbounded

Something different for a change, a post about board games. Specifically, Runebound by Fantasy Flight Games. As one of relatively few games, it can be played solo, and after reading glowing reviews, I bought it, about a year ago. I played it once, and was hugely disappointed. While it isn't quite as bad as Museum Caper, it is still one of the worst games I have ever played.

It feels like the designer did not really know about game design, and just tried to do Talisman, except different. Talisman is one of those old classics which everybody loves out of nostalgia, but in all honesty, it has tons of bad mechanics. But in the days before the internet, and before the rapture of the nerds (today, it's acceptable, or even cool to be nerdy. That wasn't the day twenty years ago), it was all we had. Talisman was a huge step up from Snakes and Ladders or Ludo.

But back to Runebound. It mostly suffers from a single problem, which is the complete lack of strategy, which comes from lack of meaningful choices. Sure, you can choose to wear a +4 axe or a +5 sword, but that is just a false choice. +5 is provably better than +4, and there is no reason to not use it instead.

I've written a longish post about why all the choices presented are false, and don't want to repeat myself here. Instead, I'm going to write down the house rules I came up with to fix things. Note that these rules are for solo play (or co-op play with two players), without any expansions. I don't buy expansions when I consider the base game to be broken to begin with.


Instead of playing a single hero, you play two parties of three heroes each. Every hero can have the usual equipment: Up to two weapons and one Armour. Either party can also carry around up to five artefacts and up to two allies. You can re-assign your gear before combat after drawing your challenges. Parties may trade freely if they enter the same hex at any point during their movement.


Your party only uses a single figure to move about the board. By default, you get to roll 5 movement dice. You may spend a 2 stamina (put the two tokens onto any of your heroes) to roll an extra die. You may also move less than 5 dice, and recover 1 stamina on each hero per die you don't roll. You may not do both, such as roll 1 die, recover 12 stamina total, roll 6 extra dice for obvious reasons. While you can always add more dice later (during your turn), if you go slow, you can't speed up.

Instead of having to end your turn on a hex to interact with it, you can interact with any hex you walk through. It would be perfectly legal to take on a green challenge, go shopping, take on a yellow challenge, and end your turn in the mountains.

If you don't want to move, you can take a rest (and do whatever the current hex allows you to do).

Rest / Second Wind

Resting restores any dead character back to life, with a single hit-point. All living characters first recover as many HP as they had Stamina left, and then recover all Stamina. Examples:

  • A is at 3/6 HP, and 2/4 Stamina. He recovers 2 HP, and 2 Stamina.
  • B is dead. He recovers 1 HP, and all Stamina.
  • C is at 1/8 HP and 1/8 Stamina. He recovers 1 HP and 7 Stamina.


New to combat: Whenever you want to attack, you have to spend 1 stamina to do so. If you are Exhausted, you may still fight (and attack), but all your stats are halved (round down) after other modifiers.


Party size is bigger, therefore challenges are bigger too. Instead of a single enemy, you draw three cards to fight. Should you draw an event, draw a fourth card. Generally you fight three monsters, sometimes you get lucky and only get two (though then you have to deal with two events). You have to assign every monster to a character (hero or ally) to fight. If you have spare characters, they may team up (just like allies and heroes can team up in the original rules). Combat is then resolved one fight at a time, until either the character or the monster dies. If there are still monsters left standing, re-assign them to your surviving heroes and allies (though you may not change equipment). Before combat effects can only be triggered once, in the very first round.

This is the table for which cards to draw on what kind of challenge rating:

  • Green: G(reen), G, Y(ellow)
  • Yellow: G, Y, B(lue)
  • Blue: Y, B, R(ed)
  • Red: B, R, R

As long as there is more than one monster, you cannot flee. Should you flee, the remaining encounters are just discarded (no book-keeping with them on the upper board border), and one Doom-Counter is added. Should there be more monsters than you have heroes to fight them with, they will politely wait their turn.

If you defeat all monsters in an encounter, you may take a Second Wind or continue your turn by walking further (and doing more encounters or going into a city, or what have you).


At the end of every turn, refill every market that is lacking cards. Then distribute three more cards among any cities that have the least amount of cards on them. You may also not put a card on a city with a hero on them. When you enter a city field, you may visit the market. Doing so allows you to draw an additional treasure card, and buy any number of them. At the end, you must discard all cards you did not buy (no putting them back to the market fields).


Doomcounters (of which there are eight) are accumulated by putting them into a Pile Of Doom.  When you have used them all up (which should be 8 of them), the forces of evil unleash a wandering encounter upon the world, and the counters are removed. Reasons to add a doom-counter:

  • At the end of every turn (after both parties have acted). 
  • At any time a Hero or Ally get killed.
  • When you flee from an encounter, add one counter for each undefeated monster.
Use the 1-6 markers with an axe on them to represent the wandering monster. 1-4 spawn at the corners of the map, 5 at the north and 6 at the south end. After the player's turn, they walk around, using 5 dice. They try to reach a city, or a hero (in case both is equally sensible, roll a die). If they reach a city, they attack it, and do as many points of damage to it every round as their power level indicates. A city has 5 HP. A razed city is considered a plain. Put a doom-counter on it. This also reduces the remaining doom-counters by one, speeding up the time it takes for the next wandering monster to appear.

If a party meets the wandering monster, they have to fight three encounter cards (ignore, discard and redraw events until you get three monsters) according to this table:
  1. G, Y, Y
  2. Y, Y, B
  3. Y, B, B
  4. B, B, R
  5. B, R, R
  6. R, R, R
You cannot flee from wandering monsters.


Whenever you defeat at least one monster in an encounter, you gain the encounter chip for exp (or the axe symbol for wandering monsters). You can then spend that on any hero in the party to level up. Levels cost 1 exp for the first, 2 exp for the second, 3 exp for the third, and so on. While this might seem a lot cheaper, you gain about three times less exp per encounter than before. If anything, it is still too low.

New Level ability: Defense. Get +1 to all three base stats, instead of +2 to just one.

Game Over

If a party gets wiped out, you lose the game. If all cities are razed (takes around 50 turns if you sit idly), you lose the game. You win if you defeat the dragon lord (see red cards).

Not much to my surprise, I find rule design more interesting than actually playing the game.

01 January, 2012

You can now Edit!

This is a preliminary update with the following features:
  1. Styles are online
  2. Rules are online
  3. The editor is fully functional. You can either edit actions you are the author of, or create new actions (with a button in the upper right).

Missing features
  1. It is not possible to create new users yet. Either you log in with the guest account (password 1234) or send me a mail if you want your own account, because the data on the guest account is prone to getting purged without mercy if I find anything problematic.
  2. There is still no GUI for Rules and Styles

Actually, both issues just require me to create a few forms because I have written the back-end code already, but forms take so much time compared to plain code.

Note that I do not do many checks for validity except for SQL-injections for security, and it is highly possible that anyone playing around with the editor will end up with unclear error messages. This is mostly experienced with naming conflicts which will throw up a generic error. So for all ids, it is sensible to choose long expressions (and ideally start them with "username_") which are unlikely to conflict.

There's also documentation to be found in the column just to the right. It might be a tiny bit outdated, but should certainly explain most of what's required.

16 December, 2011

StoryEngine without a Harddisk

I have rewritten quite a few parts of my engine with a single goal: It has to run from the browser, instead of the annoying Adobe Air environment. This means no file access, which is a bit of an issue for a program that spends most of its time with editing files and showing them in a fancy manner. I have at least partially solved it. The data is loaded from a (cheap and possibly slow) MySQL-Server instead from the disk. All else stays the same for now.

Note that the online-version does show off the editor, but you cannot (yet) upload or store anything. That requires extensive code on the topic of "what do I do if two people want to edit the same action?" which in turn will need user-authentication, which needs a way to create accounts and so on and so forth. Currently, everyone will just use the same account, and there is no code in place to support any editing at all.

Just click the link to open up the flash in a browser-window (requires Flash 10). I know there are still a few issues, some pictures don't load (or rather, empty pictures get displayed with a border, instead of not at all), but for the moment, this shall be enough. Styles are not yet supported.

03 November, 2011

Why Diablo 3 cannot be played offline

Blizzard announced it quite a while ago, and every time a new trailer is released, the comment threads on all the usual news site (RPS, Kotaku, ...) explode with bile. I am of course talking about the "feature" of Diablo 3 that a permanent internet connection is required. The amount of hate-posts this decision results in is downright astonishing. True, there are some issues with it. But I believe that most people have absolutely no clue as to why Blizzard chose to go with this. But let me start at the beginning.

The disadvantages
I will point out the big ones quickly to have something to argue about.
  1. We cannot play D3 during travel, or when our connection is bad, and if our connection drops for any reason, the game stops working.
  2. It's DRM, and DRM is always stupid and a hassle for the paying customer.
  3. If Blizzard goes bankrupt, or their servers die, the game just stops working. Which would be a shame, because (for example) many of the golden era games (System Shock 2, Deus Ex, Planescape: Torment) still run on a modern PC with some trickery, yet the companies that made these have been out of business for many years. If they had decided to disallow their games to be played offline, all of them would just not work any more.

We should just not care about it so much
First off, there are a lot of mitigating effects on many of the issues.
  1. The bandwidth we have available on our mobile phones and 3G networks is staggering. I can run Dungeon Defenders on my Android phone and play online, and that is by all accounts a more demanding game in all ways than Diablo 2 ever was. For years, I paid quite a decent sum of money to my ISPs to get a decently fast connection. This year, I was willing to halve my bandwidth for a meagre 10 CHF off the monthly fee, because even that is fast enough for a power-user like myself. At 20 MBit/s, I can download HD videos faster than I can watch them.
  2. Yes, DRM is still bad. Nothing I can do about that. On the other hand, I tolerate Steam, because it offers patching, chat service, cloud saves and keybindings, friend list and makes it a breeze to install my collection on a new machine. So in conclusion, DRM is still bad, but there are some perks that are worth having which are not possible purely offline.
  3. If Blizzard files for bankruptcy, Diablo 3 stops working. They might throw out a last patch, and make it truly offline-capable, but that is highly unlikely. If you're broke, you don't spend a ton of work on gifts to give to people who won't buy anything from you any more, because you're broke. We have seen this happen a few times in other cases, but I would never expect it. On the other hand, there will be fan-made servers anyway, probably as soon as a few months after release already. But let me point out another reason why this is not such a huge deal: I do not play those old games much anyway. I would rather play a fresh game than replay a really old one. When I was a kid, I could just not afford to play every game, so I replayed what I had. I could go and install Planescape: Torment right now, I own two copies in different languages. Yet I do not, because to be honest, it just doesn't hold up so well any more. Most games are a lot like films: You don't want to see the same thing twice if you can instead watch one that you haven't seen yet.
  4. Diablo 3 is a MMORPG without the monthly fee, just like Guild Wars. We don't complain about WoW requiring internet, do we? Diablo 2 wasn't like this, but that was ten years ago.
All of these are of course just excuses. I just want to point out that there is a difference between pure DRM (like Ubisoft) and the feature-rich version that Steam and Starcraft 2 already offer, and that "online-only" is not much of a big deal for the vast majority of people who play these games. 

Not the Point
Honestly, all of this is irrelevant and I just wasted ten minutes of your time reading these arguments. Sorry. We can all agree that there are good points (like Steam features) and bad points of an always-online DRM and if we are really forgiving, we can probably come to the conclusion that it's really not that much of a big deal to begin with. Actually, it's just like Guild Wars, and that is not such a bad spot to be in.

But all of these arguments assume that the DRM is there for DRM's sake. Which in the case of Diablo 3 is absolutely and utterly wrong. DRM is just a side-effect of a really gutsy design decision made by Blizzard, which gives me hope that Diablo 3 will be more than a boring Skinner Box. This is all about the Real Money Action House. Only EVE has done something like that, and their game is rather popular, despite being very unapproachable, complex and ugly. Blizzard really does not care much about the DRM on the game. What they care about, is the DRM on the items. They want to have absolute control over all item drops, over all loot and generally over the economy. And that is only possible if they stamp down hard on cheaters (which run rampant in Diablo 2), just like they can in WoW. 

Now you might argue (which everyone does): "But they could allow a separate single player mode, just like Dungeon Defenders (or hundreds of other games)"

And that is missing the point. Completely.

If Blizzard allows single player, they essentially allow everyone to create knock-off items. The value of a "real" Sword of Uberness would be diminished greatly by the existence of its brother, the Sword of Uberness that is absolutely identical, except it only exists in single player. Essentially, it's the knock-off Omega watch, which looks like the original, works like the original and cannot be distinguished apart from an invisible imprint on the bottom which says "SP" or "MP". Sure, one of stored on the server, and one is not, but with LAN play (and Hamachi) there is no reason to bother with the real servers anyway.

Consider the psychological effect: You want an awesome bow, yet none dropped for you. You go check the RMAH, and there is a Windforce for 50$. It's insanely rare, and nobody you know has one. People want status symbols, and will pay ridiculous prices for pointless trinkets such as WoW pets. How easy would it be to convince yourself that a Windforce is a good investment of money, especially since you can resell it later, and brag to your gamer friends with it?

But if there is a SP, the situation is different. You can either buy a Windforce in the RMAH for 50$, or you can just download a cheat tool and create a dozen copies. Why would you ever spend real money on something you can have for free? The difference between something genuinely rare, and something that is only rare as long as you suspend your disbelief is so big that our brain has completely different emotions for the two. I realized that when Diablo 1 broke for me when I figured out that I could dupe all items due to a bug. When you have access to infinite wealth, there suddenly is no point in playing a game where the only objective is to amass more wealth.

This is what the public does not understand. The DRM is there to make the RMAH work on a psychological level. The decision to control the game through servers imbues the items with value due to their enforced scarcity. That is the one and only intent behind this design, and everything else is just a result of that.

In the end, one can still argue against this decision, and claim that this is not a worthwhile feature. I am not going to tell you whether it will be awesome or horrible, because I don't know that yet. I only want to point out that this is the real reason for this unusual decision, and to be honest, I applaud Blizzard for it, because it's a huge innovative experiment. I want to see the effect this has on gaming, and on society as a whole. We (and our laws) are still unclear whether game items are worth money. I hope this will make people think about the issue, and result in interesting research for economics and social sciences. What makes me uneasy is that Diablo 3 might be too easy and therefore boring, and secondly, that it might fall under gambling laws.

Extra Credits also talks about this, and they don't disagree with me: http://penny-arcade.com/patv/episode/the-diablo-iii-marketplace

29 August, 2011

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.

26 August, 2011

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.

22 August, 2011

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.

  • 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).

19 August, 2011

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.

13 August, 2011

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).

  • 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.