08 Jun, 2009, Skol wrote in the 1st comment:
Votes: 0
An idea I'd been kicking around for quite some time was buildings that are movable.
Think say, tents. Of course the same concept could be used to allow people to actually 'build' cabins and other things.

The thought: An item similar to a 'portal' that the player can set-up and then enter. Teepees, tents, yurts, cabins etc.

Someone had mentioned the make/vape rooms (ok everyone did) in the Wilderness RaM addition thread that made me think about this concept. I'm not sure if the room descriptions would be something 'generic' or something where strings are kept on the item itself and when it's set-up, finds say extra description 'westwall' and 'mainroom' etc and slaps those on the room. Or, have a 'template' room of each kind that it takes it's descriptions from. Or perhaps both, if the item DOES have the extra descriptions, it uses those, otherwise it uses generic.
09 Jun, 2009, Runter wrote in the 2nd comment:
Votes: 0
Well, I think the two main ways of looking at this would be:
A) Code that allows a room to be a different kind of room. (Eg, you walk into aroom and it is now a tent.)
or
B) Code that lets a room be contained by a room. (Eg, multiple tents set up in a single room.)

And this code is actually pretty easy to write, I think, but that's measured by how involved you would want he code to be.
09 Jun, 2009, Sandi wrote in the 3rd comment:
Votes: 0
I have this on my ToDo list as an adjunct to the vehicle code I'm planning. First, I need to make objects you can enter, like MUSHes have. The trickiest part there is the code that lets players look and listen from inside (or 'outside', in the case of a Witch's broom).

Ideas I have listed include having the tent persist when a player logs off. Another player can use the tent, but if he's inside when the first owner logs in, there will be a fight, and the winner gets the tent.
09 Jun, 2009, Runter wrote in the 4th comment:
Votes: 0
Sandi said:
I have this on my ToDo list as an adjunct to the vehicle code I'm planning. First, I need to make objects you can enter, like MUSHes have. The trickiest part there is the code that lets players look and listen from inside (or 'outside', in the case of a Witch's broom).

Ideas I have listed include having the tent persist when a player logs off. Another player can use the tent, but if he's inside when the first owner logs in, there will be a fight, and the winner gets the tent.


In most high level languages this is very simple using inheritance and/or polymorphism. In languages without this, maybe a little more work.
09 Jun, 2009, Scandum wrote in the 5th comment:
Votes: 0
On Dikus it's probably easiest to add furniture behavior, and after that to add an entered furniture option that makes the player invisible to anyone who isn't using the same item.

It should be possible to force mobiles into object inventories by changing the linked list to use void pointers, but it's probably a lot of work to get that working properly.
09 Jun, 2009, KaVir wrote in the 6th comment:
Votes: 0
Runter said:
Well, I think the two main ways of looking at this would be:
A) Code that allows a room to be a different kind of room. (Eg, you walk into aroom and it is now a tent.)
or
B) Code that lets a room be contained by a room. (Eg, multiple tents set up in a single room.)

Long and hard have I tried to decide which of those two options I prefer…

In my opinion, (A) tends to feel more dynamic, as the buildings appear to be a seamless part of the world rather than objects sitting inside a room. It also means you don't need additional support for messages going into and out of the buildings, and it's pretty nice for handling large buildings that are supposed to take up a lot of space (so that you can enter them from multiple locations in the world, and breaking out causes you to exit the building in the appropriate place). This approach also makes it easier for things like using rooftops to travel across a city, and determining where you should land if you fall off along the way.

However (B) allows you to create a TARDIS-like effect (big on the inside, small on the outside), so that you can have extensive and detailed building interiors without having villages that take several RL hours to walk across. This is particularly nice if you want a settlement full of large multi-room buildings that players can actually walk into and explore (or rob), as it makes the whole town feel more interactive.

At one point I had a go at trying to combine the two, so that players could choose to zoom-in if they wanted to explore a city, or zoom-out if they simply wanted to cross it. I couldn't come up with a solution I liked though.
09 Jun, 2009, Runter wrote in the 7th comment:
Votes: 0
KaVir said:
Runter said:
Well, I think the two main ways of looking at this would be:
A) Code that allows a room to be a different kind of room. (Eg, you walk into aroom and it is now a tent.)
or
B) Code that lets a room be contained by a room. (Eg, multiple tents set up in a single room.)

Long and hard have I tried to decide which of those two options I prefer…

In my opinion, (A) tends to feel more dynamic, as the buildings appear to be a seamless part of the world rather than objects sitting inside a room. It also means you don't need additional support for messages going into and out of the buildings, and it's pretty nice for handling large buildings that are supposed to take up a lot of space (so that you can enter them from multiple locations in the world, and breaking out causes you to exit the building in the appropriate place). This approach also makes it easier for things like using rooftops to travel across a city, and determining where you should land if you fall off along the way.

However (B) allows you to create a TARDIS-like effect (big on the inside, small on the outside), so that you can have extensive and detailed building interiors without having villages that take several RL hours to walk across. This is particularly nice if you want a settlement full of large multi-room buildings that players can actually walk into and explore (or rob), as it makes the whole town feel more interactive.

At one point I had a go at trying to combine the two, so that players could choose to zoom-in if they wanted to explore a city, or zoom-out if they simply wanted to cross it. I couldn't come up with a solution I liked though.


Only KaVir would go so far as to simulate rooftop travel and want to determine within 2 inches of where you should land if you fall along the way.
09 Jun, 2009, KaVir wrote in the 8th comment:
Votes: 0
Runter said:
Only KaVir would go so far as to simulate rooftop travel and want to determine within 2 inches of where you should land if you fall along the way.

I'd been playing Tenchu and Thief at the time, and it got me thinking about how boring the thief class is in most muds. I thought that being able to break into people's houses and then escape across the rooftops (complete with Feist-style rooftop battles against rival gangs) would add a rather fun element to playing a thief. IMO it would certainly beat spamming the "steal" command on beastly fidos.
09 Jun, 2009, Runter wrote in the 9th comment:
Votes: 0
KaVir said:
Runter said:
Only KaVir would go so far as to simulate rooftop travel and want to determine within 2 inches of where you should land if you fall along the way.

I'd been playing Tenchu and Thief at the time, and it got me thinking about how boring the thief class is in most muds. I thought that being able to break into people's houses and then escape across the rooftops (complete with Feist-style rooftop battles against rival gangs) would add a rather fun element to playing a thief. IMO it would certainly beat spamming the "steal" command on beastly fidos.


True enough. :P
I think more of ninja than thief, though. :)
09 Jun, 2009, Skol wrote in the 10th comment:
Votes: 0
Runter said:
…B) Code that lets a room be contained by a room. (Eg, multiple tents set up in a single room.)

And this code is actually pretty easy to write, I think, but that's measured by how involved you would want he code to be.

Yeah, that was my original envisioning of it. In my own game I've set up portals so you can 'look inside' and those on the other side see you stick your head in; that gave me the idea of 'hm… tent'. The tent/teepee/etc would be something you could only enter if it was 'set-up' (meaning not held etc heh).

The _only_ thing that has held me back from simply writing the code, is how to dynamically create/free rooms. How to deal with the 'room->vnum', all that. The rest, such as someone tearing down the tent or listening, is cake (comparatively, for me).

Would it be the same approach as simple 'building' a room? If so I'd suppose I'd have to set aside a block of actual vnums that would then be created/destroyed as needed. That seems pretty limiting though, i.e. what if someone wants to set up 300 tents.

Assuming I can get this working, I think it would be a nice addition to RaM. Although if we're stopping at 'fixed RoM' rather than 'continued dev' I understand that, and would simply release it as a RaM/RoM add-on.
09 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
I don't see why you oppose A and B as such different things. Also, I think that KaVir's post is making the strong assumption that all rooms take up "equal space" and therefore having a building means that you need to build space "around" the building – I guess this makes sense given the layout of his game. But on many games where rooms are just places connected on a graph, there isn't any notion of Euclidean space, and therefore there's no reason why you can't go in a circle by going w-w-w-w-w-w-w-n-e-s.

Anyhow, the important point I think is that there's not much reason to treat these two things exclusively.

A room is nothing more than a thing that can hold other things.

If you make a room a "thing" in its own right, then rooms can hold rooms. Check.

Now, since you already have the notion of connecting rooms to other rooms via exits, you can do whatever you want with some rooms behaving "differently" than others in terms of the space they take up (if your game has such a notion).

It's possible I'm missing something, so I'll ask: why are you putting approaches A and B as opposites?
09 Jun, 2009, Runter wrote in the 12th comment:
Votes: 0
David Haley said:
I don't see why you oppose A and B as such different things. Also, I think that KaVir's post is making the strong assumption that all rooms take up "equal space" and therefore having a building means that you need to build space "around" the building – I guess this makes sense given the layout of his game. But on many games where rooms are just places connected on a graph, there isn't any notion of Euclidean space, and therefore there's no reason why you can't go in a circle by going w-w-w-w-w-w-w-n-e-s.

Anyhow, the important point I think is that there's not much reason to treat these two things exclusively.

A room is nothing more than a thing that can hold other things.


If you make a room a "thing" in its own right, then rooms can hold rooms. Check.

Now, since you already have the notion of connecting rooms to other rooms via exits, you can do whatever you want with some rooms behaving "differently" than others in terms of the space they take up (if your game has such a notion).

It's possible I'm missing something, so I'll ask: why are you putting approaches A and B as opposites?


I don't think they're opposite per se. I just think that when people consider the implementation those are two different schools of thought for people wanting tents, furniture, etc-erMeh. I don't think I disagree with you on this, regardless.
09 Jun, 2009, KaVir wrote in the 13th comment:
Votes: 0
David Haley said:
Also, I think that KaVir's post is making the strong assumption that all rooms take up "equal space" and therefore having a building means that you need to build space "around" the building

I think that's a logical assumption for any implementation of (A), otherwise you run into the issue of people effectively warping space whenever they pitch a tent or build a house.

If you want different rooms to take up a different amount of space, then I'd recommend approach (B).

David Haley said:
Anyhow, the important point I think is that there's not much reason to treat these two things exclusively.

The first treats buildings as rooms (you enter the house by walking north), the second treats them as objects within rooms (you enter the house by climbing inside it). You can't really do both at the same time for the same building.
09 Jun, 2009, David Haley wrote in the 14th comment:
Votes: 0
I still don't see why you can't do both. Some buildings will be entered by walking into them. Others can have rooms within rooms, like a crate inside a room. I'm not sure why these are radically different models.

Like I said, you can easily define this almost mathematically. The world tracks a bunch of widgets. A room is a widget that can contain other widgets. Rooms can be connected to other rooms via links we call "exits".
And that's all you need to have rooms that can be in other rooms, and have links between rooms.

I'm just not seeing what the big conceptual problem is here; in fact it seems extraordinarily simple. I feel like you're coming from a very specific game model that I'm not aware of.
09 Jun, 2009, quixadhal wrote in the 15th comment:
Votes: 0
You can do both, but you shouldn't. :)

I prefer the idea that using normal movement commands might make you go into (or out of) areas. If you're inside a house and there's an exit on the north wall, walking north should take you out onto the street. Having to "enter" or "exit" is annoying unless there are multiple choices you have to select between. Even then, unless it's a very specialized thing like a vehicle, it just feels weird.

When I was pondering the idea of coordinates for everything, I concluded that you needed a scale, so that walking south from the street would shift from the 50' street segments to the 10' interior rooms, and leaving town would shift you to the 250' wilderness rooms. Each one would scale movement costs accordingly, but it meant the player didn't have to type 'n' 100000 times to go from one village to another, as they would if you made every single room 10' in size.

If you think of it another way, you could "set" your movement speed, and that would decide how far a single "north" step takes you. If you set yourself to 10' per step, when in the wilderness, you wouldn't actually change rooms until you'd taken 25 steps, but you'd still be changing your coordinates (for whatever good that does you). If you set your step to 250' in an indoor area, you'd have to do bounds checking (or just disallow setting above the scale), or you'd zip through walls… handy for immortals perhaps, but not so good for players. :)
09 Jun, 2009, David Haley wrote in the 16th comment:
Votes: 0
Quote
Even then, unless it's a very specialized thing like a vehicle, it just feels weird.

… but that's exactly what we're talking about, right? Vehicles, tents in a room, etc.
09 Jun, 2009, Skol wrote in the 17th comment:
Votes: 0
For sure, this concept could easily turn into ships that are moving areas etc (within the RaM/RoM framework even). Simply by changing where the item is and where the entrance/exits link to as it moves.

I do like the idea of room sizes (and exit sizes), I put that into my game quite a while back, so you could have a closet sized room, a cubby hole, or a giant auditorium (or a crate heh). Then have how many 'people units' they'll hold, and max size. Make the crate a room that's say 'crate' sized, might hold a halfling/child/kender but not a minotaur. Then it's a TYPE_TENT (or whatever) and it's a room for those who can get into it.

As far as the actual 'room' goes, perhaps expand room structure to have a 'building' object it points to, if that building is NULL it removes said room. Then the objects when created would 'build' in a tent.are file or such, still seems limited if you have to keep it to rooms available. Any thoughts on that within a Rom/Ram game?
09 Jun, 2009, David Haley wrote in the 18th comment:
Votes: 0
In fact, as soon as you generalize rooms to be things that hold other things, you quickly find that a container (backpack) can be represented as a room that has a limited size. You could therefore pick up "rooms" holding people: a giant could perhaps pick up the crate that some character is hiding in. :smile:
Seriously though, I think it allows for lots of very interesting possibilities.
09 Jun, 2009, Skol wrote in the 19th comment:
Votes: 0
Yeah, I was thinking the same thing… mouse in a backpack, guy uses a shrinking spell and hides in your bags heh.
Again though, with the usual 'rom' method, you'd be out of rooms in a hurry.

That method with size being approximated, would go a long ways. Perhaps item types then would have a 'size' or how much space they take up, all of a sudden space makes sense, yeah not a bad thing.
09 Jun, 2009, Runter wrote in the 20th comment:
Votes: 0
Skol said:
Yeah, I was thinking the same thing… mouse in a backpack, guy uses a shrinking spell and hides in your bags heh.
Again though, with the usual 'rom' method, you'd be out of rooms in a hurry.

That method with size being approximated, would go a long ways. Perhaps item types then would have a 'size' or how much space they take up, all of a sudden space makes sense, yeah not a bad thing.


We've come a long way, baby! … well, from stock rom. ;)
0.0/24