Page 1 of 1

Different approaches to level / map creation

Posted: Mon Jan 25, 2010 11:36 am
by zarfius
This topic was spawned from a discussion over in the showcase forum on this thread: http://www.ogre3d.org/forums/viewtopic. ... 22#p374522
joew wrote:
zarfius wrote:Not really. I only ask because I think there is much more to map creation than the 3D model you could create in blender. How are you going to place spawn points, health packs, weapon pickups, enemies, opening doors, ambient sounds, dynamic lights and so on? I suppose you could do it with some fancy workaround in your exporter, but it would make more sense to have a specialised application for this purpose.
Actually there are arguments against have a specialized application as well. The Nebula 2 engine had a toolkit built right into Maya and it had extended functionality and it was quite good to work with and there are many commercial games built on it. Also Ready At Dawn have what is likely the best engine and toolkit for development on the PSP and it is completely built into Maya. This way you have artists and designers staying in the tool that they know how to use and you are implementing additional functionality right with the Maya SDK / Mel so you actually save a lot of time compared to building your own. I've heard arguments from people that create editors saying that you do not need poly modelling functionality right in an editor, but I can tell you that any project I've worked on has needed the ability to block out otherwise we never would have made schedule, and you get this free by building on an existing tools. (At one company I worked at we didn't have this ability and so the artists had to block out in 3DS and then export the map every single time they wanted to test in the engine... meanwhile if anybody has made changes in the editor what do you do then? Needless to say this was extremely less than ideal)

Mind you the biggest trade-off is that you are reliant on a specific tool. Now for in-house game development this is no issue, and for licensing middleware to medium to large studios (where the majority will be using Maya as a DCC) this is not an issue. Although if you look at licensing middleware to indie developers, small studios, or want to target the largest possible audience then you really need to support the widest array of tools.

In my opinion I think Blender (especially with the new alpha UI!) makes an extremely solid base to create a world builder. Not only do you have script access but you can also make additions and changes to the source if needed, which can be extremely useful. Since Blender can import the vast majority of 3D formats you also get this functionality as a bonus.

I would be very interested in hearing people's experience of why they found it better to create a custom editor rather than building on existing tools (other than the trade-off I mentioned above, which in the case of Blender really doesn't apply since you can treat it like a custom world builder after exporting from Maya).
realaxis wrote:joew,

I could not have said it better, But there are pros and cons for both approaches and one has to make the decision based on the budget and plans. Blender is really a good choice for indie company because It is opensource and It is easy to find skilled artist (cost effective). Major flaw is that blender is really not a level editor if compared to traditional level editors and it lacks lot of functionality required for creating the map on the top of that one has to do extra work to manage collision related data (Think about BSP file as traditional level editor handles them) as now BSP is not choice for partitioning we have to implemented that in different ways and then export it to your games such that your physics engine handles them properly. So level editor/modelling kit has to handle collision (partitioning) as well as modelling aspect of map creation.

Building these functionality into blender is easy (cost/time viz as oppose to creating your level editor from scratch) but if you are planning your users to create their own map and then import into game this approach is not user friendly. Having a level editor which works out of box would be a good choice if you are planning a big commercial release.

In short both approaches are fine but it is the budget/time who drives that decision.

-RealAxis
So lets define the purpose of a map / level editor whichever method you use is to create it:
- Create or layout static world geometry
- Create textures / materials on the world geometry
- Setup collision geometry that's different from renderable geometry
- Position lights and generate static lighting (light / shadow maps)
- Setup dynamic / functional world geometry (doors, moving platforms, ladders, etc)
- Place dynamic objects and setup data for the physics engine (crates, barrels and any other objects that move)
- Setup particle systems
- Position spawn points and trigger areas such as the exit
- Assign sounds and animations to the world and objects
- Place collectable items (health packs, power ups, ammo, weapons)
- Place enemies and other NPC's
- Terrain deformation

Some of these things don't apply to all games, and I'm sure that there are many more to add to the list depending on what type of game your creating. The point is that there are loads of things to think about when your creating your levels and having the right tools for the job is a great help.
realaxis wrote:Building these functionality into blender is easy (cost/time viz as oppose to creating your level editor from scratch) but if you are planning your users to create their own map and then import into game this approach is not user friendly. Having a level editor which works out of box would be a good choice if you are planning a big commercial release.
When I read this it makes me wonder why there are not that many options when it comes to level editors that allow you to do the things listed above. I realise that a generic level editor is not going to suit everyones needs perfectly but it would still be a better middle ground between building an editor from scratch and building on top of Blender. If it was designed in a way that allows you to customise functionality (scripts, exporters, etc) there's no reason why it wouldn't be a better option than using Blender.

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 12:40 pm
by jacmoe
I use Ogitor. :)

And PnP TerrainCreator, for which I helped write a Ogre mesh importer and a scene exporter.

Ogitor is a natural choice because I am a Ogitor developer (and thus can program it to my liking), PnP TerrainCreator is another good choice because is supports multiple terrain pages (up to 99 for professional edition), has tree generation, vegetation, object placement, etc.
Tree placement exports (xml) and coverage maps (vegetation) is out of the box usable with the PagedGeometry engine.
I am going to make it easier/possible to import PnP TC terrains/scenes into Ogitor, though.
Even if it's not needed.
For the curious, here's the Pnp TC forum where I put two terrain export tutorials up for Ogre 1.6 and Ogre 1.7:
http://forum.pnp-terraincreator.com/viewforum.php?f=15

However, I am also interested in Blender. If I only knew enough Python to create a editing environment.. Sounds interesting.
But, since my projects are terrain oriented, I think PnP TC and Ogitor suits my needs more. :wink:

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 3:45 pm
by koirat
I'm using blender since I'm doing closed space level.
If I had to do open space I would think about doing it in blender, but probably heightmap would be a better choice than mesh, so some other specialized level editor should be more usefull.

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 4:28 pm
by joew
There is one other downside to building on top of Blender which I did not mention, and that is if you may license your technology in the future. With Blender being GPL anyone that licenses your technology could in turn hook it to another engine and/or start licensing it to others. Obviously if you are only using your tools and technology inhouse and never plan to license then this is never an issue.

Also realaxis I agree with adding game/engine specific functionality but I also think it is just as much work as if you were to build everything yourself. Blender does use Bullet for physics and you can either use python or dig into the source to make it do exactly what you would like. Also regarding level compilation yes this is an extra step but one that you would have to build into any editor whether it be on top of a DCC or in a stand alone.

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 6:14 pm
by mkultra333
I'm using a version of DarkRadiant that I changed to suit my project. In turn, DarkRadiant is a version of GTKRadiant someone changed to suit a Doom3 "Thief" mod... so I'm not sure where that fits into the above options. My goals are probably not typical though, orbiting old Id technology.

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 9:48 pm
by Shockeye
I'm using Blender to create level geometry (zones for PCZSM) which I then assemble using Ogitor.

Re: Different approaches to level / map creation

Posted: Mon Jan 25, 2010 11:39 pm
by nikki
I like making levels in Blender because it 'fits so well for level design'. I have a built-in Python syntax highlighting text editor for scripts, a property editor, and an awesome 3d view, with undo, cool move/rotate tools and whatnot. Also, I can edit meshes (with Blender's awesome mesh-editing tools) right when I'm designing the level (good for 'brushes'), apply textures with not just 'tiling' but complete UV unwrap the way I want it, and stuff. Check it out:-

Image

Watch a video of it here.

Re: Different approaches to level / map creation

Posted: Tue Jan 26, 2010 12:02 am
by jacmoe
How about making a series, Nikki?
The DCC section of the Ogre wiki really needs more articles. :)
I'd love to see what you're doing.

Re: Different approaches to level / map creation

Posted: Tue Jan 26, 2010 12:28 am
by reptor
koirat wrote:I'm using blender since I'm doing closed space level.
If I had to do open space I would think about doing it in blender, but probably heightmap would be a better choice than mesh, so some other specialized level editor should be more usefull.
+1

Re: Different approaches to level / map creation

Posted: Wed Jan 27, 2010 12:34 pm
by realaxis
my vote for blender.

-RealAxis

Re: Different approaches to level / map creation

Posted: Wed Jan 27, 2010 3:32 pm
by koirat
@niki
I try to watch your movie but it's uploading so slow. And you can't >> it.

Re: Different approaches to level / map creation

Posted: Thu Jan 28, 2010 12:08 am
by nikki
koirat wrote:@niki
I try to watch your movie but it's uploading so slow. And you can't >> it.
Unfortunately Vimeo doesn't have the 'jump forward' feature (yet?). :( You could download the video file, there's a link to the right near the bottom in that page. I think you'll need a Vimeo account though.

Or maybe you could just let it load, then watch a movie/go for a walk/take a nap, come back and watch it. :P

Re: Different approaches to level / map creation

Posted: Wed Jan 04, 2012 5:50 pm
by StudioMaxCat
I don't know too much about map creation. Maybe someone can help me out? :)

Re: Different approaches to level / map creation

Posted: Thu Jan 05, 2012 12:45 am
by zarfius
StudioMaxCat wrote:I don't know too much about map creation. Maybe someone can help me out? :)
Your question probably needs to be a bit more specific. The best answer I can think of is to point you to the wiki.
http://www.ogre3d.org/tikiwiki/DCC+Tools#World_design

Re: Different approaches to level / map creation

Posted: Thu Jan 05, 2012 1:33 am
by duststorm
I create all the meshes and animations in Blender and textures with Gimp.
For creating my actual levels (or better: world) I use Ogitor, where I put everything together.
For specifying certain logic, like motion paths and cameras (that don't need to be pointed, just positioned, as they follow a subject) I just use special entities in Ogitor that have specific names etc. I didn't make any modifications to the Ogitor code. In my own application I load the ogitor scene file and interpret these special entities and their properties. It's not the cleanest thing but it gets the job done, and it is the fastest way for me.
Since I'm not doing a game but a visualisation with rather limited user interaction the logic is not all that complicated, at least for the parts that aren't hardcoded into the application, so I can get by with these simple hacks. If you were to do real game levels in Ogitor I can imagine you would really need some custom plugins to define game logic.