Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUDs
➜ MUD Design Concepts
➜ how do vnums work?
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Xtian
(53 posts) Bio
|
| Date
| Wed 17 Feb 2010 09:07 AM (UTC) |
| Message
| We are thinking of implementing vnums or room numbers in our MUD. Unfortunately I never played or worked on a MUD that used these, so I have no practical understanding of how these are applied. I would apreciate your helping me out.
How does your MUD use vnums?
How does your client/mapper process them?
Do they have to be continuous for adjacent rooms? Do you use path finding based on these numbers or on the whole topology?
Does this data even have to be numbers? Could it be in some form of encoded strings?
Do you use similar schemes for other objects and NPCs?
Thanks,
xtian | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #1 on Wed 17 Feb 2010 01:49 PM (UTC) Amended on Wed 17 Feb 2010 01:50 PM (UTC) by David Haley
|
| Message
| Vnums on my MUD (and indeed basically all Dikurivatives) are quite simply identifiers for rooms (and object/mob prototypes) that happen to be numbers. There are no requirements of adjacency or contiguity. They are irrelevant to path finding. Vnums, as numbers, are allocated in chunks, so that you can say things like "vnums 100 through 300 belong to the 'elf village' area". (This is organizational, really, and doesn't have other consequences.)
Basically, vnums, like any identifier, are just convenient way of referring to things. They are particularly useful for rooms, which are guaranteed to be unique, referring to mobs/objects by vnum can be ambiguous as there can be several copies of a given entity.
Vnums as numbers are really not that great, because as you allocate them in chunks you eventually find that your chunk is too small, but then you can't grow it because you have adjacent chunks. You can't distribute the areas, because other people might have things with those numbers already. They've been historically implemented as signed short integers, meaning that you only have ~32k of them (which is really not that much). Also, I personally find vnums rather hard to remember. String identifiers are somewhat more robust to things changing internally; the name "darkhaven.townsquare" will always refer to a place even if that room is deleted and recreated somewhere else. With vnums, you have to be careful that you recreate things at the same number.
Most games in Dikuland do not expose vnums to the clients, so mappers don't use them. (I think it's generally considered to be extra information that the client can "cheat" with, by seeing for example that two rooms with the same description are in fact different rooms.) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Cash
USA (626 posts) Bio
|
| Date
| Reply #2 on Thu 18 Feb 2010 03:29 AM (UTC) |
| Message
| Since you are thinking of implementing vnums, you are in a unique situation. You do not need to be afflicted with the painful way that Dikurivatives use them. As such, you can avoid some of the problems David has outlined. For instance, you could have your MUD automatically number rooms for you, thus taking out the range assignment and the need to grow it over time. Organizationally this might be harder to maintain, but overall it probably wouldn't matter since you probably have a method in place to create and manage areas without them. You also do not need to implement them as signed 16-bit integers (which is one of the first things I change if I grab a Diku base to play with), giving you a far greater range of possible values.
As for being hard to remember, this is true. However, it is easy to make a lot of aliases or simply implement additional string identifiers. While vnums are rather antiquated, I do enjoy having unique identifiers per object that I can use in a quick and dirty manner (such specifying a range and instantly creating 100 rooms). Combining string identifiers and vnums would make me particularly happy, and really would not be hard to implement.
All of that said, this is all just the Diku way. If you have no vnums, the real question is why do you want them and how do you want them to work? |
~Nick Cash
http://www.nick-cash.com | | Top |
|
| Posted by
| Xtian
(53 posts) Bio
|
| Date
| Reply #3 on Thu 18 Feb 2010 03:50 AM (UTC) |
| Message
| I am looking for ways to get unique and persistent object identifiers to the players/clients. As I understand it, MUDs that get their content from databases use such IDs as database keys anyway, so they can just pass them out to their players.
In my LP-world our object access is path driven, so I could build unique IDs around that, but obviously I really dont want to open our file structure up to players.
Room IDs are a bit special, as I guess that Mappers do some magic with them? But none of our users really use those, anyway.
So, vnums are really an Diku internal representation. I didnt know that. Hmmmm ...
Anyhow, thanks for the informative answers. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #4 on Thu 18 Feb 2010 05:42 AM (UTC) |
| Message
| I don't know if vnums are a Diku-specific concept. But certainly all Dikus use them.
I will point out that vnums aren't used for individual instances of mobs and objects. So there really is no way for a user to uniquely identify a very specific mob/object, short of terrible notation like "2.goblin" which means the second version of the thing denoted by "goblin".
My preference is to namespace things by area name, or really to use string identifiers that are guaranteed to be unique. I have no real issue with something like "elfvillage.elf2".
Anyhow, if your goal is to get globally unique identifiers for objects to communicate to clients, then vnums -- as Dikuland understands them at least -- are not what you want. You could get away with some session- or inter-session unique identifier, I would imagine.
As for getting content from databases, it's important to distinguish between getting your prototype content vs. the instance content. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
20,345 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top