I am working on a FPS game and thinking about the best way to create a (mostly) static level. It seems to be somewhat hard doing that in blender I wounder if there are an easier way to do this. Many FPS games uses some kind of sketch tool where you simply draw a level in two dimensions that made up a room into the 3D space. Maybe the best way is to create a room in NetRadiant and export it as OgreXML thing, if there are any .map to OgreXML converter. It would be nice if there was a way to parse entities like spawpoints, weapons, monsters… That might be simple to just import manually or convert to some simple loading scripts or something…
There are any better way? 
There are many ways to go about this. As far as complete scene imports go though, keep in mind that the .obj format, which I imagine would be supported by a wider selection of modeling software, would be just as appropriate as OgreXML for this kind of thing.
Blender has an extrude tool allowing you to turn a 2D floor plan to a level essentially
Yeah, thinking creating a 3d level in a 3d editor is too cumbersome is really expecting a level of automation that just cannot work properly without lots of work around it. So essentially editing in an editor like blender or max is exactly what pro game studios do and its also something you should get accustomed to 
Really?! Maybe is alike using blender is alike hammer/unrealED/gtkradiant after all. But I guess I will give it a second chance then I that is what pros use… But I still need a way to create dynamic stuff or at least add pre-made models to the level. Maybe the scene composer can be used for that. That needed to be flexible so you can change the static level without affection the dynamic stuff or vice versa. It would be nice to know how that quake3 map in jME was created, converted etc.
It was created in a 3d editor and then loaded :roll:
I am trying to find tutorial about how to making a level in blender. All of them involve using GTKRadiant… But if use that I guess some info could get lost in conversion…
The default blender box already is a (admittedly very boring) room… Just flip its normals so the color shows on the inside… Then extrude one side to make a corridor etc etc…
normen said:
It was created in a 3d editor and then loaded :roll:
The assets were obviously created individually in a 3d program but game studios do not export maps whole for current generation games. Unreal, Source, etc. all have some variation on a map editor that the studios use to design levels. And I think for similar reasons it would also be much more practical to make a map editor within jME for the described task. It wouldn't be that difficult to allow spawning and manipulation of assets. Much easier than Blender because you could take care of elements specific to the game (pathfinding, interactive objects) within the editor.
What I would do is export reusable sections from Blender (e.g. dungeon segments, crates) and then import them with their collision models into an editor that allows you to place them (raycasting snap to ground, etc.) and stores the locations in a text file.
Yeah, note that only works when you have a system to use whatever extra data you can enter into this frontent. The SceneComposer would be this “Level Editor” in the case of jME3. You can enter for example UserData which is basically the only meta data supported by jME3 or place nodes as special markers for something. What I mean to say is that nobody edits models (as in moving vertices and mapping textures etc. to make it look like it was something real) in a special “Level Editor”. Thats what 3d editors are for.
Although we could provide an editor with a similar caliber to Unity3D, UDK, etc. We do not have the time to do so.
There are things with much higher priority and unlike those products, jMonkeyEngine3 is free and open source. We do not have a full-time paid programmer team to work on such a utility.
This also means that if you create such a utility then you can always contribute it and we could add it to the jME3 core.
Would be really cool if you could do that from jme. Maybe I will do some similar editor (after I have tried to import a regular .map file in jme), just wanna know if I have to reinvent the wheel.
Hello!
I would have to agree with the Core Members on this one. The most that could really ever be provided would be an editor that did basically what Blender/Maya/3DS/yourfaveditorhere already does. Mostly because there would still need to be a level of complexity for whatever the developer has in mind. Dev1 might need some crazy ass level editor with custom triggers, custom events, custom handles, custom etc etc. And then Dev2 on another project completely might need a different implementation entirely.
In the end, it would be hard to please everyone without constraining everyone to a certain path. And in doing so, would probably raise a lot of additional work trying to compensate flexibility for everyone’s ideas to work and/or stifle the work of those who cannot do what they need to do in the editor’s state ~ which would lead them to make their own anyway or give up immediately.
In other words. It would be a freakin mess.
The reason a lot of studios make these developer tools is because they want to accommodate the artists and level designers. However, the trick here is that they’ve already defined the game, it’s structure, and how it mostly works. Then the artists/designers work within these bounds unless some really cool feature is brought up that’s feasible and then they add some support for what they can and they don’t when they absolutely can’t (or don’t have the money to waste time developing). ~ Also keep in mind these tools aren’t usually made clean for the end user. In recent years sure, a lot of studios want their player base to “mod” their game and have fun with that. But this is a growing trend, not an established one. Most in-house tools before now were rude, crude, and got the job done. They didn’t give a crap about the UI and how user friendly it is; as long as it spat out useful data they were happy.
~Just realized I wrote a book. Crap.
TL;DR - Do what you gotta do, but make sure you have established what you want to do, before you do it. The more feature creep you have, the more flexible your level editor is going to need to be. It might be wise to do it manually until you’ve got a good handle on what you need. Since really in making a level editor, for your game, you’re the “end customer.” So in order to develop a product (the editor) for yourself, you need to know what it needs to do first.
Cheers!
~FlaH (The spontaneous loudmouth)
1 Like
Yes, very true, but if you are going to make you own editor that will probably double the time needed for making the game. But yes, that is hard to build an editor that fits every game
The existing editors, plugins and in fact the whole jMonkeyPlatform GDE are easily extensible. The point being that all those little tools can be united and made accessible for everyone.
I know this topic is old, but I’m new to the community and thought I would weigh in on the topic. I worked as a game artist for Ubisoft, for what’s it’s worth we did all our level sketching and designing in Google Sketchup which there is a free version for. Then we exported the sketchup geometry to the game engine for play testing. We also brought the sketchup geometry into 3ds Max for finished art.
1 Like
Thanks for the input, cool to hear from an actual project context. We plan to connect blender and jmp very closely, this will probably result in some kind of API that can be used to connect any 3d editor to the SDK. Theres this “last bit” in the asset pipeline thats always had to get right if theres not some strict procedure kept (naming conventions for empties etc) or a really good import system in place. As people said at some point those point of interest and power up spawn markers have to go in somehow Thats why we make the SDK include all these tools: to get designers and coders closer together, like when you say you tested the assets in the engine.
Cool to hear that you used Google Sketchup imajus. I have always found that tool to be very intuitive and simple to create typical building structures and the ogre exporter from Sketchup works fine with jme3. For those who havent used it, I recommend checking it out.