ID:259205
 
I gave some thought to the problem of custom map editing last night, because I had an idea for a mini-game that would be real neat if people could design their own levels. There's been talk of it in the forum before, and I think Dantom even indicated that they'd like to tackle it somewhere down the road. So I did some thinking about how this could be achieved. Obviously it's guesswork because I know nothing of the internals of Dream Maker, but here goes anyway.

I was trying to guess what information the map editor needs when you compile. Offhand, I think maybe an object's path, its vars, and the initial values of the vars are all the map editor needs from the DM code. (And it would also need access to all the icons referenced in the code.)

My theory is that you could support map editing by doing three things:

1) Giving all drawable objects (areas, turfs, objs, mobs) a new built-in var, "editable". This would indicate that the object, and its children, would show up in the map editor's object tree. (For the developer, "objects only" would show only these editable objects. But for mappers-at-large, these are all they'd ever see.)

2) Having a var flag "editable" that would be placed in the var path (as tmp can be placed there now). Only vars marked as editable will show up in the instance editor. (One problem: how to handle built-in vars. You might want to allow, say, editing of the name and icon, but not density. Other games might call for the icon and name to be invariant, but density could be edited.)

3) Figuring out all the other details, like how to plug new maps into pre-compiled worlds, how to get this path and var info into the map editor without having .dm files available, and so on. (OK, this should probably count as more than one item on the list. :)

Here's an example.

obj
airplane
editable = 1 // This object will show up in public view
var/editable/speed = 30 // Mappers can change speed of planes
var/pilot = /obj/pilot/Elvis // Mappers can't change pilot. All planes will have Elvis.

pilot
Elvis // Mappers will not even see pilots in the object tree

Anyway, using this method, it seems that a given game's "public map editing interface" would evolve as a natural and effortless part of the process of designing the game; by the time you'd gotten a playable game, you'd also have a game for which others could design maps.

Does this make sense?
Does this make sense?

Well, I didn't catch on until the example. Cool idea! But how do you define who gets to edit it and who doesn't?

Spuzzum

On 8/19/00 8:59 am Guy T. wrote:

My theory is that you could support map editing by doing three things:

1) Giving all drawable objects (areas, turfs, objs, mobs) a new built-in var, "editable". This would indicate that the object, and its children, would show up in the map editor's object tree. (For the developer, "objects only" would show only these editable objects. But for mappers-at-large, these are all they'd ever see.)

2) Having a var flag "editable" that would be placed in the var path (as tmp can be placed there now). Only vars marked as editable will show up in the instance editor. (One problem: how to handle built-in vars. You might want to allow, say, editing of the name and icon, but not density. Other games might call for the icon and name to be invariant, but density could be edited.)

Good thinking. An alternate notation would be to augment the pre-existing (and barely documented) instance-editor settings like so:

obj/airplane as obj // editable as map obj
name as text // editable as text
var/pilot // not editable

This is sort of in place right now; you can do "as text", "as num", "in list()", etc for newly declared vars to indicate a restricted type for use in the instance editor. For example, if you currently do:

var/pilot as mob

the instance editor will only allow the specification of mob paths in that particular entry. So your idea fits in pretty well here.

3) Figuring out all the other details, like how to plug new maps into pre-compiled worlds, how to get this path and var info into the map editor without having .dm files available, and so on. (OK, this should probably count as more than one item on the list. :)

This is the tricky part. The first thing we need is to allow the compiler to grab the .dm structure of a world from the .dmb and .rsc files. This could be used to compile a new .dmb that includes a new map.

If we could accomplish the above, the next logical step would be to remove the .dmp attachment from the .dmb, or at least make this an option. That way the map-designer wouldn't have to make a new .dmb for every new incarnation of the map; he could just make a new .dmp that could theoretically be loaded into a running .dmb. This is certainly possible since one could even write a function to do it in DM. Given DM's inefficient text-parsing, it's a tricky function to write, though, and would be better built-in to the system.

At any rate, I think this is a great idea. The current map system is incomplete because it lacks the ability to load/save maps independent of compilation. The whole point of this instance-editing stuff was to alleviate this, but as you can see it's not quite ready. Let me mull it over with Dan and see what should be possible in the near future.
In response to Tom H.
If we could accomplish the above, the next logical step would be to remove the .dmp attachment from the .dmb, or at least make this an option. That way the map-designer wouldn't have to make a new .dmb for every new incarnation of the map; he could just make a new .dmp that could theoretically be loaded into a running .dmb. This is certainly possible since one could even write a function to do it in DM. Given DM's inefficient text-parsing, it's a tricky function to write, though, and would be better built-in to the system.

Inefficient text parsing?! In C++, I still can't figure out how to extract specific lines from a file. In BYOND, I just use dd_text2list("file.txt","\n") and I have my line in list[3] or something.

(Btw, if anyone could help me on that C++ extraction, I'd be grateful... =)


In response to Spuzzum
On 8/19/00 2:26 pm Spuzzum wrote:
Inefficient text parsing?! In C++, I still can't figure out how to extract specific lines from a file. In BYOND, I just use dd_text2list("file.txt","\n") and I have my line in list[3] or something.

(Btw, if anyone could help me on that C++ extraction, I'd be grateful... =)


I could probably do a reasonable job now, but back when I was just a bit older than Spuzzum I tried this sort of thing in C and man did it (and me) suck.

By the way, next release of the Deadron library is planned to make this one step easier, with a dd_file2list() function...
In response to Tom H.
obj/airplane as obj // editable as map obj
name as text // editable as text
var/pilot // not editable

This looks real good. One obstacle I could foresee -- which would apply equally to the scheme I described -- would be that it would be another detail for newbies to struggle with. You might need to make the default allow anything (as now), and come up with a special "as" (maybe "as hidden" or something) to allow low-level and/or Trade Secret(tm) objects to be suppressed. Or, you could just have a #define flag that would need to be included to enable this whole scheme for a given world; without it, things would work just as they do now.


Let me mull it over with Dan and see what should be possible in the near future.

Sounds great! Probably not something to delay the Big Release for, but it would definitely be useful sometime down the road.
In response to Spuzzum
But how do you define who gets to edit it and who doesn't?

My assumption was that, for a given game that supports the creation of custom maps, it would be OK for anyone to create his own map. But a given instance of the game on a server would only have whatever map had been compiled into it. So you might release CAT's, and then I might later use your public interface to design a separate world based in, say, the American Civil War. (Change a rifle's name and icon, set its reload rate to thirty seconds, set the size of its magazine to 1, and you have a musket. And so on.)

However, Tom's note suggested that it might actually be possible to support loading of maps at runtime. If so, then the feature for uploading maps into the world could just be handled as any other GM privilege (or however else you wanted to handle it).

Does that answer the question, or did I miss the point?