Posts Tagged Computer

Game Review: Achron

Achron

Developer:  Hazardous Software

Rating:  4/5

Bottom Line:  Achron is a groundbreaking RTS with unique and interesting gameplay mechanics and an extensive campaign, but the lack of modern RTS conveniences hampers the experience to a significant degree.  I can highly recommend this as an experiment, and as an experience, but not as a finished, polished game worth the price.

Introduction and Conceptual Overview

Back in the mid ’90s, a friend of mine and I had a number of conversations about game design.  A lot of ideas got thrown around, but I had two that I thought were particularly good.  The first was for an RTS-style game where you recruited troops, but didn’t actually directly control them.  They would roam around, controlled by their own AI tropisms, and find things to accomplish, gaining skill all the while.

Something very similar to what I had envisioned was produced a couple of years later:  Majesty.

My second idea was for an RTS that involved time travel.  The player would be able to call reinforcements to them from further up the timeline.  This would provide a quick burst of fresh troops, but a matching amount of troops would have to be built and positioned properly in the future in order to jump back.  Failure to do so would cause “paradox storms”, which would inflict increasing amounts of damage to the player based on the magnitude of the temporal imbalance.  I particularly liked this idea because (I thought) it would provide interesting counters to rush strategies — you could focus on economy, block an initial rush with up-time reinforcements, and end up with a substantial production edge over a more militaristic player.

Although it doesn’t map exactly onto my simplistic original idea, an RTS game based around time travel mechanics has just been released:  Achron.  And it’s a fascinating, if flawed, game.

In Achron, you, as the leader of your forces, sit outside the timestream.  Through the “timeline” user interface feature (easily the best-designed portion of the UI) you have access to time periods from about 4 minutes prior to the game’s “present” to 1 minute in the future.  It’s very much like a minimap, but for time rather than space.  At any given time you can click at a point on the timeline and the game will instantly snap to what was happening at that time.  But that’s certainly not all.  You can also issue commands to units in the past or future, at the cost of “chronoenergy”, a resource that is achronal (that is, uncoupled to in-game causality) and which regenerates at a fixed rate in real time.

The upshot is that you can not only observe the past, you can change it.  If you fight a battle and lose, you could jump to a period of time before the battle began and redeploy your forces, or even disengage and move elsewhere.  In multiplayer games, there could be up to 3 other players also manipulating the timestream in this way, so you can see that it could get very complicated very quickly.  If I jump back a minute and tell my forces to take the left fork rather than the right fork, you might jump back a minute and a half and redeploy your forces to again cut me off.  As long as the chronoenergy holds out, there’s no hard limits to what can be done.

The game handles the results of this time manipulation through an ingenious, if imperfect, mechanism:  time waves.  The game cannot instantly propagate changes you make throughout the entire timeframe of the game in real time; that would be computationally prohibitive.  Instead the game uses periodic “waves” of causality that propagate up through the timestream at a fixed rate (about 3 times the normal rate that time passes).  As a time wave advances up the timeline, the game modifies history according to any changes that have been put in play.

This leads to interesting effects when a time wave catches up to whenever you happen to be observing on the timeline — if someone has made a change to the past, your units may move, shift position, or disappear as a result of the changes.  It can be very disconcerting to have the rug yanked out from under you and your forces defeated somewhere in the past.

The limit to all this temporal manipulation is the fact that the farther back in time you go, the more chronoenergy you use to issue commands.  At some point in the past, the energy required to issue a command is greater than the maximum chronoenergy you can accumulate.  That point is the threshold of the “unplayable past”.  Points previous to this may be visible, but can’t be further changed.

But the time travel mechanic isn’t limited to issuing orders in the past and future.  It’s also possible (with the correct technology) to “chronoport” units through time.  Send a squad of tanks three minutes into the past, and you now have additional forces earlier in the game’s timeline.

Time travel inevitably leads to time travel paradoxes, and the game’s time wave mechanic provides a means, albeit imperfect, to resolve them.  The “grandfather paradox”, where a unit travels back in time to before it was created and kills the building that produced it, is pretty trivial to set up in Achron.  The way this plays out in the game is that successive time waves alternate between states of the paradox.  On one pass, the building will be present with no unit.  On the next, the unit will be present with no building.  Whichever state obtains when the event falls off the “past end” of the timeline is locked in as the permanent state.  As you can no doubt imagine, all sorts of weird abuses are possible with these temporal tools.

It’s worth pausing here a moment to, well, bask in the glow of the amazing time travel mechanics Achron implements.  Mostly because when I get into the details of how the game is constructed, that glow will fade quickly.  So let’s take a moment to acknowledge the genius design and tremendous work behind Achron‘s temporal mechanics….

Ready?  OK, on with the review.

Single-Player

The single-player campaign is extensive, consisting of four parts:  one for each race and one final campaign (that I haven’t gotten to yet).  Most of the early levels are devoted to teaching you basic RTS skills, followed by the temporal mechanics.  There is a fairly detailed, serviceable backstory, involving a coordinated alien assault against human colonies.  You are alternately playing either one of the human commanders or his suspiciously-powerful AI, while political infighting, treachery, alien slavery, and the sordid history of the human military’s relationship with AI entities provides the dramatic motivation.

The missions move pretty slowly if you’re used to a standard RTS like Starcraft 2.  In addition, the missions are a bit different than RTS standard.  For one thing, they’re a lot more finicky; you must almost always keep certain units alive, which can be quite difficult at times.  This isn’t as bad as it could be, however, as if they die you can simply jump back in time and change history to ensure they survive.  If you fail repeatedly, however, the escalating cost in chronoenergy can make it more and more difficult to retry as you are forced farther back on the timeline, and losing due to an event receding into the unplayable past after multiple failures can be incredibly frustrating.

Multiplayer and Skirmish

I’ve played very little in the way of multiplayer — a couple of skirmish games.  But I’ve seen enough to show me that multiplayer Achron is a different beast than the single-player campaign.  First of all, you’re always playing against an opponent who can counter your temporal maneuvering, which is very fun.  Several times I started firing on an enemy unit only to watch a time wave go by and the enemy unit disappear, presumably rerouted at an earlier point.  Several interesting strategies are possible in Achron that are not possible in other RTS games, such as a “race-switch”:  since your faction choice is selected in-game, it’s possible to jump back in time and select a different starting race, potentially throwing off early scouting by your opponent.

There are three races in Achron, roughly analogous to the three races of Starcraft.  The humans have the best firepower, the Vecgir have integrated teleportation in their vehicles, and the Grekim have an inherent chronoportation ability (albeit one that costs so much that it’s not as useful as it sounds at first).  Their tech trees are somewhat different, but the units each faction has, when boiled down to essentials, are very similar.

Unfortunately, the victory conditions can be somewhat of a trial.  I don’t know if it’s the only way to win in a multiplayer game, but in my skirmishes you had to completely eliminate the enemy forces and production facilities at the earliest point on the timeline.  When playing the computer, this meant that I had to kill everything I could find, and then sit around for five minutes while the timeline scrolled those deaths off into the past.  I started messing around with chronoportation to kill time, until finally receiving the “game won!” notification.  A human opponent would likely concede, but a griefer could tie you up for quite a bit longer in Achron than in something like Starcraft 2.

The AI itself doesn’t seem too strong, even for someone of my modest skills, but I’m not sure I’m playing at it’s highest level.

Production Values

This is where Achron‘s conceptual brilliance most obviously yields to muddled execution.  Sound in the game is generally good — the effects are fine, the voice acting for some characters is a bit over-the-top but not annoyingly so, and the music is quite nice.  Unfortunately, the same cannot be said for the graphics.  Units are rather generic and hard to tell apart, animation is sparse at best leading to a poor sense of responsiveness from the controls, and the cutscenes, although they do their job in terms of communicating the setting and backstory, look really crude, even for an indie game.  Maps are bland and drab, and do nothing in terms of establishing a sense of place.  A complete reskin would be a great fan project, and would do wonders to improve the game.

This is, of course, an indie game, but one with a split personality.  Achron costs $30, well above the standard amount for an indie title.  Even though you get two game keys for this price, it’s still steep for an indie impulse purchase.  On the other hand, it’s got a lot of content and obviously aspires to cover all the bases of a full-fledged, major-release RTS.  By indie standards the production values are acceptable, but the price is high.  By the standards of major releases, the price is great but the production values are really weak.  Trying to straddle this line has resulted in a game that doesn’t really fit in either world, unfortunately.

One overall mitigating factor I should mention is that the game is designed with moddability in mind.  Undoubtedly, over time, mods will be released to tune up the maps and models and give Achron the graphical polish it deserves.

Mechanics

Compared to a AAA+ title like Starcraft 2, it would be unrealistic to expect that Achron would be able to compete on fluidity of mechanics.  But even given a lower level of expectation, there are a number of mechanical and interface features that Achron implements really badly.

Pathfinding and unit movement is deficient on a number of levels.  Although I believe the pathfinding algorithm is close to where it needs to be, there are still some spectacular failures from time to time.  Exacerbating the problem is the fact that units won’t shift to let allies through their position, which causes huge pile-ups that have to be resolved manually — potentially at a high cost in chronoenergy (hint: play Vecgir.  Built-in teleportation means you can avoid most of these problems).  Most maps don’t have very many obstacles, and teleportation is used by two of the three races as a key movement mechanic.  Both of these factors help, but wrestling individual units to get them to walk across the map is the antithesis of fun.

The other major mechanical problem is in the implementation of group command and organization in different time periods.  The game assumes that when you issue an order to a unit in the past, that you mean to add that order to the unit’s existing queue, leaving later orders intact.  In a few cases this might be correct — if you jump back and tell your unit to cloak, for instance, you may still want it to move, fight, etc. like you will order it to later in the timeline.  But in a large — very large — subset of cases, you want to completely override previous orders (such as when you decide that attack-moving into your enemy’s base wasn’t such a good idea after all).  In such cases, you either have to issue a “cancel orders” command before issuing the new command, or watch your units follow your new order for a while only to reverse and start heading back the other way when the timeline catches up to the original order.

Achron‘s system is flexible, yes.  It covers all situations, but it’s clunky and adds annoying micromanagement to what should be the most fun part of the game.  Similarly, chronoportation has a number of limitations that make it hard to use properly.  Normally giving a command to a group leader will cause subordinate units to follow along.  This is not true with chronoportation, however.  To chronoport, each unit must be explicitly given the order to chronoport.  This is generally not a problem, unless you forget and just order your group leader to time travel, in which case you’ll watch him head off solo, leaving his bewildered subordinates behind.  Once you fire off a chronoport (regardless of the number of units involved), the ‘porter has to recharge, which means you either need to wait to send the rest of the units, or back up time, clear the original order, select all the units, and re-chronoport (if you have enough chronoenergy to pull off the retroactive command).  Again, it kludges up the fun part of the game.  I’m sure the reason for doing this was to close off some weird paradoxical exploit, but it’s still frustrating.

Other, more standard mechanics are implemented well.  There’s unit production queuing, order queuing, a form of hierarchical grouping (actually pretty sophisticated), hotkey control groups, and pretty much all the basic RTS interface conveniences are in place and function as expected.

Gameplay

Balance seems fairly straightforward, since the three factions are very similar in terms of the capability of their units, and I didn’t notice one side feeling particularly overpowered compared to another (although Vecgir teleportation, as mentioned earlier, is very handy).  Generally technology research costs way more than production facilities or units.  Unfortunately, I don’t have enough of a feel at present as to whether rush tactics are viable or if the game requires a more economic opening strategy.  It did seem difficult to build up a quick rush, but that might just be my ignorance of proper strategy.

The real gameplay sophistication comes from time manipulation, of course.  The Achron wiki reads like a cross between a quantum mechanics textbook and a medieval grimoire, with page after page of detailed analysis on the intricacies of various time travel strategies, including one ritual designed to permanently clone units that’s effectively a NOT logic gate capable of sending information to the past.

In general units tend to move pretty slowly on the map, although you can always put the game into fast-forward to make the units move more quickly.  If you get ambushed when speeding through things, you can always jump backwards and take care of the problem.  And really, for a game where you control time, it does seem like you spend a lot of time just waiting for time waves to propagate and the resultant stuff to happen.  Again, this could just be my low skill level….

Conclusion

Although there are a lot of aspects of the game that fall short of perfection, Achron is absolutely unique in what it does.  No other game has tried anything as ambitious as a 4-way real time strategy game where any and all of the players can make changes at any point in the game’s timestream.  When you think about it, it’s just amazing that Dr. Hazard (the perfect name for a mad-scientist game developer) and his team managed to pull this off as well as they did.

With the benefit of hindsight, I wish they’d have scaled back the game, focusing on a more limited set of RTS features, and doubled down on the time travel.  Achron‘s hook is time travel — they would have been better served to go all in.  With a game that was more of an intriguing temporal puzzler, focused on using a few units rather than building bases, the concept could have more fully explored the ramifications of time travel, and not gotten bogged down in all the details of implementing a full RTS.

All that said, however, I really recommend you check out Achron.  Hazardous Software deserves kudos and support for making such an amazingly groundbreaking game, and even if Achron is not the absolute best RTS ever produced, it’s still well worth checking out to see what it’s all about.

Tags: , ,

Review: Treasures of a Slaver’s Kingdom

Treasures of a Slaver’s Kingdom

Author:  S. John Ross

Rating:  5/5

Warning:  Mild spoilers.

I can see why this game is polarizing.  It’s got loads of randomized combat, which is a turn-off for some players.  It’s a pastiche of old-old-school imbalanced pen-and-paper RPGs, which may be confusing if you’ve never been a role-player.  It restricts available verbs to about a half-dozen, and the plot starts off as barely remixed Conan the Barbarian.

But under the covers, this is a fantastic game.  It’s tightly-implemented, bug-free as far as I could see, and takes full advantage of Inform technology to make the playing experience smooth and clean.  The writing, although it apes the breathless earnestness of early RPG modules, is chock full of hilarious descriptions.  Clever responses to unusual commands are liberally sprinkled throughout (try to PARLEY with your DUFFEL BAG, for instance).

This is definitely a game that benefits from sitting down and reading the documentation first.  And there’s plenty of it.  The distribution comes with a manual that details the alternate history the game ostensibly comes from, followed by the entire sourcebook for the fictitious Encounter Critical RPG that ToaSK is based upon, followed by encrypted clues.  Although you don’t have to read the documentation, the Encounter Critical RPG setting is the central structure for everything in the game, and understanding it will make some puzzles far more clear.  Also, for me, reading the documentation made the game far funnier as I was able to quickly pick out the references.

From a design perspective ToaSK is very interesting.  The decision to greatly limit the verbs obviously limits the potential actions the player can take, but doing that also helps the player get interesting responses more easily.  If there are only a few things you can do to a given object, it’s far easier to code meaningful text for all of them.  The result is a game that feels more fully implemented, even though it doesn’t have full physical modeling.  But who needs Inform’s physical modeling when you have “scientific realism”?

The other consequence of the restricted verb set is that it makes the player seem smarter.  It’s easier to figure out what items do when there are fewer interactions, and even brute-force repetition can work to reveal hidden puzzle solutions.  This type of design approach wouldn’t work for every game, but it certainly works here, and works well.

To counteract this, the parser breaks the fourth wall constantly and deliberately, and slings gratuitious insults for the slightest deviation in command input.  Fauxld English is used throughout (methinks this be, mayhaps, where Tiberius Thingamus got his inspiration).

There is, of course, no detailed conversation model.  And anyway, you’re a barbarian — sophisticated conversation would be wasted on you.  Your interactions with characters are limited to the same verb set as inanimate objects, but this still allows a surprising number of things you can do (try ENTERing characters, for example…).  And the choice to limit character interaction allows ToaSK to include many different interesting characters, from Gina the willing virgin sacrifice to the Viraxian Dark Gods, to the runecarved, peg-legged dwarf Gunwar.  And, of course, there’s Vessa, the Delicate Doxy, to whom you will be returning many times.

The game is fairly well paced via its combat leveling mechanic.  You’ll need to explore and solve puzzles to gain health points.  Gaining health points will enable you to fight more powerful enemies, which will get you more gear and items with which to solve more puzzles.  Most combats are potentially fatal, but multi-level UNDO works wonders to get you out of fights where you’re in over your head.

Overall impressions?  The world of Encounter Critical feels like a tall, cold Kitchen Sink made with bathtub gin.  Think of a handwritten mixture of Gamma World (the original edition, of course), Eldritch Wizardry, and Traveller, with some Star Trek, The Lord of the Rings, Star Wars, Dune, Sinbad the Sailor, Conan the Barbarian, and a Godzilla movie or two thrown in for flavor.  Add snark and sex, then overheat the writing to taste.

Until Christmas Eve, the full version of this game cost $6.95.  It’s well worth it at that price (and I paid it on December 23 after discovering it that day), but it’s since been released for free.  If you’ve only played the intro version, you haven’t seen anything.  Don’t miss the opportunity to play the full game, and experience one of the unsung masterpieces of modern retro IF.  Or is that retro modern?  Anyway, you should definitely, definitely play it.

Tags: , ,

Aotearoa Postmortem — Part 1: Convenience Features

The IFComp is over, the Rule 5 Cone of Silence is lifted, and we authors can now talk freely about our games.  Congratulations to all the authors — I thought this year was just great, with a large number of very good games.  I played them all and enjoyed almost all of them thoroughly!  It’s really gratifying to be a part of this generous-spirited community dedicated to producing high-quality interactive fiction and releasing it freely to the world.

I wrote Aotearoa, and I thought I would share some of the things I learned during development.  I’m going to write up this postmortem in several parts, to keep them focused on specific issues and to reduce the wall-of-text effect.  In this segment, I’m going to talk about the numerous convenience features included in Aotearoa, and try to decide whether or not they were worth including.

Overview and Philosophy

The main development theme I had in mind for this project was ease-of-use.  Aotearoa started out its conceptual life as a one-off game for my son, and even when I expanded the scope into something that I thought had the potential to make a good Comp-length game, I wanted to keep the focus on kids, newbies, and overall interface friendliness.

Luckily, I was able to stand on the shoulders of some giants:  Aaron Reed, of course, provided the Keyword Interface extension, but I also used his Remembering, Numbered Disambiguation Choices, and Smarter Parser extensions.  I used both Exit Lister and the Conversation Package family of extensions authored by Eric Eve, both modified somewhat.  And for the interactive tutorial I rewrote Emily Short’s Tutorial Mode extension.

As you might imagine, integrating all these extensions (and a couple other ones) into a harmonious whole was not completely straightforward.  There was substantial technical integration work required to get something usable, work that I tried to finish up front but that I ended up tweaking up until the very last release.

Once I had the initial concept and a basic design for the game, I decided on the technical features I wanted and started to build infrastructure.  I built a tech demo prototype game that consisted of the first couple of scenes (the boat and the ocean) just to assure myself that what I wanted to do could actually be done.  This prototype had all the convenience features except the final version of the tutorial mode, at least in a basic form.

There were, of course, some bugs in the prototype, but I was confident enough at that point to drive forward with development, and with that foundation having been laid, the work I had to do later was really more in the way of minor bug fixes than hardcore development.

So, down to the details:  how did these features stack up?  I’m going off of things people said in their reviews, along with my knowledge of how each feature contributed to the development hassle.  I’ll try to synthesize both and come up with a cost-benefit conclusion for each.

Keyword Interface

Ah, Keyword Interface!  Source of 1000 integration issues!  I think it’s fair to distinguish, as C. E. J. Pacian and I discussed in the authors’ forums, between games where the keyword interface is the primary mechanism used to play the game, such as in his Walker and Silhouette, and games like Blue Lacuna and Aotearoa, which use keywords to improve the accessibility and friendliness of the game but which otherwise act like standard IF.

The key component of that distinction is that full-keyword games don’t require the use of any verbs; everything is done through specification of a keyword.  Keyword-enhanced games use keywords for a subset of actions, such as examination, movement, or conversation, but rely on standard verb-noun parsing for other actions in the model world.

The reason that distinction is important is because a game that is 100% operated through keywords should be able to dispense with a large chunk of the headaches that come from trying to shoehorn a keyword system into a standard verb-noun parser.  And this is a big deal, because there are a lot of headaches.

One of the main problems I ran into is with disambiguation.  When you enter a command that is ambiguous, Inform has special code within its parser loop that prompts you to clarify your command, then continues with the augmented command.  If you’ve played with this behavior, you’ve probably noticed that you can completely ignore the disambiguation question if you type a new command.  What you probably haven’t noticed is that this only works if the command contains a recognized verb.  In normal situations this wouldn’t be a major issue.  But when you’re using keywords for several different classes of common actions, you suddenly start getting behavior that looks… odd.

And this problem only gets worse when you add more types of keywords.  Every new type brings new state information and new logic to handle the exceptional behavior.  I spent more time diagramming logic states in an attempt to reconcile the keyword system with the other extensions and my own game code than anything else in the development process, and I ended up having to accept both some poorly-phrased error messages and also a couple of rare cases where different actions didn’t behave the way I thought they should when issued after disambiguation.

Don’t get me wrong; I think keywords are a great mechanism to increase accessibility and newbie-friendliness, and they’re a convenience feature that some veterans appreciate as well.  I’m of the opinion that for keyword-enhanced games like Aotearoa, highlighted keywords should be an optional feature, but this is very easy to do.  I’m particularly intrigued to see what direction full-keyword games take — in my opinion, games like W+S end up feeling almost like a CYOA, albeit a CYOA that’s much more detailed, granular, and well-modeled than usual for the genre.  I suspect that with enough sophistication, full-keyword IF games built in TADS or Inform could provide a very interesting and rewarding type of interaction.

I, however, am not particularly interested in writing such games.  And I doubt I will use keyword-enhancement in my next game either; to me the advantages are outweighed by the difficulty of forcing a new paradigm on Inform’s parser — a new paradigm that does not suit it particularly well.

Conversation Package

There are a ton of ways to handle conversation in IF.  But out of all of them that I’ve seen, the TADS 3-inspired model used by Eric Eve’s Conversation Package is the most robust, flexible, and immersion-promoting that is available to date.

I like it for several reasons:  It supports the “ASK/TELL” model of conversation rather than intruding a full conversational menu.  Menu-driven conversation can work well, but I really wanted something that integrated into the story a bit more organically.  Conversation Package also gives a nice topic display that, while it disrupts the narrative flow a little bit, does a good job of naturally presenting possible conversational options to keep the player moving.

Like everything, it’s a tradeoff, but I really like this model for the kinds of stories I’m interested in writing.  That said, integrating it with the keyword system was a problem.  Topic keywords had to be acted upon differently than standard keywords, which meant tracking state and providing more complex rules for processing keywords.  And what if you want to examine something that’s not a viable conversational topic while you’re in a conversation?  I ended up building a large truth table of possible states and trying to identify desired behavior in all cases, and the final result was a set of behavior that I think works well but probably doesn’t cover all possible player expectations.

I got a lot of comments about the well-implemented NPCs, which I think is partially due to the conversation engine.  Only one or two people specifically called out the engine itself, but I also noticed no negative comments on it either, so I will definitely go with this conversational system again in the future.

Modified Tutorial Mode

There was a reasonable amount of work that went into rewriting this, and I’m not sure what I ended up with is the most efficient way to approach the problem, but overall I was really happy with the way this turned out.  Emily’s original extension suffered from a couple of issues that made me hesitant to use it as it was, most notably a sensitivity to the exact text used for command matching and a rigid ordering of tutorial steps.  I adjusted it by making it be satisfied by any command of the appropriate type, regardless of the wording or subject, and also by detecting correct commands even when they didn’t match the current tutorial step.

For example, if the current step was to teach taking, and the example command was “TAKE FLOWER”, Emily’s original extension would require the user to type “TAKE FLOWER” exactly.  With mine, “GET FLOWER”, “TAKE RED FLOWER”, or “GET CANARY” would all work to satisfy the tutorial that you understand the concept of taking an item.  And if you instead typed “INVENTORY” during the “TAKE FLOWER” step, it would acknowledge that you understood the concept of taking inventory and would bypass that tutorial step later.

The modified tutorial mode extension cleanly integrated into the rest of the code, with only a couple of changes required to hook into the keyword engine (due to the fact that pressing the Enter key on a blank line counts as looking).  So the development was pretty manageable, and the results seemed to get very positive reviews.  I definitely feel this was a feature that was well worth including.

Numbered Disambiguation

I really like this extension, and it was a drop-in for the most part.  Unfortunately, disambiguation caused me a lot of problems in general with the keyword extension in place, and some of those were reflected here even though they have their roots in the Inform parsing engine itself.  This extension is in some respects an insurance policy for the author — it’s not really adding a whole lot to gameplay, but can get the player around some nasty problems that the author might have overlooked.  On that basis, I think it was worth including.

Remembering

Since you need Eric Eve’s Epistemology for quite a few other extensions, and it’s now part of the Inform 7 distribution, why not leverage it?  Aaron Reed’s Remembering extension uses Epistemology to keep track of the last place you saw something and lets you know if you try to use something that isn’t currently in scope.  This is a minor utility feature for players — unless there are a whole ton of takeable items, you probably aren’t going to be wondering where they were, but giving the player a quick tip isn’t harmful.

Unlike Numbered Disambiguation, however, this one can bite you if you’re not careful.  If you remove items from scope or do extensive tricks with moving items around behind the scenes, this extension can end up producing messages that are confusing and immersion-breaking, and I turned up a few of these in testing.  I’m not sure if the potential for extra bugs is worth the small amount of player functionality it delivers — only one person commented specifically on this feature, and that reviewer noted a bug with it at the same time.

Exit Lister

In my opinion, if your game has any kind of extensive geography there’s no reason not to have a good exit listing extension included.  I had been struck by the exit lister in last year’s Snowquest, and knew that I wanted it in Aotearoa.  Unfortunately, I also knew that Aotearoa was going to be a Glulx game, and Eric Eve’s Exit Lister extension doesn’t do colors in Glulx.  That wasn’t too much of a problem, though; I worked up some code to generate a second, separate status line window instead of a double-height one, and retooled the exit lister code so that it would write to that window instead.  In that window, I control the window styles and so it’s easy to mimic the Z-Code version.

This was all well and good, but I ran into a roadblock late in development.  Quixe came out, and it uses a CSS model for styles.  Originally, I’d written my code such that it destroyed and recreated the exits window with a different text color each time the user cycled through the possible color selections.  Since Quixe requires preselected statuses in CSS, I had to tweak the code so that it cycled through four internal styles, which I then coded into the CSS file.  This actually ended up working better, as it was not necessary for me to destroy and recreate that window as often, and the code actually got a bit simpler.

Not many people specifically called out the exit listing, but I think it’s widely seen as a “standard option” these days; in fact, I saw several games get called out for not having exit listing.  Also, my own experiences when playing reinforce the desirability of having the exits conveniently listed.  I definitely think this is a must-have feature.

Smarter Parser

Aaron has long been an advocate of improving the stock Inform parser.  In a game focused on kids and newcomers, his Smarter Parser extension was a natural choice.  What it does is to detect a command failure, analyze the triggering command for certain patterns using regular expressions, and then determine either a better error message or a way to attempt the command anyway.

In general this extension is nice; it seldom seems to do something you really don’t want it to do, and most of its message conditions are well-formed.  It’s also very modifiable; you can easily turn off individual checks or add your own.

There was some work required to get this working cleanly in some of the odder disambiguation cases, but in general it was easy to integrate.  I didn’t get much reviewer reaction on it either way, although I did get some negative feedback on it in the authors’ forums.  I’m not sure this is something that would be appropriate for all games, but for a newbie-focused game I felt it was definitely a good fit.  I might not use it (or might use it with significant alterations) in a game targeted at experienced players.

Tags: , ,

Shift Happens

I’ve mentioned my video card struggles before.  It’s been a constant source of low-grade annoyance that I haven’t been able to use my card to its full capacity, but at least I found a way to allow myself to play.  Last night, though, even with underclocking I still had restarts just looking at the main menu screen in Starcraft 2.

Let’s not get off on the subject of why I was playing Starcraft 2 rather than working on my interactive fiction game — I’m saving that for a self-flagellating post later.  But once this problem started happening, I really wanted to figure out what the deal was, so I hit up Google and started browsing.

Some people had power issues, and that seemed plausible.  After all, it required some gyrations to get the card up and running in the first place.  Some people blamed heat, but when checking the card temps it just didn’t seem that high.  But then I found another article that finally got me looking in the right direction.

Apparently my model of video card has a feature where it automatically shifts the clock speed of the card between 500 MHz and 750 MHz depending on what you’re trying to do with it.  I don’t know all the details, but apparently 3D games under Windows 7 can confuse the card and get it to try to shift modes back and forth repeatedly, which causes the fan to go nuts and the card to eventually trigger a system shutdown.

The suggested fix for this was to lock the GPU to 750 MHz using an overclocking tool.  I downloaded RivaTune, followed the simple instructions for setting this up, and was rewarded with a card that runs stably (and quietly) at full rated clock speed.  Sure, it probably eats a bit more power just idling at the desktop, but it’s worth it to not have to worry about random reboots any more!

Tags:

Upgrading to Inform 7 6E72

With the recent releases of both the in-browser Glulx interpreter Quixe, and the newest Inform 7 Build 6E72, it was pretty obvious that I’d have to upgrade.  Sure, theoretically it would be possible to stick with the last version of Inform and manually roll out a playable website for my WIP.  But why turn down all the labor-saving power of the new “release along with an interpreter” option?  It automatically builds you a nice website, converts the Glulx file to Javascript for you, and packages it neatly up for release.  I’d also modified my source to remove the very few procedural rules I’d previously used, since I’d heard I7 is deprecating them, so I figured getting my WIP up and running wouldn’t be too arduous.

Happily, I was right!  I did run into about a dozen errors, which fell into two broad categories:

  1. Errors due to more strict syntax checking in the new build.  These were easy to find and fix — I spent maybe 5 minutes on these.
  2. Errors due to changes in the extensions I use.  My WIP uses a lot of extensions, and I hack some of them up a bit as well with overrides.  So pulling down the newest versions of all these extensions caused me a bit of worry.  Of them all, however, the only one that gave me any more than the most ephemeral trouble was the new version of Jon Ingold’s Flexible Windows.  Instead of a single drawing rule, it now uses an object-based rulebook, which required a couple of minor changes (as he points out in the changelog, I should note).  Actually making the code changes was easy; finding out exactly what needed to change was the trick.  Even this, though, didn’t take me more than about 15 minutes.

So the first thing I did now that I could get up and running in the new I7 was to set up Quixe and try a test release using it.  I was pleasantly surprised by the nice CSS defaults for the web pages.  The result isn’t quite up to the level of typography you can get with Gargoyle, of course, but for a literally no-effort setup it’s more than serviceable.  The only thing I ended up doing to the generated pages was to modify the User1 and User2 styles so that they reflected the colored text defaults that I start with, and I was off and running.

I have noticed that I7 is a touch slower to compile now than it was before, and generates a larger story file as well.  Before the upgrade I was running at just over 800 KB, and after the upgrade I’m up over 1 MB.  All the changes and improvements in the I7 release probably contribute to this, but I was pretty surprised to see the size of the generated file increase by 20%.  What this really means, I guess, is that it’s a good thing Quixe came out when it did, since the new I7 has pretty well priced itself out of the Z-machine’s range for all but the most trivial stories.

One thing I hope people continue to look at is the performance of Quixe.  The speed difference when running under Gargoyle vs. when running under Quixe is shocking — Quixe is at least an order of magnitude slower than standalone compiled interpreters, and I suspect more can be done to optimize Quixe given how brand-new the implementation is.  My fairly large WIP is certainly playable, but the slow response time is jarring.  Until speed improves I’ll still be playing most games through a standalone interpreter.

Now the only trick remaining is for me to work out how to support the dynamic color shifting for user styles that the standalone interpreters can use.  I have an extra window created below the status line that should be able to display one of four choices of colored text depending on what the user wants.  I’m thinking that with some judicious changes to the standard styles for that window, along with some minor changes to the code that displays the text, that I can support the appropriate choices in Quixe with a single set of CSS.  If I can’t, I guess I can create alternate windows with different color settings in their specific CSS sections and swap them in appropriately.  I’ll just have to ensure that whatever I end up doing for Quixe doesn’t break the solution I’m using for other interpreters.

Tags: , , ,

Andrew Plotkin’s Quixe Beta: Glulx Games Directly In-Browser!

In a surge of holiday-weekend coding, Andrew Plotkin (Zarf) has progressed his Quixe project to the beta stage and released it for evaluation.  If you’re very familiar with the excellent Parchment project, you’ll know that Parchment provides a Javascript implementation of the Z-machine, which is one of the major virtual machines used in the interactive fiction community.  When you play a game via Parchment, you don’t need plugins or standalone interpreter software at all — you play directly and natively in the browser.  This has obvious advantages for outreach — many people are leery of downloading unknown executable files at all.  And unless your game runs in Flash, convincing someone to install a browser plugin can be almost as hard a sell.  So Parchment has been a great mechanism to make Z-machine games available to not just a wider audience, but to a wide variety of devices as well.  Almost any device that supports a Javascript-enabled web browser can access interactive fiction through Parchment.

But until now, Glulx games were left in the cold.  Glulx is an alternate virtual machine developed by Andrew Plotkin to address some of the limitations of the Z-machine.  There’s more addressable memory as well as support for multiple windows, graphics, and sound, among other improvements.  Inform 7 gives you a choice of using Glulx or one of the Z-machine formats when you compile a game.

Unfortunately, using Inform 7 for a game of any complexity almost forces you into using Glulx, whether you are making use of its enhanced capabilities or not.  Inform 7 generates large game files that easily push past the Z-machine limits.  Particularly if you make use of the growing extension libraries you are likely to inflate yourself right past even the Z8 format’s cap on size.

So Inform 7 developers have (for the most part) found themselves unable to enjoy the same advantages of accessibility and ubiquity that Parchment gives Z-machine authors.

Enter Quixe.  Quixe provides a native Javascript implementation of the Glulx VM.  When combined with a suitable output layer (in this case I believe Zarf is using his own GlkOte implementation) it enables the same type of direct-in-browser play for Glulx-based games that Parchment enables for the Z-machine.

He’s currently got five games up on his page, but authors are able to convert any existing Glulx games using the zcode2js tool, and run them via his engine.  If you do this, you’ll notice that not everything is functional yet.  In particular, if you play the conversion of Rover’s Day Out you’ll miss much of the text formatting and screen effects that are visible in the game when played via a standalone interpreter.  Also, Internet Explorer does not currently work (!) Presumably these problems will be fixed and capabilities will be added in as development proceeds.  I expect we’ll also see the new style model that Zarf has been discussing over the past few months.

And of course, I had to run a conversion of my own Glulx game, Grounded in Space!  Despite not being very long or complex, I had to use Glulx for this game due the need for fairly high-precision floating-point math for one of the puzzles.  I haven’t gone through it in detail yet, but it seems to have converted correctly.  It doesn’t use any odd tricks that should prevent it from being playable, although the geometry puzzle might be even less comprehensible due to style and font issues.  At any rate, it’s very cool to have this capability, and I hope by the time this year’s Comp rolls around we’ll have a much larger number of games able to be played online due to Quixe!

Tags: , , ,

Who Moved Robin’s Cheese?

The upgrade to Windows 7 has been mostly straightforward, but while getting rained on at Thomas’s soccer game on Saturday I got a text message from Robin:

I HATE THIS NEW OPERATING SYSTEM!

It seems that in the process of installing Windows 7 and reinstalling iTunes that her music files got moved around to various unintuitive locations.  While I feel that iTunes and, frankly, myself deserve as big a share of the ire as Windows 7, it was Windows’s overintelligent search algorithm that actually drove Robin off the edge.

She was trying to set up a Gmail account for Thomas, not realizing that he was too young to qualify.  After attempting and failing to set up the account, she found herself locked out of several pieces of Google functionality, so she thought Google had dumped a cookie on our machine that was blocking functionality.  She tried to search for “cookie” on the Start Menu search field, and although it searched within Outlook for every cookie recipe email we’d ever received, and gave her an option to clear all cookies, it didn’t actually show her any individual cookies.  It took me about 5 minutes of trolling through 3rd level menus in IE8 to finally locate them and confirm that there wasn’t a rogue cookie.

I’m firmly of the opinion that Windows 7 is the best O/S Microsoft has come out with, and I think it’s great, but I think I’ve got some work to do yet to clean up and relocate some files before Robin gets truly comfortable with it.

Tags: ,

Lost Domain

Due to a SNAFU with Namecheap, I lost my domain for a day.  Combined with a power outage due to a storm here, we were left with no webpage, and when I got the computer back up, still no webpage and no mail forwarding.  So I quickly re-upped the registration and got everything set up, but I had lost the post I’d sent to my email account.  I should be able to retrieve it tomorrow.

Tags: ,

New Inform 7 Release Imminent

Great news from vaporware’s post on rec.arts.int-fiction!  Inform 7 will have a new release on or shortly after April 28th!

Items slated for the new build will include:

  • Tidier user interface
  • Easily publish Inform works to the web, including a release mode
    that creates a playable web site using Parchment
  • Many language restrictions removed, and more expressiveness in
    talking about kinds, phrases, relations, etc.
  • Many Standard Rules actions changed to provide default behavior
    closer to what modern authors tend to want (automatically opening
    doors, handling TAKE ALL more naturally, and so on)
  • More than 250 bug reports resolved

Can’t wait!

Tags: , , ,

Game Review — Left 4 Dead 2

While gearing back up for some more interactive fiction development after my two-and-a-half-month detour through Dragon Age, I made a comment on rec.arts.int-fiction to the effect that the Drama Manager in Blue Lacuna, Aaron Reed’s XYZZY Award-winning interactive fiction title, was unique in my knowledge in terms of providing an auto-adapting pacing mechanism for gameplay.

Zarf (Andrew Plotkin) responded with a link to a design postmortem presentation for the game “Left 4 Dead“, by Valve Software, which talked about their use of procedurally-generated content to provide dramatic pacing for that game.  Now, Left 4 Dead is substantially different from an interactive fiction title, but I like a good FPS as much as the next guy, and was intrigued by the paper.  In a coincidence that was happy for my wallet but not for my productivity, Valve was having a half-price sale for Left 4 Dead 2 right after this exchange, so I was able to pick up the game for just $25 and give it a spin.

The premise of the L4D series is that there’s been some sort of contagious infection that is turning people into zombies.  You play one of the four Survivors, humans that have proven immune to the contagion.  The goal is simple — escape the zombie hordes before your brains are eaten.  To do this, you have to work together to protect each other and carve a path through the ravening hordes of zombies to reach an extraction point at the end of the level.

It’s a cooperative first-person shooter game — even if you play alone, the game spawns three “bot” players to help you.  And it’s a good thing it does, because the gameplay depends on close cooperation between players.  If one person gets separated from the group, it’s very likely they’re going to get killed before too long, because certain of the enemies — the “special Infected” — can pin or otherwise incapacitate lone Survivors.  If one of your friends doesn’t quickly kill whatever’s on you, you’ll watch helplessly as the zombie rips you apart.

A big chunk of the magic of this game, as the paper I read indicated, is in the pacing.  L4D2 generates loot and enemies procedurally, depending on where you are and what your calculated level of “emotional intensity” is.  If you’ve been fighting hard, with lots of zombies on you, the game will hold at that level of intensity for a little bit and then back off to give you a breather.  If you’ve had some downtime, the game will slowly start spinning up more enemies and eventually subject you to a “horde”, where a mob of common Infected rush you, trying to overwhelm you with a human wave attack.  And every so often you get a special Infected or boss Infected thrown into the mix.

These special Infected are by far the toughest part of the game.  Each of the specials has a powerful ability it can use to wreak havoc on a team of Survivors.  Spitters can spit globs of caustic saliva, causing damage and potentially cutting off escape routes.  Chargers can sprint into a group, grab someone, and carry them along in a straight line until they reach a wall, both damaging and separating them from the group.  Jockeys can jump on your shoulders and force you to run away from your friends, and can even force you off ledges.  The dreaded Tank can absorb a ridiculous amount of firepower, and does amazing damage and knockback if you are foolish enough to let it close to melee range.

The complement to the dynamic pacing is the atmosphere.  Level design is excellent, with decaying architecture, weather effects, low-light areas, and close quarters all serving to keep the tension heightened.  The music used on each level is different, and thematically matched to the play environments.  Hordes and bosses all have special theme music, which is again different depending on the level you’re playing, and it wasn’t uncommon for me to start getting twitchy and panicky when I heard that horde theme start up again while I was stuck hip-deep in swampwater.

Your fellow survivors have a great deal of scripted conversation that is triggered in certain circumstances; you definitely get to know their personalities as the game goes by.  In addition to the level-specific dialogue, there are a lot of coordination comments they use, from alerting you to weapons nearby to reporting their imminent death.

I guess a good illustration of the intensity of the gameplay is my reaction to the weapons available on each level.  You always start a level in a “safehouse” — an impregnable room with a selection of health packs, weapons, and ammunition.  You can choose a single heavy weapon (such as a rifle or shotgun) to take with you, and you can’t change it until you find either another safehouse or a hidden stockpile of guns somewhere in the level.  And since the levels are procedurally generated, you don’t always get the same selection of guns on every playthrough.

In most first-person shooters I have weapon preferences — in Half-Life I’m a pretty big fan of the shotgun (if I don’t have the gravity gun) — but if I can’t get my weapon of choice, or if I’m out of ammo, it’s not a big deal.  I’ll just use one of the other ones.

In L4D2, if I don’t get either the AK-47 or the M-16 (on levels where that tier of weapon is an option) I feel naked and exposed.  It’s very uncomfortable not to have the precise weapon I’m most skilled with, and it’s just nervewracking and not very fun to play the game until I find an acceptable gun.  I think this more than anything else is the triumph of the Left 4 Dead series — that they can control pacing and atmosphere to such a degree that they can give you that “character in a horror movie” feel, just from your expectation of what’s coming next.

I’ve really only played the single-player campaign, so I don’t have the experience of going out and playing with three other guys using voice chat.  They do have several player-vs-player variants, including a very fun one where two teams of four alternate being the Survivors and the special Infected and then see which team can make it farthest through one of the levels.  It seems there’s a lot of replayability here, and I’m looking forward to giving some of those other modes a shot.

Even the single-player experience, however, was well worth the $25.  As an illustration of how procedural, dynamic content can serve the gaming experience, and as a darn good FPS game itself, L4D2 is well-worth playing if you have any taste for first person shooters — or zombie movies.

Tags: ,

The Quern is Digg proof thanks to caching by WP Super Cache