Sometimes I look at my old stuff and can’t help but think “what the hell is past me smoking?” My floor, wall, door and all other entity layering/sorting render logic is stupidly complex. It’s not necessarily bad and it’s advanced enough to have some nifty features. But I really don’t want to spend any more time fixing all the issues. I am spending too much time polishing the perfect visibility logic when no one actually cares and would never notice if the effect floats a bit “to the side” or something.

One of the most common visual problem is when entities move past or into the wall ceilings:

And these two are just the scenarios that happen all the time. There’s tons of issues with bosses and collisions and all manner of weirdness where being complex means needing lots of tweaking.

So I think I will just get rid of it all — layering, multi-overlay walls, etc.

So back to the full room size of 9 we go, with no 1 tile overlap between rooms. Which means back to the double walls/doors:

And I can strip down my tile world object from all the overlay extra sprites, and it’s back to a single “tile”:

So nice and clean:

I will have to fix actual sprite use though in a bit.

For now, I have to fix the removable double doors and walls, which was the big reason I didn’t want to have non-overlaying tiles (geez, the problems I come up with for myself):

I cannot compare what tile overlays what tile anymore (they don’t overlay, but are adjacent). Instead, I will mark rooms as belonging to a certain group of mergable rooms, such as halls:

This means any tiles that are removable and on the edge with another room of the same mergeable group will get “merged” or removed. And this works out nicely:

I also get to remove a bunch of code I don’t need, like styling precedence for overlapping, tracking of spawned removable tiles since I make removal decision immediately and various other semi-complex checks.

So now I need my walls to have the right sprites. This was a moderate issue before, but I will hard-code a bunch of wall rules. I mean, I say “hard-code”, but it’s by design and there’s just a single case for these. Anyway, I specify the sprites for side and top bits:

And this works out nicely:

I similarly need to select wall sprites when they are next to a door, namely, just above it:

And this works nicely for both closed and open versions:

Of course, my sprites don’t match up for these double-walls and -doors. So I need to make more sprites for them. After some thought and experiments, it turns out I need exactly 2 sprites for each of the 4 door versions — horizontal and vertical open and closed. So I have an accompanying door sprite asset for every door tile definition asset:

And these specify the door top-side or left-right bits, depending if it’s a vertical of horizontal door:

And after lots of tweaking and such, these are working as expected:

The only issue is the vertical door wall parts — these don’t have separate left/right parts, so I need to do define those separately for the walls:

And then wire them up and then they can finally align in-game:

This brings the total number of sprites to… whatever this is:

I am now missing wall top bits, that used to be made up of sides/corner/tips, but I am unsure I will be doing that sort of mess again. I think it’s just simpler to make the source sprites.

So now the two really obvious issues of overlapping effects is gone:

In fact, nothing can ever appear below tiles, and that’s perfectly fine by me at this point.

I still have lots of things to fix and streamline for graphics that I will cover next, but for now this big refactor sets up a (simpler) base to work off. I don’t even have a good joke about refactoring for the nth time.

Related Posts

MicroRogue DevDiary #64 – Walls and doors, again
Tagged on:         

Leave a Reply

Your email address will not be published. Required fields are marked *