# Thread: Room properties

1. 557
posts
Block user.

## Room properties

I'm just going to throw this out there, hopefully in the form of a question. I might have a better understanding of how to do this just by explaining it in precise terms. Any feedback is appreciated.

So I wanted to make a tile-based game that consists of one "overworld" map that's comprised of smaller maps that link together. The best way to explain it is like the dungeons in zelda - each screen was it's own little tile-based map, but the rooms all connected to make up the whole dungeon. Many of the rooms were recycled though - for example, there are maybe 20-30 room types (i'm just guessing here), populated with different enemies, items, etc.

This is all relatively easy, but what I want to do is have each room in the dungeon have properties that affect things in a larger scale than the myopic approach of ignoring rooms you aren't in. For example, maybe I'd have a monster that follows you from room to room, or maybe fire that spreads from room to room. "global room properties"

I've thought of a couple ways to do this, but it seems too tricky

I'd want the rooms to be interchangeable from a map-editing perspective. So, I'm thinking I'd have re-usuable maps for each room, and their placement would be determined in a larger "overworld" map.

Easy, right? One big problem I'm encountering with this is coming up with a solution for locked doors that would otherwise connect two rooms. I guess my best solution here is to structure my overworld map like this:

Code:
// Whereas 1-9 = room types,
// 0 = nothing,
// D0= open door, D- = locked door
map = [
[ 0,  0,  0,  0,  0,  0,  0],
[ 0,  1, Do,  2, D-,  1,  0],
[ 0, Do,  0, Do,  0, Do,  0],
[ 0,  3, Do,  4, Do,  5,  0],
[ 0,  0,  0,  0,  0,  0,  0] ];
Does that sound ok? It'd be just like defining certain tiles as walkable, !walkable, etc.

Then I could affix common properties to rooms like heroIsInRoom=true/false, randomTreasure="arrows", monsters=[gorilla, gorilla, skeleton], etc.

It seems kind of silly to do it this way, as I'm ultimately planning on rendering the whole map on screen at once, but in terms of flexibility, this seems good to me, I'm just wondering if anyone has done something like this before - I could use a second opinion, maybe.

2. I guess I would also do it this way but just slightly different, maybe even create 2 map editors, one for the rooms and one for the big picture. I would use a graph to store the rooms and either let the program search for the connections at the start or save 'em when you save the map. This way your objects (rooms) could have some easy properties such as
doorsOpen: room1, room2, doorsLocked: room3 for example. And with the editors both rooms and the implantation in the big picture can extremely easy be done.

What I don't understand is why you would want the rooms to be so separate, especially if you are planning on rendering it on screen all at once. Why do you want to use rooms? The reason I'm asking this is because you seem to not use these special rooms for anything particular.

3. 557
posts
Block user.
Originally Posted by ArmoredSandwich
What I don't understand is why you would want the rooms to be so separate, especially if you are planning on rendering it on screen all at once. Why do you want to use rooms? The reason I'm asking this is because you seem to not use these special rooms for anything particular.
I guess that's why I posted the topic to begin - I'm not even sure if I have to go this route. I don't want to go into the project in great detail here, but ultimately, I'd have the option of running pathfinding routines on two different levels - locally, this is, in the individual rooms, and globally, meaning create a route from the room at (3, 15) to the room at (7, 2) while taking into account locked doors and such. The global pathfinding script would work the way any other A* routine might work - but the doors would be a node in themselves that toggle between walkable and !walkable at runtime (of course, in addition to the rooms serving as nodes).

I could just use one massive map of tiles and do my pathfinding that way because I plan to have all the rooms be on one screen, but it'd be useful if i decide to do it zelda style, where each room is one screen.

Say I had monsters following you through a dungeon - rather than finding the path through a dungeon of 100 rooms compromised of 50 tiles each, i could first have it find the path to the room the hero would be in, and have them first work to get to that room by faking the travel (they could move a room closer every 5-10 seconds or something). Once they're about to enter the room the hero is in, i have them appear in a doorway and then finally run whatever AI script I'd need.

I wasn't planning on doing monsters like this, but I think it illustrates one possible use of having "global map data". Another benefit would be ease of editing - I could have a bunch of different room types to work with instead of meticulously editing a bigger map by hand. I was just taking a lesson from Zelda

4. Originally Posted by therobot
I guess that's why I posted the topic to begin - I'm not even sure if I have to go this route. I don't want to go into the project in great detail here, but ultimately, I'd have the option of running pathfinding routines on two different levels - locally, this is, in the individual rooms, and globally, meaning create a route from the room at (3, 15) to the room at (7, 2) while taking into account locked doors and such. The global pathfinding script would work the way any other A* routine might work - but the doors would be a node in themselves that toggle between walkable and !walkable at runtime (of course, in addition to the rooms serving as nodes).

I could just use one massive map of tiles and do my pathfinding that way because I plan to have all the rooms be on one screen, but it'd be useful if i decide to do it zelda style, where each room is one screen.

Say I had monsters following you through a dungeon - rather than finding the path through a dungeon of 100 rooms compromised of 50 tiles each, i could first have it find the path to the room the hero would be in, and have them first work to get to that room by faking the travel (they could move a room closer every 5-10 seconds or something). Once they're about to enter the room the hero is in, i have them appear in a doorway and then finally run whatever AI script I'd need.

I wasn't planning on doing monsters like this, but I think it illustrates one possible use of having "global map data". Another benefit would be ease of editing - I could have a bunch of different room types to work with instead of meticulously editing a bigger map by hand. I was just taking a lesson from Zelda
To explain my previous post (I hope this is what you're looking for). I would have two editors. One for the room and one for the big picture. The room editor would just be a regular level editor. You can then save the room to an.. array I guess. Then in the "big picture editor" you can place rooms on the tiles. I'm not sure what would be better, creating the doors in the rooms or in the big picture. In the second case you don't have to check for doors being wrongly placed.

But I think you have more experience with programming so I'm just saying what I'd do, but I guess you already figured that out.

But anyways, even though this might seem like a long way to go, when it's done you have something you can work with. I don't think it would be too hard to create levels and rooms this way.

I hope this helps

##### Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•