Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old January 7, 2009, 12:46   #1
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Unifying monster and player races, some thoughts

This idea about unifying the way monster and player races are defined in *bands have bothered me for some time, so I'll try to put it down in writing and share around for feedback. Hopefully this will also help me to get back to programming again.

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.

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.

So, looking at these two goals it's clear that I want to make each monster type a member of an in-game defined monster race.

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:

Code:
# N:race number:race name
# S:str:int:wis:dex:con:chr
# R:dis:dev:sav:stl:srh:fos:thn:thb
# X:hitdie:expbase:infra
# I:history:agebase:agemod
# H:hgtmale:modhgtmale:hgtfemale:modhgtfemale
# W:wgtmale:modwgtmale:wgtfemale:modwgtfemale
# F:racial flags
# C:classes (numeric)
N: is the needed identifier line.
S & R: are stats and skills not used by monsters for now.
X: Hit die might be needed in some way. The others are for mechanisms not used by monsters currently.
I, H & W: Are flavor stuff that make no difference in-game. These I would remove since adding them for all monster races would mean much work for no real gain.
F: Here's the first line where that would be of real use for monsters. Moving a common set of flags here should be the plan.
C: Not used for monsters at this point.

So, the things that would matter for monsters would be the flags and maybe the hit die. Of course more things would be added later, but those would probably need also changes to game mechanics.

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.
CJNyfalt is offline   Reply With Quote
Old January 7, 2009, 14:08   #2
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,966
Donated: $60
Nick will become famous soon enough
Quote:
Originally Posted by CJNyfalt View Post
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.

Quote:
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.


Quote:
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.

Quote:
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old January 7, 2009, 17:02   #3
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Quote:
Originally Posted by Nick View Post
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.

Quote:


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.


Quote:
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.
CJNyfalt is offline   Reply With Quote
Old January 8, 2009, 01:28   #4
andrewdoull
Unangband maintainer
 
andrewdoull's Avatar
 
Join Date: Apr 2007
Location: Sydney, Australia
Age: 45
Posts: 872
andrewdoull is on a distinguished road
Quote:
Originally Posted by CJNyfalt View Post
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
__________________
The Roflwtfzomgbbq Quylthulg summons L33t Paladins -more-
In UnAngband, the level dives you.
ASCII Dreams: http://roguelikedeveloper.blogspot.com
Unangband: http://unangband.blogspot.com
andrewdoull is offline   Reply With Quote
Old January 8, 2009, 15:14   #5
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Quote:
Originally Posted by andrewdoull View Post
* 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.
CJNyfalt is offline   Reply With Quote
Reply

Tags
ideas, monster race, player race, race


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Do different races level up differently? TJS Vanilla 8 June 9, 2008 11:38
[FA] Races starting in dangerous places Zikke Variants 3 June 7, 2008 00:14
Yet another new player Sordino AAR 19 May 14, 2008 11:52
player ghosts daft Vanilla 10 April 27, 2008 18:20
[All] Protecting the @ from player stupidity. andrewdoull Variants 10 July 3, 2007 14:39


All times are GMT +1. The time now is 16:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.