I have a couple of ideas, on the whole bissecting walls part, that I’d like to put up for you guys to discuss, or consider. I will write a bit, but is simply to explain the process of how I got to a possible consistent answer to your edge case questions on the video.
In a simplified manner, my idea is that a room is constituted by a space contained within a group of walls that completely close off access to the outside of it without using a door or a window (or potentially, in the future, the stairs, which I assume will be treated the same as doors and windows when it comes to room calculation).
That way, you remove those incomplete wall edge cases. like half walls not completely closing of two separate rooms and such. If a wall doesn’t completely cut a room from side to side, it does not create two rooms.
Now, touching on the more edge cases you mentioned, should a wall completely cutting a room side to side transform it into two rooms that should separate when it comes to moving them around?
In my opinion, yes. It’d be easy to understand, given the rules you seem to have established in your test cases. A room created on top of another creates a wall to separate them, and once separated, they act as completely separate rooms. If a wall is added to cut of a room, creating two, it makes sense to expect the same behavior, it adds consistency to the builder → Once a room is created, it is treated as a separate entity.
Then, the same rule should apply to removing a wall, it should merge two (or x) rooms into one. Once more, it’s consistent with the model defined, and consistency is good. It makes it simple for anyone to understand the “rules of the game”, and allows you to later build on top of it.
For the last “outstanding” question of yours, when does poking a hole on a wall makes it stop being a wall?
Well, I’d like to address this asking first a simple question: what is the use of a wall? In my view, walls, and most importantly, the rooms they can create, are a means of defense, first and foremost, and a way of gaining privacy second.
If you start thinking about it this way, then I feel it becomes simpler to answer the question. Can your Hearthling go through the wall after you poke that hole, without a door or stairs? If yes, then it stops being a complete wall, and the room is broken. As simple as that in my view. If someone can’t traverse a wall directly to get to you, it fulfills the most basic design: protection from danger. Furthermore, it should, in at least some sense, keep some privacy.
Now, the privacy part is something that is a bit more… easy to poke holes at. Say you create a “wall” where, you simply mesh voxels and spaces, a checkered pattern, where the black is a voxel, and the white is open space:
Say you got that pattern. Would that constitute a wall? Well, according to the definition, your heartlings cannot reach the other side through it, so it should in theory fulfill the protection part, but the privacy part? That’s where the issue is.
However, the privacy part makes little sense mechanically in the game, at least at this point. Hearthlings don’t seem to have any notion of “privacy” like in Sims. And as such, it should not be a limiting factor. However, I feel like it’d probably harder for the code to recognize that pattern as a wall if you built it voxel by voxel.
But still, you could apply the traversing condition to the current code and make it recognize when a wall stops being a wall based on that condition. It’s simple, shouldn’t take too long to calculate (I think) and shouldn’t be too hard to code (once more, I think).
That’s it. Hope it can help to at least create some discussion. I’m glad to see all the improvements being made. I’d also like to add that, while I’m not an experienced programmer, I do code on my current job, did it at university, and I have a passion for games, so I do enjoy these discussions from a more structured side. Keep on giving us these videos, i find them particularly interesting.