Kennels and Other Rooms

[wobbly]

This is a dog kennel from fcpb:

N:Kennel
T:ROOM:NORMAL
W:10:*:4
L:C:MON(HOUND, DEPTH+5)
M:%%%%%%%%%%%%%%%%%%%%%
M:%...................%
M:%.#################.%
M:%.#C#C#C#C#C#C#C#C#.%
M:%.#+#+#+#+#+#+#+#+#.%
M:%.+...............#.%
M:%.#+#+#+#+#+#+#+#+#.%
M:%.#C#C#C#C#C#C#C#C#.%
M:%.#################.%
M:%...................%
M:%%%%%%%%%%%%%%%%%%%%%

and straight away I notice this is easy enough to do with a build_kennel instead. The advantage being that it wouldn't always be 16 dogs, it could be random x dogs, random x serpents or random x basilisks.

These are room stacks, they actually go up to 6:

N:Room Stack I
T:ROOM:NORMAL
W:20:*:2
L:M:MON(*, DEPTH+5)
L:$:OBJ(*)
M:%%%%%%%%%%%%%%%%%%%%%%%%%
M:%.......................%
M:%.#####################.%
M:%.#......M..#..M......#.%
M:%.+.....M..$#$..M.....+.%
M:%.#......M..#..M......#.%
M:%.#####################.%
M:%.......................%
M:%%%%%%%%%%%%%%%%%%%%%%%%%

N:Room Stack II
T:ROOM:NORMAL
W:20:*:4
L:M:MON(*, DEPTH+5)
L:$:OBJ(*)
M:%%%%%%%%%%%%%%%%%%%%%%%%%
M:%.......................%
M:%.+###################+.%
M:%.#......M..#..M......#.%
M:%.#......M.$#$.M......#.%
M:%.#####################.%
M:%.#......M.$#$.M......#.%
M:%.#......M..#..M......#.%
M:%.+###################+.%
M:%.......................%
M:%%%%%%%%%%%%%%%%%%%%%%%%%

Again these are simple symmetrical building that could be done with a builder. all 6 could be done with 1 builder. The kennel could be done with the same builder, though there it would be 1 builder with 2 parts (which seems to lose more then it gains compared to 2 separate builders).

Anyway I'm curious if anyone has any thoughts on:

• Which rooms are better done with builders & which with prefabs
• How many versions to cram into 1 builder
• anything else

I plan to do the kennel for the reasons above, the rest I'm putting off till I decide whether it's worth it.

[wobbly]

Turns out kennels are tricky if you want different layouts & orientations. I'm not sure if this is right:

/**
 * Build cells on the north wall.
 * \param c the current chunk
 * \param x1 inclusive room boundaries
 * \param x2 inclusive room boundaries
 * \param y1 inclusive room boundaries
 * \param y2 inclusive room boundaries
 * \param flag the SQUARE_* flag we are marking with
 */
static void cells_n(struct chunk *c, int x1, int x2, int y1, int y2, int flag)
{
	fill_xrange(c, y2, x1, x2, FEAT_GRANITE, flag, false);
	fill_yrange(c, x1, y1, y2, FEAT_GRANITE, flag, false);
	fill_yrange(c, x2, y1, y2, FEAT_GRANITE, flag, false);
	int x, y;
	for (y = y1; y <= y2 - 1; y++) {
		for (x = x1 + 2; x <= x2 - 2; x += 2) {
			struct loc grid = loc(x, y);
			square_set_feat(c, grid, FEAT_GRANITE);
			sqinfo_on(square(c, grid).info, SQUARE_WALL_INNER);
		}
	}
	for (x = x1 + 1; x <= x2 - 1; x += 2) {
		struct loc grid = loc(x, y1);
		square_set_feat(c, grid, FEAT_CLOSED);
	}
}

Will it spit the dummy about struct loc grid appearing in both loops? Do I declare it outside & set the y co-ordinate inside?

[backwardsEric]

Originally Posted by wobbly

Will it spit the dummy about struct loc grid appearing in both loops? Do I declare it outside & set the y co-ordinate inside?

Since those declarations are in separate blocks, they won't clash.

Declarations within the for() statement itself,

for (int i = ....)

, are a C99 feature and have always been allowed in C++. I don't know the scoping rules for those in C (whether such a declaration is also visible to the block containing the for loop or if it's only visible within the for loop). For C++, they are limited to the for loop, though I vaguely recall a period of time where some common compilers didn't handle that properly.

[wobbly]

Thanks. A lot of this stuff is still confusing to me. I had to go through a bunch of my code & fix some randint0s because I'd messed up. Apparently Randint0(1) is 0 <= x < 1 rather then 0 - 1. Glad I found that out before getting much further. Anway it's working, at least as far as building the rooms, still need to place the occupants. Currently its handling the different layouts with a bunch of if/else & I notice elsewhere in the code its using switch instead. Is there an advantage to switch? Or is this about readability?

[backwardsEric]

Originally Posted by wobbly

Currently its handling the different layouts with a bunch of if/else & I notice elsewhere in the code its using switch instead. Is there an advantage to switch? Or is this about readability?

For me, the primary concern would be readability, and I prefer a switch statement in the cases where it's most applicable: testing a single integer value for whether it falls in one of several categories that don't overlap. It does have the disadvantage that the compiler won't catch the error of leaving out the break statement between cases that are to be treated separately. With the if/else construct, the compiler readily notices the equivalent error of omitting a brace.

Both will be awkward with enough separate cases.

[fph]

Originally Posted by backwardsEric

the compiler won't catch the error of leaving out the break statement between cases that are to be treated separately. With the if/else construct, the compiler readily notices the equivalent error of omitting a brace.

Isn't there a compiler warning that can be enabled to catch this? At least in GCC.

[wobbly]

Thanks again! Yeah I suspect what ever I do it's going to end up a long list of cases just because it's got a type & an orientation.

	} else if (t == 3) {
		if (o == 0 ) {
			cells_n(c, x1 - 1, x2 + 1, y2 - 1, y2 + 1, SQUARE_WALL_SOLID);
			cells_s(c, x1 - 1, x2 + 1, y1 - 1, y1 + 1, SQUARE_WALL_SOLID);
			cells_e(c, x1 + 1, x1 + 3, y1 + 3, y2 - 3, SQUARE_WALL_INNER);
			cells_w(c, x2 - 3, x2 - 1, y1 + 3, y2 - 3, SQUARE_WALL_INNER);
			
			cells_monsters_xrange(c, y2, x1, x2, depth, race, zoo);
			cells_monsters_xrange(c, y1, x1, x2, depth, race, zoo);
			cells_monsters_yrange(c, x1 + 2, y1 + 4, y2 - 4, depth, race, zoo);
			cells_monsters_yrange(c, x2 - 2, y1 + 4, y2 - 4, depth, race, zoo);
			
		} else {
			cells_w(c, x1 - 1, x1 + 1, y1 - 1, y2 + 1, SQUARE_WALL_SOLID);
			cells_e(c, x2 - 1, x2 + 1, y1 - 1, y2 + 1, SQUARE_WALL_SOLID);
			cells_n(c, x1 + 3, x2 - 3, y1 + 1, y1 + 3, SQUARE_WALL_INNER);
			cells_s(c, x1 + 3, x2 - 3, y2 - 3, y2 - 1, SQUARE_WALL_INNER);
			
			cells_monsters_yrange(c, x1, y1, y2, depth, race, zoo);
			cells_monsters_yrange(c, x2, y1, y2, depth, race, zoo);
			cells_monsters_xrange(c, y1 + 2, x1 + 4, x2 - 4, depth, race, zoo);
			cells_monsters_xrange(c, y2 - 2, x1 + 4, x2 - 4, depth, race, zoo);			
		}

That shouldn't be too bad though? Place 4 rows of cells, fill 4 rows of cells.

[Pete Mack]

I disagree with this design. You are breaking code/configuration separation for no apparent reason.

[wobbly]

Well I can potentially rearrange it, but I'm not sure what you actually mean.

[Derakon]

Originally Posted by wobbly

Well I can potentially rearrange it, but I'm not sure what you actually mean.

By baking the design of the rooms into the code, you're making it so nobody can change this bit of game content without having a full development environment set up. Much of Angband development over the long haul has been moving things out of code and into resource files, to make them more accessible and easier to modify.

I can see the appeal of "these rooms are all just variations on each other, we could have a generator that produces the variations", but then you want to be exposing, like, some kind of configuration for the generator so people can still modify its behavior without recompiling. And that all starts to sound like it gets complicated fast...