Separate vnum ranges in a Diku/Merc derived mud

[caius]

My code is based on SWR, but it has the same general setup as older codebases, where each area has a range, or block, of vnums. This has some limitations for my purposes. It makes it harder to make instanced zones (because you must translate all vnums in the original area), and it's also hard to expand an existing area's range if there's an area just below or above it.

So I want to give each area a separate range, that can never collide with other areas.

The steps I've taken so far:
* The list of prototype mobiles, rooms and objects are stored in a list inside the area it belongs to, rather than a global list.
* Vnums are referred to as type 'Vnum' rather than an int. Vnum is, at present, simply a typedef for unsigned int.

At this point I'm a little unsure of how to proceed. The plan I have in mind now is to encapsulate each vnum into a class that refers to both the area it belong to, and an identifier for the room/object/mobile. This data pair could be stored as pointers, numeric identifiers, or something else. I'm not sure about that yet. So from inside the game, a Vnum could be referred to as something like "my_area:20", where 20 is the room/object/mobile. The exact syntax is not important at this point.

I'm interested in any thoughts, ideas, feedback, potential problems, etc on this issue. For any implementation details, C++ is the language.

[Deadsoul]

You might be better off storing individual folders per zone segment. that way you can keep track of each zones mobs, loot and rooms.

that way its something to match against the struct *vnum, while also avoiding collisions later on (after things grow).

[caius]

How to organize the areas on disk has never really been an issue. And at any rate I can't separate anything into directories since I have everything in a PostgreSQL database.

I went ahead with my original plan, though, and it has worked out pretty nice. I still have a few challenges that I'm working on, but for the most part everything behaves as expected.

What I find interesting is that the majority of the people I tell about this project of mine reacts strongly in a rather negative way. I guess it's easy to grow attached to something. But I have already reaped benefits from this new setup, and I know I will get more out of it still.

Thanks for the feedback, though