prf documentation

[Zireael]

QT (yeah, yeah, I know) and ToME 4 already split out tiles into individual files

[takkaria]

Y'know, in my naive mind I was hoping I'd be able to do something like this:

trap:*:*:0x8B:0x80
trap:16:*:0x8B:0x81
trap:17:*:0x8B:0x82
object:food:*:0x90:0x80
object:food:Pint of Fine Wine:0x90:0x81
object:food:Flask of Whisky:0x90:0x81
object:sword:*:0x8F:0x80
object:sword:Dagger:0x8F:0x81
object:sword:Main Gauche:0x8F:0x81
object:sword:Zweihander:0x8F:0x82
object:sword:Executioner's Sword:0x8F:0x82

(or "all" or whatever other wildcard character/expression you like)

Patch here to add:

monster-base:BASE NAME:attr:char
object:TYPE:*:attr:char
trap:*:*:attr:char

Also converts "all" in the trap syntax to "*" just for consistency.

[tumbleweed]

Patch here to add:

monster-base:BASE NAME:attr:char
object:TYPE:*:attr:char
trap:*:*:attr:char

Also converts "all" in the trap syntax to "*" just for consistency.

Terrific!

Could you please add support for object:*:*:attr:char / monster-base:*:attr:char / monster:*:attr:char as well?

...actually let me stare at this whole thing for a moment and throw some thoughts around.

Goals:

1. ensuring that all gameplay-relevant entities receive a distinct tile
2. allowing for rapid creation and integration of a new tile set

Approaches:

1. by logical / gameplay-dictated hierarchy - this would especially help with Goal 1.
2. by internal structure - this should be the easiest to implement on both sides (internally and in tile assignment) with sufficient wildcard support.
3. by knowledge-base hierarchy - I only glanced at it relatively briefly so far, so I'm not sure how far it strays from the aforementioned approaches.

Not sure whether eg some grouping of monsters by slays (minus evil) would be feasible.

Also I guess it'd be a good idea to look at what forks are doing...

[Nick]

Patch here to add:

monster-base:BASE NAME:attr:char
object:TYPE:*:attr:char
trap:*:*:attr:char

Also converts "all" in the trap syntax to "*" just for consistency.

Added to master now

[tumbleweed]

Added to master now

All right, time to play! - By which I mean "break shit."

My current short-term goals while defining a minimal tileset shall be:

1. complete coverage of vanilla Angband entities via prf files, so everything renders without ASCII fallback.
2. ensure distinct tiles for different gameplay aspects

...and bitch and moan about every hint of difficulty along the way.

(And no tile artist ever threw a fit over this?)

[tumbleweed]

All right, so, what you still have to define manually one-by-one at the very least right now, as far as I can tell:

• 312 flavors (!) Something went... not quite right yet?
• 57 monster-base types. Quite a bit of grunt work. Probably cannot be avoided though.
• 26 feature types. This is kind of annoying.
• 8 weapon types. Not too terrible, I guess.
• 9 armor types. Same as for weapons. Lots of different body armor types.
• 15 other object types. Slight redundancies here.
• 5 spell effects (4 directions, 1 static). Nice enough.
• 1 trap type. Glorious.

I'd like to suggest the following:

1. make object:TYPE:*:attr:char override flavors
   Right now the single-most annoying bit about defining a tileset is obviously dealing with the myriad of flavors, unless I missed something.
   takkaria's wildcards don't really seem to work here as intended yet. object:scroll:* only affects identified scrolls for some reason, while object:potion:* et al don't seem to affect anything at all.
   takkaria, Nick, if you kindly would?
2. roughly sort and comment monster-base types in a prf
   Sure, it'd be nice to be able to just assign tiles to broad categories of monsters, like e.g. undead, animal, but as far as I can tell there is no easy way to facilitate this on the backend side of things?
   However, assuming that it is a matter of "exactly one base type for every single monster," I think roughly sorting and commenting the base types in a prf of their own would be a good way to at least mitigate the issue. Also if said assumption is correct, having a catch-all monster-base:*:attr:char would be nifty, while a monster:*:attr:char would be useless.
   I'll try my hand at grouping monsters and ask for comments.
3. roughly sort and comment dungeon features in a prf
   It'd be nice to be able to reduce the 26 dungeon features to a small set of relatively essential types for rapid tile assignment, e.g. unknown, floor, wall (possibly soft, hard, indestructible), door. Maybe merchant too, because while rendering the merchant tiles as door variations is commonplace, just lumping them in with doors is kind of a stretch gameplay-wise, so maybe they should be a type of their own?
   Still, any such kind of grouping begs the question what to do with edge cases like lava (impassable, indestructible, does not block sight) and passable rubble (passable, destructible, blocks sight) which cannot be trivially classified as wall or floor.
   And I don't think there's much in place on the backend side to support simplified assignment for dungeon features, so I figure just like with monsters it'd be the best approach to just provide additional guidance in a well-organized sample prf. (Not a fan of just referencing features by numbers by the way.)
4. split a graf-???.prf up further, as a template
   As the prf parser already supports rather deliberately creating and integrating further prf files, I don't see any compelling (legacy?) reason not to do this - and maybe even give each tile set a subfolder of its own (/pref/dvg, /pref/shb, etc)
   I find this makes modifying the tile assignment that much easier, so I'm pretty much right in the middle of this for the tileset I'm fiddling around with.
5. object:*:*:attr:char
   This would still be nice to have as a basic catch-all for things that can be picked up.
   Sure, I guess the 32 object types could be collapsed to fewer types (e.g. weapon, armor, food, light, jewelry, magic), but I don't see that much of a point: most of them are sufficiently distinct so anyone serious about designing a useful tileset will want to give each of those types a tile of its own as soon as possible.
   And even assigning the same tile - or just a select few - to all kinds of objects manually is not a catastrophic amount of copy&paste.

Spell effects could be reduced to one in theory, but they're very manageable as is already.

Also on a more general note, I think it'd be neat to be able to set one or few default fallback tiles for better issue visibility (like a global let's say "?" or "X"), but I guess ASCII fallback kind of works too - though the drawing/erasing quirks can be annoying.

PS: Wow, writing this up took me entirely too long.

[tumbleweed]

Looks like I'm going to have a couple days of less-than-splendid weather over here, so I'll finally get back to fiddling around with this.

Meanwhile, any news on my main request?

I'd like to suggest the following:

1. make object:TYPE:*:attr:char override flavors
   Right now the single-most annoying bit about defining a tileset is obviously dealing with the myriad of flavors, unless I missed something.
   takkaria's wildcards don't really seem to work here as intended yet. object:scroll:* only affects identified scrolls for some reason, while object:potion:* et al don't seem to affect anything at all.
   takkaria, Nick, if you kindly would?

Also I'd be interested in hearing thoughts on the on the other points I raised in my post above.

[tumbleweed]

Looks like I didn't quite think this one through, yet.

So here's the thing with flavors: Unless I'm missing something, even with the recent change as of 4.0beta 367, it's still not trivial to assign one tile to unidentified scrolls and another to identified scrolls.

You basically have to go object:scroll:*:0x83:0x86 and that covers both unidentified scrolls (flavor:n:attr:char for all n that actually refer to scrolls) and identified scrolls (object:scroll:attr:char).

I guess what I'm looking for is the ability to use something like flavor:scrolls:0x83:0x85.

This is less of an issue for other flavored items as these don't change appearance upon identification, as far as I can tell.


Also, in case this wasn't clear:

I'm not actually a tile artist myself, I just think making tile assignment easier and faster to perform can be a worthwhile endeavor. Because when I started this thread, creating and assigning a new tileset - especially without any guidance - was nothing short of daunting.

And to anyone who's at all interested or involved in the creation and assignment of tiles, please do chip in if you have additional thoughts or notice oversights on my part.

[tumbleweed]

Okay, here's what I have so far:

4. split a graf-???.prf up further, as a template

I put the prfs for my test tileset in a subdirectory of pref to separate them from the other tilesets, pref/test/

graphics.txt now uses P:test/base.prf to load the tile assignments for my test tileset.

I took the usual three prf files and chopped them up into a grand total of thirteen:

The one to rule^H^H^H^Hload them all:

• base.prf

Environment:

• dungeon.prf
• traps.prf
• spell_fx.prf

Items:

• objects.prf
• weapons.prf
• armor.prf
• artifacts.prf
• scrolls.prf
• flavors.prf

Characters:

• monster-base.prf
• monsters.prf
• player.prf

I'm currently debating whether splitting up flavors.prf by item type, or monsters by base or group as mentioned below, would make sense.

I want to avoid nesting of prfs, and I want to avoid creating too many prfs.

Splitting monsters.prf further by base would result in a huge number of files, and I want to keep the number of prfs manageable.

[tumbleweed]

spam spam spam humbug

2. roughly sort and comment monster-base types in a prf

So far I'm using the following "groups" (by sorting and commenting accordingly) in my fancy new monster-base.prf:

• undead
• dragons
• demons
• humanoids
• animals
• mimics
• other

"other" being a catch-all for the ones that didn't obviously (to me) fit one of the other categories (quylthulg, xorn, yeek, yeti, ainu, eye, elemental, vortex, lurker, golem, hybrid, icky thing, jelly, mold, mushroom).

It's a bit sloppy and arbitrary as this wasn't a priority after I was done copypasting one tile to all monster-base types. My approach for categorization was pretty naive too, largely going by intuition instead of game internals, so I'm looking for input on characteristics that could be used for grouping.