Level editor from CMU


#25

Any news on this? Could you at put it somewhere public if you cant integrate it into official CVS


#26

Looks like nothing was added in the cvs for the last 6 weeks. I would like to know too, even if you have nothing new to showcase, if you are still working on this.


#27

Bump.

I decided to try it out, but had problems starting it. It couldn’t find the WxPandaShell module. I installed WxPython to Panda’s python copy, and it does install it’s files in there. It just seems to have no effect.


#28

The government got them.

Cant people just make a level editor themselves. Theres a few source code samples around. Thats what ill be doing soon.


#29

Oh come on, its not THAT easy. Why do you think most of the game engines have one? Even if one can do that, why invent the wheel again?


#30

It’s much easier to make a specific, monolithic level editor than a generic one.


#31

I’ve always disliked the idea of engine-generic type-specific stand-alone level editors (like the one at hand). They constrain you to a particular data model so unless you are doing a very specific genre they are useless to you. If you have a very specific terrain format or a solution for terrain paging, or you can’t have scenes in monolithic files cause you stream them seamlessly, or if a part of your scene is generated procedurally, etc, etc… then the editor is useless to you.

What I would like to see instead of an editor is a series of facilities inside panda to ease the construction of an editor tailored to your needs. Like for example:

  • A 3D gizmo/manipulator thingie with arrows or w/e you call that for scaling/moving/rotating. Complete with mouse collision detection on the arrows, you’d just need to attach one to a node and start manipulating away.
  • A way to convert a node and all the nodes below it to JSON or XML or something standard and to recreate the tree from this data later. We’ll probably be able to use COLLADA for this anyway.
  • A way to attach information in the form key:value to nodes.
  • Classes to generate light maps and stuff like that.
  • Maybe some specific UI widgets to show the properties (key:value) of a node, only text, nothing fancy.

And a couple of things like these, plus the incoming rocket gui integration for the UI widgets if you don’t feel like embedding. Then you could easily roll out your own useful editor, maybe even inside your game like Doom 3 does.


when treeform dreams...
#32

Interesting coincidence, I added a blueprint to Launchpad for some kind of lightmap/ambient occlusion generation recently :smiley:


#33

Yeah I think that is the way to go, having specific features inside the engine and then having a tutorial on the manual on how to roll your own editor.


#34

For my current project it is useless for the reasons above.

But what about all the other cases?
For other projects Ive done this would work.

And the things above could somehow be done with user-made plugins.

So I disagree, kinda.


#35

It’s impossible to have a plug-in system in an editor that fix those problems, and if you really wanted achieve one you’d have to put more thought into it than into Panda itself. If you didn’t then no two plug-ins would be compatible.

There’s a reason every game has its own editor, really. Every RTS game comes with it’s own editor for example. Can you imagine an universal editor that would work for more than two RTS games? Impossible. Take a look at the software applications industry, we have professional applications for everything, modeling, drawing, ides, we even have applications for the most specific and silly tasks like texture wrapping or asset management, but where are the universal scene editors being used by big studios for any game? There are none. I know there are some scene editors suited to particular engines like ogre3d but they could only be used for incredibly boring concepts.

In fact it wouldn’t work with almost any genre.

RTS? Nop.
Graphics adventure (extinct)? Nop.
Arcade? Nop.
Sport simulation? Nop.
MMO? Nop.

So that only leaves us with load-per-level 3d scenario games. But it still doesn’t work for most of them unless they are very small. For example if your game is multiplayer you are gonna want to have a BSP and visibility zones because you don’t want maphacks to be possible. This would need to be integral part of the editor and suited to your needs. Just an example, there are a million reasons you need your own formats when you have a complex game. The most important being that the loadable levels model is obsolete and now you want things to be seamless, doing a generic editor at this point is like embracing the 90’s. You now want to design game experiences around your networking infrastructure. Also scenarios need to be dynamic which means procedural content, which is incompatible with a generic editor, plug-ins or not because in order to have an editor you need to have some assumptions about some things that you may want to generate procedurally. This would be a piece of cake if instead of an editor you’d have a series of facilities to roll your own. But the other way around, generic editor with plug-ins it’s impossible, or it would have been done by now.


#36

The only way I see it as viable would be to develop an editor hand-in-hand with basic gameplay classes, since a game’s editor and the “things” it manipulates are tied so closely together. For example create a controllable character class, a collectible item class, and so on. These classes could act as a base for people to modify to suit their own needs, or to add their own game-specific classes.

Saving out Python scripts from a level editor is not the best idea, but if it saved plain text or some other generic format (XML, YAML, etc.) it would be quite easy to use that data in either a level-load or stream-loading context.

If a functional framework of an editor was created this could allow it to be expanded to work with multiple game types. It’s pretty much like what you suggest but plus a working example of how to use it.

Of course I am only considering the object placement side of the task. Most games consist of a static “world”, and on top of that the “stuff” placed therein. Some games combine these two things into one editor, and some have separate editors for each task.


#37

Meh, I dunno :confused:


#38

Did this project ever get included in CVS?


#39

There are plenty of individuals that may find Cmu’s work useful.

If you want a example of a working decent editor for a oss game engine here is one for you:

ogitor.org/HomePage

Apparantly its working for someone.

cheers
nl


#40

For anyone trying to run the editor you might want to try running “LevelEditorStart.py” imagine that :wink:


#41

I like your idea, Gogg. It would be great to have a toolbox module with basic, abstract classes which can be used to create any editor you want. I’ve always though the wx module was neat in the way you could use style bits in the class constructor to get different types of widgets. Maybe we could employ a similar approach here. :slight_smile:


#42

hey is anyone else getting this message

protoPaletteData doesn't exist

as soon as I get that message leveleditor
it bombs out.

in protoPaletteBase.py

it is trying to do this:

    def populate(self):
        moduleName = 'protoPaletteData'
        try:
            file, pathname, description = imp.find_module(moduleName, [self.dirname])
            module = imp.load_module(moduleName, file, pathname, description)
            self.data = module.protoData
            	
        except:
            print "protoPaletteData doesn't exist"
            return

:confused:


#43

Yeah, got the same error message.

It seems the project was abandoned. This is kind of typical for university projects. They’re pretty rarely actively maintained.


#44

Is this still working? I have only first 4 options in File menu, the rest isnt there.