[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  MUD Design Concepts
. . -> [Subject]  how do vnums work?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

how do vnums work?

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Xtian   (53 posts)  [Biography] 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
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Nick Cash   USA  (626 posts)  [Biography] 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
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] 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.


6,494 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]