Posts Tagged ‘roguelike’

Screw the Berlin Interpretation!

May 14th, 2013 15 comments

In the year 2008 several men and women came together in Berlin to create the last, best definition of a roguelike. It failed…

Or at least in my view it did. The Berlin Interpretation as it became known was a set of high and low value factors for what constitutes a roguelike. These were based largely on the major roguelikes of the day. They ranged from the obvious like random content to the downright nonsense, like being set in a dungeon or using ASCII.

Let me make this really clear – adding ASCII to your game does not in any way make it more roguelike. Taking ASCII away does not make it any less roguelike. It’s absurd to place value on this beyond an aesthetic choice. It’s like saying platformers have to have pixel graphics because all the old platformers had pixel graphics. This is just one of several utterly nonsense features that the Berlin Interpretation terms roguelike.

The Interpretation comes with a disclaimer stating “The purpose of the definition is for the roguelike community to better understand what the community is studying. It is not to place constraints on developers or games.” However prefacing a definition with this line is as futile as saying “I’m not racist, but…” Of course it puts constraints on developers and games! Devs want their games to fit in, and so tweak their works to score highly on this system. Gamers want to be exclusive about their community, and so rail against anything that doesn’t fit the letter of their newfound law. This has been happening for all the years since the Interpretation was made public, and has reared its ugly head again this week in a poorly written PA Report on “What the hell is a roguelike?” The comments on the post and the related reddit thread are at least polite by internet standards, but there are still many in them that stick dunderheadedly to the idea that the Berlin Interpretation is the golden rule of what is or is not roguelike.

The problem with the Berlin Interpretation is a problem with definitions in general. Firstly, a definition is only as good as its use in general conversation. The terms “decimate” and “role-playing game” no longer hold their literal meaning, and neither does “roguelike”. Meanings and context change over time, and in the five years since the Interpretation was written there have been many changes in the roguelike scene, with novel 7DRLs and indie roguelikes stretching the genre into new and unforeseen areas. It’s out of date and out of touch with modern roguelikes. All definitions are doomed to end up like this. Those who insist on sticking to the rules are like annoying grammar pedants who spend more time arguing about English than having real social conversations. By analogy those who argue over the Berlin Interpretation aren’t playing enough modern roguelikes.

Secondly, definitions are about excluding things. They ultimately draw a line in the sand and say “if you stray beyond, you are forgotten”. This is terrible from a design point of view, as it limits creative potential. It’s awful from a community point of view because it pushes people out. The Berlin Interpretation tried to be wishy-washy with its “you don’t need every rule” but people don’t read it like that. Descriptors like “turn-based” get used as clubs to beat other games out, even games that do innovative things with the time system like FTL.

Thirdly, definitions only look at the “what” behind things, not the “why”. I’ve railed against what vs why in a similar context before. There are reasons behind the features listed on the Berlin Interpretation, and understanding the why lets you understand how they can be changed and still keep the spirit of the game. There’s a certain feel to playing a roguelike, and a reason why several of the common features work well together. That roguelike feel can be described, but it can never be reduced to a pathetic ingredients list. Trying to define the features that make a roguelike so special is akin to describing a cake’s flavour as being flour, water, butter and sugar.

So why is a game a roguelike? How does it play? Well, in my view it’s inherently replayable, capable of surprising the player on many playthroughs. It rewards cleverness and tactical thinking. It cannot simply be learnt by rote, but it can be mastered with experience. It emphasises gameplay before aesthetics, concentrating on making that replayable experience fresh and engaging on each play. It’s unforgiving, but all the more rewarding when you perform it well, offering an honest sense of achievement and satisfaction. Much of this satisfaction comes from the internal knowledge of having done well at the game itself, rather than artificially constructed rewards. [Edit: Some people are taking this as a suggested definition – it is not! It’s just meant to be a more healthy way of reflecting on what makes roguelikes what they are.]

When making or playing a game think about how the design satisfies these feelings of play, and which features best contribute towards the spirit of roguelike. And screw the Berlin Interpretation, or any other list of yes and no features. These definitions are only used by pedants to silence conversation and stifle creativity and potential in the genre. We don’t need that crap! Roguelikes are an exciting genre with a huge range of still untapped potential – we need to be exploring new territories and looking for new boundaries, instead of trapping ourselves into a tight space of already knowns.

Viva la Roguelike Renaissance!

Ancestor Worship

November 30th, 2012 3 comments

Last week Michael Brough made a great post about maturity in game design.  Go read it, it makes some important points and is a good thought-stirrer.

It touches on some things that have been going on in the independent gaming scene recently, in particular the great lauding (and financing) of old developers making games anew, often in the same mould as the venerable titles they are renowned for, some even direct remakes or sequels.  I’ve expressed reservations about these in the past, especially the ones promising just “old school” and appealing to nostalgia instead of talking about their new games.  But I’m a gamer, and I’m not immune to these assaults myself.  I understand the nostalgia appeal, and I’m disgusted with it even as I walk into its trap.

It’s not a new thing of course – Nintendo have strummed on the nostalgic heart-strings of gamers for years.  Independent developers, many of which are now crying out against the attention these old developers are now getting, have long exploited nostalgic techniques in game design for their hungry audiences.  Pixel art and platformers have abounded.  But in the last couple of years I had a genuine sense that we were moving forward, with indies stretching to wholly new territories, creating novel art styles and truly innovative mechanics.  Has all that progress been reversed?

At the International Roguelike Development Conference earlier this year I opened with a talk entitled “The Roguelike Renaissance”.  The premise of the talk was simple (though likely too over-simplified for art buffs) – that the current wave of new and innovative roguelikes is akin to the Renaissance era of art, full of new ideas and optimism, as opposed to the Dark Ages that came before.  The Dark Ages of roguelike design were characterised by ancestor worship; the belief that everything had to be Nethack++, that the old games and mechanics were best.  In the Renaissance period we have ditched that philosophy, with new games like DoomRL and Tales of Maj’Eyal showing that we can do better than all that has come before.  We no longer blindly copy designs and feature-sets, we openly question the traditions of the past, and we say “screw you” to those that would proscribe what is and isn’t a roguelike.  This is a fantastic atmosphere to design games in, and I think it’s one of the reasons why Roguelike Radio has proven popular – we are free to question and conjecture to our heart’s content, and after breaking through the shroud of the past the space for novel game ideas has proven huge.

How strange it seems then that our ASCII-centred community can feel more forward looking than our mainstream and indie cousins!  It is a question of audience perhaps, as Michael concludes in his blog.  We roguelike devs with our free and open source games don’t care too much about audience, at least not as far as finances go.  Having said that, roguelike audiences do still flock around the older titles and traditional mechanics.

The new versus old is an important debate.  And it is versus.  We can enjoy and be inspired by old games, but we shouldn’t think they are the future as well as the past.  New works are important, new ideas are necessary.  We absolutely cannot just copy the crafts of our predecessors.  We can do better than that!  This notion that the classic stuff is better is ignorant and narrow-minded.  There is always room for improvement, we are capable of being better than those that came before us, and if we are to stand on the shoulders of giants then we can reach to different areas than they did.  This is the spirit of the Renaissance that we must embrace.

I hope the more mainstream community can pull itself away from this recent ancestor worship.  A ray of hope may be that the only real Kickstarters Success Story so far has been the innovative and popular roguelike space sim FTL.  There is still excitement for new things out there, and new generations of developers coming up with ideas others cannot dream of.  Our own works may prove as inspiration for the youth of today, and if they grow up surrounded by the spirit of constant innovation and improvement then they in turn will surpass us greatly.

Tags: ,

Hate Random, Love Procedural

November 14th, 2012 5 comments

As roguelikes and games with roguelike mechanics get more mainstream success I’m seeing a bit of backlash against what is termed “too much randomness”.  I’ve seen a lot of this directed against FTL, but also against The Binding of Isaac and complaints of it in the latest X-COM.  Yahtzee wrote a good article on the topic earlier this year, and Craig Stern recently wrote in great length about the failings of random mechanics.  But I think it’s vital that we distinguish between randomised content and procedural content, as although there is some overlap the end implementation can have very different effects on play.  And for developers it’s important to understand the role of procedural generation, and why it’s not the same as “just random”.

I’ve always hated random mechanics in games.  Missing a weak enemy twice in a row because you got a bad dice roll can really ruin the feeling of a game.  Plus some developers seem to think having the ability to run thousands of dice rolls means they should have insanely complex systems that require intense study on a turn-by-turn basis to assess the probabilities.  If you need Wolfram open to figure out how many attacks on average it takes to kill that monster then likely the battle system is badly designed…

Chaos Plane in ADOM

This is random…

Dice rolls were popularised with D&D, where rolling that d20 and praying for a 17 or higher was part of the tension and the fun.  But a good DM knows that letting the dice rule the game is not so fun overall.  When role-playing you don’t want to be thinking about numbers all the time, and random chance can get in the way of a well-designed campaign.  The essential element of unpredictability should come from the imagination of the players.  However this history of dice in Dungeons and Dragons has made its way into many RPGs, with a lot of fantasy roguelikes in particular using numbers and dice ranges lifted straight from the Player’s Handbook.  Whilst drawing inspiration from their favourite sources they also blindly copied over these poor features.

I don’t want to get too much into why I hate randomness, especially when the two articles linked above go into plenty of detail.  If you’ve played Risk you probably know all the reasons.  Go play Small World instead and you’ll see how much more fun a deterministic system can be.  Feeling in control means you don’t feel cheated by the system, and you properly respect the winner for their skill in attaining victory.  Importantly in single player games a deterministic system means you have only yourself to blame for failure, and you are forced to learn to be a better player instead of blaming the game.  Instead of thinking “I’ll get lucky next time” you think “I’ll make better choices next time”.

I do sometimes use randomness in games though.  It has its place in providing variety, and in also giving the player the option of taking a risk on something.  Usually in my games when an option is open with random chance it’s a high risk, high reward decision; it’s part of my philosophy that power always has strings attached.  But when present it’s usually entirely optional – the default action is the deterministic one – and the chance of failure is made clear.  Another good (or at least acceptable) application of randomness is in providing bonuses instead of failures.  The assassin’s 1 in 4 chance of paralysing an enemy in Dungeons of Dredmor for instance.  You know you can’t rely on it, and you always feel good when it kicks in, yet it doesn’t dominate the play.  But I’m very much against randomness overshadowing the outcome of player choices.

So why do some games make heavy use of randomised results?  To stop them being linear puzzles, predictable from the very get-go.  To prevent you feeling secure in what’s going to happen next.  But this is where procedural content generation comes to the fore.  And it’s important to both consider how it creates content for the player, and for how that content changes over time (AI).

It should be stated loud and clear that procedural does not equal random.  It tends to use a random seed, yes, but it builds upon that intelligently to produce *interesting* content instead of just random content.  A perlin noise map is very different from a procedurally structured forest map populated with enemies, items and quest goals.  Your level generator should be more than just a form of terrain mapping – it should be its own AI, a designer following a ruleset with some random initialisation to produce varied content.  The rules and design it follows should produce intelligent and interesting content for the player that goes far beyond simple random patterns.

Jeff Lait's Smart Kobold

…and this is procedural – Jeff Lait’s ‘Smart Kobold’ with intelligent content arrangement

However if one does procedural content badly then it can degenerate into pseudo-random levels.  Unfortunately a lot of games using procedural techniques use them weakly.  Dungeon generation is separate from monster placement, which is separate from item placement, and monster and items tend to be spread randomly across the level without consideration for the player experience.  This is really not taking full advantage of what a well-designed procedural generator can do.  Of course writing such a generator is far from trivial…

But even poorly implemented procedural content is better than pure random.  It sets limits to ensure the game is completable, that the challenges can be overcome or avoided.  Floodfilling to ensure dungeon connectivity for instance, or restrictions on monster spawning to prevent them appearing next to the player – simple touches that make a big difference, removing the chance of perceived unfairness from the game.  A procedural generator provides a more structured experience, with patterns that the player can come to recognise and take advantage of / game.  It ends up forming part of the game rules that the player is working with and against, an integral part of the play.  And of course there’s the element of surprise – the turning round the corner to find something you haven’t prepared for, and thus having to react to the circumstance in novel ways.  This is different from a string of random misses in a random battle system, as it doesn’t take away any sense of entitlement and still leaves you feeling in control of whatever situation arises.

Procedural over time is another area that’s under-developed.  AI is a big part of this – mobile units that react to the player’s actions and present their own challenges.  These can introduce the complexity of interactions that normally other players add to a game.  Good AI is also tricky, but even simple behavioural patterns can create the components for emergent complexity.  What there really isn’t enough of though is procedural changes in the level over time.  A dungeon that reshapes itself, that reacts to your presence or the movements of enemies, can create an engaging environment to explore and forces you to constantly reassess your tactical surroundings.  A few examples of this are the ice levels in HyperRogue, the sand dungeon in Tales of Maj’Eyal, and the rather crazy dynamic levels in my own UNSTOPPABLE.  There can be more detailed control of content over time, like the famed AI Director in Left4Dead, and I’m hoping we’ll see even more novel stuff in future.

PCG for me has always been about crafting a player experience that is fun, engaging, and of course different every game.  Randomness, on the other hand, I find is rarely fun or engaging, and often ends up feeling very samey over time. One game of snakes and ladders feels very much the same as any other, and if you keep staring at perlin noise maps they quickly lose their novelty.  A really detailed procedural system can not only generate compelling content, it can also react to a player’s actions, crafting a uniquely tailored experience which only that player will ever see.  Achieving that is far far better than a string of natural 20s.

Rogue Accessory

August 2nd, 2011 Comments off

I was going through a department store and my girlfriend pointed out something which she joked that I should buy. Much to her chagrain I bought it with delight:

Rogue accessory

Yes, it’s a large wooden @ symbol. Not sure why such a thing was for sale in a department store, but upon seeing it I knew I had to have it. I’m not really one for home decorations (being a bloke and all) but this now has a proud space on my shelf. Next to it is a small toy I saw one time that puts me in mind of a baby grue. Yes, I’m a geek… :)

Tags: ,

Trapper: Director’s Cut

September 11th, 2010 Comments off

A new version of Toby the Trapper is ready! Download it here:

Currently only includes the windows exec and source. If anyone on Linux or a Mac can compile it with FPC on those platforms and send it to me I’d be most grateful. [Edit: Have Linux exec included in package now.]

There are various changes, including speed optimisation, rebalancing, more enemies and a lot of little tweaks. Enjoy!

Halfway point

March 9th, 2010 Comments off

Well, can’t say the game is half-finished, but in terms of real-time hours I’m around halfway through.  However I anticipate having more time than I’ve had so far on Friday/Saturday/Sunday, so hopefully all will go well.  Some notes I’ve been taking as I go along:

   9th March 18:58: Well, gave up on that message handler at around 2am.  I'm
      sure if I had more time I could get it running, but it was too much for
      my weary head and I don't have the time to sort it out properly.  For
      now I'll stick with the KISS philosophy (Keep It Simple, Stupid) which
      has always served me well.
   Update 19:42: Got my very bsic message looper worker perfectly.  I love it
      when I think up an idea and then I find it works exactly as I had
      planned... it's a rare event.  Next step - test out digging.  After that
      I'll finally get some ogres on the loose.
   10th March 01:27: Added diging and a bunch of other stuff.  Got rather
      sidetracked actually - added in the menu display for traps and the gems
      to be collected to open up new trap types.  Traps can't actually be laid
      yet though, and more importantly there's no enemies to use them on.  I
      will have zero time for coding till Thursday, and not much time even
      then, so I really hope I can get a lot of work done during the last hours
      of the weekend.  Implementing enemies may turn out to biting off more
      than I can chew...

Progress ahoy

March 9th, 2010 Comments off

I have a working cave explorer thingummy going.  I can’t get message handling working well, so I’m giving up on it.  Next up is adding monsters, which will turn it into a proper game.  In my lunch break at work I wrote the following background story:

Gadzooks!  Wuggy the Warlock and his gang of ugly ogres have attacked the
tiny gnomish town of Turgylton and stolen the Gems of Power!  Now it's up
to the town's hero Toby the Trapper to venture into the villain's
cavernous lair and retrieve the holy Gem of Life.  But this is no easy
stroll down the mine - the ogres aren't just ugly, they're also big and
tough, able to squash little Toby with a single swipe!  And deep
within the dark lair Wuggy the Warlock and his fiendish friends guard the
Gem of Life with foul sorceries and terrible powers!!
Still, it's not all doom and gloom.  Toby is much faster than the big
brutes and can see better underground too (the dumb ogres can only sniff
their way around, and it's hard for them to smell anything above the
stench of their own ugly bodies!)  He also still has some Gems of Power to
create traps to use against them, and may find more along the way.  So do
you feel up to helping Toby fight these dastardly villains?!  With
Flashers and Bangers and Boomers and Blinders and much more besides you'll
explore varied random dungeons filled with dread and excitement in your
quest to help Toby defeat the wicked warlock and save his tiny town!  Let
the adventure begin!!!!!

For the curious you may also wish to see my development notes so far:

7th March 23:44: 0.0.1.  Ported code from The Lion King and Gruesome.
Includes dungeon generation of a few cave types, LOS and moving
around.  LOS should work out of the box, rest must be properly
tested and tweaked.  Many worries.
Update 8th March 02:41:  Got everything working after a lot of fiddling
and silly sleep-deprived errors.  Need to make some code adjustment to
how the last level is generated, but otherwise extremely happy with
results.  Also may wish to tweak some colour schemes, but that's not
immediately important.  Next up is message management, wall-digging
and properly implementing enemies, none of which I've done thoroughly
before.  How exciting...
8th March 20:31: No time to work on it today.  Just spent a few minutes
tweaking the map generator so that the final level is more selective
about layouts that are too spartan.  Thinking of adding something to
encourage loops in levels, but no need for it now...  Will try and
find time to get stuck into the real mechanics of the game later.
I've now labelled it 0.0.2 - it's a stable cave explorer with different
level themes, essentially.
8th March 23:55: Gonna play a little with a message handler, but if I don't
get far then I'll just give up.  It's not important enough to waste
much time on.

Anyway, on with the coding…

Once upon a beginning…

January 28th, 2009 16 comments

Hi, and welcome to “The Adventures of a Newbie Roguelike Dev”, a weblog featuring articles from a beginning game designer. I call myself a newbie because my programming skills are very poor – I have no knowledge of pointers, file-handling or OOP and have yet to implement basic game mechanics like AI, pathfinding and items. However, I have released a game, and quite a fun one at that, in spite of its simplicity (or maybe because of that). It’s called Gruesome, and you can find it here. Give it a quick try – you might just like it.

This blog will sporadically feature update and development notices about this game and others I have planned, but more importantly I intend to write a few articles about my experiences in taking up programming and game design. Aspiring developers may find it a source of inspiration, or maybe even a warning of what not to do. Experienced developers may find it a fresh take on conventional ideas. Overall though I hope it’s simply enjoyable to read, as I try to tread lightly past the hazardous pitfalls every developer must face: bugs, procrastination and over-ambition.