Unifying monster and player races, some thoughts

**Nick** · January 7, 2009, 13:08

Originally posted by CJNyfalt

First, what I would like to change in current *bands is that the engine threats monsters and the PC differently, which makes separating the engine, the UI and the AI a bit harder than it could be. Ideally it should not matter at all to the game engine if it's a player or a monster turn. This is of course a huge task, so let's take a look at other reasons to see what to work on first.

Maybe not that huge a task. Instead of a main game loop which gives energy, processes the player, then processes monsters, then repeats, you just give energy, then process everything in order with enough energy, then repeat.

Second, I want to have ways to befriend and tame different monster races. Where each race would have several attributes of opposite types: hot-cold, living-undead, .... Continuing close contact with a certain type would give the player bonuses with that type while making enemies out of monsters associated with the opposite type.

I like this.

Now, I'm not certain how to start, yet. However, a good starting point of discussion would be to take a look and discuss how a player race is defined in vanilla:

At the other end of the spectrum, there is the Posband monster description:

Code:

# N: serial number : monster name
# G: symbol : color
# I: speed : hit points : vision : armor class : alertness
# W: depth : rarity : maximum mana : experience for kill [ : unique ]
# B: attack method : attack effect : damage
# S: spell frequency | spell power
# S: spell type | spell type | etc
# F: flag | flag | etc
# Y: unique artifact index
# D: Description
# [player body info]
# L: base level : evolve level : evolve monster 1 [ : 2 : 3 : 4 : 5 : 6 ]
# E: class to emulate + 1
# A: str:int:wis:dex:con:chr:base_ac:max_ac:base_speed:max_speed
# C: dis:dev:sav:stl:srh:fos:thn:thb
# c: bare:edged:hafted:polearm:axe:sling:bow:xbow:throwing
# M: hit die : infra : spell stat
# K: weapon:bow:ring:amulet:light:body:cloak:shield:helm:glove:boot
# O: flag | flag | etc
# P: level : mana : name : fail
# P: ...
# Z: corpse weight : corpse base name

N-D are fairly standard; the interesting stuff is in the body info:

Code:

# === Body information ===

# These attributes are applied to player, when he possesses or evolves
# into the monster.

# 'L'  Levels.  The first number is base level, and the second is
#      evolution level.  These are used to calculate the gradual
#      AC/speed bonus.  For example, if "L:20:30" is specified,
#      and AC range is 40...60, then at level 20 or less player will
#      have innate armor class of 40, at levels 21-29 it will gradually
#      increase, and at level 30 or more it will top at 60.
#
#      When the player reaches evolution level, and the body is his
#      native (i.e. he isn't just possessing it), he may evolve.
#      Up to 6 new forms are possible.  Their indices must be specified
#      after the first two fields.  If there are two or more choices
#      available, the game will prompt player for the new form.

# 'E'  Class to emulate.  Some monsters, normally various humans ('p'),
#      when possessed, will grant player all the normal abilities of
#      some class.  Class index from p_class.txt must be specified
#      in this field.  This will override a number of other attributes.

# 'A'  Attributes, in order: STR, INT, WIS, DEX, CON, CHR bonuses;
#      min and max AC; min and max speed.  AC and speed bonuses will be
#      assigned from the given range, according to player's current
#      level (see 'L').

# 'C'  Non-melee skill bonuses, in order: disarming, magic device,
#      saving throw, stealth, searching, perception.  Two more fields
#      can be specified: melee and ranged weapon skills.  These are
#      deprecated in favor of individual weapon skills; see 'c'.

# 'c'  Melee weapon skills, in order: barehanded, edged weapons, hafted
#      weapons, polearms, axes, slings, bows, crossbows, throwing.
#      If no weapon slots are available, these skills are irrelevant
#      and the game will display "N/A" in the character screen.

# 'M'  - Hit die.  This is the only relevant hit die; base hit die
#        from p_race.txt and class bonus from p_class.txt should be zero.
#      - Infravision x 10ft.
#      - Power-casting stat index (STR=0, ..., CHR=5).  Irrelevant if
#        no powers are available.

# 'K'  Slot ("limbs") information.  Number of slots, in order: melee
#      weapons, ranged weapons, rings, amulets, light sources, body
#      armor, cloaks, shields, helms, gloves, boots.  The total number
#      of slots should not exceed 22.  The game currently assumes
#      that one and only light source slot is available.  No other
#      assumptions are made.  Multiple melee weapon combat is possible.
#      Wielding >1 ranged weapon is possible, but the player will need
#      to choose one when firing.

# 'O'  Flags, similar to "object" flags.  See lib/info/hacking.txt for
#      more information.  Some object-specific flags do not make sense
#      here (like BLESSED or LIGHT_CURSE).

# 'P'  Powers.  Up to 22 (or is it 23?) 'P' lines are possible.
#      Fields are: level required, mana required, power name
#      (see powers.m4 source file) and failure rate.  Failure rate is
#      currently zero for all bodies and powers.  Perhaps this should
#      be changed in the future.

# 'Z'  Corpse.  First field is corpse weight, in 0.1 lb.  Second is
#      corpse displayed name ('&' will be replaced with article and
#      '~' with pluralization suffix).  Corpses are internally defined
#      as objects with tval=85, sval=0, pval=race index.  Template for
#      this tval and sval should exist in object.txt.

This is a kind of expanded player info; maybe your monster/players shoudl be somewhere between the Vanilla version and these.

There is then the question of whether you give the player innate attacks like monster blows, etc.

Posband certainly illustrates that this is doable; I think planning it out like this from the start is an excellent idea.

Another thing to consider is what to do with monsters I class a "vermin". (The other classes would be "sentient" and "animal"). These are monsters that are very ill suited to be both a player race and a player pet: molds, mushrooms and worm masses. My own thought on the subject would be to threat the non-moving mushrooms and molds as features and/or traps and to remove worm masses.

I would leave them all in as non-playable, non-tameable monsters.

**CJNyfalt** · January 7, 2009, 16:02

Originally posted by Nick

Maybe not that huge a task. Instead of a main game loop which gives energy, processes the player, then processes monsters, then repeats, you just give energy, then process everything in order with enough energy, then repeat.

Well, I was more thinking about things like using the same melee system for both player and monsters (more about this later). Still, your suggestion is an useful generalization.

At the other end of the spectrum, there is the Posband monster description:
<snip>

This is a kind of expanded player info; maybe your monster/players shoudl be somewhere between the Vanilla version and these.

My biggest issue with the Posband way of representing the data, is that it's spread around in the monster.txt file, making it harder to edit and get an overview.

There is then the question of whether you give the player innate attacks like monster blows, etc.

Well, I'm a bit unhappy with how the whole melee system is working. I feel that player weapon attacks, martial arts and monster innate attacks should become unified in some way. However, this is something for the future. I'm not up to such a gargantuan task right now.

Another reason why I would like to add monster races is that defining them down helps in the process making the game-world more internally consistent and less hodge-podge.

**andrewdoull** · January 8, 2009, 00:28

Originally posted by CJNyfalt

Well, I'm a bit unhappy with how the whole melee system is working. I feel that player weapon attacks, martial arts and monster innate attacks should become unified in some way. However, this is something for the future. I'm not up to such a gargantuan task right now.

I'm in the middle of such a gargantuan task at the moment and here's my notes:

* It is 'relatively straightforward' to unify monster spells, player spells/item usage and monster blows. Unangband has done most of the hard lifting for this already, with the exception of getting the display strings done.

* You'll never be able to unify player blows with any of the above without radically changing the combat algorithm and the way objects work. This is because player blows depend on the object the player is attacking with, and the ego multiplier is not additive. The only way I could see of doing this would be to have GF_ types corresponding to every possible ego combination, or unify GF_ types so that they are a combination of ego flags.

I don't, however, see any argument you've given as a requirement to try to unify player and monster types.

The only possibility I could see, is if you want the player to be able to shape change/possess monsters, in which case you're going to have to redesign the entire inventory system ala ToME. For anything less than that, you're better off treating different shapes as a set of stat modifiers plus innate activations/spell books.

There is no need to unify them for e.g. friendly monster AI. I didn't have to do this, and Unangband has complex, interesting and adaptive friendly monster AI.

I think you're making unnecessary work for yourself for little gain.

Andrew

**CJNyfalt** · January 8, 2009, 14:14

Originally posted by andrewdoull

* You'll never be able to unify player blows with any of the above without radically changing the combat algorithm and the way objects work. This is because player blows depend on the object the player is attacking with, and the ego multiplier is not additive. The only way I could see of doing this would be to have GF_ types corresponding to every possible ego combination, or unify GF_ types so that they are a combination of ego flags.

I don't, however, see any argument you've given as a requirement to try to unify player and monster types.

The only possibility I could see, is if you want the player to be able to shape change/possess monsters, in which case you're going to have to redesign the entire inventory system ala ToME. For anything less than that, you're better off treating different shapes as a set of stat modifiers plus innate activations/spell books.

Useful comments.

What's really is bothering me is the case of playing monstrous PCs (dragons, spiders, and other races as in Pos and Dr), where there's the need to combine martial arts skill with claw and bite attacks.

Another insight I had last night is that I should add monster races first, and start to worry about unifying them with player races later. It's after all the ability to define a group of common flags of several monsters in one place that I really want most of all. Fortunately this while requiring some work isn't a complex task.

Unifying monster and player races, some thoughts

Unifying monster and player races, some thoughts

Comment

Comment

Comment

Comment