I am making a game at the moment, it has pretty much in common with a MUD. These are my questions:
How the f*** am I supposed to make the rooms?
(I know they should be areas, right?)
I need to be able to create rooms and exits on the fly, any number of rooms with say max 10 exits each. How?
How do I move people between the rooms?
How do I save the created stuff( and player locs) to a file?
I probably have more questions, but these are the ones that come to my mind ;>
ID:150968
 Jun 20 2001, 11:57 am
|
|
On 6/20/01 3:54 pm Abraxas wrote:
No....BYOND doesn't internally support text-muds...you have 2 choices... one is to download the MUD library, the other is to make it yourself..you'd start by writing a Room datastructure.. You can make a perfectly good MUD using areas as rooms. I have. Here's a simple look: area/var/eastexit area/var/westexit area/Room1 name = "Pool hall" desc = "You see lots of people playing pool here." eastexit = "Foyer" area/Room2 name = "Foyer" desc = "This is the entry." westexit = "Pool hall" area/New() tag = name mob/verb/east() if (!loc:eastexit) usr << "You can't go there." else loc = locate(loc:eastexit) mob/verb/look() usr << "[loc:name]" usr << loc:desc And there's no need for the masked vulgarity. We'll understand you just fine without it. ;) Z | |
On 6/20/01 4:09 pm Zilal wrote:
On 6/20/01 3:54 pm Abraxas wrote: In fact, areas were designed with the intent of being rooms in text MUDs. | |
On 6/20/01 5:22 pm LexyBitch wrote:
In fact, areas were designed with the intent of being rooms in text MUDs. I could be proven wrong, but that's my recollection from reading the DUNG (pre-BYOND) docs. | |
ok here is some more specific stuff:
now I have the Rooms as their own class /Room. what I am working on right now is the verb for creating actions on the fly, this is what I need (I think): create_action() get a pointer to the current room check if the room has space for more actions (10 is max) make an INPUT for description of the action store that in the actions list ask the player if the action is leading to a new room or one that already exist if the answer was "new" store the next free roomID in the actions list AND go to create_room() if the answer wasn't "new" prompt the player for the ID number of the destination room. store that in the actions list I would be very grateful for all help ;> | |
On 6/20/01 4:09 pm Zilal wrote:
On 6/20/01 3:54 pm Abraxas wrote:cut... area/var/eastexit The problem with this method would be that every rooms are hard-coded. What about soft-coding of rooms? What to save them? Like in the character-saving demo? | |
The problem with this method would be that every rooms are hard-coded. What about soft-coding of rooms? What to save them? Like in the character-saving demo? Remember that you don't have to adhere to the standard ATOMic objects. With datums, as Kaidorin (the Majorly Non-Newbie, regardless of who doesn't remember him =) clearly is using, you can make your own system, creating and removing rooms as necessary. Areas can't be created, per se, at runtime. The only difference with a datum system and an atom/area system is that atoms have a loc variable that points to the area. But with a tiny bit of work (in my late text MUD, I used datums and it took me about 2 hours to have a fully-functioning system), you can have a datum-based system in no time. Take Dan's MUD library for instance, a good example of a datum system. | |
With datums, as Kaidorin (the Majorly Non-Newbie, regardless of who doesn't remember him =) clearly is using, you can make your own system, creating and removing rooms as necessary. Areas can't be created, per se, at runtime. Um, please don't tell LexyMUD or my text mud this, as both of those rely heavily (the text mud more so than LexyMUD) on run-time created areas. I tried datum-based rooms for a while, but then realized I was basically reinventing the wheel. Or the area. Whatever. The point I'm making is that the atomic types have all sorts of nifty things like name and contents and desc already hard-coded in. | |
On 6/24/01 6:48 pm Spuzzum wrote:
Areas can't be created, per se, at runtime. Areas are funky, but I think they can be created at runtime. | |
On 6/25/01 9:14 am Deadron wrote:
On 6/24/01 6:48 pm Spuzzum wrote: Hence the "per se". =) They don't function like regular objects; they have some weird quirky bits. Yes, you can create them, but you can't create them per se. Anything can be instantiated at runtime. It's just that areas are strange, in that the hard coded ones exist and don't exist simultaneously; they aren't actually present until you edit their vars or something, but then they're automatically instantiated without the need of a new() instruction. The soft coded ones can be created as desired, but they're annoying to save in my humble opinion. I say avoid the whole mess and go with datums. Just have a global list that points to all of the rooms, and you're set. | |
No....BYOND doesn't internally support text-muds...you have 2 choices... one is to download the MUD library, the other is to make it yourself..you'd start by writing a Room datastructure..it's a LONG explanation..read the guide and reference manual...
It can be done, but you need everything before it working to even THINK about it...so ask that once you have a room structure
have characters have a "location" that points to a room... you 'move' by changing that location value
that's savefiles..there's at least 2 or 3 tutorials about them
Well, ask more specific stuff once you get to the point that you can :)