Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old May 30, 2015, 18:17   #21
tumbleweed
Adept
 
tumbleweed's Avatar
 
Join Date: May 2015
Posts: 112
tumbleweed is on a distinguished road
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 is offline   Reply With Quote
Old June 18, 2015, 16:20   #22
tumbleweed
Adept
 
tumbleweed's Avatar
 
Join Date: May 2015
Posts: 112
tumbleweed is on a distinguished road
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?
Quote:
Originally Posted by tumbleweed View Post
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 is offline   Reply With Quote
Old June 20, 2015, 14:34   #23
tumbleweed
Adept
 
tumbleweed's Avatar
 
Join Date: May 2015
Posts: 112
tumbleweed is on a distinguished road
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.

Last edited by tumbleweed; June 20, 2015 at 14:58. Reason: clarity
tumbleweed is offline   Reply With Quote
Old June 20, 2015, 17:38   #24
tumbleweed
Adept
 
tumbleweed's Avatar
 
Join Date: May 2015
Posts: 112
tumbleweed is on a distinguished road
Okay, here's what I have so far:

Quote:
Originally Posted by tumbleweed View Post
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 is offline   Reply With Quote
Old June 20, 2015, 17:39   #25
tumbleweed
Adept
 
tumbleweed's Avatar
 
Join Date: May 2015
Posts: 112
tumbleweed is on a distinguished road
spam spam spam humbug
Quote:
Originally Posted by tumbleweed View Post
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.
tumbleweed is offline   Reply With Quote
Reply


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
Keymap documentation? Timo Pietilš Development 11 June 2, 2011 17:46
Microsoft NMake documentation FAIL zaimoni Idle chatter 7 September 4, 2009 04:53
Zaiband: Sidebar documentation zaimoni Variants 8 March 4, 2008 07:40
[Un] Restuffing the documentation Bandobras Variants 39 March 2, 2008 07:02
Saving PLAYER.prf *where* under Windows? TJA Vanilla 2 August 17, 2007 00:32


All times are GMT +1. The time now is 23:38.


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