Review: Clive Barker's Jericho

Clive Barker's Jericho is as much fun as you make it - a squad of seven special ops straight from the Laundry each of which is equipped with enough weapons and supernatural abilities to be the lead protagonist in any other first person shooter.

And that is its greatest failing. Jericho cries out for the inspired level design and puzzle solving featured in the God of War series, and makes the mistake of borrowing the quick time events instead. And it is because you never spend enough time with any one of the squad that you will miss the depth and subtleties of each soldier's specialties.

Jericho desperately needs a Miyamoto to craft it puzzles using a strong visual language or a Warren Spector to build places explorable using a wide variety of strategies, or even just the rebel encampment from the original Predator movie to allow you to practice all the bad-assedry you'll finally get comfortable with just as the game is winding down.

You'll end up blaming the AI or seemingly under-powered characters* or uninspired corridors with their monster closet cramped close quarter fighting when you should instead be celebrating the fact that you can be a self-cutting ninja with a machine pistol whose blood sprouts snaking tentacles which grasp out at your enemies while you slice them limb from limb, or a dual-pistol wielding priest with three different ammunition load outs per weapon who can drain the life of his enemies and resurrect the fallen, or a telekinetic sniper who can steer bullets with her mind and whose high performance rifle has an under-slung grenade launcher, or an astral walking ancient history expert who has thoughtfully attached an automatic shotgun to his assault rifle - and can set alight or blood ward any creature he possesses, or a warlock with a mini-gun, a demon embedded in his arm and the largest customized pistol I've ever seen, or a reality distorting, time slowing technical expert with programmable grenades who can conjure ammunition for the rest of the team and scan enemies for weak spots.

But in fact, you are all of them.

Clive Barker's Jericho is available on Steam for a criminally low price. Play it because more games need warlocks with mini-guns.

* Two glaring examples of how badly the game explains or requires the protagonists powers: almost every review cites Jones, the astral traveler, as being underpowered. Except he can set on fire any enemy at any range which he can see, and use Church's blood magic abilities at a distance where she must do so close up. And Cole's visor highlights enemies weak spots, should you zoom in. I neither used or was aware of either ability on the first play through.

Coursework

Be sure to ask for extra credit if you commented on the blog...

Worship the new god

Just to wrench you away from Unangband for a moment: a good summary, the confession, and yet people don't understand how random numbers work. If you generate them in advance, they're still random - unless that information is leaked. And provided you don't peek.

I crafted my backpack away last night so that I only have hats left. It feels... liberating.

Poll results for 'What changes do you like in Unangband 0.6.4?'; new poll

The results for what changes do you like in Unangband 0.6.4? Thanks to the 28 people who voted.

Improved dungeon connectivity	8 (28%)
New room types: burrows	4 (14%)
New room types: caverns	5 (17%)
New room types: polygons	5 (17%)
Familiars	5 (17%)
Offering stuff to monsters	0 (0%)
Stealing stuff from monsters	2 (7%)
Monsters surrendering	3 (10%)
Magic book reorganisation	2 (7%)
Less bugs	9 (32%)
Improved documentation	11 (39%)
Improved spell regions	3 (10%)
Sneaking	2 (7%)
Neutral monster AI	2 (7%)
Interaction with allies	4 (14%)
New spells	5 (17%)
New monsters	4 (14%)
Other	2 (7%)
Haven't had time to play	6 (21%)
Unsure; there's so much stuff	3 (10%)
Unsure; still getting a feel for things	1 (3%)

The new poll follows on from the Level 40 post I just made.

Level 40

I was somewhat surprised by a recent post by LostTemplar on angband.oook.cz:

When I played UN it seemed to me that it is too hard in the beginning and way too easy in late game.

This has to be fixed immediately. I can't have players calling Unangband easy...

A big part of the problem, as Mr Templar points out, is that high level Unangband players end up with an obscene amount of hit points. This is a result of making the size stat determine hit dice, which means even a mage can have a large hit dice. I've tried to balance this by having size penalize agility if your size exceeds your strength, but since every item which adds size also adds the same amount of strength, it is easy to ignore this limitation.

If I remove the size = hit dice benefit, there is little incentive to have a high size, and the size bonus feels about right for most of the game. It's only at high levels (and high stats) where the bonuses becomes obscene.

Which leads me to conclude that I should reduce the level cap for Unangband from 50. This way, the per level bonuses for hit points can remain significant as size and constitution increase, while not having to worry so much about the results at the top end.

I'm immediately attracted to the idea of limiting player advancement to level 40. The reason is that almost all mage spells are under level 40, so I won't have to redesign to many spells to fit the lower level limit. In fact, I shouldn't have to design any*, because spell specialists can cast spells 20% higher than their level, so that they can effectively cast up to level 48 spells. Given I have a to do item to add higher levels spells which only specialists can cast, dropping the level limit to 40 is an automatic win for this reason. This should start to address some of Templar's concerns about imbalanced spells as well.

There are two downsides to this approach: tradition, and level advancement as carrot. Tradition means that long time Angband and Unangband players will wonder what is going on when they get to level 40 and no higher - which will mean that I'll get pestered with questions. Level advancement as carrot means that there'll be less short term goals available to higher level players which they can grind towards. I'm unsure whether this is a good or bad thing.

An alternative is to play with the way that hit points advance. I've done this for other stat advancement: in particular the number of spells learned by low intelligence players is capped before they get to maximum level. I could take this approach. It's very much in the spirit of AD&D second edition where you no longer got to roll hit dice after a certain level. Size contributing hit points up only until level 20 would be one such example. This would make extra size add extra hit points, but not too many extra hit points - +20 hit points per increase in size above 18/110. Constitution by way of contrast gives +50 hit points per +1 CON at level 50 for similarly high constitutions.

* Except Fireball III which is level 49.

Review: Dark Messiah Might & Magic

This game is like every fun Dungeons & Dragons campaign you played as a teenager - a tenuous plot which takes you from set piece to great set piece. It is a fantasy Half-Life 2: cleverly designed physics, beautiful visual design and animation, well-thought out abilities which combine with classic RPG tropes (zombies, dragons, goblins) to make you feel like a fantasy hero. It also succeeds as one of the few fantasy games to make every opponent a worthy challenge.

It will take you a little while to get the feel for the game: don't worry so much about making every stealth kill, because the joyous melee combat engine will win you over. Some mechanics are also not made initially clear - both oil and barrels require you have a separate source of fire to be useful, you can throw your dagger at a fleeing opponent or when you have adrenaline for an instant kill - but where it betters Half-Life 2 is that solving the physics problem won't win you the fight alone. And yes, there are points where it feels like you can kick your way through, but don't ignore the fact most attacks will knock your enemies backwards and take pleasure from the clash of blades, flight of arrows or burning agony of your enemies.

Highly underrated on release because of some poor reviews, along with teething problems with bugs which have since been ironed out. Ignore the apparently atrocious Xbox 360 release, crank the video settings up to the max which should be fine for most modern graphics cards and enjoy the ride.

You should get this now on sale on Steam. (Unless you are afraid of spiders).

The Blockenheal

I note in passing that Valve have returned their Overhealer design to the TF2 beta. The Overhealer is a Medigun that allows the overheal effect to persist. Previous iterations have allowed overhealing up to +100% of hit points - which allowed, among other obscenities, 600 hp Heavies which could ignore a 500 hp backstab - while the latest version merely allows a persistent +50% healing.

The downside is -50% healing rate, instead of previous versions which had a greatly slowed Ubercharge rate.

The Overhealer is an interesting weapon design for a class that has been underserviced by unlocks since the initial release. (The Spy is the only other class which has only 3 unlocks at present - the 4th will possibly be a flame proof suit which replaces the Revolver). During normal play, where the Medic is positioned slightly behind the front line of battle, the Overhealer will unlikely provide much difference to his alternative weapons. At this point, the Medic has a hard time healing characters quickly enough for persistent healing to take effect.

The Overhealer might make a difference between respawns, particularly if the Medic respawns with 2 or more others. That way, the race to the front should allow the medic to get several classes over healed.

But the most interesting time to use the Overhealer is during set up. At the moment, the out of the gate response to a medic is almost always an invulnerability Ubercharge whereas the Kritzkrieg tends to be used during unstructured play.

But the Overhealer is an ideal alternative during set up because it becomes possible for the Medic to overheal the entire team, providing an interesting alternative to an Uber rush.

When considered in this light, giving the Overhealer an invulnerability uber as well doesn't make a huge amount of sense - because the Medic gets both the overheal benefit to the entire team, and the benefit of this initial Ubercharge. I suspect Valve has been tuning the Overhealer rates primarily for this set up time, to either prevent the Medic healing the entire team, or getting the Ubercharge straight away.

The Blockenheal avoids this problem by giving the Overhealer an alternative Ubercharge effect. When charged, right-clicking with the Blockenheal immediately overheals the target and the Medic to 200% of their maximum health, regardless of how much damage they have sustained. This appears as a zap of electricity which shoots up the medigun beam to the target.

For the next 8 seconds after this instant heal effect, the Blockenheal heals at +200% rate - that is three times as fast - up to 200% overheal. Players healed beyond 150% health have noticeably larger overhealed particles surrounding them. The healing above 150% decays at the normal Overheal decay rate after the Blockenheal uber finishes.

The Blockenheal recharges at +100% the speed of the Medigun - that is twice as fast. More importantly, the Blockenheal starts out charged, so that the Medic has the ability to be a useful choice during the dying seconds of the match, without being an overpowered one. The Blockenheal normally heals targets at the same speed as the Medigun and Kritzkrieg.

The Blockenheal allows the ridiculous ways of breaking the game by having 200% health, while requiring the Medic keep a watchful eye on the class he is supporting. The Blockenheal uber doesn't provide the same level of punch that the Kritzkrieg or Medigun does, but benefits more players around the Medic than the Uber or Kritzkrieg is capable of helping. The instant heal effect can also be used defensively, to protect a Heavy from an incoming spy, crocket or distant sniper, or if the Medic becomes isolated.

Morality in beta

A lot of games by independent developers go through extended beta periods - Mount & Blade is a good example. Many roguelikes take this to the extremes: Unangband has been in beta for over 10 years (Unless you consider most of that period to be alpha).

During that period it is inevitable that players will encounter bugs while playing the game. But with a roguelike, especially one as deep as Unangband, it is not often clear while you are caught up in the moment of play whether the behaviour of a particular element in the game is a bug. It could instead be an exploit that has been permitted or sanctioned by the developer, or unintended consequences which may be patched in a later version of the game.

Ashkir, while playing Unangband, has experienced one such unintended consequence which he has framed explicitly in moral terms. His familiar, which is a customisable summons which develops throughout the game alongside the one subclass of magic user able to summon it, was able to avoid being killed by a unique monster because it is also a unique, and at the moment in Unangband, uniques can only be killed by the player.

As I mention in the thread, I didn't pick this up during testing because I inevitably accidentally would kill the familiar early on in the game, and as a result never noticed this issue. This is important, because once a familiar is dead, it won't come back - a partial permadeath. While this may seem draconian, it met the requirements I initially set for the Find Familiar design.

The Master magic school has a wide variety of summons spells but needed an introductory spell that would allow Master characters to learn about managing their summoned monsters very early on in the game without unbalancing the class by allowing them to spam summons to abuse the game. Find Familiar is therefore a low level spell which allows you to only summon one monster, and implemented as a 'throwaway hack' - something fun I could code relatively quickly and without having to worry about the impact on much of the game. The improving abilities are intended as a bonus for those players who do manage to keep their familiar's alive - and as a way of anticipating the feature request that would have inevitably been made by the player base.

Unsurprisingly, people became incredibly attached to their familiars, to the point where the most common feature request made is the ability to name them. Ashkir has taken this one step further and built his entire play style around the familiar abilities. But I am intrigued about the depth of his reaction to finding out his familiar can't die, for several reasons.

Firstly, is the fact that an unkillable assistant is such a common feature of computer games that has become a trope of the genre. Your pet in Torchlight is the example closest to the genre - it flees instead of dying, because having your pet die would completely unbalance the in-game economy.

Secondly, is that he has been completely abusing another significant bug in the familiar game design without the slightest moral qualm:

'Most importantly I made his attacks drain health so as he hits creatures the life drained is added to my own hit points. This is incredibly useful and gives a Necro a huge advantage as they have a spell that drains their own life to give themselves back spell points, giving me an almost limitless supply of power."

The problem with this statement is that I never intended for the familiar's drain health ability to heal the spell caster - it should merely heal the familiar. This unintended consequence occurs because of the way that your allies attacks are treated as your attacks for the purpose of getting experience.

Thirdly, is the fact that if I gave him what he wants, a completely dead familiar, he in all likelihood would stop playing the game:

I've had a great time with this @ and will definately go back to him later but I'd rather not do it while the bug is present or without using the familiar as it's a massive part of the Necro's play style.

(My emphasis added).

I've presented him with exactly that Solomon's choice simply to see if he takes it up.

There's a lot here worth discussing further. What do you think? (And Ashkir, feel free to correct anything I've assumed here, in the comments, or on the thread you started).

Respect

I've just finished listening to a detailed discussion on the Another Castle podcast about Shiren the Wanderer (with the always excellent Anna Anthropy aka auntie pixelante; who'd be on my top 5 game designers worth reading along with David Sirlin, Clint Hocking, the sadly no longer writing Ted Vessenes and only infrequently blogging Soren Johnson) and I was reminded, again, about the incredible amount of respect people have for the roguelike genre.

It feels like everytime a roguelike peeks above the parapets into more mainstream gaming circles, the comment threads are filled with people relating their positive experiences of Nethack, Zangband, Shiren or some other great example of the genre. And game designers especially seem to love roguelikes, for ways they push game design in directions few others seem willing to explore.

Sure, there is the odd person who dismisses the clunky graphics or user interface problems, but they are in the minority.

I hope as a roguelike developer I'm producing something worthy of that level of respect.

Game Design Podcast recommendations

I have a not insignificant commute every day (1.5 - 2 hours each way, longer if I drive) and was wondering if you, the Internet, have any recommendations for game design podcasts that I may have missed.

I'm specifically looking for game design, or interviews with game designers, or journalists who have in-depth knowledge of a particular game genre.

Currently on my podcast rotation:

Highly recommended:
Another Castle (just discovered which has prompted me to ask the question)
Brainy Gamer
Three Moves Ahead

General games gossip, and worth it for entertainment value:
Gamers with Jobs
One Life Left

Still in the early days of listening so can't make a recommendation yet:
Second Person Shooter (promising)
Hey Ash Watcha Podcastin' (not so)

Not really worth it despite the caliber of the journalists involved:
Rock Paper Shotgun (still on rotation)
Kotaku (taken off rotation)

Light entertainment about stuff that's not as serious as games:
The Economist
TED

Thoughts?

I'm portable

Klaus Breuer has kindly converted a couple of the articles I've written to PDF format using Latex (plus some light edits which I should include in the originals). If you've ever wanted to read me offline, you're more than welcome to download them from here.

Proceduralism: Part Two (Taxonomies)

[You'll probably want to read the original article series that inspired this follow up, then start with part one of this series.]

In attempting to define a taxonomy of procedural generation, I was conscious of the lack of a rigorous vocabulary when talking about procedural content born from the lack of academic investigation of procedural content systems (as distinct from, say, Artificial Intelligence). That is not to say that procedural content generation hasn't been primarily a focus of academia: it is built from mathematical systems which have intrigued academics ever since the Fibonacci sequence, but there has been only a limited exploration of the consequences of these systems, particularly with regards to the game development. This is changing: particularly in the last two years spurred on in a no small part by the efforts of Julian Togelius (not to take lightly the contributions of many others in the field) but also by the validation of games as a field worthy of serious academic investigation.

But taxonomies are difficult beasts to design correctly, because language itself is used in two distinct ways in talking about knowledge and the properties of systems. Language is incredibly powerful tool which we often take for granted, and we often disagree strongly over attempts to provide definitions, which degenerate into arguments about semantic relationships of words to other words. In this sense, words are slippery creatures which we cannot pin down like butterflies to a mounting board.

There is one subset of language is useful: when we talk about the formal properties of a system. When I say that a particular maze is acyclic, I'm not referring to a debatable point which you can disagree on - I'm instead referring to a particular well-defined property of a particular maze which we can provide a number of different but equivalent tests to agree that this property exists for some mazes and does not exist for other mazes. This formal use of languages is equivalent in many ways to mathematical expressions: I've chosen mazes as a specific example both because of the utility of mazes for procedural content generation and the excellent reference on mazes at the Think Labyrinth website.

Using language in this rigorous way has its basis in mathematics, particularly the mathematics of proof, and has grown naturally from there to other scientific disciplines as they have adopted the tools of mathematics in its various forms. But at the same time, the phrasing and idiosyncrisies required of mathematical proof has been adopted as a rhetorical device, and spread much further than the methods of proof it is based on. You should be suspicious of anyone who talks about a definition of something by saying it is this, but not this, and because it is this and this, it must also through induction be this as well: because they are attempting to frame an argument in formal language about a system which is not formally defined, and that is not how people are experimentally shown to give meaning to words.

(How they do give meaning to a word is likely to be something like Prototype Theory).

But while people are not swayed by formal logic, they are swayed by rhetoric, and so my earlier attempt to define a taxonomy for Procedural Content Generation can be seen primarily as series of rhetorical posts, arguing for something (PCG) and against something (little p procedural), and then expanding on what is great about procedural content generation, and setting up various categorisation tropes so that you felt like there existed a field of procedural content generation, stretched back to the history of early gaming (Elite, Rogue and Pascal - the person - if you were especially diligent).

It was, I'll state modestly, relatively successful. Not necessarily directly, but it did force me to actively expand on my initial categorisation efforts into the PCG wiki, which has hopefully created a little more interest in procedural generation, and attempted to provide a working vocabulary for practioners in the field. The one thing I think it has done well is popularized a way of stating what people are working on (Procedural Content Generation) - and the acronym PCG (which undoubtedly has been independently been coined elsewhere).

The taxonomy itself has not been useful. And attempts to categorise games using PCG using it has never got anywhere.

If you look at the PCG wiki algorithms page, instead of the six (or seven) point categories I outlined, you'll instead find a number of headings: concepts, map generation, sequence generation, ontogenetic and teleological, and the categories I proposed buried as relatively unimportant subheadings alongside various other algorithmic techniques and high-level concepts.

Concepts is kinds of a catch all category, which should really be the name of the whole page (instead of algorithms or code), because there is a large amount of talking about concepts on the wiki, and links to people outside the wiki, and precious little in the way of actual algorithms and code. I would love at some point to sit down and write lots of example code, and if you have the time, please do so. But you'll probably succumb to Doull's Corollary.

(For the record, Doull's Law as "Any time saved using procedural content generation techniques will be lost staring at the resulting screen saver." and Doull's Corollary is "Don't ask the procedural generation community for help because they're inspired by procedural generation as a way of avoiding the type of work you're asking them to do.")

Map generation and sequence generation were suggested early on by droid as a way of breaking down a relatively monolith version of this page into two different but related types of algorithms. They are good at doing that, but of themselves are not especially useful as ways of thinking about procedural content generation.

Ontogenetic and teleological on the other hand are incredibly useful concepts which I stole shamelessly from an article by Mick West. (I'd love to know if there are any earlier references to these two terms being used in association with procedural generation). In short, ontogenetic algorithms attempt to duplicate the end result of a physical process without emulating the intermediate steps, and teleological algorithms attempt to simulate the physical processes which result in the desired procedural output. Each approach can be used in combination, but any time you attempt to create something procedurally, you will be guided by one or other approach.

Julian Togelius, first in a post to the Procedural Content Generation group, and then in a paper Search-based Procedural Content Generation written in conjunction with Georgios N. Yannakakis, Kenneth O. Stanley and Cameron Browne outlines some other decisions required in the development of a procedural content generation algorithm: online vs offline, necessary vs optional, random seed vs parameter values, stochiastic vs deterministic generation and constructive vs generate and test. Note that each of these is a continuum rather than a necessarily binary distinction, and they do not attempt to define what is not procedural content, but more what are the decisions around implementing or requirements of a particular PCG algorithm. I highly recommend the paper as an overview of PCG and a view of where academic research in PCG is currently concentrated. It is written at a level you should be able to follow even if you are not especially technical or academic.

There are other distinctions which you could attempt to make between various types of procedural content generation. One example I'll pick is content generation vs content selection - described in an article at Grand Text Auto. You'll see from my comments there that it is a distinction I don't necessarily agree with, although it is another attempt to redefine what I called user mediated content in the original article series.

The take away from this revised overview of PCG taxonomies is that you shouldn't wed yourself to any particular definition of what is or isn't procedural content beyond the point where it assists you in creating a particular procedural generation algorithm. At the time I wrote Death of the Level Designer, there wasn't a particular emphasis in academia on the Procedural Content Generation as a discipline, but since then (and I hasten to add, not because of the article) there is a growing belief that there are specific reasons to investigate PCG as a separate field of study distinct from its parts. You should use resource like the PCG wiki to help get inspiration for how to solve a particular problem, but feel free to look elsewhere (I'm fond at the moment of this implementation of Navier-Stokes equations).

In part three in this series, I'll ask the more fundamental question I've been avoiding so far: if words are slippery enough that we can't define a PCG taxonomy, can we at least define what procedural content generation is?