Adding color rooms to Angband

[Nomad]

And the colormap parsing... woah, some C knowledge would probably help if I had any. The parser.c:211 does the line parsing and I found the parse_room_d which probably needs a parse_room_c copy. I haven't found the line that actually parses the D: lines in room_template.txt yet that could be re-used for the added C: lines. Can anyone give me another nudge in the right direction for the D: line parsing?

It's in gen-room.c in the build_room_template() function. (Also, I'm sorry to inform you that I did all the code to implement templated rooms, but actually have no idea how it works, it's all just cribbed from the pre-existing vault code with a few add-ons to create more randomisation.)

Incidentally, my aim with the room templates was to get the maximum flexible reuse out of each individual template, so I'd suggest rather than a fixed colour map defining say, "these squares always yellow, these squares red", what you want is just a colour map that says "colour #1 goes here, colour #2 goes here" that you can then apply any number of different colour schemes to, whether "1=red, 2=yellow" or "1=blue, 2=green", etc. (Which would also facilitate applying the same set of theme colours to entire levels.)

Also, while you could potentially do it by adding a set of C: lines for every single room in room_template.txt (which would be a real bugger, since there are currently 500), I feel like the more efficient way would be to add 'accent squares' to the existing rooms, defining specific floor and wall tiles to be a different colour from the default applied to the others. And there are actually already some "special symbols" in there that you can potentially make use of without having to make any changes to room_template.txt at all.

For instance, as part of the efforts to generate multiple variant rooms from a single template, I added code for "optional walls". Those are the x squares here:

D:%%%%%%%%%%%%%%%%%
D:%...............%
D:%.xx...#1#...xx.%
D:%.x...##.##...x.%
D:%....##...##....%
D:#...##..9..##...#
D:%....##...##....%
D:%.x...##.##...x.%
D:%.xx...#2#...xx.%
D:%...............%
D:%%%%%%%%%%%%%%%%%

The code "flips a coin" in the shape of a Boolean called "rndwalls" which gives you a fifty-fifty chance of generating those x squares as floor, giving you this room:

[bc=black]#################
#...............#
#......#[color=#C08040]+[/color]#......#
#.....##.##.....#
#....##...##....#
#...##.....##...#
#....##...##....#
#.....##.##.....#
#......###......#
#...............#
#################
[/bc]

Or walls, giving you this one:

[bc=black]#################
#...............#
#.##...#[color=#C08040]+[/color]#...##.#
#.#...##.##...#.#
#....##...##....#
#...##.....##...#
#....##...##....#
#.#...##.##...#.#
#.##...###...##.#
#...............#
#################
[/bc]

You could, however, potentially give them a double purpose and add code so that x squares (whether they're generated as either walls or floor) are a different colour from the rest of the room, allowing you to apply your different colour schemes to various effects:

[bc=black][color=green]#################
#...............#
#.[color=cyan]##[/color]...#[color=#C08040]+[/color]#...[color=cyan]##[/color].#
#.[color=cyan]#[/color]...##.##...[color=cyan]#[/color].#
#....##...##....#
#...##.....##...#
#....##...##....#
#.[color=cyan]#[/color]...##.##...[color=cyan]#[/color].#
#.[color=cyan]##[/color]...###...[color=cyan]##[/color].#
#...............#
#################
[/color]


[color=#3333ff][color=#8888CC]#################[/color]
[color=#8888CC]#[/color]...............[color=#8888CC]#[/color]
[color=#8888CC]#[/color].[color=lightgreen]..[/color]...[color=#8888CC]#[/color][color=#C08040]+[/color][color=#8888CC]#[/color]...[color=lightgreen]..[/color].[color=#8888CC]#[/color]
[color=#8888CC]#[/color].[color=lightgreen].[/color]...[color=#8888CC]##[/color].[color=#8888CC]##[/color]...[color=lightgreen].[/color].[color=#8888CC]#[/color]
[color=#8888CC]#[/color]....[color=#8888CC]##[/color]...[color=#8888CC]##[/color]....[color=#8888CC]#[/color]
[color=#8888CC]#[/color]...[color=#8888CC]##[/color].....[color=#8888CC]##[/color]...[color=#8888CC]#[/color]
[color=#8888CC]#[/color]....[color=#8888CC]##[/color]...[color=#8888CC]##[/color]....[color=#8888CC]#[/color]
[color=#8888CC]#[/color].[color=lightgreen].[/color]...[color=#8888CC]##[/color].[color=#8888CC]##[/color]...[color=lightgreen].[/color].[color=#8888CC]#[/color]
[color=#8888CC]#[/color].[color=lightgreen]..[/color]...[color=#8888CC]###[/color]...[color=lightgreen]..[/color].[color=#8888CC]#[/color]
[color=#8888CC]#[/color]...............[color=#8888CC]#[/color]
[color=#8888CC]#################[/color]
[/color][/bc][color=#3333ff][/color]

etc.

I mean, hopefully less... bad, but you get the general idea.

There are also a bunch of other special symbols that are instructing the code what to do without affecting the look of the room that you could repurpose to implement various colour effects. For instance, numbers 1-6 are random doors - one number will be picked and used for door positions, while the others are converted to walls - so you could make those walls a distinct colour from the others. Or you could make connecting wall squares (%) on the outside of a room a different colour from standard wall squares (#) on the inside. Nearly all of the layout templates are symmetrical, so tweaking the colours of any of this stuff should create fairly balanced, tidy patterns.

(Of course, I leave the matter of how to get the parser to colourise those squares differently as an exercise for the reader. )

[redlumf]

Konsole is "special". It doesn't allow redefinition of its colors. So GCU (meaning main-gcu.c) redefines Angband's colors instead. It does that with all terminal emulators, even though (in my tests - of course, I only tried a few emulators) only Konsole doesn't change its colors.

Good catch. Try this
Settings/Profile Edit Profiles

On General Tab "Enviroment:" -> Edit

Mine was
TERM=xterm
I've changed it to
TERM=konsole-256color

I think that fixes Angband's colors

[t4nk]

I think that fixes Angband's colors

Konsole never reacts to init_color() (http://stackoverflow.com/questions/1...-set-the-color - see what Thomas Dickey has to say (that's the maintainer of ncurses)); so main-gcu.c doesn't call init_color() (and does bizarre things instead; IMO, it's better to just not support Konsole).

[droof]

I hadn't found my way into gen_room.c yet. This is great help, thank you so much!

I think it's challenging to get a good color pallette for a room, something that enhances the look of the room and not only diversifying it. A fixed color map allows for great precise control over the pallette and be used to great effect. But it goes against the philosophy of a room template, allowing multiple variations of the same room. And getting 500 rooms right is a lot. Maybe C: lines can be made optional and defaulting to white?

Predefined themes would be limited. For an easy example, a theme could be a single color with 4 shades and the room templates have additional symbols to predefine the placement of the 4 shades for whatever theme is applied. This is much more limited and each theme would just be a color variation of the same room.

Then again, I personally think any subtle color would be better than just pure white. Themed levels might be the easiest choice with so many rooms. Maybe I'll try both as I get my head around the code. One way for themed tiles would be allowing multiple colors specified in terrain.txt. For example, each terrain having 4 colors. A level would choose a theme number from 1 to 4 (or maximum number of available colors for terrain, if each terrain has the same number of color indexes) and use only terrain colors from that theme index. This way color themes are easily modified from terrain.txt. Not thinking about code for the moment, it'll probably be just as difficult as a colormap with this setup.

Are room templates chosen at random, or do different rooms have a different chance of appearing on a level?

[Nomad]

Are room templates chosen at random, or do different rooms have a different chance of appearing on a level?

Currently chosen at random. The capacity is there to do something more complex - the room_template.txt file has two fields called "type" and "rating" that I added to be able to distinguish between rooms based on shape and size/interestingness - but currently those values are just set to 1 for all rooms and the code doesn't do anything with them.

The templated rooms start being generated from level 5 onwards, and are more common the deeper you go. (Room templates are actually a relatively recent addition to the game, so there are several other types of rooms in gen-room.c that are hard-coded rather than loaded from templates; dungeon_profile.txt sets the probabilities of the various different types being generated.) If you switch on "Peek into dungeon creation"/cheat_room in the cheat options while you're testing, it'll tell you the names of any template rooms generated at level creation.

Also, the game doesn't care how many rooms there are in the room_template.txt file (it just picks a random one from among however many are in there) so if you start adding colour maps to just a small number of rooms to begin with, you can comment out/delete all the other rooms while you're testing and everything will still work fine. (But you need to exit the game and reload for it to register any changes you make to the text file, because it only reads the data in once when Angband first starts up.)

[t4nk]

And getting 500 rooms right is a lot. Maybe C: lines can be made optional and defaulting to white?

Well, yeah, I was thinking about something along the lines of

if (color_map != NULL) {
    apply_color_map(color_map, other_params...);
}
/* else leave them white */

The color maps are just an idea though; it seems to me like the most straighforward way to get something working, but certainly there are numerous ways to do that.

[Pete Mack]

I am still wondering about the usefulness of having different colored dots on the map. I understand it for terrain. But just because?

[t4nk]

Art is useless, Pete
One thing where most of that code would be useful is 'blood splatter'. That is, in other games (Dungeon Crawl, DoomRL, Infra Arcana and other roguelikes), when you hit a monster, some tiles around it become bloody (red). The harder you hit, the more bloody tiles! It's great fun, and Angband really lacks it See https://github.com/crawl/crawl/blob/...loodspatter.cc for an example.

[Pete Mack]

UnAngband has blood spatter!

[EpicMan]

UnAngband has blood spatter!

And fleeing enemies leave a trail of blood, allowing you to rest a bit before hunting them down. It's very cool.

[droof]

I'm trying to bring color to the environment of Angband, dots are only part of it. Most RPGs have rich color environments that trigger emotion. For example World of Warcraft, every zone sets the mood with its own color theme. Disney uses different color shades for the same setting to trigger emotions like happiness, danger, mystery etc. Will this also work in 256 color text Angband? No idea, but it's worth a try I think.

I'm making a little progress thanks to t4nk and Nomad's comments. I'm testing with room_template.txt with only two rooms defined. One room has a color map. The color map is parsed and passed on to build_room_template(). This function isn't triggered yet, probably because of what Nomad said, the function is triggered from dungeon level 5 and up. I'm testing at level 1. I tried changing the room templates from level 5 to 1 in dungeon_profile.txt, but that change also doesn't trigger the function. So to test this, I need to dive to level 5 and use words of recall?

From what little I understand from the code, each terrain type has a terrain index from terrain.txt and a color index from z-color. Terrain bits from build_room_template() are set through square_set_feat(). This sets the appropriate terrain feature to a chunk / cave x y coordinate. And this information somehow ends up in grid_data_as_text() where the color of the feature type is displayed.

To color room templates, maybe I can pass along the color_map color with the feature index in build_room_template() and store both at the cave square coordinate. Is this what you meant with the additional attribute for cave.h:132, t4nk?

But grid_data_as_text() doesn't have current square coordinates or the cave object to look up and overrule the feature color for display. I should probably trace back from grid_data_as_text() until I have both and pass along the overriding color. Am I on the right track?

[takkaria]

Am I on the right track?

Yes. You will want to add a new member to the grid_data struct and make sure it gets set correctly, and then use the value in grid_data_as_text().

[t4nk]

So, it gets technical, I answered in the dev forum: http://angband.oook.cz/forum/showthr...266#post116266

[Nomad]

This function isn't triggered yet, probably because of what Nomad said, the function is triggered from dungeon level 5 and up. I'm testing at level 1. I tried changing the room templates from level 5 to 1 in dungeon_profile.txt, but that change also doesn't trigger the function. So to test this, I need to dive to level 5 and use words of recall?

You can use the debug tools for testing. ^A will get you the debug prompt, and if you type ? at that prompt it gives you a help page with a list of commands you can use there. Particularly useful ones:

j - jump to any dungeon level
t - teleport around the current level
W - "wizard light" the level (maps out everything like quaffing enlightenment)
c - create an object from a menu (so you can make rods of detection and such)
A - level up to level 50 and max your stats (useful to avoid getting killed while you're testing at deep levels)

My usual method for testing room layouts:

- switch on cheat_room
- jump to a deep level like 60-80 where template rooms are really common
- hop around the level with t until I wind up close to a staircase
- stairscum until cheat_room tells me the room I'm looking for has been generated
- wizard light the level so I can see where it is

[droof]

Why isn't every room on every dungeon level generated from room_template.txt? Rooms like simple and circular can be added and with over 500 rooms and growing it shouldn't get repetitive. And I assume room_template.txt is meant for normal rooms, not like rare dangerous vaults and pits.

If we can make every dungeon level interesting with room templates, why shouldn't we do that?