Drawing multiple sides of a building in a topdown RPG world

In games like ROM City Rampage, you can only see one side of the building. In my game, you should be able to enter all sides of the building. I'm not sure how to draw the building then. I'm thinking about whether the map should have a 16x16 or a 32x32 block resolution. The game isn't for the NES, but for a DIY gaming console called Pokitto which has a 220x178 resolution if I'm not mistaken. The game is an RPG in which you can enter buildings by walking on the map, but when you enter the building, it turns into a 2D platformer like in Zelda 2. Since the map is based on a real city in which there can be buildings facing any direction, the player should be able to enter any of them from any direction and see their front face even if it faces north. So I'm thinking about if a building's block should be a square split into 4 triangles for each side of the building and have a smaller square in the middle for the roof; it would look like SMB1 stairway blocks in SMB1. I just hope it doesn't look messy. Chained buildings would have the intersecting sides removed and connected via the smaller square in the middle which stretches into a rectangle.

How would you draw a building that's enterable on multiple sides?

Draw pathways of some sort toward the entrances.


The path next to the well between the houses draws the eye to the back of the houses

You could do something like how the game Prison Architect does it? In that picture, they show the building interior, but you could just cover it with roof, but still leaving the sides and doors visible?

Years of training of JRPGs has taught us that, despite the paths, there's probably not entrances there (unless it's a secret room).

^^^ I haven't seen any of those…

Traditional side- and back-exits whose doors can't be seen have a dirt area around the entry, to suggest traffic wearing out grass, etc.

These are some of your perspective options:


Personally I'd go with the normal one visible wall perspective and go roofless.

You forgot a full trapezoidal perspective:


I started to mock-up a "remake" of an older project of mine, but I haven't worked on it, in a while...


For those of you who recognize the color palette, yes, it's exactly what you think it is:

I "forgot" many other perspectives, I was just showing a few very different types. The one you showed isn't all that much different from the bottom right one.
Btw, really good graphics there, nice!

I like this! I was thinking about something like that! Just not trapezoidal projection. But since you've mentioned it, I'll do it!

Looks very Zelda 3-esque.

Personally I find it strange and I prefer the more traditional top-down perspective, although I understand in some cases another perspective is necessary to show more details.

This is something i'm working on for the compo.



The pros:
-Pushes the limit of what is expected from a perspective standpoint on the nes.
-Gives a nice sense of depth
-Can help tell the player something about the height axis
-You can place points of interest in more varied locations than in the JRPG perspective
-More easily enables tactical level layouts compared to the JRPG perspective

The cons
-Will require another layer of cases in your map drawing algorithm, if you use one, or if the screens are hand-drawn and hard-coded, they will be prone to the human factor (bending perspective rules by mistake).
-Moving Sprites either have to 1) beconfined to a floor-level 2d plane, 2)break perspective noticeably, or 3)have lots of work done to them, graphics and code wise.

Because of the cons, we might actually roll back to the classic JRPG perspective, depending on how it goes. We'll need to factor in time, convenience, to some extent cpu bandwidth. and if the wow-factor is large enough. We've already rolled back some ROM expenses in the form of another nuance of perspective, taking up another subset of tiles. That adds up when having multiple sceneries. In one end, JRPG perspectives are the simplest things that could possibly work, and in the other, it has been done so many times that you need to go further in order to succeed making something fresh.

Other things to note:
-The perspective and scale must be made to match the active play area. If 1 screen with screen by screen switching/scrolling when trespassing borders, no problem. If for example 2x2 free-scroll screens, you need to scale the perspective accordingly.

This mockup has been through quite a few iterations in a short development cycle, with the perspectives changing. I plan to do a full writeup comparing snapshots once the design has solidified enough.

Are you using "traditional JRPG" to mean a cavalier projection, or cross-sectional?

I associate cavalier projection with (mostly western?) MSDOS era CRPG:s.

What i meant with "classic JRPG" was a forced perspective where you see front and top of a cube, but not the sides.

This is what i call Cross-sectional perspective, which is what the project in its current shape is approximating, but with compromises due to level drawing complexity, storage, attribute grid, and sprite handling. Hypothetically, a truer form of cross-sectional would require many attribute masking sprites, subsequently locking a sprite subpalette, a more careful/constricted layout, and Solstice-like sprite masking tricks, which amounts to an enormous task.

An earlier iteration had more trapezoid elements, like zelda 1, 3 and so on, but it didn't work out for the intended design goals.

so, as FF1-6, DQ3-5 (and, though the bricks look more like you're showing 0 sides, DQ1-2), Seiken Densetsu, Chrono Trigger, Wild Arms, Soul Blazer, Illusion of Gaia, Terranigma, etc. etc.

actually Soul Blazer does show trapezoidal southwalls when inside, so not quite.

I think that if the characters are chibi enough then they don't need to adjust to perspective. Looking great so far!

That's similar to what this diagram on Wikimedia Commons refers to as "top-down oblique projection".

What I'm planning to do for a future project is show width and height at full size but depth at half size, as if the camera is pointed 26 degrees down. Then speed of movement along the depth axis is halved to compensate.


To illustrate, I drew a crate

Thus 1 m wide is 16 pixels, as is 1 m tall, but 1 m deep is only 8 pixels.

Thanks for the link - very illustrative!

That's a very nice take on the top-down oblique perspective. I suppose you don't see that too often because of the 16x16 attribute grid (basically same with isometry or any skewed perspective).

Some solutions:
-2 subpalettes with dupe colours
-Common colour is floor colour
-1 subpalette for bright side, 1 for shadowy side and floor
-ExRAM
-Sprites (worst, since you spend both scanline bandwidth and an extra subpalette for something that still is on a 8x8px grid)

^^^ 16x8/8x16 attributes are fairly trivial to implement on a board, if you don't plan to scroll, since you can just switch CIRAM tables based on the LSbit (be it for X or Y) of the preceding NT fetch.

(Or, in software, raster-swapping the NT every 8 scanlines, but that'll crimp your cycles very fast.)

Thanks, that helps a lot; I was looking for such, but your search-fu is better.

So with GTROM:s 2 pages of 4-screen nametables, you could theoretically software-swap them to provide a 16 x 8 (or finer, though it makes little sense) grid with easy free-directional scrolling; provided you have enough cycles to spare. Right? The ease of the scrolling might lend just a little bit to that end.

Yes, but the hard part is timing the splits without IRQs. You'd have to run timed code most of the frame and end up with little time left for the bulk of the game logic.

Oh yeah, and when you mention it, vertical scrolling would require offsets to the timing.

How about making one's own mapper where the mapper changes the attributes and the nametable and bankswitches by counting the scanlines like MMC5 does and then it has a table of scroll values that the IRQ code simply copies into the PPU_SCROLL registers from fixed mapper registers which are updated by the mapper?

Or if hardware accelerated on the pcb, can we decouple attribute page switching from nametable pageswitching on a hypothetical new mapper? It seems redundant/fidgety/restrictive to lock all of the nametable RAM on cart to timed toggling when all we want to toggle is the last 64 bytes of each NT. The fact that they're interleaved between nametables rather than sorted last or first in address space rules out the simplest form of masking, though. I have difficulties comprehending what should be used instead.

Unfortunately, changing the way the PPU's attribute table is laid out is relatively I/O intensive, more-or-less requiring an FPGA. There are two conventions for making the attribute table have the same layout as the nametable, both targeting 8x8 attributes—MMC5 and Quietust's UNL-DripGame.

On the other hand, if you "just" want the ability to bankswitch the last 64 bytes of the nametable to something else, but retain the same 16x16 pixel granularity and packing ... well, there's no established mapper for that, but it is electrically simple.

It feels as if i'm missing a piece here. If toggling/bankswitching the last 64 bytes of a nametable is electrically simple, what's more complicated about doing it a fixed rate, via a timer set at 8 scanlines? This question assumes we don't need to reroute addresses.

There's nothing hard about that. That's what Myask was referring to—it's easy to take note of ("latch") the address of the preceding nametable fetch and use that number to automatically bankswitch the attribute table.

Oh, right. Thanks for clarifying that.

So basically the features would be
-Scanline based IRQ counter
-Attributes are switchable (rate selects x or y), so we can get 16x8 or 8x16
-a time offset at 0-7 steps so the attribute toggling can fine scroll

Whether it's CIRAM or ExRAM (like GTROM, etc) is arbitrary, even though the latter is of course more convenient and flexible, which is the whole purpose of a new pcb/mapper - to make pretty things work on a NES at a reasonable price.

no need for the third; it'd line up to the tiles naturally.