Archive for the ‘Design’ Category

7DRL start: A Wall Of Souls

March 5th, 2017 2 comments

My favourite week of the year is back :) This year I’m making a game that in many ways is similar to last year’s The Trapped Heart. ‘A Wall of Souls’ is about a lone knight trying to free his Queen from some nefarious force (exact plot still being worked out). The knight will have a number of “soul shields” following him, and being cut off from the shields equals death. Enemies will have ‘soul points’ that look similar to the shields from The Trapped Heart, but this time the way to kill enemies is to surround their soul points – ie. position yourself, your shields and walls to cover up those sides of the enemy. An enemy with 6 shields needs to be fully surrounded.

That’s the vague plan of the game. In addition the shields themselves will have mechanics and abilities attached to them, and there are more to collect over the course of the game. And a bit of meta-gaming I’m playing with is that every time you die you leave a statue of yourself, which can help restrict the environment in future games.

This will be the first game in which I play with a hunger clock – over the course of the game you will gradually get slower, so that what were once easy enemies are suddenly going faster than you.

How well this all works I’ll have to find out. And how well I can explain this to the player will also be a challenge…

Best of luck to everyone taking part! I look forward to all the cool and innovative new roguelikes I’ll get to play in a week’s time :D

DataQueen – 7DRL Success

March 23rd, 2014 6 comments
DataQueen screenshot

Destroy the gridbugs, protect the data!

Last week I completed DataQueen, my 4th successful 7DRL. It’s a hex-based roguelike with a number of unique mechanics that makes it very tight and tactical without ever feeling too overwhelming. The feedback I’ve received has been immensely positive, so I may work on polishing this more (and have had the generous offer of someone drawing a tileset for the game). You can download the game here:

[Edit: Note there’s currently a little bug when you first run it that might make the game hang. If you restart the bug disappears forever. Yes, I’m confused too…]

The big concept I wanted to try in the game was from the board game Hive, where you only die if you get surrounded. This seemed like a cool idea to port to roguelikes! So enemies can’t attack you directly, and movement is very important.

DataQueen combat screenshot

You can set up several attacks to trigger at once.

At the same time you have a wheel of special abilities called the “hex wheel”. For each hex direction you move in you have a special attack that hits in that direction. You can gain new hexes and place them on the wheel as the game progresses. This gives a range of tactical options all tied to just the movement keys. Every turn the wheel spins, meaning you have to plan moves and positioning if you want to chain attacks together. The abilities have all been designed to combine in interesting ways, encouraging the player to make multi-turn attacks.

Movement itself is made more interesting by giving you free movement on green grids. This lets you reposition yourself for different attack directions very easily. Moving onto blue grids converts them to to green, but enemies will do the opposite, quickly eating up your useful tactical space. This cuts across all the mechanics in the game and adds a lot of tactical depth. To progress you need to connect pink grids up with green grids, so the war with enemies is mostly one of terrain (and not dying).

DataQueen upgrades screenshot

Upgrades! The UI artwork was done by daftigod.

The base enemies all have unique abilities which can challenge the player. Most enemies die in one hit, but they can be a huge problem in mass numbers. Each level there is a boss, and each of these requires special tactics to overcome. It makes for a challenging game that hopefully never feels unfair.

I’ll be doing a developer Let’s Play video of it soon, talking about some of the design choices and how the game operates. For now you can hear me discuss the game a bit on the latest episode of Roguelike Radio, alongside discussion of lots of other cool 7DRLs! Let me know if you have any comments about the game, and anything you’d like to see changed – feedback is hugely appreciated.

Anatomy of a Procedural Music Engine

June 15th, 2013 Comments off

At IRDC last week I gave a presentation on the procedural music in Mosaic, and it’s about time I put it online. I’ve also updated the game itself a bit, with WAY better sounding music and some enhancement of the player powers. You can find the latest versions here:

Here are the slides from the presentation itself (pdf, 1.68MB). But they won’t make much sense on their own, so here’s some notes to support it:

  1. Introductory slide with the @ symbol / treble clef combo that was at the heart of Mosaic.
  2. Proteus was an influence with its procedural music. In particular it made me want to make a game that was beautiful.
  3. Tonematrix was another big influence, a sequencer you can play in your browser. The grid and the on/off switches made me immediately think of a roguelike where you move around the space and control it. Hence Mosaic!
  4. So I had this idea of music based on the grid, and the player wandering about, and it fused with a bunch of others ideas about creativity and procedural art, and so Mosaic was born! I spent most of the week on the look and the mechanics, but come the last day I knew the time for music was near…
  5. …But I didn’t know anything about music. So, with about 7 hours left before the end of my 7DRL week I went to Twitter and asked the important question – how the feck do I make music?!
  6. Michael Brough, magical indie dev extraordinaire, responded in good fashion with a hint towards the “pentatonic scale”.
  7. To Wikipedia! Except none of this musical terminology makes sense…
  8. Some further reading down the page and I’m still confused, but I pick out a string of notes – ACDEG. I think right, I’ll try these notes out!
  9. But first I tried a bunch of piano notes and shoved them into the complete game engine, copying Tonematrix pretty exactly.
  10. Er, it worked, but it didn’t sound fantastic. The notes didn’t go well together, it all sounded messy. Tried a bit more with xylophone and harp, and there was some improvement. So, new idea, how about a whole orchestra?
  11. Firstly I got a load of notes from the Sonatina Symphonic Orchestra – a really great resource! Creative Commons notes for almost all instruments – here’s the torrent file.
  12. Next I looked up Pachelbel’s Canon in D.  Y’see it wasn’t an entirely new idea, I’d thought before that an ultra cool thing to do would be the Canon in D procedurally. This was a more advanced idea than just a Tonematrix clone, and now was the time to try it out. The actual music terminology was beyond me, but I looked at the note sequence and saw how they moved in wavy lines. So, right, wavy lines, lots of notes – can’t be that hard, right?!
  13. I assigned instruments to different lines of Mosaic, with the trombones as enemies. There’s a deliberate set up to this – harp and bass are at the top and bottom as these tend to get turned on a lot. The brass notes for enemies are deliberately distinct from the strings from the grid. This isn’t just random, it’s procedural!
  14. And wow, just wow, it sounds good! I was amazed, truly amazed, that with bugger all knowledge I had quickly managed to cobble together something that worked and sounded pretty decent. I got different feedback on this, mind – some people said it sounded fantastic, others that it was utterly awful. Turns out it depends very much on how you play, which is in itself a cool feature!
  15. Now the code, which is beautifully simple. This has been reorganised since 7DRL week but is basically the same in function. Every 0.25 seconds a tonal_shift is set – which way the notes should go. This is balanced towards small shifts, but can have a whole 5-note shift on the pentatonic scale (so a whole octave). The code looks along the current column, and on each tile if level = 1 (meaning a coloured tile) then it plays the corresponding note for that tile – self:playNote(i,1) (the 1 just means volume = 100%). It does the same checking for enemies and plays trombone notes if present – playNote(11,1). The pulse references are just for graphical effects to show notes being played. The playNote() function, not shown, decides whether that instrument follows the tonal_shift or goes its own direction, and does some admin-type stuff on pitch changes to meet the pentatonic scale – this is much better now than on the original much more note-limited 7DRL.
  16. Since the 7DRL week I’ve had lots of ideas for procedural music tied to gameplay. Sounds that are based on the environment and your interactions and events in the game. Sounds that are altered in a number of ways based on the numbers in the game. Roguelikes are especially suited for this, as using plain mp3s gets really repetitive. There’s a lot of potential here! I hope to explore this more in future.
  17. Lastly, some advice I’ve received from various sources, and a few things I found out myself – especially the last point. Music really is a deep rabbit-hole to dive down. If possible avoid this and fake things as best you can!

I wrapped up by then playing a bit of Mosaic live, which seemed to go down well enough.

I hope some of this is of interest and helpful to others! Was a lot of fun, and it’s still cool to muck about with. Rogue Rage in particular has a lot of potential for application of procedural music. Have a go yourself – it may seem intimidating, but it’s very cool when you get it working!


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!

Rogues and Heroes

May 10th, 2013 5 comments

One thing I like about roguelikes is that they are not about heroes. Well, they can be, some are centred around a heroic quest, with the player eventually taking up the mantle of heroism. But whilst most may involve heroic deeds they are not in essence about the hero story that plagues so much of modern gaming.

Rogue Epyx box art - a thief seeks an amulet in a dark dungeon

The original Rogue box art from Epyx emphasises the depowered nature of the game’s protagonist.

The Hero is the chosen one, the powerful one, with some special abilities that give him (almost always a him) superiority to his foes. He goes through the game undefeated, conquering all trials before him, and eventually slays the evil dragon and rescues the princess. Or perhaps his loved one was killed and he seeks revenge against the evil sorcerer that also happens to be threatening the world. Or whatever other cheesy male power fantasy trope you want to choose. I personally hate these stories – they are boring and usually laden with misogyny.

The Rogue is different. He seeks to steal an item and escape with it. Instead of climbing a tower he descends into a dark dungeon. The creatures he defeats are not a threat to the world outside, they’re just obstacles to his end goal. Some of the creatures are too powerful to defeat and have to be evaded or run away from. The Rogue gets hungry, gets scared, gets debilitated, and most importantly gets killed. He or she is not the chosen one, oh no, for many men and women have died beforehand and more will die again.

At the heart of the roguelike story, going right back to the original Rogue, is a subversion of the typical power fantasy. Though the setting may be fantasy the player is not invited to live a fantasy lifestyle. They may have swords and sorcery, but those swords can break and that magic can fail. There is a gritty realism to how many roguelikes play, a simulation of just how a desperate thief in a monster-filled dungeon would feel. You can make mistakes and they are permanent. The game has no pity for you when you die.

Rogue C64 box art, with a muscley man wielding a homoerotic sword. In the background is a bikini-clad lady to rescue.

But Rogue’s C64 box art completely misses the point. Image NOT representative of game content!

And what’s wonderful is that communities accept this. YASDs are frequently far more interesting than YAVPs. Suggestions for game additions often come in the form of new enemies and obstacles rather than new player powers. People invent extra challenges and restrictions to play with that make the Rogue’s journey even more excruciating. Players complain when the game gets too easy.

There are some major exceptions – ADOM and Angband are all about being the hero and saving the world, and you can build supremely powerful characters in them. ToME sets the player up as a hero (albeit with uncomfortable moral quandaries), and even has a “save the girl” sidequest, complete with cheesy smooch of victory. But it’s interesting to note how often people do go back to the original “get an item and come back with it” quest of Rogue, such as in DCSS and Brogue. Or how games like Smart Kobold deliberately frame the hero as being someone motivated by greed rather than adventure. The one Roguelike I know of which specifically has a “save the royalty” main questline is PrincessRL, where you are the princess saving the prince – again a subversion of the popular fantasy tropes.

It may be part of what makes the roguelike experience alien to outside players. It’s not just the poor (or lack of) graphics, archaic interface and unforgiving difficulty. It’s also the way they strip the player of a feeling of power. They don’t pat you on the head and say you are special. This is not a simple escapist experience where you have fun being a cool wizard or warrior. In both the mechanics and the theme of the game this message is repeatedly reinforced. You are underequipped, always running out of resources, always facing enemies that are stronger than you, having to use your wits to survive. You are not a Hero – you are not here to save the day, and even your death may be pitiful and forgotten. You are a Rogue, and the dark places you walk in are fraught with danger.

So go play some Rogue!


Flood-filling for Procedural Wizardry

December 4th, 2012 Comments off

In case anyone is not a Temple of the Roguelike regular, I highly recommend reading through this thread discussing floodfill applications.  It includes simple code examples, discussions of problems/alternatives, and practical ideas on how it can be used for good content.  All excellent brainfood for anyone looking to use one of the best algorithms in the procedural design toolbox.

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: ,

Procedural Tips

November 23rd, 2012 1 comment

So there’s a cool article on now with tips on using proc gen elements in your game.  Maarten Brouwer of procedural platformer Cargo Commander goes into some great details about how to use procedural content beyond just having random elements, but really going into making it balanced and interesting to the player.  Very similar to what I wrote about a few days ago in making the program design the levels, not just randomise them.  Go read the article – it’s got some great insights and practical advice.

A big “but also” I’d add is relating to his first point on not worrying about connectivity.  Worry about connectivity!  Floodfill is a miracle tool that can ensure everything is connected, whilst also being a golden technique for procedurally generating content in interesting ways.  It can be used to make 100% solvable lock-key puzzles for instance.  It can determine the optimum point to place enemies and items, and inform the AI about the right way to behave in that area.  It can detect dead-ends, which can then be removed, looped up, or transformed into something interesting for the player.  Best part about floodfill is it’s quite a simple algorithm at its base, easy for any basic coder to learn.

Some take the attitude that 100% connectivity isn’t important. Personally I think if a human designer would never make such a level, why should an AI designer? There’s no excuses in design faults like this, no matter how much you brush them over. There are a wealth of procedural tools out there to help overcome any design problem, it’s just a matter of using them right.

The Thoughts of a Procedural Level Generator

November 14th, 2012 4 comments

So earlier I blogged about how procedural is so cool and rad, etc, whilst also bemoaning that there’s not enough detailed procedural generators that tie different elements like monster and item placement together.  I’m as guilty of this as anyone else, partly because it’s so much quicker to use simple algorithms, but also I guess because people don’t expect any better.  Well, let’s have a look about how a good dungeon generator might think through the creation of a level:

1. Huh? What? Oh goodness, I oversleep()ed and now I have to crank out a dungeon level. Well, let me think, should I have a theme? Yes! And what should the theme be? It’s deep in a dungeon and there’s not been a forge level yet, so I’ll make one of those, yes? Active forge? Yes. Will there be a dominant monster type? Yes. Population? Orcs. 60% dominance.

2. Okay, let me think openly about the general shape.. .. .. .. .. My, that’s a lot of noise/BSP tree/cellular whatsits! I’ll shape that up here with some heightmaps / room space allocation / edge smoothing / whatever else. Ah, that looks much nicer now! Any extra decorations to shape I want for now? No, it’s good as is.

3. Hmm, better check it all connects together. Got a lovely floodfill for that… And whilst I’m at it I’ll check there are no lengthy dead ends by adding a heightmap to the floodfill and connecting up some of the maxima. Can’t be having our avid adventurers backtracking all the time, after all…

4. Should I have a river? Nah… Lava? Sure! Let’s spill it in the east side, let it burn down some walls, go under this corridor (now a bridge over lava) and carry on south-west. Island in the lava? Okay, and I’ll place a special item there for adventurous types to fawn after. Enemies in the lava? Sure, I’ll throw some fire drakes in. They have a lovely ranged attack they can use on anyone crossing the bridge.

5. Might put a small vault in the north of the level. Keep things connected as it’s placed. What monster type? I’ll follow the orc theme and choose some orc assassins. Artifact reward? Nah. Large gold pile? Sure. Trapped entrance door? But of course…

6. Since it’s a forge I’ll make a large central room into a forge room, with a forge inside and some relevant materials. And an orc weaponsmith, and some goblin slaves. Nearest room will be stockroom. I’ll make it 40% armour, 30% weapons, 30% consumables.  Artifact? Okay, medium grade. And a second low grade too. I should definitely place a guardian here – a nice big troll in fact. Doors to this room are locked – I’ll put the key somewhere else on the level which is definitely accessible from the entrance stairs (ah, floodfill, I love you so).

7. Any other special rooms? An altar in the west will suit. Include some scrolls. And a rabid orc priest. Followers? No, but we’ll give him a pet. Fantastical creature? Sure! We’ll make it a griffon. And I’ll throw in some griffon babies too. Aren’t they cute?!

8. Hmm, there’s a dead-end room in the west.  Any chance of a special item for here? Sure, a special potion. In a trapped chest. Guarded by… mages. Path to the dungeon entrance from here is to the north, so I’ll position them in a defensive formation near the door there, with a healer behind them.

9. Now, in the other rooms we’ll place some orcs and a couple of other creatures, with no more than 2 being higher than base level. We’ll give one of them a wolf pet as well. And in one corridor we’ll put an archer – everyone likes archers in corridors, right?  And a trap there too, but we’ll let the archer know not to trip over that. And we’ll have the archer carry a nice bow and dagger.

10. All done now! As a final touch I shall christen this level “Corpsefire Forge”.  Bon appetit, adventurer!

Looks very involved, yes? Kind of like the thoughts a real designer would go through? But that’s the point really – you want something almost as good as hand-made content, but with on-demand infinite generation and variety.  It needs some coding together and a good pool of input values.  The coding is not so hard as you might think – everything above has been done before to some degree in open source games, so at a push you could copy paste this generator together.  But the hard examples to draw from are a lot more work if you don’t want the same few combinations popping up over an over again.  I guess this is partly why big roguelikes are so popular – the larger content pool allows for greater variety in random encounters.

Some day I’ll make a cool generator like this.  Honest  ;)

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.