I'd like to address this in a separate thread.

While I have a history of building graphical tools and interfaces, I have always tried to make it very clear that my points are aimed at getting people to think about improving UX in any context, whether pure text or pure graphics. The sky is the limit to how much you can improve even simple text / CLI user interfaces, and I've often in the past picked the subject of fast-scrolling text as one example where every MUD dev, even those radically opposed to any graphics, can improve.

It's an easy reaction to say that I'm pushing for graphics, or that my examples are only valid for graphical UI's. But the thing is, they are not. It is abundantly clear to me that the things I was describing are equally possible in plain text interfaces as well.

In the example of OLC and VNUMs, you can improve on the vanilla 1990's OLC of any MUD to offer a building experience where nobody, visually impaired or not, ever has to worry about remembering the unique id of anything:

One example (that I believe some folks have actually implemented) is a "room-painting" mode where the builder toggles a flag and starts moving around. Each move either generates a new room, or links up to an existing room that has already been placed at that position in the "grid". Or, you could just improve your existing "dig" command to prompt the user to link up if a room already exists "there" or to override and place the room in a non-Euclidean position.

Putting code in charge of linking up rooms and collision checks is a no-brainer. It not only takes human error in inputting VNUMs out of the picture, it also makes initial room layout x10 faster. And you don't have to show an actual grid to the end user to accomplish any of this.

Another example is setting an object to load in a room, or on a mobile. Rather than ask the user to input the unique id of said item (which is just a bad punt on the part of the person who designed this tool), you could offer a menu to run a search for the item, and then list the results for the builder to pick from. There is 0 need to show VNUMs anywhere in this process.

From a UI designer point of view, confronting non-technical folks with geek stuff like unique id's is an obvious no-no, graphics or no graphics. You have never been asked to remember and input your unique Facebook user id, just like you have never been asked for the Linux user id of the user you want to page.

In the context of poorly designed OLC tools, the LPMud approach was marginally better than the Diku one. But the real lesson here is that it shouldn't matter to any human being what the system's unique id for an entity looks like. And it's a valid lesson even for folks who feel comfortable and endlessly forgiving towards vanilla OLC.

I don't care about smart mapping or build walking or whatever the dozens of different implementations have been called. I basically take that for granted as existing in any OLC now. Quix threw it out as a counterargument because lolDiku and it's still 1994 in his mind. The part I don't grok are these menus you reference. How do those work in a way that doesn't require the user to remember aliases to game objects? I can see it working in an intelligent way with graphical tools where you can click some check boxes to narrow down properties, then drag and drop things.

Dropdowns, checkboxes, drag-drop are all very nice, but they're really just icing. Underneath it all, you just need a good way for users to look up items instead of having to remember their unique id's. For example, right now, when I try to set an item to load on a mob via OLC, I get this:

Enter choice : j
C) Create New Equipment
D) Delete Equipment
Enter number to edit [0 to exit]: c
Insert after which equipment [0 if first]: 0
1) Position
2) Chance Load
3) Object Virtual Num
4) Max Existing

Current Equipment: E -1 0 -1 0

Enter Choice [0 to exit]:3
Enter object number to load:

Let's set aside for a moment that if I was a newbie builder, I would have been thrown off by having to type 0 for first item, something that the system shouldn't even need to ask because it knows there are no items currently listed…

At this point, OLC is asking me to remember the unique id of the object I want to load. It really doesn't matter much if that id is a number of a string, because as a human being I may or may not get it right.

Now, the code is already able to do this:

vnum o crystal
1. [ 2590] a ward major
2. [ 4415] a crystal key
3. [ 8345] a crystalline key
4. [ 8369] a ring of lordship
5. [ 9506] the Crystal Trident
6. [10146] Anklet of Crystal Steam
7. [14402] a necklace with a crystal set in it
8. [15303] the crystal of Darkness
9. [19880] a tiny crystaline dragon
10. [20532] the Crystal Shard
11. [20546] the key to Hell
12. [20632] a Chromite crystal
13. [24247] a crystal chandelier
14. [24503] a key with a crescent moon inset
15. [24833] the crystalized goblet

It begs the question, isn't it an obvious improvement to OLC to simply hook it up to the lookup command at this point? Why ask a human being to remember and input the correct unique id, when you can help them pinpoint the item they want to add? If the search matches too many items, you could even offer the user a choice whether to list only items within the current zone, or world-wide. After that, he or she can just pick from the list, for example #6, and be confident that the correct item has been added.

And MY point was… if you have to look up the vnum to figure out which crystal is the one you wanted, then the vnum concept is pointless. Why not have the identifier be "the crystal of Darkness"?

Yes, I used LPC as an example because I'm familiar with it, and I think a hierarchical naming scheme makes a lot of good sense for most MUD environments. It's not arbitrary, or just because of some antique filesystem concept.

"/d/Shylar/rooms/BackRoom" is a hierarchy, so if you have multiple "back rooms" in your game, you know this particular one is the one in the Shylar area, and that it's a room and not the "BackRoom" key, door, or designer coffee mug.

You could just as easily make it "Shylar.BackRoom" or "rooms:Shylar:BackRoom" or even "rooms[Shylar].BackRoom". You could use a more textual description like "The back room of Shylar's Inn", which would also be a unique and easy-to-read identifier.

What do vnums gain you? What's their point? The game driver doesn't care. A std::map does the same lookup for a vnum as it does for a string. If you're using a plain array, you have to convert from vnum to array index anyways, so no benefit there. If you wanted a specific object, you'd use the UUID, so again… what do they actually DO?

Maybe a few humans like numbers more than strings. Great! If you can remember 20K different vnums easier than a short text description, especially 5-10 years later, more power to you. I feel sorry for anyone who might work on your team, since THEY probably will have to spend lots of time looking things up.

SO, back to the point… in your fancy OLC that already shows you the lookup to your search as a selection menu… why would you not list those descriptive strings instead of the vnums? Surely any menu or drop-list would be easier to use if it had a sorted list of descriptive strings?

I want to edit "the legendary sword of doom".

> vnum 'legendary sword doom'

[343411] the legendary sword of doom

> oedit 343411


Not really sure how that constitutes spending "lots of time" looking things up.

As Lyanic observed, I think you're very much stuck in the "us vs. them" mindset. The point I'm trying to make is that human beings shouldn't have to worry about:

1. Coming up with identifiers for new entities and testing whether they are really unique.

2. Having to remember identifiers so they can provide a reference to those entities.



If you are making strides towards a truly user-friendly content building experience, then it will matter very little (as in not at all) what kind of system is used to uniquely identify entities. Think about it.



Why should you ask the user to come up with a unique identifier? What if there are 10 back rooms in Shylar already and a new builder wants to add another? Why would you ever want to do that to a fellow human being, force them to do an inventory of unique id's in the area just to come up a new unique string, or number, or string + number for the new room when the server can generate and verify a unique id in nano-seconds? It can even generate the kinds of unique id's you are showing, but that's beside the point. The point that you seem to keep missing is that the debate of vnums vs. strings is just a distraction here, because neither approach offers any distinct advantage to solving the issue. The issue is solved by never letting users (even implementors) worry about unique id's, period.



Why should you have to remember anything? As a game designer, you should have a clear understanding of why you need unique id's in the first place. Practically speaking, they are needed to disambiguate between entities, and to provide a way to persist references to entities. If you are asking content creators to remember 20k of vnums, that's because your tools are hastily put together. If you are asking people to remember that they set some room id to "rooms:Shylar:BackRoom11" and not "rooms:Shylar:RoomInBack1", that's because your tools are hastily put together.



I'm shocked that you can't see the limits of your thinking here. Of course I can show some other room property instead of the vnums. I can show whatever property helps the user disambiguate and select, and I don't need to have a human-readable unique id to do that. Whether the id is a simple number, or a string of concatenated properties, or a random sentence in Swahili is irrelevant if you have what today are considered standard content creation tools.

Look at how and why SQL and NoSQL databases handle unique id's, and you'll realize that the whole VNUMs vs. LPMud strings debate is from another era.

If you are only using OLC to create and edit content, I would venture a guess that spending a few hours to integrate lookups into the building flow is going to pay itself off in less than a year. Time savings are only part of the equation here. I strongly suspect that just having improved the workflow is going to make a psychological difference for builders who want to be creative, but are dreading the fact that they are asked to perform unnecessary extra steps at every turn.

@Hades Kane, why not just:

> oedit "legendary sword doom"

Why make me use the vnum? If the string is unique enough to only produce one result, why add another identifier when you already have one? If it's NOT unique enough, then you STILL have to go look at each "vnum" to figure out which one is actually the one you want to edit, no?

What's the point of the vnum? It seems redundant.

@Planzi, I started to type up a long reply, but then I considered that I believe we're arguing two different viewpoints in an apples and oranges kind of thing.

I agree that from the CODE point of view, it makes no difference what you use for an identifier, as long as it's unique. It could be a vnum + an instance UUID. It could be anything else. The code doesn't care.

As you say, if you use OLC, it should provide you with all the lookup tools, hopefully integrated into the actual bulding process so you don't actually need to look things up, but just select them from whatever menu/list/etc your OLC provides.

Where I find the descriptive string identifier to be useful is when you're trying to audit an area for approval, or when hand-loading things. I suppose you could create a fancy version of look that would also list exit linkages and other details, but I think you'd end up creating fake string identifiers in the process of displaying that data anyways.

Quix - there are plenty of instances, of course, in which an item won't be that uniquely named. An easy solution to that is to provide, alongside the vnum results, the name of the area. IF that still isn't enough? There's something on the building side that needs to be addressed.

Additionally…

> goto <areaname>
>redit
>olist sword

It's trivial with regards to time on finding objects and such, and there are enough things built into OLC (and a few other easily added additions) that makes working with vnums quite easy. In fact, when learning to build, that was the easiest concept and part of building an area for me to learn and grasp, anyhow, once I got past the initial "more than one thing can have the same vnum" with regards to rooms, objects, mobs, etc.

I'd like to also chime in with the fact that maybe I want to create two legendary swords of doom. Then I'd have to remember the special name I used to differentiate between the two. Using just a string is a lot messier in practice than you're claiming, and you know it. You can go ahead and tell me I'm wrong, though, due to the spacial alignment of some stupid shit tangent no one gives a fuck about.

Let's keep the tone civilized, please.

I would also like to try and steer the conversation towards the topic a bit. Let's say that everybody loves their current unique id system and sees no need to make it more user-friendly. What are some other ways in which you do think you can make a text-based UI more user-friendly, maybe by questioning something in your code that "has always been that way"?

As an example, we recently started thinking about a way to radically de-spam combat. What if someone just wants to see what is important / actionable information during a fight? So we came up with a kind of summary combat mode idea, where instead of seeing each and every action, periodically the player will receive a status update on how they are doing. At the end of combat, they will see another summary, complete with useful information such as average damage they dealt, etc. Of course, we also thought this mode should be optional, since the majority of our current playerbase is likely addicted to the combat flood they've been seeing for years. But what if we managed to make the summary mode show really really useful stats that they would be tempted to toggle?

Along those lines, a very popular addon for World of Warcraft was "floating combat text". Blizzard eventually incorporated this into their native UI. What this did was show damage numbers that were being done to you over your head, and damage you were doing to others over their heads. These numbers moved (up or down) away from their point of origin, fading as they moved. Damage drifted up, Healing drifted down.

Now, what made this very useful was that larger hits (or heals) were rendered in a larger font, and drifted away at a slower speed. Critical hits were in a different color and popped into place, lingering without moving for a time.

Bringing that idea to a text UI, I would be tempted to rank things by percentages of the target's health and allow the user to set a threshold of how much detail they want to see. The default (like a normal MUD) would show everything, just like it does now. But if the user really only cares about big hits that need attention, maybe saying "only show me hits that take 20% of my health or more" would reduce the spam. At the same time, you would probably want to see threshold values, so as your health drops below 75%, print a warning to that effect. Chances are you also want to know about status effects like poison and so forth, so they can be cured or countered.

All the player wants to know is whether they are winning or losing. Might take the fun out of things if you report exactly that.

It could be considered somewhat of an in character ability to have access to that kind of information, knowledge of the particular creature you are fighting, etc. Such a system would naturally reduce spam.

Heh, the problem is… it would work in exactly the opposite way most players would want it to work. When you're fighting something unknown, for the first time, you probably want to see lots of detail so you have every chance to react to what it's doing. Once you've killed our 2000th goblin, you just want to see the "dies" message so you can "get all corpse" and find more.

BTW – that's another avenue that can be improved upon. Corpse looting.

I'm of the opinion that you should just automatically loot any money, and any obviously benign items that you have room for. Items that are unknown (might be magical, might be cursed, might be poisoned) should be the only messages you see, so you can decide to deal with them, or leave them. Also, a summary of items that you would have picked up if you had room in your backpack.



No point in making you type "get all corpse" or "get gold corpse; get sword corpse…." You know you will. The game can know that too.
But, at this point, you can decide to drop something if you want the dagger, or more apples. You can also decide if you want to investigate the bracelet.. maybe by casting detect curse or detect magic on it before you try to pick it up.

This seems like a flawed argument to me. For simplistic/ease of code, in my opinion everything having a unique ID is superior than a unique string.

Then, from an olc standpoint, why not have it take both either the ID or the string. For example:

invoke 500, invokes entity with unique ID of 500.

invoke sword
(open sub menu)
0) sword of truth
1) sword of justice
2) sword of ridiculous arguments
player inputs 2 and that sword is invoked.

If you want a user friendly OLC, make it do both. This way it fits many users preferences, its not hard. You can put an entire menu system in and use it for all kinds of fun things not just building.

AS Quix said, if there is only one just make it selected by default. Not doing it means you don't use olc a lot.
I tend to code those candy as soon as I can. It really saves valuable time.
Especially since all the code is already there. Just need a counter and if ofind only hit 1 occurence, just call the oedit function.

Even better when you oedit and there are multiple occurence of the same 'sword', oedit shoudl select the one that is in the area you are already editing. (show the others though)
Everything that makes life easier for the builder should be coded, especially since it is really easy to code those.

But what if I was looking it up to oload it?

Edited my post, it was indeed missing something to make it clear.
You should not need to ever call 'vnum 'sword of doom' fr when you want to edit one.
You should only 'oedit 'sword of doom' and at worst oedit vnum only if there is multiple possibility AND the one per default is not the one you want.

and for olaod same story, but just not automatically load one if there is multiple choices. (at least the first time you call it)
Though that could be adresses too.
Multiple possibily: show them.
One only: oload it.
Call the function twice in a row with same argument: oload the first possibily if there are multiple choice.

Computer are there to automate actions. Not using them for that is a waste.

I apologize for the thread necromancy here, but I am considering writing a new OLC so I find this discussion really relevant to me.

I really don't see how it's possible to do away with unique identifiers (even from the builder's perspective) without introducing complications or ambiguity.

There seems to be a lot of drifting into the debate of VNUMS vs unique string identifiers, and rightly so. I personally don't see any other option to having SOME sort of unique identifier. And, unless I have overlooked it, I don't see a single alternative suggested in this thread.

What is the other option? The hierarchy system that LPC uses has its own set of disadvantages.

In OasisOLC (my preference of the existing OLC systems for CircleMUD)

> olist
Index VNum    Object Name                                  Object Type
—– ——- ——————————————– —————-
   1) [41400] an iron hand-axe                               [WEAPON]
   2) [41401] an iron shortsword                             [WEAPON]
   3) [41402] an iron longsword                              [WEAPON]
   4) [41403] an iron battle axe                             [WEAPON]
   5) [41404] an iron warhammer                             [WEAPON]

> load object 41403

which does not seem to me to be more cumbersome than the LPC MUD's approach which as far as I know must be done in a way akin to

> ls
/wiz/roobiki/areas/goblin_dungeon/:
iron_shortsword.c    iron_battleaxe.c    iron_longsword.c    iron_handaxe.c     iron_warhammer.c

> clone iron_battleaxe.c

In fact I vastly prefer the VNUM approach because the latter system involves navigating the file structure when loading objects from other areas.

Maybe I'm just missing the point of the thread?

Ok, I realize there was an alternative suggested. Would it be something like this?

> load iron
Index Object Name                                  Object Type
—– ——————————————– —————-
  1) an iron hand-axe                              [WEAPON]
  2) an iron shortsword                            [WEAPON]
  3) an iron longsword                              [WEAPON]
  4) an iron battle axe                            [WEAPON]
  5) an iron warhammer                            [WEAPON]

Which iron? 3

You load an iron longsword.