Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Monday, 6 February 2012

Sunday Progress

A few really minor features added over the weekend:

  • Mouselook. Trying out an implementation where you can only look around in a limited arc, and having the view direction automatically rotate back to the default when you start moving or turning your character. Not sure on this, might be more useful to have your character's direction change once the view rotates sufficiently. Danger here is that I'd like to have facing be an important tactical concern within the game, so character rotation is a distinct action that you don't want to trigger by accident.
  • Textures! OK, this was a ten minute bodge-job hooking up javax.image.ImageIO to grab JPG and PNG files, and they don't even have mipmaps yet. But it works, and as I have a working DDS export implementation... getting DDS import in place shouldn't be too hard. Then they can even be properly compressed textures with pregenerated mipmaps and all kinds of... ancient, unremarkable technology.
  • Tangents! And Bitangents! I'm just generating these at load-time from the data in the .obj files. I'm fully aware that at some point I'm just going to have to face the Python and create a Blender export script to a more sensible format, but... bleck, Python.


As a consequence behold the power of really, really ugly normal and diffuse maps:

More importantly than all this minor tech progress, and thanks in no small part to the aid of He who is called Fhtagn, the game actually has a design document! And the design is, at least for now, inspiring. It's good to have a direction. We're currently lumping everything in a few shared google docs, which is a nicely asynchronous way of working.

In between writing the code and reducing the inspiration quotient of the document, I've been playing a bunch of CRPGs (I blame finding The CRPG Addict's blog archive). In particular: Morrowind, Wizardry 8, Temple of Elemental Evil, Neverwinter Nights, and Neverwinter Nights 2. Flitting about between these is playing merry hell with my ability to keep track of quests, but the contrast is fascinating.

Tuesday, 22 December 2009

::tap-tap:: Is this thing still on?

Oh! Hi there.

Amazingly, I have been working on this little project. It's been slow going.



The rendering system has been refactored considerably. It is very much still a nasty mass of imperative wrongness, but its also a bit more consistent and less fragile. I've been experimenting with different methods of generating the world geometry. I've tried half a dozen implementations of a game-entity framework, none of which seemed adequate. I added a quick random map generator (screenshot taken from one such random map), and worked on the water shader a little. It looks OK in motion, but definitely needs to be somewhat more obvious generally. Those little divots in the ground are shallow water, the light source being the player (who's mesh has temporarily elected to disappear).

Oh, and I gave Clojure a spin too. Experimenting with the property-bag approach in a Lisp is relatively joyous, especially with Clojure's explicit syntax for hash maps. I found it hard to scale projects up, though. I'm too used to arranging things in terms of objects and classes, both Haskell and Clojure befuddle me with a mass of functions. My failing entirely, the languages have much to recommend them.

I started using Mercurial SCM for source control on this little project. Although I do find myself wanting a P4Win-like GUI front end (which may well exist somewhere), the command-line tools are quite lovely and I refuse to give up on them before becoming at least somewhat proficient.


Now for some design babble. This idea surfaced recently when trying out a few entity and time-handling systems, and I think has some interesting gameplay connotations. Here's the gist:

  • Every turn, collect actions from all agents in the game world

  • Execute all actions, regardless of validity, to produce a new world state. Each agent also tracks the actions that changed it this turn.

  • Resolve the world state by resolving invalid conditions


The third step is obviously the tricky one, but also where the most interesting aspects spring from. The first two steps merely simplify some aspects of mutating the game world.

So this tricky 'resolve' stage... what happens here? Well, take a very simple set of verbs: agents can either stand still, or move one space each turn. More than one agent occupying a space is invalid. If two agents occupy the same space, do some basic conflict resolution and then generate a valid world state based on that. The losing agent could be displaced back to its original position (and also presumably lose some health, in a standard Roguelike game of HP and damage rolls...), whilst the winner occupies the contested space. In the case of a tie, both agents are returned to their starting positions. An agent who didn't move in this turn gets some manner of defensive bonus, but if it loses the conflict will be displaced away from the attacker.

There are immediate problems with this simple method. What happens if another agent occupies the starting position of the losing agent in a conflict? How do we handle three or more agents in a space? What about an agent surrounded by enemy agents, such that no position is valid after losing? Conflict in dead end corridors?

Some embellishments to the system should allow most of these to be resolved. For example, agents could be in a standing or prone state, and not occupy any space when prone. Losing agents with no valid moves can be knocked prone. And so on.

But what do we gain from this approach?
  • Most interestingly, this represents a gateway to yomi, as described in the linked post. As every action is essentially simultaneous, a suitable number of counter moves and counter-counter moves allow for much greater potential depth in conflict. There aren't enough in the simple example above, but it at least admits the possibility. In order to be really satisfying, either the AI behaviour needs to be tractable for the player, or multiplayer might be considered.

  • Strategic positioning - this is a big part of what I'd like to capture in combat. Being able to 'bull rush' opponents is crucial; several character development options suggest themselves to allow more tactical control over the way a battle evolves. This feels a lot easier to approach when all potential movement is handled in a single step.

  • I think this system is less predictable. As everything happens at once, actions are more likely to fail and rather harder to evaluate. Rather than just considering the success chance of a given action, the player must consider all the possible actions of relevant agents that could interfere with its execution. This is a good thing in general.


And what is lost...
  • Agents all move at a uniform speed, or at integer multiples of that speed. We lose the fine-grained ordering of agents based on some intrinsic properties and/or the execution time of actions. All actions take one turn. We can allow for slower agents by forcing them to take null actions except every N turns. In theory we can also allow faster agents by slowing down the rest of the world in much the same way, but that seems inelegant - as many actions will require a graphical representation and time to be displayed, doing this will slow the game for the player.

  • The system is less predictable. Players can no longer easily guess the outcome of an action, as it depends on the actions taken by other agents in the same turn. This could be a bad thing for transparency.


It needs more thought, and the implementation details could get very messy for the semi-mystical 'fix the world' step.

Tuesday, 29 July 2008

Core Mechanics

Design is hard. Design is even harder when instead of focusing on it, you waste time playing a big heap of gaming goodness, but that aside...

For the moment, I'm not (overly) displeased with the technical aspects of my code. I really want to get on and implement some gameplay stuff, get the combat working, stick some kind of character advancement in there. Y'know, nudge it towards being a game. This will probably root out the next crop of show-stopping issues with the code, but it'll be progress.

This is where I'm stuck. Because I haven't thought about the core gameplay mechanics anywhere near enough: they're ill-defined and derivative.

Don't get me wrong, I don't want to go usurping tried-and-tested design decisions for the sake of it, nor do I hold any illusions that the game I want to make is in any way original or revolutionary.

I just want to make sure I've thought about these decisions and made an attempt to cobble together a design that supports the kind of game I want to make.

I'm not exactly a fan of BDUF, and a lot of the motivation behind writing this game is exploration of both the programming language and game space, so I'm leaving plenty of wiggle room. Besides, I'm lazy, and speccing out every little thing is hard.

Nonetheless, I want to have a long hard stare at some absolutely key areas that I haven't addressed fully yet:
  • Character advancement: experience, levels, skills, and other madness
  • Resource pools: health, fatigue, spellcasting resources etc.
  • Magic: a huge topic to be split into more digestible chunks
  • Defense: I've got some ideas about how combat will work from the offensive point of view, but not the other side
So, expect further brain-dump posts about these soon. I'll try to sprinkle some screenshots in between the incredibly boring stuff though.

Hmm, looking at the above list makes me wonder what I do know about this game I'm writing. I'll get back to you on that.

Thursday, 19 June 2008

Attributes, skills, magical items, cake

Attributes and skills are a tricky bunch, of which I've waffled before.

Nontheless, I need some kind of framework to start thinking about these things, so here's the seed. I'm trying for the usual balance between flavour, mechanical clarity and balance, and separation between the attributes tied closely to the host body and those inherant to the servitor.

I think it's quite important that the mind of the host has some influence on the final attributes. After all, the inhabiting spirit is not good at thinking in meatspace. Any actions with a physical component, even casting spells, need to be processed by the physical brain and body. Any accrued memories - less those burned out by the process of possession - will also be vitally useful to the emissary.

Physical attributes
  • Brawn - strength, endurance, explosive muscular power and general burliness. Contributes to melee damage, especially with heavy weapons, damage reduction (natural and from armour/shields), health and fatigue pool size.

  • Grace - agility, dexterity, speed and accuracy of movement, stamina. Contributes to hit checks with melee and ranged weapons, dodge and block/parry checks, stealth skills, attack speed, fatigue regeneration rate.

Mental attributes
  • Wit - Speed of thought, depth of perception. Contributes to reaction speed, ranged hit checks, casting speed, damage with ranged and light melee weapons, resistance to mental attack.

  • Lore - Accrued memories, ability to apply knowledge. Contributes to all crafting-type checks, casting checks, all identification checks (including things like combat styles, spells being cast, and all the usual stuff).

Spiritual attributes
  • Empathy - how well the spirit meshes with the host flesh. Affects how much magic can be safely channeled through the body, resistance to mental attacks, health regeneration rate, speed of recovery from debilitating effects on the body (poison, nausea etc.).

  • Comprehension - sensitivity to the flows of the spiritual/arcane. Affects perception and identification of magic, and creatures of spirit (whether possessing a mortal body or not), as well as casting checks and speed of recovery from debilitating effects on the mind and spirit (curses, magical debuffs).

Creatures without attendent emissary spirit will have zero in the last two scores, which should make generating them somewhat easier. These are only rough ideas of course, things will be moved around, renamed and generally made to work. The split of abilities and bonuses, assuming everything else is balanced and, erm, implemented, looks like a reasonable start.





On the subject of magic items

Was pondering magic items whilst walking home from work. I think I'm going to rip off Talislanta because it is awesome and win.

You can have seven active magic items on your person at a once, any more than that and they all stop working. Most items will be considered active if you're wearing or using them, so having stuff in your backpack doesn't count. Likewise consumable or items only used briefly don't affect the total (in most RLs, these would be potions, scrolls, wands etc). The reason for this is simply that active magic flows through the mortal plane, and interacts... oddly. Having too many active items would have nasty side effects in addition to rendering them all useless, but those wouldn't be exposed immediately.

To make things more interesting, certain items will be active all the time, even if you're just lugging them about. Diable II (and possibly the original) had these, although I can't remember what they're called. In said game(s) they took up lots of inventory space, but were otherwise just passive, stacking bonuses exactly as if you'd found an extra inventory slot somewhere. Artifacts or items of similar crazy power will act like this, although depending on the nature of the item you may get no benefit from not using it, it'll still count towards your total, and possibly count as multiple lesser items. This should make 'retrieve the all-powerful maguffin!' quests a lot more... interesting. Anyone up for a naked Amulet of Yendor run?

There may be certain ways to get around these restrictions, with side-effects. For example, items with identical effects might be worn and count less towards the total, although any bonuses do not stack perfectly and there will be nasty things happening if this is done for any length of time. Sure, you can wear three rings or regeneration for a few weeks, but how are you going to go to parties with that atrophied spare arm dangling from the small of your back?

Wednesday, 11 June 2008

A database, a database, my select * from Kingdom for a database


Databases make me all tingly, in a nice way.

Finally started using SQLite in the main game. There's now an attribute database as a kind of test for the concept, covering skills and inherent attributes. The nice thing about this so far is that it's very easy to modify at runtime, as I have a debug console command that allows for arbitrary query execution.

My current thinking is that attributes will be very simple. An attribute has a name, any number of parent attributes, and some information about whether untrained (score = 0) usage of the attribute makes sense.

My test DB has a grand total of 7 attributes for testing. These aren't sensible or final in any way, shape or form, obviously. I'd need to design things for that to be the case, and I'm allergic.

Anyway, the core test abilities are strength, dexterity, agility, plus melee, ranged base skills. All these are used untrained with no penalty, and have no parent attributes.

spear_ranged and spear_melee are more complex. They have a small penalty to untrained usage, and have as parents ranged, dexterity and melee, strength, agility respectively. Finally, there's the atlatl skill, which has a very large untrained penalty, and has spear_ranged as a parent.

So a skill check is currently absurdly simple. You provide the name of the attribute, and the DB interface turns it into a list of that attribute plus any parents. 'Character sheets' are just basic String => Int tables, so for every attribute in the list its value is looked up in the character sheet. Any missing or zero entries are considered untrained, and so may have penalties or result in automatic failure. All the scores are summed to give a final attribute total, which then goes on to the Core Mechanic for resolution.

I'm not sure this is actually going to work for a full-scale system, though. I'd originally envisaged something more complex, where various attributes contribute in a weighted fashion, skills had a more fully developed hierarchy and objects could have unique attribute requirements.

Thing is, I really like the simplicity of the current system. It means you can examine a prismatic obsidian blade in your inventory and instantly know which attributes and skills will affect your efficiency with it, and by how much, because everything is handled in the same way.

Likewise distributing experience in a 'doing stuff increases attributes used' system is simple; just split the XP earned evenly among all attributes in the list. This has the pleasant inherent property that 'deep' skills will be harder to train and will increase 'core' skills more slowly.

Downsides... unique items that interact with attributes in fun ways are harder to implement. An artifact blade that uses the wielder's intelligence, for example, just doesn't fit. Perhaps more importantly, deeper skills automatically have larger scores. This could be fixed by simply using the mean rather than basic sum of all attributes I guess, without compromising the transparency too much, or by taking great care when constructing the skills themselves. More thought needed here, as with pretty much every aspect of the game so far...

Monday, 19 May 2008

Themed magic

That was a very pleasant week away from work, largely spent indulging in gaming.

Unfortunately this included quite a bit of WoW. Sigh. I thought I'd kicked that habit for good.


Regardless of my recurring bad taste in MMOs, one particular design topic has been nipping at my hind-brain all week. As the title subtly hints at, it's magic.



So magic in many (computer) games is very dull and... non-magical. It's functional, reliable, and generally quite boring. People have written very nice stuff on how to make magic more magical, and I'm letting some of those ideas ferment too, but one seemingly simple concept I'd like to see more games explore is the idea of themed magical skills/schools/whatever.


Of course, almost every game has this to some degree. Fire and ice seem to be incredibly popular (thanks, Blizzard), and just generally elemental themes are rampant. There's nothing wrong with that, but it doesn't exactly offer much in the way of flavour any more. A far better example of what I'd like to see would be Dungeon Crawl's concept of magic. Despite my apalling inability to play them, I just love Transmuters. They get really weird spells, and use odd resources in addition to the generic mana pool - sticks and corpses, at low levels, are a staple.


Mesmers from Guild Wars are similarly fun in some ways. Although the relentless balancing act required for the PvP aspect of the game exerts a subtle homogenising force on all classes, there's still some flavour to be had. Mesmers work largely through indirect action, an underexplored area of fun in most CRPGs.



Anyway, here are some ideas.



Somatomancy

Somatomancers (I'm not at all sure this word is a valid construction, but what the hell) are the warrior-philosopher archetypes. Their magic is all involved with their bodies, and the perfection thereof. They also branch into meditation and similar ways to encourage perfection of mind/soul and unification with their flesh, etc. etc. fluffwaffle. Almost all somatomancy spells are buffs, and the main resources for casting would be 'focus' (a measure of how well the caster can direct magical energy within his/her body) and some analog of chakra points. Somatomancy spells are intimately tied to certain parts of the body, and there's some kind of experience dependant limit on how many can be maintained in a given location, focus constraints aside.


Somatomancers would have abilities such as self healing and cleansing the body of toxins and disease. Their spells would cover areas ranging from making themselves faster and stronger, to hardening their skin, channeling magic through their unarmed attacks, warding their minds from attack by magic/spirits and protecting themselves from the elements. Eventually of course, the search for perfection must lead to far more interesting abilities, such as growing bone spikes, claws, additional appendages, chintinous plates, toxic spit or a venemous bite, and so on.



The way of the tentacle

Yes, the name is very silly. I can't think of a better one right now. This random bundle of 'whu?' all cascaded from an extended thunk on Black Tentacles (full name omitted for WotC reasons), a wonderfully useful spell from D&D. This school of magic is based around the idea that a metaphor for the magical realm is an ocean, with deities as vast floating islands trailing toxic awareness. But the sunlit zone is an insignificant fraction of the sea, and the primitive life of the abyssal ooze is where the Way finds power. The Way revolves around bringing this base vitality to the material world in a Lovecraftian squirm-fest. Tentacles burst from the ground, rock squirms and pulsates underfoot, the walls grow articulated claws. Wood collapses into primordial muck, and cilia writhe in dark places. The Way is basically themed around summoning, but of non-sentient entities thoroughly grounded in non-living matter.

Wednesday, 7 May 2008

Further thinks

Gothic III again. Just pondering it from a graphical point of view this time. I've always appreciated the 'clutter' in the Gothic series, especially in wilderness areas. Much like Oblivion, there's a certain mushroom-picking joy to be had wandering around in the pleasantly lush undergrowth harvesting herbs, berries, fungi and the occasional wolf pelt.


But more interesting is the shape of the world. Unlike most games, Gothic's landscapes aren't simply a heightfield with a few meshes stuck on top, but actual 3D models. Soaring cliffs, overhangs and caves are an integral part of everything, and contribute hugely to the epic feel of the landscape.


Of course, going this route is not without it's problems... I'm quite sure the pipeline for authoring the world is painful, and certainly in Gothic II there were several areas with missing/broken collision data, or where diligent leaping and bounding could land you somewhere devoid of world mesh data and let you fall into the infinite blue void. Equally, it's hard to recall a game with landscapes that look and feel as interesting to explore. Knowing that the edge of a precipice may hide an overhang or gully replete with monsters or treasure is far more interesting than the confident extrapolation of a heightfield.




Does this mean anything to the Roguelike? I don't think so. From a gameplay, presentation and implementation point of view, the heightfield approach is a hell of a lot easier than some arbitrary topology, especially with a discrete grid for movement. I'd like to clutter up my dungeons with undergrowth, rocks, roots and suchlike though, so maybe that's the easiest thing to take away from the Gothic vista.

Tuesday, 6 May 2008

I live!

State of the Snut

Eh, long hiatus there. I'm trying to keep this more up to date than previous efforts, but... well, I'm easily distracted.


I'm still working on the Roguelike, but I'm marginally stumped as to the direction of the AI now. Although the planning prototype worked after a fashion, as soon as the number of planning actions started creeping higher the complexity and space requirements of the planner became silly, even without allowing for such simple things as predicted enemy moves or group interactions.

One option would be to severly limit the maximum plan length, to maybe four or five steps. This is adequate for most simple action chains, such as move to and pick up ammunition, reload weapon, fire at enemy. As the number of actions grows, the plan length could be a limiting factor, and we still have on the order of 5N plans to consider.

Limiting the number of actions available to a given enemy would be very helpful. In some cases, this would make perfect sense. Less intelligent enemies will have a smaller set of actions available fairly naturally. For more seemingly intelligent AI, something artificial must be introduced... perhaps a core set of essential abilities, plus a random subset of all the advanced options would work.


There are some other issues with the design and implementation, of course. I need some motivation or inspiration. I think adding some pretties might help get me out of the code slump, although it's not useful in the grand scheme of things.





Current distractions

Recently I've been playing a load of Dungeons & Dragons Online. It's a strange game. It's nice being able to create varied characters, and develop them in strange and not necessarily optimal ways, whilst having some idea of how the mechanics and system work. I like D&D well enough that I can overlook the Eberron setting, which is merely broken. There are some hard choices that were made to adapt the game to realtime, online play, and on the whole I agree with a lot of them. On the other hand, Turbine have made massive strides to completely break certain aspects... the equipment is vastly out of whack with what 'should' crop up in a D&D game at equivalent levels, and the entirely synthesised-for-DDO enhancement system has some scary issues. Skills are vastly less useful in general, and there are few of them implemented. Prestige classes don't exist except as a few scattered enhancement tack-ons, which only works for a few PrCs anyway - namely those without interesting class features. All told, classes are far more pigeonholed, twinking is quite destructive and rampant, and monsters end up with vastly inflated health, saves and AC to try to keep up. At level 16 (the current cap) the average monster has on the order of 450 hitpoints, going up to a thousand or so on Elite. Very silly. And yet I keep coming back to it; possibly this is simply down to the lack of decent MMOs out there. Other than DDO, the only one that's held me for more than a few weeks have been WoW and Guild Wars. The latter because of overall superlative design and the former because... um... I don't know. I doubt anyone knows. I'm thankfully over that particular addiction though, for now at least. I'm not sure what GW would have to add to lure me back into regular play, but I'll be keeping one eye on it


Gothic 3 Has also been tempting me recently. The learning curvecliff is brutal, as is much else in the game. In particular, the combat has me thinking about some of its oddities. For those blissfully unschooled in the pain of close combat in Gothic 3, the most effective technique I've found so far is a kind of relentless assault. The main reason this is so effective is quite simple - whenever you take damage in combat, your attack is interrupted. The length of the interruption is approximately the same as the time between swings for most melee weapons. Essentially, if you get hit even once in close combat, it's frequently Game Over... but if you keep battering your opponenent, you force him (<aside>there are a dearth of females in the Gothic universe, especially this installment, and most especially female combatants are notable by their complete absence</aside>) perpetually off balance and are pretty much assured victory. Against intelligent foes with weapons, it's possible to mix up the attacks with defense and some marginally complex attacking, but against most animals the only way to not die is to keep hacking and not allow them time to recover. This death spiral effect means that:


  • Multiple opponents are to be feared. Although as part of your attack you actually force your opponent back (and move forward yourself), it's quite possible for an enemy to sneak behind the arc of your swings and hit you from behind. Once knocked off kilter, everything moves in from the kill and it's time to reload. Three goblins can be a lot more scary than a single elite orc warrior, even way past the time such creatures become 'trash' to be steamrollered in most games.

  • Forcing opponents into corners/against walls is valuable. Especially animals that have no method of blocking, and so dodge backwards to try to evade blows. Being cornered is deadly.

  • A group containing even a single archer is many times more effective. Arrows will mess up your attacks just as surely as a sword, and are very hard to avoid whilst in melee.


I'm still not very far into the game, but these are the things I've noticed so far. Combat's fairly visceral and terribly unforgiving. Whilst this almost binary combat does feel a bit too random to be entirely comfortable, it's definitely a different approach and adds a lot to the feel of the Gothic series. Combined with the distressingly long load times, and combat isn't something to be trivialised here. Despite many awkward and clunky features, not to mention the occasional annoying bug, I'm still enjoying it hugely for these reasons and the general feel of the game.



BioShock doesn't really warrant commenting on at this stage. The theme is lovely, although the linearity is a bit galling after so long in more open games.


Heroes of Might and Magic V has some niceness. I think the 3D adds considerably to the charm of the game world, although the camera is a PITA in the world/adventure map it rarely needs to be fiddled with. Turn based combat is wonderous!

Monday, 10 March 2008

Belated title edit

This blog has languished of late. Between being ill (damn colds); looking for a flat; and my native bone-idleness taking over much of my time; it's fallen by the wayside.

I must confess, over the past weekend I've also been indulging in Dwarf Fortress and DDO. It's research, damnit!

The (still un-named) roguelike does ooze forward, however.

Setting

After a great deal of deliberation, the mesoamerican theme has won out. I've got some reference material, and there are so many shiny possibilities inherent that all the other setting concepts seemed quite underdeveloped in comparison.

The first race to be constructed will be based around the Maya, Olmec and Aztec kind of area in mundane history, jazzed up a little to be generic-fantasy-race (bee-lizards!) rather than boring ol' humans.

I'm very tempted to further abuse the setting, and pull it forward to steampunk level tech. This might be poorly suited to a Roguelike, however, so I'll probably put that on hold and go for an easier tech level: primitive but with medium/high magic. The first race will have little access to metals, for example. But who needs iron when you've got a magically hardened axe of green obsidian?


Theme

This needs more focus. The basic mechanics are shaping up relatively well, but I need to find more ways to support the main themes of the game. Not sure how this is going to work, yet. Due to the desire to have lots of combat kicking around, thematic stuff may be largely present as world flavour (especially magic) rather than in the core rules. This seems a bit of a wussy approach though.


Code

After a desperately needed refactor, the code base is a lot nicer to mess around in. I've been prowling unproductively around some rendering and world generation issues, but in the meantime the planning AI is shaping up well and the engine basics are looking a bit more coherent. Prototype modules such as the console and database wrapper are migrating into a game-worthy state. Hardly exciting stuff, but very useful.

Currently, I'm most excited about the planning module. It's quite general at the moment, manipulating any object that represents a world state. My test code uses a list of string-int tuples and has actions that do basic addition, subtraction, multiplication and division on the ints. You hand it a start state and a goal state, and it generates a list of actions that get you there (or in the case of a failed attempt, a list which get you as close as possible).

It's not admissible, and to make it more suitable for interesting responses it has a bit of random weighting, so it's not guaranteed to produce an optimal plan. But doing the optimum thing all the time's dull anyway. There are some big question marks still remaining over how the goal state is generated, but those bridges can be crossed later.


Random thoughts

I've seen a few people of late postulating that the goal of the AI should be to act out the role expected by the player, i.e. to do something interesting, fail, and die horribly. I've also heard it said that games which procedurally generate encounters will always be inferior to scripted fights because there's no designer in the background saying "Oh, what if the Foozle turned out to be the player's long-lost aunt? That'd be cool!" and pulling the strings.

Recently, I think I've decided that both these standpoints are bollocks, at least as far as my taste in games is concerned.

  • For the first, how devastatingly crap is it when the almighty villain makes schoolboy errors in executing their dastardly plan? Especially when they're supposed to be superhumanly intelligent masterminds! What is this, a Bond film? I want a nemesis who tries its damnedest to kill the player, using every last erg of its strength and every scrap of wiles I can throw at the AI. At least beating it will be a genuine achievement rather than some preordained thing. Good AI is certainly no panacea, but it seems a lot better than artificial amateur dramatics.
  • In the second case, it's more a question of taste, genre and the competence of the designer, but my main objection is that often these 'cool ideas' are forced upon the player. If in the first encounter with the Foozle you pull off an amazing feat of violence and completely slaughter it, there's little more annoying than the good old Cutscene and Badguy Escapes To Fight Again! because the designer didn't want you to kill his or her personal baby. Not yet, anyway. That wouldn't be cool enough. What's not cool about killing the Evil Overlord when you're level 2?

Friday, 22 February 2008

Brute forcing a solution

Combat.

It should be fun. That means it should be interesting. That means there should be choices, and those choices should be meaningful. It has to last long enough that choices can be made on the timescale of a turn based game. It has to be short enough that it doesn't degrade into a boring repetitive action. Ideally, a tough fight should see both participants gain and lose the upper hand a few times before one eventually emerges victorious.

Not a particularly easy problem.

As a small step forward, I wrote a little simulator that brute-force optimises combat stances for a particular flavour of opponent. The results are, well, I wouldn't say interesting, but they give a concrete starting point.

The results are split into two categories:
  • The first tries to optimise for efficiency i.e. maximising damage dealt for a given energy (time) budget. This kind of stance represents the optimum for battles of attrition - versus a horde of small things or one immensely tough creature.
  • The second tries to optimise for speed in terms of actions (turns) i.e. the minimising number of attacks to dispose of a foe. This should be ideal for dispensing a slow stream of foes one-on-one, where killing something in a few hits and moving on is preferable. This is how most action in Roguelikes seems to take place, during dungeon exploration.

The attacker has a fixed attack skill value, whilst the defender varies in both defense skill and damage soak. In these contour graphs, soak is on the x-axis and defense skill on the y-axis (bottom left is 0 skill, 0 soak).

The bland blue colour is 0, whereas the brighter turquoise is 1. Red-yellow-purple are approximately evenly spread between these extremes. The big flat blue areas in the top-right of the charts represent areas where the soak/defense prevented damage entirely.

Yep, they're horrible and noisy, and I really hate Excel. So much. Especially this hideous '2007' offering. That aside, it's helpful to see the problems with my current implementation.

The most obvious issue is that speed is useless in these scenarios. There's a fringe case for efficient slaughter of creatures with negligible defense and armour, but really that's a tiny local maximum. Damage also appears under-represented, especially in its intended niche of fast dispatch, although this is not as badly nerfed as speed. Accuracy therefore dominates, especially as soak and defense increase. The latter is desirable, but after poking around I suspect the former is not.

So my current thoughts are to increase the effect of speed across the board, remove the armour-piercing quality of accuracy, and slightly increase the effect of damage on the overall calculation. Implementing a less crude optimiser and some way to visualise the data without using Orifice would also be nice...

Tuesday, 19 February 2008

On the nature of weapons...

A quick discussion with that most ominous source of Great Game Ideas turfed up this little concept, which I record here for posterity. Or myself after having slept and clean forgotten.

Weapons in RPGs typically have a big pile of attached stats. In the shoddier systems, these are basically a disguise for a ranking from 'small, bad, cheap, use only for rats (small ones)' to 'big, expensive, the only things you'll ever use after level 3'.

Clearly weapons should be different, but equally clearly most weapons also evolved to fill a niche. Some are certainly easier to make and so cheaper and more commonplace. Still, the best designs will stick around, and cost is not commensurate with utility in all circumstances.

Not all reasons necessarily work for all games, mind. A bog-standard roguelike such as mine is unlikely to find a use for the easy concealment of a dagger or bladed fan. Even so...

Right. Combat will be based around a system heavily purloined from Zir'An, because of the aforementioned mechanical elegance of it. Combat will further use the three (or more) weighting system. Characters select from speed, accuracy and damage at present. I think weapon variation slots into this by providing bonuses and caps for certain axes in this kind of system, plus additional bonuses.

For example, the humble dagger provides a bonus to speed and accuracy, but places a cap on the damage axis. Not this doesn't prevent the dagger dealing X damage, it merely limits how much of a preference you can express for doing damage in your combat style. It also provides some less direct bonuses - you can use it in a variety of situations where a larger weapon is ineffective (prone, grappled, etc.), it works well as an off-hand, it can be thrown, it takes up minimal space so you can carry many of them, and certain special combat actions are available with one. It's hard to use defensively.

A generic sword is a more balanced and flexible proposition. A decent number of special attacks are possible, it makes a reasonable defensive weapon, no particular restriction on combat style and so on.

A rapier is similar to the dagger in that it provides a lot of flexibility and bonuses to speed and accuracy, probably additional bonuses to a lot of dueling-type maneuvers, and so on.

Axes and hammers are harder to use in an accurate or fast manner, but definitely dish out the damage, and so on. Staves are good for defense.

It's starting to look like each weapon will have potentially three bonuses and caps for the primary style axes, plus some kind of 'tactical use' data. Special combat maneuvers can probably be broken down into a few groups depending on the weapon types and combat styles that can use them (bladed, blunt, piercing, large, small), plus there may be some that are exclusively available for only some specific weapons. Armour penetration is a fiddly bit in the current nebulous cloud of planning, which I'll return to after beer.

Initially, the bonuses/caps will be a good start, and if all weapons have a place based solely on that then it'll make sense to balance the tactical advantages of each.

Now, armour penetration and stats-for-combat... think think, think think...

Addendum: Penetration seems like it belongs with accuracy. The weighting system splits up your attack action somewhat, and also handles how success points are spent. This leaves speed in an awkward position though...

I think an example might help me work this stuff out. I'll assume 9 points are available as 'float' in the attack calculation. An exactly balanced stance and weapon provides 3 each to the accuracy, damage and speed weightings. This might translate into a +3 bonus on the attack roll and a 9% decrease on the
energy cost (speed) of the attack, plucking numbers purely from the air. The attack yields 12 success points, again split equally. When determining the effect of the attack the points translate into, um, 6 points of armour (soak) negation, and 4 points of bonus damage.

The obvious flaws in this system come through in lightly armoured, hard to hit things and heavily armoured, easy to hit things. The former you either miss lots or waste a lot of penetration for little damage, the latter you waste damage because of lack of penetration. I guess both can be gotten around by dropping speed though. Hmm. I need to try this with some more realistic numbers and a copy of Excel...

Monday, 18 February 2008

Attributes - background waffle

Via the wise ramblings of the Rampant Coyote, I came across this interesting discourse on attributes in (C)RPGs.

This got me thinking about things. Sloooowly of course, because I'm dumb, but thinking regardless. One thing I'm keen to experiment with is making all attributes useful in some fashion, and all combinations of skills and attributes, well, as far from stupid as possible.

So here's a long, rambling pile of waffle loosely related to attributes. Especially how they should work in a single player, single character, combat-heavy, turn based, randomly generated RPG. What can I say, I have specific needs.


Attributes: What the hell are they anyway?
Attributes in most CRPGs suffer from being a terribly mixed abstraction.

On the one hand, they represent basic inputs to the game mechanics. For the average test, most games seem to favor some variant of skill+attribute(s)+dice roll. Sometimes the size of the dice depend on the attribute rather than it being explicitly present, sometimes the skill isn't really a skill, and in d20 you mangle the attribute pointlessly to generate some half-arsed bonus from it rather than simply using the damn thing as-is. But in any case, it has an often visible and direct influence on the result of tests.

But on the other hand, they often have an altogether more narrative and character-driven role. They're named for qualities we value, and can readily identify in the heroes we hope the character will join. Strength, dexterity, agility, intelligence, perception, wit, endurance... even pure jammy luck.

This tends a cause a big mangled mess, because these attributes are so obviously tied to feats in the real world that they end up assigned to associated tests in-game. Of course, these are rarely distributed evenly. The vast majority of important actions a character might take will end up clustered like freezing penguins around a scant few attributes, leaving the remainder in the cruel katabatic chill of 'dump stat' status.

Once the narrative and mechanical concerns get tangled, it's fairly tricky to sort out. Picking attributes based on game mechanics is transparent and easy (or at least easier) to balance, but can feel clinical, dull, devoid of depth and flavour. Picking attributes that resonate with our heroic fantasies frequently creates a mish-mash of derived, secondary and tertiary attributes, and great swathes of illogical or poorly distributed actions. It becomes hard to reason about which choices are quantitatively better than others, both for the designer and the player. Strange caps and level dependencies are introduced in an attempt to duct-tape the whole thing into working order. WoW presents an excellent example of this kind of system gone completely bonkers.

So, are there any games or systems that got it right in this regard? Only a few come to mind.
  • SPECIAL from the Fallout games seemed remarkably close. It was quite hard to find dump stats for any character, to me a good indication that the attributes have been well-used. Not bad, really. You were granted some leeway by the secondary characters you acquired, though.
  • Guild Wars used purely mechanical attributes, and went further than most by making them profession specific. Add to this the ability to freely change attributes between combat areas, and the whole package worked rather well. Unfortunately all the campaigns hit the level cap fairly quickly, so beyond your initial choice of primary profession and the short ramp up to max level, there's really little in the way of permanent character development. To be fair, this wasn't and isn't the focus of the game, but it makes it hard to evaluate the effect of such an attribute system in the context of a more traditional RPG.
  • Games which deviate strongly from human baseline can often use a more abstract, artificial system. Even though I hope they all explode from shame, a few White Wolf products make a fair job at this. Sometimes. The dot thingy still blows chunks, but anyway. The assumption here is that the character's can do pretty much anything a human could even remotely expect to accomplish, so the only attributes of interest are those involved with strongly superhuman qualities. This puts them safely outside the terrible reach of 'common sense', and therefore they're subject to being fiddled until they work within the game, without even giving the illusion of modeling the real world.
  • If my brain worked, this would be a longer list.


The archetype that doesn't fly
There's an issue that rolls around in RPGs, and that's how infrequently the agile, fast guy is a wise choice compared to the big slow bruiser. This kind of contrast is a staple in fiction, but it rarely works out sensibly in games, at least in part because of the way attributes commonly work.

I did originally have an enormous spiel about my beliefs regarding why this so often doesn't work, but the upshot was mostly to do with timing so I'll save it for a later post.

With respect to attributes, this is probably just a very pointed example of how a narrative influence doesn't even necessarily support key clichés in the kind of stories they often want to tell.


Snut makes a considerable effort to get back on-topic
Pondering on the issues of chained actions. We think of some things in RPGs as being discrete events, such as a single attack. But what really happens often boils down to at least two tests. One to see if we hit the target, and another to see if we affect it. Sometimes this latter is more about magnitude than a simple all-or-nothing, but over time the result is much the same. Sometimes the first test influences the second, such as a critical hit in a d20-based system, but they're still rather distinct.

This presents an interesting knot, because often attributes will influence both tests. A large bonus to either end of the sequence is of less use than medium-sized bonuses (boni? Nah) at both testing points. Combat-based tests may have additional effects too. Does a poisoned blade do anything if you don't overcome the target's soak? What about a magical flame effect? If you miss the initial to-hit type roll, is there a chance of hitting another nearby target?

Going back to an earlier point, attributes which influence both ends of the equation frequently become overpowered. Strength in d20 is an incorrigible repeat offender in this regard.

As I've no desire to puzzle through the convolution of a two-attribute curve by some peculiar random number distribution, it seems to make sense to combine these two steps somehow. A wonderful game (The Secret of Zir'An) presents one option for doing that, although by itself it translates poorly to a roguelike implementation. In a nutshell, an attack is an opposed test as we're all used to, but every point the attacker beats the defender by is available to spend on various combat effects. At the most simple these allow for increased damage or armour penetration, but they scale to include all manner of fun options, disarming opponents or blinding them, trips, throws and generally being evil.

Zir'An still has a (flat) base damage for weapons, mind. Taken to the logical extreme, where damage is entirely dictated by the level of success, this kind of simplification might exacerbate some problems with combat munchkinism. In most current games even if your foe's basically guaranteed to hit you every time, you can still hope for minimal damage, and in fact the 'death by a thousand cuts' routine rather mandates accuracy and damage be distinct.


Implementation? Maybe?
A few things that have been decided about this game (still unnamed, I need to fix that) which could help in designing an interesting and workable attribute and skill system:

  1. I'm drawing a clear and inviolate line between mental and physical attributes. This is a fairly obvious result of the nature of the player character. I'm also thinking that attribute increases through level advancement (or whatever) will alternate between these two subsets.
  2. It's a roguelike. Or roguelikelike. It's all about survival, combat, traps, treasure, random stuff and inevitable, bloody death. In addition to being an inhuman soul-sucking immaterial monster, there's no real reason to be good at making chit-chat with the meatlings anyway, as they're only there to be killed or point you to the next dungeon. And maybe sell you some overpriced tat. Hell, there may not even be non-hostiles for several game iterations! So social attributes and skills can bugger off, and I don't need to worry about trying to make them less dump-statish.
  3. There will be no humans. Even the creatures not inhabited by servitors of the uncaring gods won't need to be realistic in the slightest in their stat block, because the comparison with humans will be speculative at best.

Of course, there's also cloud lurking in this argent glow:

  1. Monsters, especially intelligent NPCs, must be easily auto-levelled by the game - including attribute increases. Random generation should also be possible. As far as I can tell at this stage, this will boil down to making attributes as evenly spread as possible. I place no great faith in the ability of my monster generation code, or the fairness of the RNG, so it's quite likely that really broken statblocks will come wobbling into view. They don't have to be equally dangerous, of course, but the more evenly spread everything is the less work the AI will have to do to at least make them interesting, if not effective.

Sunday, 10 February 2008

Natural terrain

More OpenGL wrestling occurred, but eventually I bent it to my will and managed to get VBOs working.

The dungeon now has a floor and ceiling that varies in height, and a very rough first stab at a continuous mesh:


Now, there are many things wrong with the implementation so far, not least of which is the lack of textures and shaders. Those will require me to gird my loins and head back into the terrifying world of the GL. No, perhaps more fundamental is the way solid areas (natural rock in this case) are represented. Right now I did a quick hack and pulled the terrain up to mimic the effect, but this causes nasty artefacts thanks to the stretching of polys and is far too restrictive. A different approach would be needed for crafted walls.

I'm thinking a better approach will be to create a separate wall mesh by extruding the lines defining a change from solid to traversable terrain. There are some big potential problems with this, and another method is still required for constructed rather than natural areas, but I think on the whole it's a win. It also reduces the amount of geometry to be recalculated when creatures dig or destroy walls.

So the basic dungeon components are looking like:
Floor/ceiling - heightfield, possibly with discrete mesh tiles (flagstones)
Rock and ruined walls - extruded continuous mesh with procedural variation
Worked walls in good order, unique features - discrete meshes, possibly welded together.

A new map format will be needed soon. The .txt map generator is beginning to look a bit under-featured, especially for representing material differences. It may still be the first step in map creation though, as I like how easy it is to check the output.

The heightfield meshes still need to represent material variation (rock, sand, vegetation, pebbles) and there may be additional mesh layers (water, lava, ground cover). So much to do, and as ever so little time...

As an aside, my rough thoughts on combat with height variation:
Melee - if the attacker is half a tile-width or greater above the defender, attacker is at +1*. If half a tile lower, attacker is at -1. Height differences equal or greater than 1 tile prevent both standard movement and melee attacks.
Movement - movement uphill takes more energy than moving on a flat, and movement down less. I think this'll cap at around double/half cost for the max gradient. Maximum gradient for movement without a 'climb' action is 45 degrees. Non-climb movement down a slope >45 degrees counts as falling, and will cause damage roughly proportional to the height difference squared. There will be rules for falling/climbing on inclines that are greater than one tile wide.
Ranged - projectiles deal increased damage and have increased range when fired from an elevated position
LoS - high tiles may block LoS, depending on height relative to player and 'interesting objects' (monsters) in potentially hidden tiles.

* Where +1 is a small attack and damage bonus. Possibly +1d4 to both - it depends on the exact mechanics for combat and stuff, which are currently not defined...