Wednesday, November 16, 2011

IF Comp Results

The results of the Interactive Fiction competition 2011 are in. Kerkerkruip took a very respectable 8th place out of 38 games, which was almost exactly what I expected. What I didn't expect, at all, was having such a low standard deviation! Either fewer people than I expected hate roguelikes, or people were impressed enough by the technical aspects of the game to ignore their dislike of the genre.

Participating in the IF Comp was a very good idea. Kerkerkruip has now been played by many more people than I would have otherwise reached. That is not just something to caress my ego, as we say in Dutch, and not just a way to get more feedback either, though it is that. What I hope is that Kerkerkruip will become something of a standard example of randomised combat and tactical gameplay in IF. Not in the sense of "the standard", but in the sense of "one of the ways you can do it, and a game you should take a look at if you want to attempt something in that direction". New authors wanting to write a combat game appear surprisingly often, and until now there weren't many clear examples you could point them to.

What about the future Kerkerkruip? I intend to keep this project alive. Knowing myself, that means I will work on it like mad for two weeks and then forget about it for three months, but that is fine. Kerkerkruip is the kind of game you can keep improving and extending. It is the project I can turn to whenever the urge to make something really game-like overcomes me. (May it be the project I can turn to whenever the urge to buy and play Diablo 3 threatens to overcome me!)

I have set up a Mantis bug tracker for Kerkerkruip, so if you are interested in seeing what I've been doing -- or interested in reporting bugs in that way, though email is probably better -- you can check it out. The bug tracker does contain spoilers, of course.

The comp was a lot of fun, the authors' forum was great, the reception of my game was as good as I hoped; in other words, I'm happy with it all. Thanks to everyone who made this event happen! And congratulations to my fellow authors!

Thursday, October 20, 2011

[Inform 7] Complex interaction, events, and rulebooks

Suppose that your game involves people that can be sleeping or awake; and a huge gong, that, when struck, wakes up everyone in the room and all adjacent rooms. This is the most natural way to implement something like that in Inform 7:
Carry out hitting the huge gong:
   say "You hit the huge gong!";
   repeat with guy running through near people:
      now guy is awake.
Where I am, of course, assuming that you have already created a definition for "near", and so on.

This is fine if your game is simple enough that (a) waking people is the only effect of hitting the huge gong, and (b) hitting the huge gong is the only cause of waking all near people. But if you are aiming for a complex world model, this will often not be the case; and even more often, you will not be certain whether it is going to be the case.

Why is this a problem? Because you do not want your code to look like this:
Carry out hitting the huge gong:
   say "You hit the huge gong!";
   repeat with guy running through near people:
      now guy is awake;
   other stuff that happens;
   more stuff that happens.

Carry out pushing the alarm button:
   say "the alarm sounds!";
   repeat with guy running through near people:
      now guy is awake;
   other stuff that happens;
   more stuff that happens.

Every turn when having-a-screaming-fit is true:
   say "You continue screaming.";
   repeat with guy running through near people:
      now guy is awake;
   other stuff that happens;
   more stuff that happens.
Evil code duplication! Maintenance nightmare!

This is obviously better:
Carry out hitting the huge gong:
   say "You hit the huge gong!";
   have a loud noise event.

Carry out pushing the alarm button:
   say "the alarm sounds!";
   have a loud noise event.

Every turn when having-a-screaming-fit is true:
   say "You continue screaming.";
   have a loud noise event.

To have a loud noise event:
   repeat with guy running through near people:
      now guy is awake;
   other stuff that happens;
   more stuff that happens.
But that is still not ideal, because all code that relates to loud noises must be in the same place. If I code up a delicately balanced Cavendish experiment that will be unbalanced by loud noise (and believe me, it will), I want to have the code about the unbalancing right there with all the other code having to do with the Cavendish experiment. I want to be able to see what the experiment does and how it can be influenced at a single glance, not by looking through the entire code.

I would like to suggest that the natural way to think about this is the following. Loud noise is a kind of event. If object A can generate that that kind of event, this should be defined in the section of the code pertaining to object A. If object B is influenced by that kind of event, this should be defined in the section of code pertaining to object B. This gives us the cleanest, most readable code, that is easiest to maintain and extend.

How do we do that in Inform 7? By using rulebooks, of course:
The loud noise rules are a rulebook.

Carry out hitting the huge gong:
   say "You hit the huge gong!";
   consider the loud noise rules.

Carry out pushing the alarm button:
   say "the alarm sounds!";
   consider the loud noise rules.

Every turn when having-a-screaming-fit is true:
   say "You continue screaming.";
   consider the loud noise rules.

A loud noise rule (this is the noise wakes people rule):
   repeat with guy running through near people:
      now guy is awake.

A loud noise rule (this is the noise does other stuff rule):
   other stuff that happens.

A loud noise rule (this is the noise upsets the Cavendish experiment rule):
   upset the Cavendish experiment.
And all these snippets of code can be placed wherever they most naturally belong -- in the parts of the code pertaining to gongs, alarm buttons, screaming fits, sleeping, and the Cavendish experiment respectively.

But of course this means that, knowing that you are building a game with a complex world model, you should have coded that very first gong like this:
The loud noise rules are a rulebook.

Carry out hitting the huge gong:
   say "You hit the huge gong!";
   consider the loud noise rules.

A loud noise rule (this is the noise wakes people rule):
   repeat with guy running through near people:
      now guy is awake.
Which may seem exceedingly wordy at the time, but will pay off in the long run.

Today's lessons, then: learn to love rulebooks even more than you already do! Resist the temptation to implement special cases!

Saturday, October 01, 2011

[Results] The Interactive Fiction Top 50

The results of the Interactive Fiction Top 50 are in! No fewer than 35 participants cast a total of 437 votes on 183 different games. Of those games, 48 got three votes or more, and those are the games that will appear in the Top 50 below -- so it is actually a top 48. Games which have the same number of votes appear in the same spot, and will be listed in alphabetical order (ignoring "the", "a" and "an").


Does this mean we finally have proof that game X is better than game Y? Of course not. But I hope you will be inspired to try some of these games. Or perhaps you will be inspired to tell us about that game you think really deserves a spot in this list but hasn't received enough attention. Most of all, I would like you to click on the link above and read the reasons that people gave for choosing one game or another. After all, a reason close to your heart may be more important than a large number of votes.


Fuller results, including a list of games which got two or one votes, will follow; but now, without further ado, the top 48!


First place -- 17 votes

  • Spider and Web, Andrew Plotkin (1998)

Second place -- 14 votes

  • Lost Pig, Admiral Jota (2007)
  • Photopia, Adam Cadre (1998)

Fourth place -- 11 votes

  • Anchorhead, Michael Gentry (1998)

Fifth place -- 10 votes

  • A Mind Forever Voyaging, Steve Meretzky (1985)

Sixth place -- 8 votes

  • The Baron, Victor Gijsbers (2006)
  • Blue Lacuna, Aaron A. Reed (2008)

Eighth place -- 7 votes

  • Savoir-Faire, Emily Short (2002)
  • Shrapnel, Adam Cadre (2000)

Tenth place -- 6 votes

  • Shade, Andrew Plotkin (2000)
  • Slouching towards Bedlam, Star Foster and Daniel Ravipinto (2003)
  • Trinity, Brian Moriarty (1986)
  • Varicella, Adam Cadre (1999)
  • Vespers, Jason Devlin (2005)
  • Violet, Jeremy Freese (2008)

Sixteenth place -- 5 votes

  • Galatea, Emily Short (2000)
  • The Gostak, Carl Muckenhoupt (2001)
  • The King of Shreds and Patches, Jimmy Maher (2009)
  • LASH -- Local Asynchronous Satellite Hookup, Paul O'Brian (2000)
  • Make it Good, Jon Ingold (2009)
  • Rameses, Stephen Bond (2000)

Twenty-second place -- 4 votes

  • Ad Verbum, Nick Montfort (2000)
  • Aisle, Sam Barlow (1999)
  • All things devours, half sick of shadows (2004)
  • City of Secrets, Emily Short (2003)
  • Curses!, Graham Nelson (1994)
  • Fail-safe, Jon Ingold (2000)
  • Gun Mute, C. E. J. Pacian (2008)
  • Sunset over Savannah, Ivan Cockrum (1997)
  • Treasures of a Slaver's Kingdom, S. John Ross (2007)
  • Wishbringer, Brian Moriarty (1985)
  • Worlds Apart, Suzanne Britton (1999)
  • Zork I, Marc Blank and Dave Lebling (1980)

Thirty-fourth place -- 3 votes

  • 1893: A World's Fair Mystery, Peter Nepstad (2002)
  • Adventure, William Crowther and Donald Woods (1976)
  • Aotearoa, Matt Wigdahl (2010)
  • Arthur: the Quest for Excalibur, Bob Bates (1989)
  • Blue Chairs, Chris Klimas (2004)
  • Delightful Wallpaper, Andrew Plotkin (2006)
  • Eric the Unready, Bob Bates (1993)
  • Everybody Dies, Jim Munroe (2008)
  • The Guild of Thieves, Rob Steggles (1987)
  • Hoist Sail for the Heliopause and Home, Andrew Plotkin (2010)
  • Mentula Macanus: Apocolocyntosis, Adam Thornton (2011)
  • Planetfall, Steve Meretzky (1983)
  • So Far, Andrew Plotkin (1996)
  • Suveh Nux, David Fisher (2007)
  • The Warbler's Nest, Jason McIntosh (2010)

Discussion preferably on the forum.

IF Comp, doctorate

In a couple of hours, the IF Comp 2011 will start. Or at least, the deadline for uploading games will have passed; it might take a little longer before they actually become available. Since I will be participating, I won't be publishing reviews during the competition. In fact, I won't be saying anything at all about the competition, because I don't want to be disqualified.

So let me take this final opportunity and wish the best of luck to my fellow authors, the greatest of wisdom to the judges, and the finest of times to us all.

Also, although this is not a blog about my personal life, I cannot resist the temptation of sharing with you the elation I still feel about getting my doctorate two days ago. Impression of me with my two 'paranimfen': photo. Imagine a committee of 11 people to the left, and an auditorium full of friends, family and colleages behind the photographer. In the Netherlands -- this differs widely between countries -- the actual defence is a big ceremony. At that stage you can no longer fail, but it is still a very exciting day. And you do have to answer difficult questions about your thesis for 45 minutes while all your loved ones are watching (and wondering what you are talking about).

In case you are interested in a PhD thesis on philosophical theories of explanation, you can find it here.

Sunday, September 25, 2011

IF Top 50 -- deadline in 5 days!

If you haven't participated in the Interactive Fiction Top 50 yet, and you still mean to do so, stop procrastinating! The deadline is five days from now: September 30.

You can post your games in that topic, email them to me, or even post them as a comment to this blog entry.

Sunday, September 11, 2011

What is the first secondary world?

Under the influence of Tolkien, fantasy moved towards the creation of secondary worlds. Let me define that term:
A secondary world is a fictional world which is neither a geographical nor a temporal part of our world; and is not connected to it as a dream world, a realm of Faerie, a space of Ideas, a land-beyond-a-portal or anything of that sort. Furthermore, the secondary world should be a real world, not just an allegory.
For instance, the tall tales that Odysseus tells in the Odyssey are fictional and fantastic, but are not set in a secondary world, because they are supposed to have happened on our Earth. On the other hand, modern fantasy writers like Martin and Jordan do use secondary worlds: no explicit or implied relation exists between their fantastical realms and the world we inhabit.

My question is, what was the first book that introduced a secondary world? I haven't managed to think of any clear examples that predate The Lord of the Rings by more than a few years. This is probably wrong. There were probably secondary worlds before 1948 (the earliest book I can think of; see below). But it is not as easy to find them as you might suppose.

For instance, I cannot think of any ancient examples. Later fantasists like Dante, Ariosto and Rabelais evidently put their creations in our own world. Indeed, we can move far closer to the present day and still find the same. The land of Oz can be reached by stepping into a tornado, and is probably supposed to be somewhere in the American desert. Lord Dunsany's Elfland can be reached by humans. E. R. Eddison's magical realm is, if I recall correctly, presented as a dream. A Voyage to Arcturus brings us to its metaphysical mythology by a journey through space. James Branch Cabell's Poictesme is connected to our world through historical transmission of documents. Peter Pan lives somewhere beyond the ocean. Narnia lies beyond a wardrobe. The pulp writers (Howard, Smith, Lovecraft) often hinted that their tales were set in a distant past or future. Fritz Leiber's characters seem to inhabit a weirdly fluid set of dimensions that might very well include ours. Peake's Gormenghast is obviously somewhere on Earth.

The oldest example of a true secondary world that I can currently think of is The Well of the Unicorn by Fletcher Pratt, which was published in 1948. Its introduction explicitly tells us that our world is "another world than the one discussed here"; and it looks and reads much like a piece of modern fantasy. There even is a map at the beginning of the book.

Again, I doubt that this is the first secondary world. So, my general question to you is: what is the oldest example you can think of? There are bound to be some borderline cases, but I'm interested in anything that you think might fit the bill.

Friday, September 09, 2011

The King of Shreds and Patches on the Kindle

I don't own a Kindle because, well, closed platform, right? But if you do own a Kindle, have access to the Kindle app store, and have even the smallest interest in interactive fiction, I would like to point you to The King of Shreds and Patches.

The King of Shreds and Patches is a very good game; in fact, it appeared in my recent top 10 interactive fiction games ever. It is long, well-written, well-researched, not difficult, and a lot of fun. Because of its length, accessibility, and quality as a page-turner, it is perhaps the single piece of IF which I would have most liked to see ported to an e-reader.

So, highly recommended.


P.S.
I wrote a long analysis of the game here, but you really shouldn't read that until you have finished the game.

Wednesday, August 31, 2011

Participate in the IF Top 50!

Interactive Fiction Top 50

Link to forum topic.

Based on a discussion on the interactive fiction forum, I am organising a interactive fiction top 50 (or a top 100, or a top 20, depending on the number of participants and the distribution of the votes). You send in a list of your favourite IF games, I add those lists together and publish a "best of" list.

The aim is not to decide what the best IF ever is by majority vote -- that would be foolish. Rather, the aims of the top 50 are:
  • To create a good opportunity for people to think about the best games they have played, and discuss their ideas on this topic with others.
  • To allow people to be inspired by what they see on other people's lists.
  • To create a useful list of great games at which you can point newcomers to the IF scene.
  • If it is successful and we do this every few years: to create a way to track how the taste of the community evolves.

To make this work, we need your help. Please send us a list of between 1 and 20 interactive fiction games that you consider to be the best IF games ever made (or at least the best that you have played). The list can be posted at the IF forum or mailed to myfirstname@lilith.cc, where you replace "myfirstname" with my first name. Which is Victor. You can also email me if you want me to post your list on the forum (in case you don't have/want an account). Here are the rules:

  • You can list between 1 and 20 games.
  • The order in which you list the games is not important. The total number of points a work receives is the total number of votes it gets.
  • You can list each work only once.
  • You can list multiple works by one author.
  • You can list your own works.
  • It's up to you to decide whether a work counts as interactive fiction. As a rough rule of thumb, anything that is or should be listed on the IFDB is suitable.
  • We are asking you to identify the best interactive fiction, not the most influential, most important, most innovative or most accessible interactive fiction. (But of course, if you believe that influence, importance, innovation or accessibility are important parts of being good, that is fine.)
  • The deadline for entering your list is 30 September 2011.
  • The organiser is allowed to participate. (It's good to be making the rules.)

You don't need to do anything except send in a list. However, the whole thing will be a lot more fun if you also post the rationale behind your choices in some public place.

I hope to see many of you participate!

Tuesday, August 30, 2011

IF Comp reminder

A small reminder for people who want to enter the IF Comp: the deadline for intents to enter is in two days. No reason to delay any longer!

(Note: I'm not an organiser.)

Saturday, August 27, 2011

Designing achievements

Nowadays, many games offer an achievement system: if the player manages to do X, the game recognises this and keeps a record of it in a privately or publicly accessible place. Many of us will have felt a deep suspicion about achievements. Aren't they designed to appeal to the worst part of us, the part that likes to hoard (and sleep, and feed)? Isn't the whole point of achievements to seduce us to waste our time trying to get them all, even though doing this is neither particularly fulfilling nor particularly fun?

Such suspicions are well-founded, and very often correct. Mocking achievements is good. And yet, there also good achievements, achievements that do add something to the game experience. So let us look at what is good and what is bad. (Recommended reading: achievement design 101 at Gamasutra.)


Good achievements

Additional challenge

Many games ask you to perform at a certain level before you are allowed to continue. In a shooter, you must get through the level without losing all your health. In an RTS, you must defeat your opponent. The game recognises this by showing you a "Victory! Loading next level"-type of screen.

But it is of course possible to adopt higher standards of performance, in order to make the game more challenging and more fun for better players. Achievements are a good way to implement this: not earning an achievement still allows you to continue the game, so less good players are not penalised; but better players are rewarded for taking on the additional challenge.

Starcraft 2 is excellent at this. Every single-player mission comes with several achievements that make it tougher. For instance, you might be playing a defensive mission, where you have to survive for 20 minutes. One achievement is awarded if you don't lose any buildings during that time: this forces you to get a better, more organised defence. A second achievement is awarded if you destroy four of your opponent's hatcheries (big buildings). This forces you to somehow get an attack force together and do counterattacks while still defending your own base. Difficult, but very satisfying when you pull it off.

Teaching the game

By setting a goal, and asking players to attain that goal, you can teach them an essential gaming skill. For instance, Starcraft 2 has an achievement that has you
Train 10 marines during the first 320 seconds of a single Melee game.
The only way to train 10 marines in 320 seconds is to really optimise your build. You have to think about and experiment with different tactics: for instance, should you spend you early money on more marine-making buildings, or is it more efficient to spend it on marines immediately? When you have earned this achievement, you have not just learned a useful in-game skill (getting an army very quickly), but you have been introduced to an entire way of thinking about your early-game strategy.

Recognising progress

A certain amount of feedback on and recognition of your progress in a game is often desirable, and achievements can be used to provide this if the basic structure of the game does not. That latter part is essential: if the game obviously recognises your progress, achievements that do the same thing are cheap and useless. The Valve-games (Portal, Half-life 2) are culprits in this regard: the whole structure of the game is that of linear advancement, so you get continual feedback and recognition; and yet Valve has added achievements of the form "you have reached part X of the story!". Useless.

Much better are the song-by-song ratings in Guitar Hero-type games. If you get better at the game, you will manage to beat your previous records. This gives a sense of gradual advancement that would not otherwise be present in the game.

Bad achievements

Superfluous progress recognition

See above. An achievement that you get just for advancing in a game, where advancing in the game is already an obvious reward for your success, is a useless achievement that feels cheap. It makes the player wonder whether the designer really thinks the player is going through the game just to earn achievements.

Random achievements

Achievements for things that you cannot really set out to accomplish are bad. Team Fortress 2 has quite a few of these. (In general, I am underwhelmed by the Team Fortress 2 achievements.) Consider the "Rasputin" achievement: In a single life, get shot, burned, bludgeoned, and receive explosive damage. There is no sensible way to try and get this achievement; it is just something that will happen to you if you play the game often enough. Or you can join a special achievement server, where people help each other getting these random achievements...

Random achievements do not reward skill, and if you do get them, they do not feel like an achievement. The only thing they reward is perseverance, which is exactly what makes us suspicious about achievements. Of course, just because you cannot set out to achieve them, they are still better than...

Grinding achievements

The very worst achievements are the ones that require no skill, but only a willingness to keep doing the same thing over and over again. Team Fortress 2: "Kill 100 enemies while both you and your victim are underwater." Starcraft 2: "Win 1000 1v1 Quick Match games of each race (as well as 1000 random games)". World of Warcraft: "Get 100,000 honorable kills". And special hatred goes to Half-life 2: Episode 2: "Squish every antlion grub in Episode Two.", an achievement that manages to combine tedious grinding with an miss-one-and-start-over system.

The only purpose of a grinding achievement is to make you play the game longer. They are not challenging, They are not fun. They are just a meaningless reward given to those who become addicted. And yet -- they are psychologically powerful. I have succumbed to some of them.

Marketing

And achievements like "you have recommended this game to a friend on Steam"? Let's not talk about them.


Bottom line

A good achievement is an achievement that enhances the game. The game can be enhanced by adding interesting challenges, a bit like adding an extra level of difficulty; by teaching the player useful in-game skills; and by allowing the player to track the improvement of his skills.

Skill is the central word here. Those parts of the game that are not about skill (theme and story, beautiful art, interacting with other people) do not need achievements: it would be ridiculous to have the game say "Great! You have seen the crucial scene about how sex without emotional vulnerability may be fun but is not, in the end, really fulfilling!", or to have it say "Wow! You just had a good time with your online friends!". Games that do not rely on skill do not need achievements.

Bad achievements are primarily those that attempt to disguise non-skill as skill: "Wow! You have managed to kill 1000 rats!". The skill is killing a rat, but not killing 1000 rats. These achievements are cynically used to seduce players to spend more time with the game than they otherwise would. In a further act of cynical manipulation they are often combined with a system that allows you to proudly display your achievements to other players.

It makes one shudder to think of Diablo 3, does it not?

Thursday, August 04, 2011

Kerkerkruip - looking for testers

Kerkerkruip has entered beta, and I'm looking for a few testers. If you are interested, please send me an email at victor@cc.lilith -- except that I have cunningly switched "lilith" and "cc" to confuse the spam bots!

Even if you don't have time to really test the game, you can still help me out in a few minutes if you have access to (a) OS X, or (b) older hardware. I need to know how the game runs on the OS X interepreters, and I need to know what the minumum hardware requirements are. (Kerkerkruip runs without noticable delays on my own system, but turns take a noticable, though not irritating, amount of time on an EEE-PC netbook.)

Also, I will post no more updates about the game on this blog until the competition is over. I do not want to build "hype", or even raise the suspicion that I am trying to do so.

So radio silence starts now.

Sunday, July 31, 2011

[Inform ATTACK] Version 3 released

I am happy to announce Version 3 of Inform ATTACK. As always, the latest version can be found here; if you specifically want version 3, click here.

Code written for version 2 will generally be compatible with version 3, though you should check out the changelog below to see if any of the changes might interfere with your existing code. Updating to version 3 is recommended because it brings a more robust handling of readying and natural weapons. Version 3 also adds the "weapon damage bonus" property, which can be used to increase or decrease the damage dealt by weapons in a more flexible way than was previously possible with only the "damage die" property. (The base damage dealt by a weapon is now a random number between 1 and damage die, plus the weapon damage bonus.)

Full changelog:

  • Added "wield [weapon]" and "use [weapon]"' as synonyms for readying.
  • Readying now applies to a visible rather than a touchable thing.
  • A new check readying rule, the cannot ready what is already readied rule, rejects the readying action when applied to a readied weapon. This failed action takes no time.
  • The standard report readying rule now handles second person singular and any person plural correctly, and has a slightly improved message.
  • The parser now considers it unlikely that the player wants to ready a natural weapon.
  • The ready natural weapons if no other weapon readied rule has been removed in favour of a more robust system of readying natural weapons.
  • There is a new phrase "ready natural weapons", which readies the natural weapons of any alive person in the location who has no other readied weapon. This is run every combat round (by the govern combat first part rule).
  • When play begins, the ready weapons for everyone rule is run, readying a weapon for every person in the game -- carried non-natural weapons if possible, otherwise natural weapons.
  • The standard AI will no longer sometimes choose to ready an already readied weapon. (The weight entry has been decreased from -100 to -1000.)
  • When striking a blow, the game now abides by (rather than considering) the immediate results of hitting rules. This gives the author more control -- for instance, the author can now stop the blow if the immediate result of hitting someone is death.
  • The phrase "You were killed by X." will no longer be printed as (for example) "You were killed by the dead troll." if the troll also died during the attack. ATTACK will now always print "You were killed by the troll.".
  • If the damage die of a weapon is less than 1, it will no longer be rolled by the standard damage roll rule; its result will be considered 0. (Negative dice make little sense.)
  • All weapons now have a number that varies called the "weapon damage bonus", which is usually 0, but can be both positive and negative. The standard damage roll rule adds this number to the damage roll. The damage dealt by a weapon before modifiers is therefore 1d(damage die) + (weapon damage bonus).

Friday, July 15, 2011

On judgement

This post has been in the back of my mind for a very long time, but has recently been promoted to the front by reading reviews of The Witcher 2. I guess I should make it now, before a proximity with a competition I intend to enter may make it seem less disinterested than it, of course, is.

Here is a typical discussion you'll find on the internet about a review of a game.
A: This review sucks, because X.
B: A review is just an opinion, man! It can't be wrong or right.
C: No, a review is not just an opinion.
D, E, F, G and H: You're really stupid!
But C isn't stupid. C is right. If you write a review, you are not just giving an opinion. You are giving a judgement, and a judgement is something that aims to be reasonable and objective. There are standards to which a judgement must conform; and a judgement can fail to conform to those standards and be wrong.

It is important to understand that this reasonableness and objectivity have little to do with the final verdict expressed in the judgement. Reasonable judges can give the same game a 10 or a 3. A judgement is reasonable and objective when it is based on reason; when the judge can give an analysis of the game and explain his verdict using criteria that other people can understand and sympathise with. There may be disagreements about the exact application of those criteria, but there is in general agreement about the criteria themselves.

Why was this topic in the back of my mind for a long time? Because every IF competition has a couple of judges who flagrantly ignore the basics of what it means to be a judge. These are the people who write reviews that go: "After playing for five minutes, I really didn't like the game and I couldn't be bothered to play any further. So that is a solid 1." That is not a judgement about the quality of the game. That is an expression of personal feeling. There is nothing wrong with approaching IF with the idea that you will stop playing any game that doesn't make you enthusiastic in five minutes. Fine. But something is very wrong with having this attitude and then being a judge in a competition. When a competition is looking for judges, it is looking for judges, for people who are willing to invest enough time and thought into the games that they can form a reasonable judgement about its quality; it is not looking for people who believe that their immediate emotional reaction to something is valid and worthy of being communicated to the rest of mankind. (This may be hard to grasp in the era of Facebook and Twitter, but really, it is true!) If that is the way you approach a competition, you are just as wrong as a legal judge who doesn't weigh the evidence but bases his verdict on personal like or dislike of the accused -- the only difference being that the consequences of your actions are less dire.

So, yes, reviews can be reasonable or unreasonable; they are not just opinions; and judging a competition is serious business. Before you give a bad mark to a game because you "didn't like it", ask yourself whether you have seen enough of the game to come to a reasonable judgement. Otherwise, a little bunny cries. Really.

Kerkerkruip design journal #8: an update on progress

You may think my not posting about Kerkerkruip means that I haven't been working on it. Nothing could be further from the truth, however. In fact, I am very rapidly approaching the first beta: a feature-complete game with documentation, cover art, and hundreds of bugs!

Talking about documentation, I am planning on recording a short introduction video. You will see me playing the game in gargoyle (the video captures a part of my desktop), and you will hear me explaining the basics of the Kerkerkruip system. Technically, this is very easy (using gtk-recordmydesktop); and I suspect a tutorial video can be a lot more fun than a written tutorial. There will also be written help, of course, for those who prefer it and those who wish to look something up.

I just got permission to use the photograph I found on Flickr, so let me share the cover art with you:


Perhaps the text on the right should be a bit more orange? Let me know what you think.

I'm really looking forward to the IF competition. And it is still so far away...

Friday, June 24, 2011

Kerkerkruip design journal #7: progress and plans

Thinking up cool things and then implementing them is of course a mode of programming that is a lot of fun. In interactive fiction, it is also generally unproductive: you have a story to tell, and "cool things" are often mere side attractions that decrease the time you have to develop the core game. Luckily, for Kerkerkruip this is not the case. The core game is simple, and adding cool things to it is exactly what I should be doing.

Of course, some thought needs to go into the kind of cool thing one develops: having several hundred weapons with different cool stuff isn't much good if the player can only fight an identical goblin over and over. (Be assured: Kerkerkruip does not have a goblin. It does not have a giant rat or an orc either, and the skeleton is a temporary standard monsters slated for removal.) And although I believe it is important and cool to have "special" situations that only occur in a small percentage of the games, it would be unwise to spend most of your coding time on such rare situations and neglect the more common ones.

In the last few days, I have made a heat system and a rust system. The former developed from the thought that it would be cool to be able to heat up weapons, having them do more damage to enemies, but at the price of weakening them -- a heated weapon has a small chance of being destroyed whenever it is used in combat. But if you can heat up weapons -- by holding them into a forge, say -- you must also think about what happens to other items when you heat them up -- some might be immediately destroyed, others might melt, others might burn... thus was born my simulation-heavy heat system. Objects can be heated, and hurt the people who carry or wear them; objects can heat up other obects in their vicinity; and so on. A huge amount of applications suggests itself; and the system ties in nicely with the materials system I had already developed in order to make the difference between iron and silver weapons. The forge that turns an iron weapon into a deadly if somewhat weakened blade will immediately melt the silver weapon.

If there is one system I truly hate seeing in an RPG, it is equipment degrading through use. Training up my "repair" skill in order to repair my weapons and armour is not my idea of fun. But equipment degrading for a specific reason, that is something different, and this is where the rust spores come in. Once the spores of this obnoxious fungus enter a room, they start rusting everything in the room that is made of iron. Worse, rust spores spread through the dungeon: every turn, there is a small chance of them spreading to any adjacent rooms. I am planning on three sources for rust spores:
  • With a very small chance, one of the rooms of the dungeon may start out containing rust spores.
  • With a small chance, an unconnected room full of rust spores is generated somewhere in the dungeon. If the player digs into this room using the magical spade (or another means of creating new tunnels) the rust spores are out. (Other unconnected rooms that are sometimes placed in the dungeon are the Hidden Treasury, which it would be good to find, and the Eternal Prison, which it would be not so good to find.)
  • With a very small chance, a closed container in the dungeon may contain rust spores. Opening the container sets them free.
So this is a feature meant to come up only in about, say, 5% of the games. Rust spores degrade weapons, but there are several things the player can do to stop this from happening -- turning them into silver, for instance, or heating them up. (At a later point, I'll probably add a way to close of passages, giving the player the ability to contain the rust spores.) And rust spores can be a boon as well as a bane: iron weapons used by monsters rust just as easily as those used by the player, and monsters made of iron... well, they won't be too happy.

I have drawn up a preliminary plan for the development of Kerkerkruip:
  • Now - first week of august: go on implementing whatever sounds cool.
  • Second week of august - last week of august: implement whatever the game needs most in order to give a complete and rounded experience.
  • September: testing.
  • September 30: upload Kerkerkruip to the IF Competition.
That's right, I'm planning to enter the IF Comp, for the first time. I find it hard to predict how the IF crowd will react to an IF/rogue-like hybrid, but, well, one doesn't need to win to make it worthwhile.

If you would like to see an alpha version of the game and perhaps give me some feedback on it, let me know at victor-lilith-cc (only those who can guess where the @ and the . go, i.e. humans, need apply!). But be warned that the game is in alpha state: there will not just be bugs but also unfinished features, no attempt at balance has as yet been made, and so on.

Sunday, June 19, 2011

On inventory limits

I doubt Kerkerkruip will have an inventory limit. Given that almost all games which feature inventory also feature an inventory limit (the big exception being modern IF), it may be interesting to look at the phenomenon in a bit more detail.

Inventory limits come in several forms.
  1. You can have a straight-up maximum amount of items which the player can have in his inventory. Common in early IF, but pretty unusual in graphical games and even non-graphical rogue-likes, which generally go for the second option, or a combined second/third option. It is used for weapon possession in some shooters, like Borderlands, Left 4 Dead, Crysis 2 and Duke Nukem Forever. (Some of these claims based on reading reviews.)
  2. You have a limited amount of types of items you can carry, but can stack multiple tokens of the same type in one inventory slot. There may be a maximum amount of tokens such a slot can hold, and you may or may not be allowed to dedicate multiple slots to a single type of item. Examples are most rogue-likes and the classic Black Isle RPGs (Baldur's Gate, Planescape: Torment).
  3. You have a maximum amount of X you can carry, and different items (or item stacks) come with a different amount of X. This X is commonly either weight (many rogue-likes, The Witcher 2) or space (Diablo 2). This allows the designer to make some items easier to keep in your possession than others, which can be used for interesting tactical design. Most often, however, such a system seems to be designed for 'realism': as far as I can see there are no deep game design reasons why a suit of armour takes up more X than a ring in Diablo 2 and Dungeon Crawl. It just does because that is 'realistic'. (In case it wasn't clear, I have a deep disdain for any design argument that invokes realism. When I see someone complain that it isn't realistic if you can just shoot a bow without having to buy or find more arrows all the time, I want to punch that person.)
  4. Finally, there is a system where you can carry just a few kinds of items, and each kind has a specific maximum. This is almost universally used for ammunition in shooters, where you might be able to carry (say) up to 200 pistol bullets, 50 shotgun shell, 12 rockets, and 4 grenades. You cannot take more grenades by taking less shells.
Given that many games have inventory limits, what good do they do? Let's look at some of the bad reasons first. (I don't want to categorically claim that these reasons could never be good for any game, but it would have to be a rather special game.)
  1. Inventory limit puzzles! Right up there with mazes, everyone hates the kind of old IF puzzle where you can take only 3 items with you through the portal, and you get stuck if you take the wrong ones. Or if you can return through the portal, it just adds tedium as you move back and forth to get new items. You'd have to think of a brilliant puzzle to make this kind of thing work again.
  2. Realism. See above.
  3. Giving the player decisions, and then punishing unwise decisions through boredom. If the player can stash her loot away, can go get it when she needs it, and the only (or major) associated cost is player boredom -- you have done something wrong as a designer. To a certain extent, a game like Dungeon Crawl suffers from this: you can't escape to get to your stash at every point, and there is an objective cost (hunger), but in general dropping stuff in a stash and retrieving it when you need it works. And is boring.
  4. Making the optimal strategy really boring. In almost every game with shops that buy items, the optimal strategy is to pick up absolutely everything until your inventory is full, then returning to the shop and selling all items. Generally, this would mean that you are spending half the game travelling between the action and the shop. Nobody does this, instead only picking up the most valuable items; but the game does in fact reward you for doing the really boring thing. Not a good design idea.
  5. Getting people to buy another copy of your game. You can artificially increase your inventory limit when you play Diablo 2 on Battle.net if you own a second copy of the game -- it allows you to log in as two players at once and swap items between characters. Really. Try getting a full set of set items without this trick.
 Now for some good reasons for having inventory limits.
  1. Adding interesting tactical/strategic decisions. Do you take the scroll of teleportation for an easy escape, or the axe of fire for when you meet a hydra? Is that ring of poison resistance really more important than the boots of stealthiness? And so on. In order for there to be real choice, it is essential that items you do not take become unavailable: they either disappear or the in-game cost of retrieving them becomes too great. (If this fails, you get option 3 above.) It is also essential that you have enough non-hierarchically related items to make the decisions interesting: if one item is always clearly better than another, there is no decision.
  2. Saving the player from becoming overwhelmed by choice. While having options is fun, having 328 options is not fun. If my inventory in Borderlands contains more than ten weapons, I'm starting to lose sight of what they all do, and I'll just stop using them -- there's no way I could go through all of them and choose the right one during combat. So thank god for an inventory limit that at least forces me to get rid of my weapons when I hit the 20 weapon mark. Otherwise, I would at some point face the daunting prospect of having to look through 1000 weapons and finding the best one...
  3. Making the player use items. In general, if you are not risking permanent death, it is strategically best to save your best items for later. So the player who is implementing the best strategy might be saving up all the cool stuff, never using any of it. But if she hits an inventory limit, using it suddenly becomes the best choice -- and this often adds to the fun of the game. For instance, the best 'normal' weapon in Half-life 2 is the Overwatch machine gun. This gun has a ridiculously low ammo limit of 90 bullets. This means that once you hit 90 bullets, and you see some Overwatch guys (who will drop ammo for it), you ought to use this highly satisfying gun. If there were no inventory limit, you might try to do everything with your pistol, stockpiling thousands of machine gun bullets for who knows what bad-ass enemies the rest of the game might bring.
All of these good reasons, especially the latter two, are more applicable to long games than to very short games. In Desktop Dungeons or Kerkerkruip, there is no temptation to save your items for a later threat, because the final threat is right there, in your face. There is no possibility of being overwhelmed by choice, because you'll never have more than ten items. And given the small world of the game, it is not easy to see how you could implement a system where items become permanently unavailable if you don't pick them up. All right, I can think of some systems. But they wouldn't be very natural, and you'd only want to implement them if you were certain they would result in good tactical choices. In a game with few items, it is doubtful whether further restricting the amount of items you can use is the best source of more tactical decisions.

It should also be obvious that none of the three reasons applies to either puzzle-based or puzzleless modern IF. They only apply to games with repeatable actions and underlying game mechanisms. So it is clear why modern IF has moved away from the inventory limit.

Saturday, June 18, 2011

On the design of Half-life 2

Yesterday, I finished Half-life 2. Not for the first time; I'm certain I played it when the Orange Box came out in 2007, and I might have played it before that as well. I remember I really loved it.

I loved it a lot less this time around, and in fact have major complaints against the design of the game. This is odd, because I'm pretty sure that the things I loved 4 years ago were the same things I disliked now. Let me try to explain, and I'd love to hear what you think.

Story and characterisation

The story is simply bad. There's a lot of SF nonsense about humans being oppressed by aliens from another dimension, and there's a being out of time who manipulates Freeman for purposes unknown. All very "mysterious", but the kind of mystery where you feel that the guys at Valve are not giving you a coherent story because they don't have a coherent story to give you. This feeling was certainly borne out by the two episodes that followed, which did little to clarify the situation.

Most mysterious is the design decision to give Freeman no voice. I'm not talking about voice acting, but about any means of communications at all. People are continually saying things to you, you do not utter a single syllable, and nobody thinks this is strange. What are we to make of this? Do they all know that you are a mindless automaton? No, they seem to treat you as a human being with emotions. So why are you not talking, and why are they not noticing? Freeman's silence makes it impossible to take anything in the game at face value; but then the game doesn't provide another value for you to take things at. We only have bewilderment.

I really don't understand this design decision. There have been other games with a they-talk-and-you-do-not approach, like Diablo 2. But that was different. (1) Since you trade with these guys, you are apparently communicating, even if the game doesn't show this. (2) You were still selecting options from a menu, even if they were as impersonal as "trade" and "turn in quest". (3) Since the game was less cinematic and the conversations were less about personal feelings, reactions of the protagonist were less important and less expected.

Freeman really freaks me out. I don't believe he is supposed to, but man... his silence is his only personality trait!

Gameplay

Many of the original reviews agreed with me that Half-life 2 didn't have a great story. So let's put that to the side, and look at the gameplay. Surely that is brilliant? It has everything: not just fast FPS action, but also vehicles and jumping and shooting down huge robots and summoning ant lions and getting the upgraded gravity gun and whatnot. A truly fast-paced game with lots and lots of variety.

And it's true. Half-life 2 does give us a lot of variety. A lot of creativity went into it. But, and this seems to me the game's central problem, all of it is the creativity of the designers. Nothing is the creativity of the player.

It starts with the extreme linearity of the game. There is exactly one path, and it is impossible to deviate from it for more than a few meters. Even where there was absolutely no reason to choose such a design, Valve insists on linearity. For instance, near the end of the game you are turning off generators in some kind of public building. It's a big building, you need to get to all generators, there's no story reason to do them in a particular order. But Valve blocks off all corridors except one with force fields, and then slowly turns off the force fields one by one as you shut down the generators. Why? Apparently just so the player doesn't get overwhelmed by having... a choice.

The linearity of the game is so ridiculous that you cannot help but wonder -- again and again and again -- why the Combine is sending soldiers at you when all they would have to do to stop you is lock a single wooden door, or put a single 70 cm high obstacle in a corridor somewhere. In fact, if they just did nothing, Freeman would get stuck in one of the many areas where you can only proceed once your enemies have blown up a wall.

Linearity wouldn't be so bad if Valve allowed us to decide how to take on the enemies. To a certain extent, of course, we can: we can choose to throw a grenade, or use our crossbow, or shoot with our machine gun. But in fact, this extent is quite limited. We are continually placed in situations where there is exactly one way to proceed, and all we have to do is pick up the designers' hints and act on them. Combine soldiers behind shields? You'll be given a bunch of grenades just before you arrive there. Lots of zombies coming through a narrow corridor? Three circular saws are lying on the ground at your feet. In fact, if you come across a cache of rockets, you know that you will have to fight an airship or a strider. This is true every single time. You don't see a strider and decide which weapon to use against it: only rockets will work. You don't see a strider and think of a way to get rockets: there will always be a cache of rockets nearby, and there will be no other way to get rockets. The designers have decided that it is time for a rocket-vs-strider battle, and therefore you are given a strider and rockets and the battle commences.

This design philosophy informs every aspect of the game. The designers at Valve have decided what you are going to do at each point of the game, and any significant deviation is impossible. You never duck into a small tunnel because it allows you to circumvent the guards; you duck into a small tunnel because it is the only way forward. You are never moving crates and floating barrels because you have had an interesting idea, you are moving them because you have come to see that the level has been designed in such a way that you must positions the barrels and crates in position X in order to proceed. If you find placable turrets, you know that you'll have to defend the area against lots of enemies. There are no exceptions. Perhaps worst of all, there is Ravenholm with its awesome anti-zombie traps: gas-and-fire traps, falling cars, rotating knives, truly brilliant. But every trap has been designed and placed by Valve. The player just pushes the on-button. You don't even have to lure your enemies towards it, because if there is a trap, Valve will of course have provided you with a couple of enemies who are walking towards it.

As I played, the feeling that I was just acting out a script given to me grew stronger and stronger, and I came to resent it more and more. Why don't these guys just leave me alone? I don't want to be fed the set-pieces you have thought up in advance; just give me a level in which I can move and do things and be smart. And if it's a pure arcade game in which I don't have to be smart, but just have to show my skill at shooting in the right direction, that would be fine too -- but do not force me to act out the smart ideas you have had.

Seriously, if you think that crushing zombies under a falling car is cool, design a game in which I can raise cars, lure zombies, and crush them. Don't design a game with a suspended car, some zombies wandering towards it, and a button which I can push to drop the car. Because that is me acting out a scenario you have thought up and imposed on me.

Let me put it another way. The Half-life 2 designers are like a bad kind of Game Master: the kind of guy who has thought up in advance with what tactic the monster should be defeated, who gives you the tools to do it, and who rules that anything else you try will not work. "Nope, your spell does nothing. But remember that wand you just found in the previous room?" To which the natural player reaction is: "Yeah, I remember it, but I refuse to be manipulated. You are trying to usurp my fun, and then you want me to congratulate you on your well thought-out scenario. Go away." That seems to be exactly what the Half-life 2 designers have done: usurp my fun, and then expect me to applaud them for their brilliant "design". I'm not applauding. I just feel manipulated.

Friday, June 17, 2011

Kerkerkruip design journal #6: silver weapons

Monsters and the undead

In Kerkerkruip, regular monsters are not only the main obstacles, but also the main opportunities: you gain powers by killing them, and absorbing their souls is the only way of healing. (If you kill a regular monster, you immediately regain all your health.)

This means that having more low-level monsters in the dungeon actually makes the game easier, because you can retreat from a difficult boss fight in order to kill a lowly monster and regain your health. But in general we want additional monsters to make the game harder, especially if they are generated because the player tried something risky, like opening that sarcophagus that may or may not contain treasure... and may or may not contain a monster. Therefore, we have soulless monsters which grant neither powers nor healing; and the most important class of those are the undead.

Undead not having souls makes sense and is easy to remember, and it is also easy for the player to recognise new monsters as undead, even though they might vary as wildly as vampires, mummies and liches. (None of whom are in the game right now, by the way. I only have one lonely stock skeleton in order to test things.)

Silver weapons - resistances and vulnerabilities

Having made undead, the urge to make a kind of weapon that is especially good against undead came to me immediately, and I coded up the silver property. Silver weapons deal less damage to non-undead, but significantly more damage to undead. Diversifying loot -- great idea! Right?

Wrong. As Ascii Dreams has told us long ago, there is something deeply wrong with the common system of resistances and vulnerabilities, where some monsters take more or less damage from weapons or spell of a certain type. It mostly devolves into finding out once what the best type of weapon/spell is to use against enemy X, and then using that type in the future. It gives us a one time 'puzzle', not a recurring strategic or tactical decision. Undead? Use silver. Boring.

Now I guess there is some value in simply diversifying loot, since it gives the player more things to look forward to, and more moments to relish. But resistances are about the worst way to accomplish this, as they finally boil down to a simple question of luck: if you do find a silver weapon, undead will be easier than in the average game; if you do not, they will be harder. There is nothing interesting about it.

Alchemy to the rescue

But what if you never give the player a silver weapon, but you do give him a means to turn a normal weapon into a silver weapon, permanently? In effect, this means ruining a weapon for normal combat, while making it better for combat against the undead. Is there a weapon you want to sacrifice for this purpose? If so, which weapon?

In the right circumstances, these can be interesting choices. They are not interesting if you carry around fifty almost identical weapons, because in that case, you are not sacrificing anything when you turn one of them into a dedicated anti-undead weapon. But in Kerkerkruip, an average playthrough should yield maybe three or four weapons, each with their own distinctive advantaged and disadvantages, useful against different foes and in different circumstances. Deciding to turn one of them into a silver weapon, less useful in normal combat, should be a relatively tough decision. And tough decisions is what we are looking for.

Thus was born the unguentum argenti, which I hope is Latin for "salve of silver", which can turn iron weapons into silver weapons. For this to be tactically interesting, all of the following conditions must be met:
  • At any time, a player will have relatively few weapons, all of which might be useful in the future. (Or if a weapon will not be useful in the future, it will not be useful against the undead either.)
  • The player does not find silver weapons, but must actively sacrifice a normal weapon.
  • Turning a weapon into silver must be permanent and non-reversible, otherwise the decision becomes a no-brainer.
If at any time one of these conditions will cease to be true, I'll have to rethink the mechanic.

Towards generality

Thereis always the temptation to write code for the special case, rather than to write code for the general case, which might become useful later on. In Kerkerkruip I try to resist this temptation as often as possible, but in the case of silver weapons I succumbed to it. I just made a silver property which only weapons can have, and made a standard message for using the unguentum on anything that was not a weapon.

And then I though: but what if the player tries to apply the salve to an iron monster, of which I already have two in the game? Wouldn't it be lame if this did nothing? Wouldn't it be cool if by this (incredibly risky) action you could actually weaken those iron monsters? Asking the questions was answering them, so I started anew, and coded a more general materials system.

Now to think up some more good uses for it...

Monday, June 13, 2011

Kerkerkruip design journal #5: regeneration

Kerkerkruip is the new name of my roguelike IF. It is a literal Dutch translation of "dungeon crawl", except that "kruip" translates the verb "crawl" but not the noun "crawl". With all those k's, I think the word looks suitably evil and fantastic for my purposes, and it will be easy to find on Google. (Right now, searching for "kerkerkruip" gives only a handful of results, some of which are machine translations of the English dungeon crawl, and some of which are forum posts by me... I have been known to coin this word before.)

I have been quiet for some time, which may have suggested that I was busy with other things. That was indeed the case. But the past two weeks have seen a lot of development on Kerkerkruip again, bringing new monsters, new items, new 'systems', and in general bringing us a lot closer to an playable alpha. Most of the things I could post about would be just me being joyous about implementing new things -- there is a joy in the act of creation, and especially in the act of writing code which actually works when you play the game -- but I doubt my audience would enjoy such posts. On this blog, I want to take a step back and talk about design from a point of view that is a little more detached.


So today I'm going to write about a game system that I implemented yesterday, and which I am going to remove from the game as soon as I finish this post. Not because I tested it and it didn't work, but because I suddenly realised it cannot possibly be compatible with my design goals. Today's lesson, then, is to always keep your design goals in mind.

The system I'm going to remove is a simple regeneration system: depending on your regeneration rate (which is normally 0), you will regain health during every round of combat. With regeneration 1 you regain 1 health every round, and so on. Some monsters would have a regeneration (as the trolls in D&D had), and the player would be able to gain regeneration by using certain items or defeating certain monsters. Pretty simply and pretty standard. You can do fun things with it, though; I was already thinking about items which give you regeneration but lower your total health.

But what are some design goals of Kerkerkruip?
  • The optimal strategy should be a fun, fast and risky strategy, not a slow, safe and boring strategy. (Players should not be rewarded for doing boring things. None of that old D&D crap where the optimal strategy was to search for traps in every room and passage, and sleep after every encounter.)
  • Combat should be fast and exciting. No protracted, seemingly interminable battles.
  • Games should be quite short. (These goals are obviously closely related.)
These design goals are not well served by a regeneration system. For if the player regenerates, the optimal strategy is shifted towards dragging the combat out: in a longer combat, one regenerates more health, and thus increase one's advantage over the monster. On the other hand, if the monster regenerates, combat will become more tedious. It might start to resemble those ridiculous boss fights where the developers could think of no better way to increase the difficulty than by giving the boss 10.000 hit points. And if both regenerate, we might get into the situation where the average damage dealt each round is less than the average amount of health regenerated... which is the worst possible case, as it would make the fight literally interminable.

Given all these disadvantages, it is probably best to just kick out the system.


(I am experimenting with monsters that can heal other monsters, but that is a slightly different case. Suppose a group of monsters consists of -- using MMORPG terminology -- a tank, a fragile DPS, and a healer. If the healer is good enough to significantly slow your killing of the DPS, you should take out the healer first. Thus, the optimal strategy avoids dragging out the fight too much, and this strategy is always open to the player. By the way, "DPS" in the meaning of "a character with high DPS" is the worst noun ever.)


P.S.
It's not as if I'm throwing away a lot of work. This is the entire regeneration system:
A person has a number called the regeneration. The regeneration of a person is usually 0.

Every turn (this is the regeneration rule):
    if hate is present:
        if the regeneration of the main actor is greater than 0:
            heal the main actor for the regeneration of the main actor health.
But I was making a general point. :)

Monday, May 09, 2011

[Spring Thing 2011] Bonehead

Bonehead is actually the third Spring Thing game I have played, but I have put off writing about the other two because I may want to write something a bit bigger than a quick review on my blog. (No promises, of course) These two other games were The Promise, a game with a lot of good stuff and an ending I hated, and Mentula Macanus: Apocolocyntosis, which it would be hard to recommend too highly. (Though check out Jimmy Maher's blog for another opinion.)

So, Bonehead by Sean M. Shore. This game is about baseball, and specifically, about what is apparently an infamous game of baseball in which Fred Merkle either made a stupid blunder or, depending on your perspective, was the victim of what RPG players will call a rules lawyer. The structure of the piece is interesting: you are told in the beginning that this is going to be the worst day of Merkle's life, and you get non-interactive flash forwards to prove the point. It is possible to escape from your fate, but only through early endings, that is, to what feels to the player as losing endings; while the final ending, in which disaster strikes, is the one that is hardest to get to. It works, perhaps because the disaster is not something for Merkle to be truly ashamed of? Or is the relation between player success and character success even easier to sever that we have thought?

My enjoyment of this piece was mostly theoretical, because it was about baseball. I know nothing about baseball. Well, I know you have to hit a ball and then run from base to base to score a point, but that is where my knowledge ends. Now the game realises that not all its players will have the required background knowledge, and attempts to remedy this; but the attempts are not very successful. For instance, you can take batting practice. I assume this is meant to teach me how to bat, and thus prepare me for the real game. But what happens is this:
> swing early to opposite
You keep your hands back and execute an inside-out swing, slapping the pitch through the hole on the right side of the infield.
This means nothing to me. My first thought was that maybe I should warn someone that there is a hole in the field, before someone falls into it. More problematically, I have no idea whether "slapping a pitch through the hole on the right side of the infield" is a good thing or a bad thing; and thus, I have no idea whether "swinging early to opposite" was a good or a bad decision. A training session in which I cannot distinguish positive from negative feedback is not very effective.

Later in the game, it was clear that I was getting negative feedback:
Matty deals to Kling.  It’s a fadeaway – a Matty specialty – and it runs right in on Kling’s hands.  He makes a defensive swing, and taps a slow roller towards Art Devlin at third.  Kling dashes towards first base as Devlin barehands the ball.

> catch ball
The ball isn’t within reach.

Devlin starts to throw, but sees that you’re not covering the bag.  He pockets the ball rather than risk throwing it into right field somewhere.  The cranks are screaming bloody murder, all of it directed at you.
But I have no idea what I did wrong. I should have "covered the bag"? What bag? Why? How? Should I throw myself on top of it? Pull a cover around it? Write a piece of journalism about it? I was continually reduced to reading the hints and typing the commands it gave me. In the present case, doing this cleared up the situation (apparently, covering a bag means putting your foot on the base; and apparently, you have to do this before people are allowed or inclined to throw a ball at you), but all sense of choice or agency was effectively killed.

Most hilarious was the moment where I got the following command:
“Fred, Art: you two creep up a little bit when he squares around to bunt and be prepared to field the ball if it’s hit your way.”
Sure, man. Creep up. When he squares around to bunt. Then field the ball. No problem. Except -- what on earth are you talking about?

Here's the main point I want to make: I love the game for doing this. Sure, I cannot really play it, but who cares? A game about baseball should be about baseball. It shouldn't cater to the lowest common denominator of baseball knowledge. It should be passionate about baseball. It should exhibit all the lovingly researched historical and gameplay details that Bonehead exhibits. I want to see more games that dare to sacrifice accessibility to a broad audience in order to increase interest to a narrow audience.

Of course, I also hope that some of those games will include me among the narrow audience.

Thursday, April 28, 2011

SPAG #60; Lyttle Lytton 2011; nY #9

Three pieces of unrelated news concerning me and (in one case very tangentially) interactive fiction:
  1. The new SPAG is out, now with a beautiful cover, many interviews, an interesting design document for Hoist Sail for the Heliopause and Home, an overview of the PAX 2011 Demo Fair, and my analysis of Gigantomania. It is not too early to start writing a piece of criticism, an essay on design, or some other interesting article for the next issue! What about recapping and reflecting on an interesting discussion that has been held on the blogs or the forum? There are many possibilities. SPAG needs you!
  2. I sent in a sentence to Adam Cadre's 2011 Lyttle Lytton competition, where you have to write the worst possible short opening sentence for a novel. I'm pleased to say that Adam awarded me a shared second place for:
    This is the story of how one woman overcame breast cancer by never ever losing faith in herself.
    Coincidentally, just after I had sent in this sentence, big posters appeared in the Netherlands showing a baby and the text "Vrouwen creëren meer dan borstkanker ooit kan vernietigen", which translates to "Women create more than breast cancer can ever destroy". Which is terrible in so many ways that I don't even know where to begin.
  3. I published an article on interactive fiction as experimental literature in the Flemish (and Dutch-language) literary magazine nY, issue 9. I focus on two aspects: the many roles in a piece of IF, and how these can be used to explore, for instance, the theme of authority (think Fail-Safe and LASH); and choice, and how this can be used to explore moral issues, to represent reality in its potentiality as well as its actuality, and to represent consciousness without assuming that thinking occurs one thought at a time. I believe the piece will appear on the website at a certain point, but I'm not 100% sure; if it does, I will of course post an update.

Wednesday, April 06, 2011

[ATTACK] Inform ATTACK version 2 released

I'm happy to announce the release of Inform ATTACK version 2. Apart from adopting a new and saner version numbering system, this release adds a couple of small features, fixes several bugs, and fixes many typographical errors in the manual. Get it from the usual link.

Change log:
  • Fixed a bug whereby the going action was counted as acting fast, because it triggered the looking action.
  • The decide whether hate is present routine now calls a rulebook called the hate rules, in which there is one standard rule called the standard hate rule. This makes it possible for the author to customise when ATTACK thinks a combat is being fought.
  • ATTACK now stores its decision about whose turn it is in the main actor variable. Thus, if you want something to happen every turn when the player is the primary actor, you can now write an "Every turn if main actor is the player" rule. (You cannot use the actor variable for this, because Inform will always reset this to the player by the time you reach the Every turn rulebook, even if an NPC has been acting.)
  • The handle the combat round routine now considers a new rulebook called the starting the combat round rules after the main actor has been set, but before a prompt has been printed or an AI rulebook has been run. This allows the author to intervene at an otherwise inaccessible point.
  • Fixed several typo's in the manual and the Test Dungeon game.
  • Fixed a bug with the artifical intelligence of the troll in the Test Dungeon game.

Sunday, March 27, 2011

Dungeon design journal #4: making a monster

Introduction

If you are using Inform ATTACK, how much code does it take to create a monster? Six words.
The boar is a hostile person.
I have spent a considerable time coding up three monsters for my dungeon crawling game. The third one took me about 1600 words, which is a little more than 6. Where does the discrepancy come from?

One of the main design goals of almost any tactical combat game should be to make the enemies as diverse as possible. This is not necessarily easy. Desktop Dungeons, which features only a handful of monsters, has only few good ones. Mostly it is just the "raise one stat, lower another" approach: a monster with a lot of health but little damage, a monster with little health but a lot of damage, a monster with high magic resistance but low health. Dungeon Crawl Stone Soup has many awesome monsters, like hydras and ugly things, but also (certainly on the earlier levels) a lot of monsters that feel more or less identical. And I for one wasn't impressed by the diversity to be found in Dragon Age: Origins.

There is of course such a thing as cosmetic diversity: different sprites or models or descriptions, even if they have no effect on the gameplay, can enhance the game. This is not unimportant. But we want more. We want monsters that force the player to rethink their tactics and their strategy. This means that the monster must interact in an interesting way with one or more tactically important aspects of the game: the items, the skills, the spells, the terrain, the basic combat actions, or whatever else you have. So thinking up a good monster generally starts with thinking about your tactical system.

Let us observe something about the basic ATTACK system of attacking, dodging, parrying and concentrating. In general, dodging and parrying are pretty much no-brainers: if you are attacked, you do whichever of them seems to be the most useful against the current attack. (Parrying a bullet is not going to work.) You could concentrate instead, if you are feeling very brave, but the AI is good enough at deciding when attacking is useful that this is rarely a good idea.

No, the basic tactical decision in ATTACK is that between attacking and concentrating. It might seem that this is a decision between investing in a better future attack (concentrate) or doing some damage now (attack). In general, however, that is not really what you are worrying about. What you are worrying about is your opponent's concentration level, your ability to destroy his investment and his ability to destroy yours: when you deal damage to someone, that person loses his concentration. So suppose your concentration level is 1, and your opponent has just raised his level to 2. If you attack, you might very well miss. If you miss, he can raise his level to the maximum of 3, and you, with no concentration left, will have a hard time disrupting him -- which means that he can unleash a very deadly attack. If instead of attacking him now you concentrate to 2, and he concentrates to 3, you'll have a much better chance to hit him and disrupt his concentration before he can attack you. So concentrating might seem like a good idea.

On the other hand, what if you raise your concentration to 2 and he does not raise his concentration to 3, but attacks you instead? If he hits you, you will lose two turns' worth of investment. That is very bad. So maybe it would after all be preferable to hit him right now and try to disrupt that concentration before it gets any higher. If you hit, you might very well win initiative, and then you'll be the one ahead in the concentration race.

Now there might well be an optimal strategy for ATTACK, but the math is complicated and highly dependent on little changes in the stats and the health the combatants have left. So it does feel like a tactical gambling / bluffing game more than like a math problem to be solved.

Why bring this up? Because an understanding of the basic tactical decisions allows us to think of ways to turn these decisions on their heads, so to speak. In the basic system, a person is most vulnerable when he is maximally concentrated: concentration gives no defence bonus, and if you get hit you lose a big investment. So, for a radically different tactical situation, what about a monster that is least vulnerable when it is maximally concentrated?


Enter the chain golem

The chain golem is a lumbering mass of metal chains that attacks by lashing out at its opponents with some of those chains. When it concentrates, it starts spinning around, whirling its chains through the room. As it concentrates more, it starts spinning faster and faster -- and obviously becomes very unsafe to approach.

In game terms, what happens is this: anyone who tries to attack a concentrated chain golem must first avoid the spinning chains. This becomes more difficult as the spinning increases. Failure leads to a painful collision with the chains, damage, and loss of concentration. So the most likely thing that will happen when you attack a concentration 3 chain golem is this:
The chain golem spins even faster, audibly slashing the air with its whip-like metal appendages.

Act> attack golem
The chain golem lashes out with a heavy iron chain, trying to stop the attack.

You attempt to duck under the whirling chains. You roll 5 + 5 (dexterity score) = 10 against a target number of 12, failing the dexterity check. One of the chains catches you with a loud smack, dealing 6 damage and breaking your concentration.

Rolling 2 - 2 (defender parrying) + 4 (tension) = 4, you do not overcome the chain golem's defence rating of 8.

Several of the wildly spinning chains lash out at you.

React>
Which is not an enviable position to be in. Indeed, you will have to rethink the way you approach this particular creature. Stopping it before it can get up to full speed is essential. If it does get up to full speed, it might be smarter to let it attack you then to try to break its concentration. Best of all would be to get an ability that allows you to damage someone (and thus break that person's concentration) without actually attacking that person -- and one of the other monsters I have made does grant you such an ability, although it is never guaranteed to work. So killing that (level 1) monster before attacking the (level 2) chain golem could be a good idea. Only, you'll lose any level 1 ability when you kill a level 2 monster and gain the corresponding level 2 ability, but not the other way around... so perhaps you might want to wait with killing that level 1 monsters. Decisions, decisions.

Overall, the tactics needed to defeat the chain golem are probably less interesting than those needed to defeat a basic monster: that is, it would be more fun to play in a world with only standard ATTACK monsters than to play in a world with only chain golems. But of course, that is not the point: the point is tactical diversity. And I think the chain golem certainly provides that.


Making things interesting

That is all very well, but we want our monsters to be even more interesting, and combat even more intense. So I have given the chain golem a special ability: once in a while, it will attempt to wrap one of its chains around your weapon, yank it out of your hand and send it flying across the room. While not necessarily leading to new tactics -- unless you have another good weapon, you should probably try to retrieve it -- it does spice things up a bit, and increases the unpredictability of the combat. Furthermore, it allows us to have the chain golem interact with its environment in interesting ways: at some later point in time, I intend to write a "when something is randomly thrown through a room" rulebook that could be invoked by the chain golem's disarm ability as well as other events in the dungeon; and that will allow the current location to intervene and have an effect on what happens. If the chain golem protects the narrow bridge over the lake of lava, you might want to consider fighting it without using your favourite weapon!

Another good future addition would be a probability for the randomly thrown weapon to hit and damage a third person in the location. Even if it only came up once in every several hundred games, the chain golem accidentally killing its own ally would be great.

In order to have such 'emergent' events, you need to write relatively general rulebooks that can be called by different events. If the chain golem is the only thing that can send an object flying, writing an entire rulebook for this eventuality is probably not worth it. But if it can happen more often -- well, then it obviously is. (The player throwing objects at an enemy? Certainly a possible action to be considered.)


Rewarding the player

Once the player has defeated a monster, he absorbs its soul. This gives a general stats increase, but also grants the player a passive or active power. In the case of the power of the chains, the player gets the ability to "lash". This is to attack the enemy as a reaction: i.e., to attempt to disrupt the enemy's attack by counterattacking, something that is usually not possible in ATTACK, and which everyone will love to be able to do.

Writing all of that, with the required prose, takes about 1600 words. Not too bad, actually, since I'm thankfully experiencing that everything I try to do fits into ATTACK very neatly (perhaps because I think like myself, but let's assume for my sake that it is because ATTACK is well-designed). The entire carry out rules for lashing are:
Carry out lashing:
    choose a blank row in the Table of Stored Combat actions;
    now the Combat Speed entry is a random number between 8 and 14;
    now the Combat Action entry is the action of the actor attacking the provoker of the actor;
    say "You will attempt to strike swiftly, before you are hit.".
In basic ATTACK that Table of Stored Combat actions only ever contains one action, and the fact that actions have a combat speed never makes a difference. But I put it in in case people wanted to write something like the lash action (or even more complicated things, involving more people and/or actions). Thank you, former me!

(In case you wonder: actions with a lower combat speed get carried out earlier; attacking has a standard speed of 10; so lashing has a 2.5 / 7 = 36% chance of happening before the attack.)


Additional things

Three monsters, two rooms, a couple of items: its not exactly going quickly, but we're getting there. I might put out an early alpha release when I have seven monsters and enough rooms to put them in, for those who are curious.

There was some talk in the previous thread about whether I should just disable saving or include my Permadeath extension. I'm certainly willing to do the latter if people prefer that. (Erik, I don't think your idea of autosave and autorestore will work, because you cannot force someone to overwrite their old save when they die, and I don't think the game can save without help from the user? Permadeath solves the problem in a somewhat more complicated manner.)

I'm finding that writing this game, and thinking about it, is both pretty exhausting and pretty fun.

Thursday, March 24, 2011

Dungeon design journal #3: design philosophy

With the basic system in place, the times has now come to think about content. In fact, I have already coded up two rooms -- one of which is the Entrance Hall, which doesn't do an awful lot. But before I dive into content creation, I should spell out my design philosophy, both to make it explicit for myself, and to get some early feedback.


Thematic background

The thematic background of the game will be sword & sorcery: gritty and violent fantasy that takes place in crumbling civilizations built on the ruins of even older empires. It is a world where wizard don't throw around fireballs and other flashy weapons of mass destructions, but cast curses that trap the soul or rot the body -- curses they have learned in a search for forbidden knowledge that left them more demon than human. It is a world where horrific monsters threaten mankind everywhere, but where no elves, dwarfs, orcs, trolls, faeries, or any of the other "races" of Fantasyland have ever been seen. It is a world where priests are not holy men who turn undead, but cruel butchers who sacrifice men to appease evil ancient gods. It is a world full of the wildest decadence and the deepest despair. It is, most of all and appropriately for a rogue-like game, a world where life is very cheap indeed.

High fantasy and character death have always been an uneasy union. If you are in the business of "wish fulfillment", as the Dragon Age developer on the PAX panel described his own job, you need a world where the player feels heroic, in control, and epically successful. If you're making a rogue-like, you do not.

Sword & sorcery is not an overused genre in computer games. There is a Conan MMORPG (which I have not played, and in fact, I have read almost no Howard), but as far as I can see that is about it. On the other hand, it does allow almost as wide a variety of locations, events and creatures as the degenerate "high" or "epic" fantasy that is overused in computer games.

In the end, given that I'm writing a random dungeon crawl, none of this is too important -- but I like having a vague thematic idea to work with.


Design philosophy

Core design goals. The core design goals of the game are tension, tactical depth, variation, and absence of grinding. The player should be on the edge of his seat all the time, because danger lurks everywhere; success must be a matter of making the right decisions; randomisation should be used to generate a large variety of tactical situations; and increased survival chance should never be a matter of taking more time.
Note that "grinding" is not just a term for things like killing thousands of identical zero-threat monsters, or doing a hundred Mephisto-runs in a game without permanent death in order to get that piece of armour you need. It also encompasses things like the "we rest until healed" and "I search for traps" mechanics of D&D, where slowing down the game session to do a risk-free activity is always the tactically optimal option.
Length. As stated in a previous post, I am envisaging a game that takes place in a small dungeon (say 10-15 rooms) and takes only a short time (say 10-30 minutes). This means that there can be more danger (every monster in Crawl or NetHack cannot be dangerous because of the length of the games), and it removes a lot of opportunities for grinding. However, an external file will be used to track how many games have been won, and new features for the dungeon will be unlocked as the player wins more games.

Fairness. Fairness is not a core design goal for this game. This is a game meant to be played in fifteen minutes. If a lightning elemental was randomly generated in the Tesla coil room (not an actual example from my game!) and no electricity resistance can be found -- tough luck, but you lose only a few minutes worth of play and can simply start again.

What I do want to minimise is "unfairness" that is "unfun": a game that kills you arbitrarily or leaves you optionless in the beginning. Even perfect play may lead to death, but reasonable play should never leave the player without a chance.

Hostile environment. I want the whole dungeon to feel hostile and dangerous. Not just the monsters, everything, including empty rooms and treasures. Partly through description, partly by actually making everything potentially dangerous. Also, we will not hold the player's hand. If she types "jump in lava" or "eat poison", the game will oblige her. None of the "That wouldn't be very smart." stuff.

Trade-offs will play a major role in the game. The basic combat actions already offer the player a tactical trade-off (you can concentrate to do more damage later... but you might be hit in the meantime). Using finite resources ("scrolls" and "potions" in many rogue-likes and RPGs) is always trade-off between greater chance of survival now versus greater chance of survival later. And I'd like permanent items to adhere to this philosophy as well: no "sword that is better than your current sword", but a "sword that is mostly better than your current sword, except". An important kind of trade-off is the temptation: offering the player a prize that can only be obtained by braving an optional danger. Rogue-likes often work this way. "I can run away from that ogre, but if I kill it instead, I would get enough XP to level up...". Many deaths are a result of giving in to temptation -- but many victories are as well. It is also thematically appropriate: the temptation of great riches is often a prime motivation of sword & sorcery characters, and it often leads to their untimely demise.

Surprise. I would like the game to contain a lot of surprising features that will keep even experienced players interested.


That is the theory. Now for the implementation. Comments are very welcome.

Tuesday, March 22, 2011

Dungeon design journal #2: further dungeon generation

After getting the basics of randomly generating the dungeon map in place, I spent some time cleaning up the code. This is a necessary step in any larger project: whatever you have written after several hours of obsessed coding may work, but it is almost certainly not pretty. Cleaning up the code can be as easy an rearranging it and adding headings, but more commonly also involves separation (any part of a routine that might come in useful elsewhere should be written as a stand-alone routine) and rewriting (of code that is either ugly or not as general as it could be).

One thing I tried to do this time is reducing the number of global variables I used -- using local variables for local properties is neater and less prone to strange bugs later. However, I don't think you can send local variables to rulebooks. You cannot, for instance, write "consider the monster scoring rules for (guy - a monster) at (place - a location)" and then use "guy" and "place" as local variables within all the monster scoring rules, like you can do for a routine. So you have to use global variables to send information to a rulebook -- right?

I also implemented a check on the generated map to see whether it is not too narrow in the beginning: we don't want the player to be stuck on a linear path at the start of the game which might be blocked by an obstacle he or she cannot overcome. I'm certainly not striving for total fairness, but some fairness is good; and we want the player to be able to make decisions.

My basic design idea at the moment is that there are five levels of monsters, levels 1 to 5. Every dungeon contains two monsters of levels 1 and 2, and one monster of each of the other levels. Killing the level 5 monster ends the game. (Obviously, the exact numbers can all be changed during play testing.)

When you kill a monster, your character absorbs its soul, which will heal you and grant you a set of powers specific to that monster. These powers will in general include simple statistics increases, but also more specific and fun abilities or resistances, and they will be more powerful when the level of the monster is higher. However, absorbing a level n soul will immediately destroy all level n and lower powers you already have. So if you have a level 2 power and kill a level 3 monster, you lose the level 2 power; but if you then kill another level 2 monster, you will gain its power without losing the level 3 power.

This should be tactically interesting because it generates a basic risk-reward problem: killing a higher level monster is easier when you have already absorbed the souls of lower level monsters; but you can only keep the souls of the lower level monsters for the next fight if you first kill the higher level monster. E.g., before taking on the final monster, you would ideally kill a level 4, 3, 2 and 1 monster in that order. But killing the level 4 monster without the help of having absorbed a level 3 soul is going to be quite difficult. Add to this the fact that different souls will help you more or less against specific monsters, and the player might face some hard tactical decisions even when he is just trying to decide in what order to defeat his enemies.

Of course, we'll need to see how it works out in practice.


By the way, I tried to think of a way to generate a name from this basic mechanic. Soulstealer and Souldrinker sounded too much like bad Michael Moorcock fan-fic, so I have gone a slightly more mystical route: the current working title is The Breaking of the Vessels.

Now a vague theme of mysticism gives me some basis for creating a set of locations, mechanics, monsters, and so forth, with a coherent feel; but I'm not sure it's going to be the easiest or most successful route. If anyone has a better idea, I'd love to hear about it. At all costs do I want to avoid the "throw in every fantasy trope you can think of"-feel that can be found in so many rogue-likes: I want something more coherent. Also, preferably not too clichéd. I'm very open to suggestions -- my head has been so preoccupied with the mechanical side of things that the fictional side has not yet received a lot of thought.


Getting back to the actual work, I implemented a system to distribute monsters across the map. Basically what I'm doing is that I sort the rooms by their distance from the Entrance Hall, and then put the strongest monsters farthest away. This ensures that all rooms are reachable (nothing can be beyond the final monster), and that the player can always get to the weaker monsters before he has to defeat the stronger ones -- although it is very possible that he could take on the stronger ones early on, because the maps resulting from my generation algorithm have a lot of branches.

There are, of course, also easy ways to specify that certain rooms cannot contain monsters; or that certain monsters are more likely to be found in certain rooms.

Finally, I put in a basic framework for "treasure" generation, but I think that's something I'd like to mostly leave to more specific code. I then wrapped everything into an extension and added ATTACK to my source code.

So at this point I have a game in which you get to walk through a random dungeon and fight the stock ATTACK monster under different names. Not quite awesome, from a gameplay perspective, but a good basis for further development.