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.

Webazaar

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.

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.

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

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.

Passwords, part three of two

This post and more specifically, this comment make me want to write a few more sentences on the topic of password selection. First off, the article is a good read, and talks about what kinds of bad passwords people chose.

Now for the frequent objections I get to the method I suggest. They all some some truth to them, but none of them are convincing enough not to use this system.


1. Someone can figure out your password generating rule if they get to look at one of them.

An example: okdufgo3fa. Can you tell that this is a password for Facebook? Could you tell that erdufgo3ga would be the corresponding Gawker password? You probably can, at least if you have two, and if you took a few moments to go through the most obvious ways to do that. There are two issues with this: One: This is a problem where you have to find a pattern. Humans brains are ridiculously good at anything pattern-related. Computer chips on the other hand are incredibly bad at it, especially if you start to use rules which are obvious to humans, but arbitrary to computers, such as "put all vowels in front of the consonants (facebook becomes aeoofcbk). Computers don't even know about vowels.

This directly leads us into our second point: We have CPU power in abundance, but not human eyes. No hacker would bother looking at thousands of leaked passwords personally, trying to figure out the rule for every one of them. And since everyone else has a password like '12345', why should he even bother?

Conclusion: Nobody will take the time to break it, and even if, it's not actually as easy as it sounds.

2. What do you do when you have multiple accounts for the same service?

Completely different, yet the same underlying issues. What does it mean to have two accounts at the same service? Well, two user names use the same password. But how is a hacker going to know which two user names match? He cannot even do this via brute-force, because all the people that chose '12345' will crowd the list of duplicates. Again, this comes down to the fact that a hacker won't even bother.

And secondly, how is someone going to use that knowledge, if they do not have your other account name? They cannot infer the rule to generate more passwords (since they only have one example), they cannot break into your e-mail or your bank, and most importantly: When a service gets hacked, you lose both your passwords there to begin with and usually not just one. In the end, this does not make any difference at all.

3. Some services require you to change your password from time to time.

In that case, there is no useful way out of it. Your chosen rule will probably not adhere to anything like this. But compare it to any other system of choosing passwords: You would also have to change your password every few months. In the end, no system can cope with this to begin with, so the best way to handle such an egregious exception is to make it one: You will have to remember a specialized (frequently changing) password for just that service. I would recommend not using the service, because that's just a huge bother.


4. Restrictions on character range or length.

This only really applies if you chose a bad function that does not include one or two digits, and is very short. The easiest way to avoid the issues is by selecting a function which will always result in 9-12 characters, and have exactly two letters in it. I know of no web-service where such a password would not work. Except for my bank account, where only letters work, so I have to write that password down on paper. It figures that my most important password is the one I have to treat the most risky, by writing it down.


Overall conclusion: There are some small issues with the system, but they are less impractical than any other system would have, facing the same problems.

Addendum: Nobody has yet pointed that out except for Randall, but the real issue of passwords is mostly length. 20 lowercase letters are way harder to solve than a combination of letters, capitalisation, punctuation and numbers if they only last for 8 characters. You can just use a very long static string in this system, and you're fine.

Synology DNLA transcoding alternative

I am a happy owner of a Synology NAS (a DS411j). The DS offers DNLA support, so I could theoretically just plug my TV into the ethernet, and watch all my accumulated movies and anime easily. Sadly, the TV is too cheap to have any decent codec support. Usually, one would install Serviio or another DNLA server onto the DS, as described here.

But annoyingly, the DS411 only sports a tiny ARM CPU which cannot keep up with transcoding difficult codecs (h.264 to mpeg2). The solution? Do all the transcoding over night, and not while you are watching it. This solves the issue of lack of processing power, and results in a neat directory full of files that actually work. The obvious tradeoff being hard drive space, but then a DS411j has four disk slots and hard drives are dirt cheap.

Follow the directions over there to bootstrap the NAS, install ipkg, wget, ffmpeg and yasm. Also execute these two lines if you get an error message about libraries not found when you try to start ffmpeg:

cp /opt/lib/libbz2.so.1.0 /lib
cp /opt/lib/libz.so.1 /lib

After that, use a script such as this

#! /bin/sh
SOURCE_DIR="/volume1/input"
TARGET_DIR="/volume1/video/transcode"
for a in "$SOURCE_DIR"/*.mp4 "$SOURCE_DIR"/*.avi "$SOURCE_DIR"/*.mkv
do
 if [ -f "$a" ];
 NEW_NAME=$(basename "$a")
 COMPLETE_NAME="$TARGET_DIR"/"$NEW_NAME".avi
 echo $COMPLETE_NAME
 then  
  if [ -e "$COMPLETE_NAME" ]
  then
   echo "Already converted: $a"
  else
   echo "Converting: $a"
   ffmpeg -i "$a" -y -vcodec copy -vbsf h264_mp4toannexb -copyts -acodec ac3 -ab 128k -ac 2 -map 0:0 -map 0:1 -sn -f mpegts "$COMPLETE_NAME"
  fi
 fi
done

to automate the conversion. It will check whether a file was already converted, and if not, automatically start to do so. Note that the parameters for ffmpeg work for my Panasonic Viera, you might have to use a different set of codecs. You can check the Serviio forums for a good selection of transcoding profiles, and then trial and error your way to success.

You can then set up a cron job (more on that later) and make your script run automatically every few hours. If there is nothing to convert, it will immediately terminate.

Open issues:

• If anyone with more .sh-knowledge than me could improve upon this and add recursive folders and some such, I'd very much appreciate it.
• I also cannot get my Synology to find these newly created files very quickly, it takes a long time until the DNLA service finally displays them. Is there a quick way to add them to the index?
• I cannot get .wmv videos to convert, ffmpeg seems to fail to read them. It might be my selection of them, or a general issue, I don't know yet.

Passwords, part two of two

We have established why you really do not want to use the same password in more than one place. I have a really old text document in my backups which has a list of all passwords I used ten years ago. I believe it has more than one hundred entries. Online games, discussion forums, redundant companies (amazon.de, amazon.co.uk and amazon.com require their own logins) and generally useful services sum up faster than you think. The issue is:

You cannot ever remember a different password for every service.

It is just impossible to remember hundreds of expressions such as "agclue.jf312kd". Most people use a priority system: Crappy password "plork" for services they do not care about much. Medium password: "Naftalin23" for  their Flickrs, Twitter and Gawker. Safe and unique password for e-mail, eBay and Amazon. That leaves you with a dozen passwords or so. It is workable, but for obvious reasons not a good solution. Is there a better one? I present:

The One-Way-Function. ("hashing")

It works like this: You think of a function that only works in one direction efficiently. A typical example is "I see something and it is black." It is very easy for you to decide whether something is black. It is very hard for everyone else to figure out what exactly you are talking about. While I didn't invent the principle, there seem to be miserably few people who create their passwords with this technique. Let me give you a simple example:

Use the first two letters and the last two letters, then write "qelgf.15" behind it.

Google: "goleqelgf.15"

Twitter: "twerqelgf.15"

eBay: "ebayqelgf.15"

Facebook: "faokqelgf.15"

While already very strong, you could easily add capitalized letters to the static expression, that is "qelgf.15", making it "qElgF.15", for example. You might be disppointed that eBay can be recognized. That's an artifact created by our slightly less-than-ideal hash function, but it actually does not matter that much, because it is still incredibly hard to detect without human eyes taking a look at the passwords. And when you are a criminal and out to steal passwords, you don't want to waste hours to guess such functions, when there are thousands of people using "password" or "12345" instead. In conclusion: Just pick any function which you can do quickly in your head which will result in a few letters from a service url, and append something in front or after (or both).

And if you want insane security, you could even do something like writing your full name with birth year (note that this would be one of the least safe things otherwise), and interjecting one letter from the service name backwards. Assume your name is Michael Kennedy, and you're born in 83. Whenever you type your password, you first type out "Michael83Kennedy", then put the cursor at the beginning and move it right once, then type a letter, repeat.

Google: Meilcghoaoegl83Kennedy

Twitter: Mriecthtaweilt83Kennedy

eBay: Myiacbheael83Kennedy

Facebook: Mkiocohbaeecla8f3Kennedy

It isn't very fast, but leads to passwords that couldn't be safer, and it is impossible (and not just unlikely) to have the same password twice, because two services are always named differently to begin with. And before you point it out: For mathematical reasons, the last names looking identical is completely irrelevant. Do me a favour and adopt such a system.

Passwords, part one of two

In light of the current PSN disaster, and with clear memory of the recent Gawker problems, I want to write about something important, which bothers me a lot.

Do not use the same password in multiple places.

People do not understand why this is such a gigantic problem. They think it is just a matter of convenience (few passwords to remember) versus security, quite alike to how you don't use a different key for every lock in your life. The key that opens your car also starts it, and the key to your apartment complex also opens the door to your flat. But that is very far from the truth. The proper analogy would be to use a single key for all your locks, but at the same time, give a copy of your key to safeguard to every single person that ever enters your home, including the plumber and the boyfriend of your daughter of whom you do not approve.

In more technical terms: If you use the same password for Twitter, Facebook, Gmail, eBay, Gawker, PSN and Flickr, then your chance of losing all accounts in one fell swoop has risen significantly. It does not matter if Gmail and eBay have tight security. If Twitter screws up, your bank account is gone. If Flickr screws up, your bank account is gone. If PSN or Gawker gets hacked, kiss your eBay account goodbye.

It does not actually end here, it gets worse. We all have our major sites which we use daily. But most of us also have accounts at places where we really do not need them often. I play Bloodline Champions (recommended!) which is a tiny game with only a few thousand players, made by a small developer. But I have a forum account for that, which is all but inactive. Still, there is a password involved. And if they get compromised, or a disgruntled employee leaves them, my password could get lost. If it were identical to my others, I would be in trouble.

And it gets worse still. There are quite a few sites out there who want you to register with them, for no reason whatsoever. Some warez downloads lead to files that are password protected, with a text file nearby, telling you to register at their shady site. If you do, not only are you prone to get spam on your e-mail, but even worse, they get a username/password combination from you. They can just try that on google and see if it works. This is the extreme, but do you trust Google? Do you trust Twitter? Do you trust the guy that hosts that discussion forum on politics / porn / kittens you frequent often? Or would he just sell your password? Identity theft is a serious business.

Next up: How to do better.

Addendum
There is such a thing as "salted hashes", which is a technique to store passwords on a server without allowing people to read it, so as to prevent an employee to sell them. In that case, it is a lot harder to get your real password. But it requires that the people running the service know what they are doing. Most do, but if only one does not and gets compromised, the shit has hit the fan.

Portal 2 and Refactoring (alpha 4)

I planned to write a post earlier this week. Then Portal 2 happened and I was forced to play through that once or twice. It's incredibly good and you should definitely go play it now.

In other news, a small (but not insignificant update). I've been doing some refactoring. For the non-technical reader: that means I rewrote parts of the code so it works exactly as before, just better. This also meant that I could clean up some convoluted problems with rewards, which work now much nicer than before. There are two major changes:

Rewards
Rewards for stats are very much streamlined now. The following example is now valid (though a bit silly).

<stat exp="50" level="10" repeat="Inefficient" tag="Charming" untag="Ugly">Personality</stat>
Essentially, I've merged and nodes, and removed the unintuitive requirements for them to have only a subset of all options available at a time. I still would not recommend to mix @level and @exp, because that will reward experience twice (and possibly influence each other), and of course, you can only have a single @tag and a single @untag node per stat. That's just how XML works for attributes.


Challenges
I found "Primary" and "Secondary" to be really imprecise and unclear, not to mention rigid and difficult to use correctly. So I threw that out, and instead give you very simple mathematical tools. We now have the option to average values, or to add or subtract some, or parts of them. Example:

<avg>Reflexes</avg>
<avg>Lucidity</avg>
<sub mul="0.2">Trauma<sub>
<add>Muscles</add>

This will take the average of both Reflexes and Lucidity, then subtract 20% of the Trauma value, and add the Muscle value in full. The total is then tested against. Powerful, but very simple. Most actions will probably just use a single node, and be done with it.

I've also added a few more actions to the demo, showing off on how to do shopping. If you read through the XML to see how it is done and come to the conclusion that this takes a lot of effort to do, then you are correct. Inventory management is also not really something that I think RPGs should obsess over so much. The process of buying an item should be more interesting than the item itself. There is also slightly more content at The Coffee Shop. But as said before: I'm not so much a writer as a software engineer.

Challenge Pass/Fail in Alpha 3 (r52)

On request, I added the option for challenges to be deterministic: You can declare a certain value, and if the player has the required stats as high or higher, he will automatically pass. If he has less, he will fail. No dice rolled, no random chance, no luck. Obviously, it is simpler to use, since it only requires a single value.

Introduction

What is this thing I am making, exactly?

Vision

I comes down to this: An engine to play story-based games in it. Imagine an RPG, but without the (often tedious) combat (and no graphics, I'm not quite rich enough to pay 50 artists for three years). My objective was to write a game which can be extended by fans and which uses some of the ideas that have shaped game design in the last ten years, but without all the typical crap in AAA-titles, such as long and boring combat just to make the game last longer. 

I would hope that people will pick up on the idea of writing their own stories or small storylets, and share them with each other. If possible, it would be nice if everyone would try to write in an action to get from a central transport hub to their respective places in some way (if you want to write your own locations, which I hope), or add to the general fundus. I kindly ask that you do not edit somebody else's work and pass it off as your own (and to be clear: that would be a copyright-infringement), but you are of course free to take their work as inspiration.

Motivation

See here: http://blown-to-bits.blogspot.com/2011/04/story-engine-alpha-1.html

Technology

The engine runs on flash 10, and will read all .xml files in its program folder. Pictures  are loaded with paths respective to that folder too. Currently, write or administration access is not needed (mostly because one cannot save their game, yet).

I plan to offer a correct XML-schema and validation at some point, but that is really boring to program, so I skipped it for now.

Setting (of the demo)

The setting and basic examples are very loosely based on Eclipse Phase (by Posthuman Studios, free to download and it's worth a read or play in any case), with some stats, ideas and topics taken from there. The rules used are quite different though. 

I have decided on a handful of "official" things. Do not write redundant stats such as Strength or Health, and try to be a bit original.

Stats: Reflexes, Lucidity, Determination, Suaveness, Muscles, Trauma

Items: Character Creation Credits, Yen (though more currencies and exchange actions are an obvious path to take)

Legal crap

This stuff is copyright 2011, Kajetan Abt. I used a few pictures I found on image boards, such as /tg/booru. If you made them and want to be credited or have them taken down, just tell me.

You are free to use everything as long as you don't try to sell it. You may (try to) sell stories you write yourself, of course, since you still own that copyright. I only claim the engine and the storylets I wrote myself.

No restrictions apply on what you can write. If it is good, I would like to read it, and I will possibly link to it.

Alpha 2

A decent update, I would call it.

Changelist:

• Additional Requirement nodes for Location, Time or Date
• Multiple Rewards work now (mostly used by Rules)
• XML structure reworked
• Mostly Rules (those look rather different)
• Requirements are now more similar to Rewards
• Bugfixes

The new files can be found here (with updated documentation):

Downloads
If you look at the XMLs and think they are complex, just open the HowTo.rtf, it should explain enough to get started. If that's not good enough, please leave a comment, I will clarify.

If you need Adobe Air to run it, you can find it here: http://get.adobe.com/air/

Edit: I have added a file "Story_Alpha2_InstalledFiles.zip" which is a zip containing the installed files. If anyone tries to use it without having Air installed, please let me know it that works. I do not want to uninstall Air to test that, because that would mess with my developer environment.

Story Engine Alpha 1

Games are a big hobby of mine. Card games, board games, or the thing that made me study Computer Science: Computer games.

I gripe a lot about how computer games are shallow, do not evolve much (apart from the indies which have had a hugely successful year with Minecraft and World of Goo), but mostly: How all, including the vast majority of indie games, are about one thing, and one thing only: Combat.

I do not think I exaggerate when I claim that 99 out of a hundred games are purely about killing, murdering, shooting or slashing enemies. Be they humans, be they zombies, aliens, robots, tanks, ships, spacecraft, military, monsters, dragons, bugs or even abstract shapes. Seriously, why does this hobby come down to killing so much? I can accept that a game without conflict would not work very well, and of course, combat is a form of conflict that we all understand. But on the other hand, is it really necessary? Can't we have conflict without death?

I could rant on and on, and much to my friends annoyance, I frequently do. And "do it yourself then!" is such an annoying argument.

So that is what I did.

I hereby release the absolutely first version of a piece of software that I hope will inspire some people to create something more than just murder simulators.

Downloads: See bar to the right.

How to install:
1. Install the AIR application (you might need AIR from Adobe)
2. Unpack the zip into the application directory, so the xmls are in the same folder as the .swf and the pictures are in a subfolder.