ID:138683
 
I believe Dantom has been thinking about ways to provide for some kind of loadable modules, so I thought I'd throw in a thought or two...

As I create a world that can be built by guides from within the game, I pretty quickly run into a major consideration: how will they create/edit fully featured NPCs and areas? Well, scripting would seem to be the answer. They could upload scripts that I would parse on the fly...

But the more I think about this the more problematic it is. It will be slow, and worse, it will be duplicating an easy development environment that already exists: the BYOND builder and compiler.

The ideal would be for a guide to be able to work on a mob/area/turf definition (possibly with my libraries or source code available), compile it in some manner, and upload it to the server, where the world reboots and reads it in, making it available right away.

Is this sort of thing on the table?
On 3/23/00 11:01 pm Deadron wrote:

The ideal would be for a guide to be able to work on a mob/area/turf definition (possibly with my libraries or source code available), compile it in some manner, and upload it to the server, where the world reboots and reads it in, making it available right away.

Is this sort of thing on the table?

I have given a great deal of thought to this very issue. At one extreme we have this concept of DM as a runtime language, in which code could be incorporated on the fly, without even rebooting the world. This could be really slick, because not only could you change existing worlds but you could send information to other worlds and change them as well! However, as a general solution, this is just out of the question for now.

At the other extreme we can define a "language in a language", allowing limited coding by defining properties to be saved and loaded through savefiles. This is nice because the flexibility is completely up to the user, but isn't really practical because generality is difficult. It also seems like overkill, given the fact that we already have, as you say, a language to do as we need.

So I think we may be able to develop some sort of compromise. There are a couple different routes to go, and once we get a general idea as to what is best we can see whether more needs to be built into the program or into the various modules. Here are a couple of thoughts:

  • It would be relatively easy to build in code compilation into the hosting server. We wouldn't even have to modify any backend code, as the work could be done in DM. Basically you would just have to give a command that would trigger a version of Dream Maker up at dantom.com. This would generate the .dmb and could even reboot your world. At the very least, we should get this working. That way you could upload your changes via small .dm files that you have pre-tested locally. This isn't an ideal solution, but it is easy and functionally should get the job done.

  • I would like to extend the above to the next level and put in a runtime compilation function into the language. The server could call this to recompile the code and reboot the world, if said code exists. Since all of the "brains" of the various programs are accessed through those .dll libraries, all of this functionality is really already there.

  • This doesn't really apply to your situation, but it is related: I would like to see worlds that take advantage of the server linking by defining a common code base that represents the data transmitted when objects are sent between servers. "Guides" could edit worlds by defining code for their own worlds, off of your common code base. They would then compile these into unique .dmb files and link them in with your central world. This is similar to the hub, but would be better because the worlds could be linked from both ends. The idea here is to spread cpu lag over (possibly) multiple servers and also protect worlds from being corrupted by ensuring that each guide is editing his own personal territory. Just some food for thought.

    I would like to see more discussion on this topic, as I completely agree that runtime world building is a very essential feature the online experience.
In response to Tom H. (#1)
  • This doesn't really apply to your situation, but it is related: I would like to see worlds that take advantage of the server linking by defining a common code base that represents the data transmitted when objects are sent between servers. "Guides" could edit worlds by defining code for their own worlds, off of your common code base. They would then compile these into unique .dmb files and link them in with your central world. This is similar to the hub, but would be better because the worlds could be linked from both ends. The idea here is to spread cpu lag over (possibly) multiple servers and also protect worlds from being corrupted by ensuring that each guide is editing his own personal territory. Just some food for thought.

    Actually, I was planning on that system exactly for Haven. My base system would be called Haven - The Forbidden Planet, and subsequent modules would carry section titles, such as "Dalania" or "Tribana". Each of these modules would be a full-fledged continent, and would carry a fully-open link to the next continent in order. If, for some reason, the server was down, you would be denied permission to leave the module, and then it would simply wait until a GM told it that a server was running again, and its network address. Business as usual. The actual size of Haven is going to be in the bounds of a single 1000x1000 area for each module (which is a LONG way, I assure you... 500x500 took Theodis nearly forever to build up from one side to the other in Cityworkz.). Thus, the entire expanses of the world could be in the range of 20000x20000 or greater. Of course, you would have to waste time travelling from one module to another (ala Guy's EQ troubles), but the end result would probably be both worth it, and allow you to add a creative edge to the universe.

    What I would REALLY like to see is password protection or something, so people could read-only the base modules, and thus disable people from editing them, copying/pasting from them, etc.