Tiledmap looping/wrapping maze - NES Zelda style

1

Hi all, sorry if this has been posted before but my google fu seems to be off.

Right now I’m playing around with a NES Zelda 1-esque prototype for a larger game idea I had. One of the things I’m wanting to add to it is the standard ‘loop the same room’ maze that you see in them. As in, it drops you into a room and you have to follow a set path to get through. The rub is that each room looks the same, so without knowing that path it can be hard to get through it via brute force, if the game even lets you without a flag or something set.

The problem I’m having is figuring out how to do that when i have 1 large map for the entire world. My current map is like in NES Zelda fashion where you only see 1 room at a time without any scrolling, until you hit the edge and it takes you to the next room with a transition. I’m using monogame extended’s tiledmap functionality to display it right now, and going back and forth between contiguous rooms is fine, but I can’t seem to wrap my head around how, if at all, having a room loop on itself while having the same room->room transition scroll would be possible.

I’ve been debating on several methods for implementation.

  1. Separate all rooms into their own file, rather than 1 large map. The benefit to this is I could tell the system which rooms connect to which and it would just load the same one on the transition. The downside is either editing the overall world is a pain or I have to create a script to chunk it up which I then have to remember to run each time the world changes.
  2. Have a copy of the world and display a section of it when I’m doing the transition until the transition is done then dump it. This one seems the most messy, especially since I’m not sure the tiled part of monoxtnd would support that. Actually, if it already can and I can just tell it to display the specific room…might be the most beneficial.
  3. Copy the current room to a rendertarget or texture or something and then display that for looping rooms. Basically the same as #2 but not using monoxtnd for it, though I’m not sure how to display a rendertarget in a different position for the transition.
    Though, there’s probably other solutions that might be similar/better, but searching for this situation has been difficult for finding examples. So I’m curious if anyone has advice/implementations they could provide?
    Thank you!
2

In the original Zelda that was not one giant map, but a series of rooms (most like defined by as little data as possible - there was not much room on a cardridge back the days, so there were several tricks applied to make the size smaller - that’s one reason why many rooms look pretty similar.

So 1 large map is a bad idea - you don’t need separate files but at least organize them in game as separate rooms - you could do this ingame at runtime as well, so it should be no problem with your editing - more like partitioning your data - so there is no real downside any more for your #1 implementation

3

if you wanted to keep one large map, you could accomplish that by using triggers of some sort at the room exit that would move/teleport the player back to the start of the room if collided with.

You just have to code in logic to disable them once the player has solved the maze

4

Thanks for the replies!

@reiti.net Right now my big TMX map file has objects marking the boundaries of each room. I’m doing a little bit of processing on them already, but getting them split up is being annoying with how mg.e is set up. I might end up having to roll my own, which I’d rather not do if I can help it. Fun times!

@bradvs I’m actually doing something like that currently, but without the scrolling/wrapping/transition that the non-maze rooms use, it doesn’t look right.

5

Turns out the answer is yes, at least for the time being, roll your own. I cobbled together a mix of TiledSharp & the mg.ex one and it’s doing the trick. The files aren’t rolled up into one xnb, as I didn’t feel like making a pipeline extension, but for what it is it’s sufficient.