Room generation - part 1

This post is all about how the rooms are created randomly in LOTWK.  It’s a pretty extensive subject, so I’ll divide it up into two meaty posts, instead of one giant one.  The first step for the room generation in LOTWK is to create the room shape, which we do by placing the floor tiles.  The result of this first stage looks something like this:

The floor tiles are placed based on some descriptors in the XML data files.  These descriptors set out some simple factors such as how many blocks of tiles to place, their approximate size, and any limitations on where and how to place them.  The details are pretty dull, so I’ll just throw in this example XML and you can pick it apart yourselves:

<room name="test room">

                <mainBlock width="12" height="12" />

                <block1 width="8,8" height="10,10" count="1,2" angle="180,180" tag="x" />

                <block2 width="3,3" height="10,10" count="1,2" angle="180,180" startType="previous" />

                <block3 width="8,8" height="4,4" count="1,1" angle="90,90" startType="tagged" tag="x"  />

                <block4 width="6,6" height="4,4" count="1,1" angle="90,90" startType="previous"  />

                <block5 width="2,4" height="2,4" count="4,8" startType="random"  />

                <columns1 width="2,2" height="2,2" count="1,3" buffer="3" />

                <templates1 category="furniture" count="4,12" tags="normal,desks" />

                <templates2 category="furniture" count="4,12" tags="normal,benches" />

                <templates3 category="loot" count="1,4" />

                <templates4 category="decor" count="5,15" />

                <templates5 category="structural" count="1,5" />

</room>

                As you can see, there are a series of “blocks” elements, and it is these that describe the approximate shape of the room.  Each location theme (snow caves, forest, dungeon, etc) will have a large variety of room styles described through XML “room” nodes, so that a noticeable variety of rooms exists, instead of them all being hewn from the same cloth.

                The next phase is to throw in the walls.  This is pretty straightforward – because the room is tile based, determining which tiles should become walls is a simple matter of finding floor tiles with empty tiles adjacent to them.  Corner wall tiles can be identified in a similar way.  This results in something like this:

                Gah!  What’s with the six bajillion lights on the walls!?  This is how LOTWK determines where to place wall-torches and other wall-mounted light sources.  Each wall segment is a template (a group of objects) which gets placed.  This allows for things like paintings, banners, torches, and all other manner of objects to sit neatly aligned with the walls.  Because the walls can be any shape, a system that tried to automate placement of objects on walls would result in a lot of ugly clipping issues, or worse, floating objects!  So we use a template grouping approach, where templates are randomly placed for each wall segment, including wall decoration and lighting.

So the next phase is to clean up all those extra lights.  This is dead simple – the game iterates through the lights and deletes those that are too close together.  The end result is something like this:

Next up we need to fill in dark areas.  These dark areas are created because there are no nearby walls, and therefore no wall-mounted light sources to fill the darkness.  So let’s place some floor-based light sources.  And while we’re at it, let’s also extinguish a few of the existing light sources to add a little variety.  The result looks something like this:

The room is still very barren though – it’s just walls and light sources.  It needs some furniture.  This is achieved in a similar fashion to the wall placement – it uses template groups of objects and tries to place them around the room.  An example grouping might be a writing desk, which would consist of the desk, a chair, the quill and ink, and perhaps some scrolls of paper.  These items are all grouped together in a template data file, so that the game engine can then attempt to place them all together up against a wall.

This brings me to the real power of the template system – placement types.  Each template group has a placement type variable associated with it, which tells the engine how best to place the template in the room.  These types are things like “up against a wall”, “in a corner”, “in open space in the middle of the room”, “between two walls”, or “tucked away in an alcove”.  By only allowing a template to be placed in a specific fashion, it prevents weird situations like a bookshelf sitting alone in the middle of the room.  With some furniture thrown in, the room looks something like this:

(note, the game is still early in development, so there is not much furniture to place yet, and so the room is still quite barren with only a few rotting desks and some pipes on the wall)

The final stage of room generation is to make the room look a bit prettier.  This is done through floor patterning and edge bordering.  Floor patterns work much as object templates, but instead of a group of objects, it’s a group of floor tiles which get placed around the room.  The bordering is where the game detects the tiles that run alongside the walls and makes them into nice border tiles, which makes the room look like it was designed rather than thrown together using a random number generator.  The result of the floor additions looks a bit like this:

And there it is; a room with stuff in it and torches on the walls.  What more could a band of psychopathic, money-hungry adventurers ask for?

Next time I’ll go into the specifics of how monsters are selected for placement in the room, and how the game will try and balance the room layout with the type and quantity of monsters.

The data driven approach

What is the data driven approach, you ask?  In a nutshell, it means using information instead of code.  There are many places in game development where you re-use a lot of the same basic mechanics and build up variations through small changes in the data.  For example, the difference between a male barbarian and a female barbarian would be small stat changes, a different mesh, and a few other changes like name and the noise s/he makes when hurt.  The actual code that handles all these aspects does not change, all that changes is the data.

To thwack or not to thwack

               This post is going to be delving into the murky depths of the melee combat system inside Last of the Warlock Kings.  I really wanted the melee In the game to be more than the rubbish standard you see in so many RPGs and turn based games.  You get a basic swing of a sword, and a basic pain animation plays in the target.  Or worse still, you miss, but the same attack animations play out and your sword goes through the target character – what sort of a miss was that!?

To automate or not to automate

This post will be about a very simple thing to implement, but which can save a lot of time - data automation.
   
    The biggest hurdle to a game like Last of the Warlock Kings is the sheer amount of 'stuff' you need to put into the game.  When you combine this with the data driven approach (a necessity when you want to make the game very mod friendly) you quickly find yourself making a ton of data files, all of which share a lot of the same content.

To think or not to think

    This post will be delving into the journey from mindless inanimate characters to one of slightly stupid, artificially minded characters.  That's right, it's AI time!  Read all about it after the break (there's even a video for you lucky, lucky people!).
   

To effect or not to effect

    This post is going to talk about how the game uses a very generic form of script to provide effects or actuators on a wide variety of objects, performing a wide variety of effects, for a minimum of coding.

    Following on from the previous post where I discussed abstracting the myriad of actions available to the player, this discussion is about the same type of abstraction, but applied to a different game mechanic.

    Think, if you will, of a character in the game.  Let's say it's a smelly little goblin called Bog.  Bog, in the heat of battle, has been struck with a multitude of different magic spells - he is slowed down by a cold spell, he is on fire from that stray fireball, and his sword is currently heating up rapidly because of that damn fire witch!  Each of these effects require the code to change a different aspect of the character.  The slow effect needs to reduce movement, and the fire effect needs to apply damage over time.  The heating-up weapon means soon poor little Bog won't be able to keep hold of his sword and will have to drop it.  To code these up would normally be a bit of a pain in the backside, because they are three very different results, but there is a better way!

2Abstract || !2Abstract

    In the last entry, I talked about the multitude of actions that a game like this needs, and how it's difficult deciding what to cut and what to keep.  I then mentioned the term 'abstraction' and how it can help expand the number of actions available to the player without significantly increasing development time.  Now I'll delve into abstraction and what it means for game development.
  
    Abstraction is a somewhat nebulous term, and can be used to mean a variety of approaches within game design and development.  In this case, I use it to mean a kind of separation between objects and their interactions, and a move away from specific actions to a more generic form.  For example, one action can be used on many different items, without the need to code many different responses.

To do or not to do

    There are a LOT of possible things for players to do in a game like this.  A LOT. (not to be confused with an alot).  For one simple example, imagine a character opening a chest.  This simple action has many possible permutations - the chest might by booby trapped, it might be locked, it might be empty, it might be full of riches, it might have a vicious creature inside it, the chest itself might be a sentient being called Barry.  The list goes on, but that's not the end of it.  Every action has its own permutations and subsequent actions to consider.

    If it's locked, the player might pick the lock, or they might bash the lock, or they might have a spell to unlock it, or they might have the key.  If it's booby trapped, they might try to disarm it, or they might choose to deliberately trigger it and take the hit, or they might back away and try to trigger the trap through ranged attacks, or they might have spells to disable traps.

    Suddenly the simple act of opening a chest has many different potential actions, each of which must be accounted for in the game.  The problem as a game designer is which actions do you leave out?  In a perfect world, the player would be able to do everything to anything.  In the real world, there aren't enough hours in the day or enough coffee in the pot to make that happen.  You have to make hard decisions and cut one or more actions in the interests of actually finishing the game before the world ends (which I am assured is any day now).

    Now add into the mix the problem of player expectations - some actions are very common in games and to leave them out would result in many players being confused or annoyed that they cannot perform that action.  Then consider that every action you add creates future expectations.  If the player can bash the lock on a chest, they should also be able to bash the locks on other containers, and on doors.  The decisions required for a game like this are incredibly complex and nuanced - far more than most people might realize.

    Fortunately there is an 'out'.  A way to include many actions at once, without hurting future expectations and without having to leave out many at all.  This option is called abstraction, and I shall go into technical detail on this subject in the next entry.

To cliché or not to cliché

When creating an RPG game set in a classic swords-and-sorcery style of world, there’s a distinct problem that arises – that of originality.

On the one hand, I want to be as original as possible when it comes to creating characters, monsters, worlds, and adventures for the game.  I would love to just let my imagination go wild and create the weirdest stuff ever conceived without powerful hallucinogens.  The other side of the issue is one of familiarity; players need a certain amount of commonly known characters and themes to be able to quickly feel at home with the world.  If the world I create is too unusual, too bizarre, then players will take much longer to adapt to the settings and concepts of the world.  I would be risking alienating people who really just want to see a wizard throw a fireball at a goblin.  Unusual and unique is great from an artistic point of view, but at the same time I want players to feel like they know the world and how it works without a lot of unnecessary exposition and hand-holding.

Ultimately, I’ll be trying for a mixture of the two; a selection of the normal and the trans-mundane.  I have a strong desire to put unique and unusual characters into the game, and do not want to limit myself to just the normal fantasy tropes.  Yet I do understand that those tropes go a long way to making a swords-and-sorcery RPG popular and likeable.  Clichés are important.

To wait or not to wait

One major drawback to using a third party engine such as Unity3D is that the developers are always teasing you with the promise of future features and upgrades.

There you are, at the beginning of the long road to creating a game.  You plan out your game, start developing it, and then they drop a blog-shell – a blog post talking about all these shiny new features they are going to implement real soon... honest!  So you’re left asking yourself the question:  do you develop with what you have available now, or do you put parts of development onto the back burner in the hopes that the features will come along in a timely fashion?

Part of you really wants to wait for the new stuff – partly because it would make for a better player experience, but mostly because the promised features usually involve more efficient ways of working, which can save you heaps of time.

At first the answer seems like an obvious yes – wait for the new stuff and make a better game in less time.  The problem is the Unity engine is constantly evolving, and improving.  As soon as you get comfortable with one feature set, they promise more, shinier features in an upcoming release.  You end up stuck in a perpetual state of learning new features and systems, only to be trumped by the next promised bounty.

At some point you just have to say to hell with it, and start developing to a specific version of the Unity engine, and try your best not to read the Unity blog.

To toon or not to toon

A very early decision for the game was this:  Do I make it cartoon style silliness, in the vein of the Munchkin card game, or do I opt for a more traditional, semi-realistic fantasy setting?

I’m sure a lot of people would immediately answer that question with “cartoon silliness!”.  The obvious thought is that you can do anything in cartoons, plus it looks more interesting.  Originally, this was my thought too.  However, as I dwelled on the idea more, I started to realize that cartoon styling is actually quite limiting.  Realism won out because, bizarrely enough, it allowed me more freedom than a cartoon world.

Welcome

Welcome one and all to the new developer diary blog for the upcoming game 'The Last of the Warlock Kings'.

The game will be a deep, tactical, turn-based party combat game set in a dark fantasy world.  The player will control a band of mercenaries-slash-adventurers-slash-heroes, as they attempt to fill their boots with gold, and if they get to kill the evil tyrant warlock too, then that's a nice bonus.  The game's biggest features are:

• A procedurally generated world, vastly different every time you play through.
• Procedural loot, items, and enemies, meaning no two encounters will be the same.
• Large randomisation of player characters, equipment, encounters, quests, and more to keep every play through feeling fresh and challenging.
• an emphasis on player advancement, with a deep and very permeable skills tree, unique to each of the many playable characters.
• A unique triple-staged advancement system, allowing you to tailor your party to your needs.
• high levels of crafting; create everything from weapons and armor, to new potions, unique bombs, unusual traps, new spells, new enchantments, and more.