As I mentioned in the bugs page, one of the few things holding Cerulea back is the lack of a system that would allow me to create brand-new procs and verbs from within the world.
I wish I could provide more details about how other MUDs do this, but my knowledge is sketchy. In one system I know of, GMs write up scripts with the in-game programming language (I've forgotten the term for such a language), compile them to test for errors, then attach them to objects, rooms and mobs. I'm not sure how the compiling thing works.
So. Suppose I am GMing today, sitting in my little GM office in Cerulea, thinking up special items that will be randomly distributed through critter treasure for players to find. I decide I want to make a sword that will whoosh through the air when waved. All I need to do is go into the appropriate .dm file and create an obj/sword/specialsword, which will have a special Wave() proc that is called whenever it is the target of the wave verb. And then I need to recompile, re-upload the gigantic .dmb file to the server, start up the game again, and create a sword/specialsword in the game. All done.
It isn't terrible. The end result works fine, and I could just save up changes to the .dm files and upload a new version only once a week. But I am hungry for more power than that.
What I would like to be able to do is... well, all of that, but from within the game and without rebooting. A tall order, huh? This is the big kahuna.
I would like to be able to create an obj/Wave() proc that's unattached to anything; I would write it in the proc editing window, which would be a notepad-like text editor to pop up in the browser window.
obj/Wave()
name="Whooshwave1"
desc="Makes an object whoosh when waved."
if (usr.hidden == 0) Desc13("You wave [src.article][src.field1][src.field2][src.field3][src.name]. Whoos!","[usr] waves [src.article][src.field1][src.field2][src.field3][src.name]. Whoosh!")
else Desc1("You wave [src.article][src.field1][src.field2][src.field3][src.name]. Whoosh!")
The proc I write would go into a .dmx file on the server, for extra DM procs, stored under its name. Checking could be done to make sure no other .dmx procs already had that name.
Then I'd create a regular obj/sword. I would use the ".attach" verb to bring up a menu of all the procs and verbs stored in my .dmx file, listing their names and descriptions (if I had created a description):
1. Shoutecho (room/verb/shout(msg)): Creates echos in a room
2. Whooshwave1 (obj/Wave()): Makes an object whoosh when waved.
I would choose 2, which would attach the obj/Wave() proc named "Wooshwave1" to my obj/sword. Then whenever I waved the sword, the wave verb would call this proc rather than the default one.
If I then waved the sword and discovered that it says, "You wave the sword. Whoos!" I could go into a mode that would allow me to edit procs in the .dmx file, and edit Whooshwave1 to fix the typo. I could do this if any sort of error was generated. (The proc editor would be beautiful if you could do a baby-compile to check for missing expressions, parentheses, and variable declarations.)
When the sword was saved and loaded, somehow the files would have to remember to save and load "extra" procs/verbs it might have attached to it. And if for some reason the .dmx file had been taken out of the directory the .dmb was in, and an extra proc/verb had to be called, it would either call the default instead or--if no default existed, as with my "shout" verb above--simply generate an error. "Error: cannot find .dmx file."
And of course, if I wanted to detach a proc or verb from something, there would be a way to do that too.
Wow, what a mouthful, Z. This would be a major feature and it's certainly possible to make great living online worlds without it... but it would really help such games reach their true potential, securing their status as fine professional products. And it would do the same for BYOND. I'm probably a little bit of a pain in the neck with all my suggestions, but I think this is one feature your most ambitious users will all yearn for at one point or another.
Z
ID:138419
 Aug 28 2000, 6:27 am
|
|
On 8/28/00 10:27 am Zilal wrote:
Wow, what a mouthful, Z. This would be a major feature and it's certainly possible to make great living online worlds without it... but it would really help such games reach their true potential, securing their status as fine professional products. And it would do the same for BYOND. I'm probably a little bit of a pain in the neck with all my suggestions, but I think this is one feature your most ambitious users will all yearn for at one point or another. I like your thinking, but this is no trivial task. The full-blown version is asking for a runtime compiler that can maintain the state of the world while compiling up new code. That opens up all sorts of difficult situations. I don't know of a product that can handle this kind of complex runtime parsing. I imagine that these runtime mud-editors are mainly just filling in descriptions and setting variable values. That could be done in DM through a "meta" language such the one proposed by Deadron. Dan's mud library does this in a clever way. You might want to take a look even if you don't plan on using the code; perhaps it will inspire you. When the new server is up, we plan to make life a bit easier by allowing compilation from dantom. It could even be set up to run from within a byond world, so that you could provide a "hack" approach by saving the world, editing a dm file, launching the compiler, and loading the world back in. Of course, compilation is bound to produce errors so it is probably best done locally. | |
On 8/28/00 2:36 pm Tom H. wrote:
I like your thinking, but this is no trivial task. The full-blown version is asking for a runtime compiler that can maintain the state of the world while compiling up new code. That opens up all sorts of difficult situations. Hmm I don't have time right now to think up a concrete proposal, but I'm feeling like some simpler solution should be possible here. Say, a scripting object with hooks into the running world, which knows how to parse small scripts... The first time it parsed a script it might cache an "object" form of it, but primarily it would be a real-time parser of perhaps a simplified version of the DM language. Or you could consider the approach I was working on -- a simple scripting language based on the model provided by the Mail wizard in MS Outlook. In this case, the scripting is done by selecting from the available statements, then clicking on hot links in the statements to fill in variables. Anyway, my challenge is that if we put on our thinking caps we might be able to come up with an approach that is accomplishable... | |
On 8/28/00 4:37 pm Julio Monteiro wrote:
Then you could do a loadLibrary(<filename>) in runtime! This is an excellent idea, and, I think, a realistic goal sometime down the line (although Dan can give you a much better answer). The first step would be enabling the server to merge multiple .dmb files (eg- loading a new .dmb on top of a currently running one). Your "object files" would just be unrelated .dmb files full of objects; no overlap would be allowed. From a modular point of view this is probably better anyway. The recommended way to make modular games in the current system is to have a common code base and simply run different processes, sending the players between servers with interlinking. That way you can write new code and have existing players test it without cutting them off from the world. Since a lot of the data transfer is done through savefiles it also forces the designer to have a solid savefile system that can be used for general saves too. True object files on the compiler is another idea. I think the main use of this would be to save compilation time for large projects. Zilal mentioned that Cerulea is 25 files, so it probably takes a bit of time to compile in even the slightest change. Object files would reduct this considerably, since only the changed source file would have to be recompiled. But I think this is a slightly tricky problem, given the way DM preprocesses and merges code (this is how it gets away with not having header files). Certainly it is important in the long run, though, as the projects grow in complexity. But I've wandered off topic. | |
As I mentioned in the bugs page, one of the few things holding Cerulea back is the lack of a system that would allow me to create brand-new procs and verbs from within the world. Yes. This would be very nice and I also like both Julio's modular object file and Deadron's run-time script idea. As Tom noted, you may want to look at the /obj/action in my MUD library. It demonstrates one possible framework for dynamically adding verbs to rooms. You are in search of something a little more general, but this still may be helpful. As we ponder how best to proceed, a very simple improvement would be compression of transmitted files. No, they are not currently being compressed! I think we can cut down upload times quite a bit, which would save you some time and us some bandwidth. --Dan | |
As we ponder how best to proceed, a very simple improvement would be compression of transmitted files. No, they are not currently being compressed! I think we can cut down upload times quite a bit, which would save you some time and us some bandwidth. Tsk tsk. I suggested that way back on the old DUNG forum, and Tom must've forgot to add it to The List. See? My prophecies ring true; The List will bring doom to us all! =) | |
On 8/29/00 9:57 am Spuzzum wrote:
See? My prophecies ring true; The List will bring doom to us all! =) The list resides under the bed and has glowing eyes. By feeding the list you only encourage it. | |
On 8/29/00 9:57 am Spuzzum wrote: See? My prophecies ring true; The List will bring doom to us all! =) I watched VH1's The List last night. They had the Survivor cast on. Now we know doom is on its way. Z | |
First:
I imagine that these runtime mud-editors are mainly just filling in descriptions and setting variable values. I don't think they are. From what I've seen, my GM friends in other games have been creating their equivalent of procs whole... though I could be wrong. On 8/28/00 5:24 pm Tom H. wrote: Zilal mentioned that Cerulea is 25 files, so it probably takes a bit of time to compile in even the slightest change. 30 seconds to a minute to compile, I think, and 5-10 minutes to upload. I haven't timed it. I imagine the .dmb will grow to about twice the size before I'm done... Z | |
I watched VH1's The List last night. They had the Survivor cast on. Now we know doom is on its way. I should honestly think of being a prophet by profession. =) My next prophecy; there will be a new BYOND program that lets you create "browser-based" games based upon a generic rules system. I prophesize that it should be ready sometime soon, depending on whether or not I... er, I mean the designer, finishes it before school homework begins to arrive (School in a week! *shudder*). | |
On 8/29/00 1:40 pm Zilal wrote:
First: You're probably right. I'm pretty naive of the mud market, but I am so overconfident in our (mainly Dan's) abilities that I shudder to think someone else could pull something off while we struggle! Anyway, I'd like to see what kind of things are possible in these other systems, and how easy they are to use, etc. Do you know the names of the popular ones? 30 seconds to a minute to compile, I think, and 5-10 minutes to upload. I haven't timed it. I imagine the .dmb will grow to about twice the size before I'm done... Ouch. That compile-time is pretty long. I'm very impressed that you have the sanity to put up with it. This leads me to believe that this is a pretty significant element that needs to be addressed. Ideally, you want to recompile as often as possible (even if it means only changing a few lines), but the current system discourages this. If we had some sort of object file this would be alleviated, because it would probably only take a few seconds to recompile the current file and merge it into the project, rather than recompile the whole project. Maybe with a prohibative model (where the user must set certain compilation properties) it won't be so bad. | |
Fortunately, there's nothing about your proposal that you couldn't implement in Byond today. In fact, I made a lot of progress on this in my RPG system -- GMs could create new kinds of mobs and turfs and define their values, on the fly.
When I stopped, I was working on a scripting system -- even got a book on compilers and such to learn how to do this.
BUT...it's a lot of work. And it means you have to reimplement much of what Dantom have already created, and in the end I think for me I decided it was time to get back to simple stuff I could create within Byond itself...
I think your well-considered request boils down to supporting an interpreted scripting language from within a game, preferably (to my mind) the same language we're already using.
I have no idea how tough this would be for Dantom...