There are a bunch of things related to the tile/wall/door changes that I need to adjust and work on further. There are still some big things, like lighting and collisions pending. For now, I will do some less tedious and more broken ones first related to presentation.

Firstly, the room placement logic and the overlapping walls/doors. Everything was doubled for my fake-3D stuff:

So, firstly, I need to remove any excess double-tile spawning for those fake walls:

And then overlap the rooms again to produce “normal” 1-width doors and walls between rooms:

This is again the whole overlapping versus adjacent rooms logic and all the things that come with it.

I was previous using wall sides when they are “below” a wall, so some of those hard-coded rules do mess up some things, such as tile revealing (it think it needs to “light up” double doors):

The second big thing is getting the style to work again. I reduced the number of sprites I need by a lot for walls and doors, so now I can think more about getting some different sprites for distinct places in the dungeon.

So I can go back to my dungeon styling definition asset and specify some styles. I am also adding a “room” style:

I am also thinking I am not going to have per-level style definitions, since they are all essentially the same anyway. I can still point to different assets, if I ever want to, but I will keep a single central one for now:

I am also merging my tile sprites with tile definitions now that I don’t have elaborate rules for choosing these:

So I don’t need to work with so many assets when I add another style:

I can then specify different definitions for different styles (I had most of this working already, but it got somewhat broken in last tile changes):

Anyway, this then correctly selects the style I want for the rooms (green):

There is the old problem of style order though: rooms get spawned pretty much by iterating the dungeon generator’s grid, which means overlapping room tiles do not necessarily get styled correctly:

Instead, I will sort the rooms based on their style and the order is the style order in the styling definition:

Two styles like this need a total of 6 sprites:

Of course, I can, for example, reuse doors sprites that are the same for the styles. I can mix and match and such. Wall tops can all be the same color and only sides be styled. Anyway, these are arty question I will get back to eventually.

Another thing to consider is the angle at which the game is played, that is, my perspective camera lean angle. The more top-down it is, the less “realistic” it is. But the more I lean it to be realistic, the more I have to render behind it and consequently the player can see less in “front” of the camera:

This is an extreme example, but the values between seeing the whole level and seeing just the immediate surroundings are literally about 10°.

One thing I am also adding is for objects to have an extra view angle offset parameter in camera system, so they can lean or fall back slightly more in relation to the camera.

Furthermore, I haven’t yet messed with my camera FOV setting:

As opposed to real 3D FOV differences, this looks different because of the fixed angle camera and on-the-rails panning. Higher FOV means more pronounced verticalness. It’s hard to explain and even to show, but it basically means the player is sort of fish-eying their character and everything around it gets (nightmarishly) exaggerated and tall:

The actual values I want are probably somewhere in between (full viewport screenshot):

But I have to be careful making it look too realistic and “too 3D” or I end up with uncanny visuals, where things obviously don’t align (but align just close enough to seem like they are broken rather than intentionally abstract):

This is especially noticeable when other objects are the ones close to the edge of the screen with higher FOV:

If you don’t think about it — it’s fine. But once you see it — you can’t unsee it.

It’s mostly fine and even near-perfect when things are “further” away or with lower FOV:

I think if my sprite graphics are pixelated enough and I add more level detail, it will pass off as a deliberate style and not half bad. (Can you tell how confident I am in this style?) Well, I think it will work better than flat 2D. It might not be as consistent, but it’s unique-ish. In any case, I spent some time experimenting with sliders and running around the dungeon with different camera settings. I think I have something that looks reasonably good and sufficiently abstract.

MicroRogue DevDiary #89 – Layout adjustments
Tagged on:             

Leave a Reply

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