I've been thinking hard about how I want to do exits for my text-based game, and I am having a lot of trouble deciding which will be better for me. Out of all the ideas I've come up with, two stand out to me, and I'm not sure which is better than the other and why:
1) Exits as room variables. A room has a variable called exits[]. The contents of exits are lists named as the exits' id tags.
Example: /room.exits[cave[],oakdoor[],stairs[]]
Each item in the list is an associative list that contains the exit's properties.
Example: /room.exits[cave["name"="A small cave","direction"="east","dest"=/room]
"name" is the name of the exit, as displayed in the room's description. "direction" is the cardinal direction, if any. "dest" is a reference to the room the exit takes you to.
2) Exits as /exit datums. The information would be almost exactly as the idea above, except the exits[] variable would contain references to exit datums. All the exit properties would obviously be in /exit.vars.
So, I can't decide which is better, if any is better. The first option seems bad because it makes /room so information heavy, but the second idea seems bad because it creates so many objects when the MUD is loaded. Each exit is a separate object, even the return exit!
Any suggestions or input from some who have been this way before would be most appreciated.
=$= Big J Money =$=
Edit: By the way, I am going to be using a command parsing system (ie. not Byond verbs), so that I can have the Builder create exits that can be typed in manually. If a room had an exit called "crack in the cave wall" the player would actually type "crack" or a shortened form to take the exit
Edit#2: I am NOT using the Byond standard movement commands, I am overriding them. Cardinal directions are all relative to my own MUD and how I plan to implement them. They are also optional, as many exits will not even list a cardinal direction at all.
Edit#3: This isn't near the amount of data that exits will have. By the "end" (do MUDs have an end?), I'm estimating an exit will have around 20 variables, besides the three original ones I've listed here. Sorry for that confusion.
ID:153035
 Mar 15 2005, 3:41 pm (Edited on Mar 16 2005, 5:47 am)
|
|
Maybe I didn't explain my situation enough. My room exits cannot be defined in the script, they are soft-coded through an OLC program. That's why I used the term "Builders". I want them to have the power to create whatever exits they so choose. It needs to be much more flexible than exits.Add("staticinfo").
Maybe I'm just too sleepy now, but I can't see how you caught that. =$= | |
Using datums would be a LOT easier to manage. All you'd really need to house in it, though, would be the direction (or special exit keyword), perhaps a short description describing the exit, and a reference to the room in that direction (most MUDs just use integer values to reference rooms), and the status of the exit (open, closed, locked, destroyed, etc.). From those four items, you can derive just about any information that you need about the adjoining room.
| |
Then modifiy it to work with whatever you use. But the same principle still applies... keep the data in variables owned by the datum and just have an associative list of exits instead of keeping all the information multiple times in exit lists for different rooms.
| |
Actually, my exits are planned to have a lot more information than that. Here are only a few vars I've come up with so far:
desc: Displays message when looked at upon_exit: Displays message immediately before walking though upon_enter: Displays message immediately after walking through *Note - You might think that I can get by with using Enter() and Exit() for this, but I can't, because I want each EXIT to have a special message, not simply leaving and entering the room. Those will be put to good use as well, I might add. trans: Short for 'transparent'. Basically, can an exit be seen through into the next room audio: Does sound travel through this exit? open: Is the exit opened or closed. This defaults to 1, and is only ever set to 0 if the Builder wants to have a closed door, for example Edit: Now that I think about this one, it might be better to have a var called closed or door. To save memory, this variable wouldn't even exist if the exit doesn't function as a door. size: What sized cretures can get through this exit In the future, I will dream of others. Probably things like whether skill checks are required to navigate the exit; what keys are required to open the closed exit; if the exit is trapped or not; etc.. etc... The point is, exits have the potential to have a lot of data on them, and I still want to make sure turning them into objects is the most efficient way to do it. Thanks for all the input so far, =$= | |
There is something you mention here I'd like to comment on too, if I may. You say that most MUDs use an integer value as a reference. With Byond, I have the ability to make a direct reference, and I also have the ability to use tags. Do you see any reason in particular why I should go with the typical MUD's integer-based reference? I've been wondering about that as well, lately. I think I am going to use tags and make sure they are unique from zone to zone. I can't imagine making very many inter-zone room calls.
=$= | |
The only problem I'd see with using reference-based storage of rooms is related to savefiles. Each room that you save would save the rooms it referenced (which would be redundant), so you'd wind up with HUGE save files. Now, with a tag or integer based system, you don't run into this problem, since you're just saving a number or a text string. Personally, I prefer integer-based systems for muds, since that's what I'm used to, but the choice is really up to you. If you're up for having more realistic 3D space in your MUD, maybe you could even consider a 3-Dimensional list. This method would assume that any room "touching" the current room in the array could potentially be accessable, if their was no "obstruction" between them, and would essentially allow for 26 directions of exit (3 sets of 8 cardinal directions [1 on the same plane, 1 going at an upward slant, 1 downward], and straight up or straight down). Now, this system would be best used if rooms would all be representing areas of a uniform size, but would allow players to create exits by mining/destroying/maiming walls... pretty handy. Oh, also, to respond to your thread about variables for exits, I still say you should stick with just the 4 basics, and handle messages/audio/special events with separate script objects (just a suggestion from the wonderful world of MUD OLCs :) ). Anyhow, good luck, it sounds like you've got a good head on your shoulders, and that you're really putting some thought into this.
| |
First of all, thanks for all the input on my post about the references. I hadn't quite followed that logical chain of thought yet. It would have sucked if I'd have let it creep up on me.
Quoting Igmolicious: "Oh, also, to respond to your thread about variables for exits, I still say you should stick with just the 4 basics, and handle messages/audio/special events with separate script objects (just a suggestion from the wonderful world of MUD OLCs :)" Ugh, you have to bring up script objects at a time like this, don't you? Heh. Well, here was my thinking: I want to make it so the Builder can fill out a quick series of forms and "Presto!", their room and exits are all created, along with full implementaion for the game's features. I was going to save script objects for things that call special occurences; things that don't happen in most rooms. Resource deposits, possible quest initiation, and FOE spawns are a few of the things I can think of right now. Keep in mind that I'm actually not trying to make a MUD, per-se. I'm trying to make a very MUD like text-game that uses Byond's programming features to their fullest to achieve things that classical MUDs cannot. Maybe that's not possible, and I just don't know quite enough to figure that out yet :-/ That might explain why I tend to ignore advice that uses MUD code bases as their validation. Most MUD bases were made on PCs with nowhere near the CPU and Memory bandwidth we have today. =$= | |
Then connect the elements to their objects.
Something like this might do, if you only have one room per room-type. If not, use a tag system instead, which would still be based off the same principle.