Member Discussions

Which is better: Loading all your rooms into memory at once or reading them from a file as they're called?

I would say loading to memory would be better depending on the size of the MUD . . . but I could be mistaken.

'Better' is a subjective term, depending on your needs of the moment.
Bootup loading pro: Once all the rooms are, the requested room description and associated scripts, items and NPC's and their scripts and items are quickly available. If you have background processes working such as digging NPC miners or other such things that do not require a PC to be in the vicinity, then loading all the rooms at one time is 'better'.
Bootup loading con: Consumes more memory, possibly memory that would not be used for more than a few minutes per month, especially if you have a lot of areas that are rarely visited. Also slows the bootup process considerably.

I would suggest you do a little research to determine which way would be best for your unique needs. If you have a large playerbase but rarely require reboots, then perhaps loading them at bootup might be the best way to go. You might also want to add some sort of statistical data function to your game to keep track of what areas are used the most and perhaps load those at bootup and the rest when needed.

Have a lot of fun!

> Which is better: Loading all your rooms into memory at once
> or reading them from a file as they're called

Lazily loading them is generally better. Your mud will be able to scale to billions of rooms without excessive load times and memory footprints. Loading everything at boot is just an unnecessary optimization, spurred by a lack of an abstraction in Diku for finding and iterating over rooms.

Taking that first step into an area can make for a wierd pause though. This could make it feel weird for people on the MUD.

With proper segmentation, there is no noticeable pause to the user.

Kelson

I pointed this out in a previous thread regarding area loading but fairly simple optimizations help here: set a 'perimeter' for a given room (or coordinate, or whatever), so that the room is loaded not when someone enters it but e.g. when someone enters any of the adjacent rooms in a n radius (in expectance of this room being needed soon). Areas or other intensive tasks could then even be loaded in a separate thread, if necessary. Additionally, simple heuristics could be used to try to determine whether it's necessary to load or not.

.

> Taking that first step into an area can make for a wierd
> pause though.

Completely unnoticeable on my mud, where every room is loaded individually when it is first requested. But players don't step into 'areas' as a whole, they step into 'rooms'. There is also no need to load an entire area when you only need a single part of it. Although as muir stated it is often useful to use batch loading as an optimization technique, I haven't yet found a case where it was necessary for room loading.

Do you think it's a viable option to load and unload the rooms based on necessity, or are you simply doing lazy loading?

.

> Do you think it's a viable option to load and unload the
> rooms based on necessity, or are you simply doing lazy
> loading?

Currently I'm simply doing lazy loading. Although I haven't implemented a strategy of unloading rooms, I plan to have the room loading procedure insert an unload event into the scheduler. You just have to make sure all your dependencies are using weak references, which I haven't done yet. You really can't have a truly large world without having some strategy for unloading rooms (and their dependant NPCs and inanimates) like this.

Keep in mind that Unifex is running his MUD on a system that has multiple processors and RAID disk access which typically perform in the range of 100-120MBs/sec, while normal disks perform around 10-15 MBs/sec. Though you still shouldn't see much of a delay when loading small portions. Just thought I'd point that out.

Well all of my development and benchmarking is done on a server which is cobbled together from my old hardware scraps. It's not exactly the quickest thing on the road, but this method still performs admirably.