Developing Levels Now

[Skyalmian]

You can create content for Core Decision right now. Pick your favorite 3D application and get started modeling and painting -- there's your toolset. The engine imports .obj and .x files.

The engine uses a poly-mesh system that allows for extremely detailed shapes and structures.

Okay, so we know we can make models to be imported from the following:

• 3DSMax 5/6
• Lightwave 3D
• GMax
• Maya
• D3Edit

Hopefully it will feel so good you won't really even want to convert anything. I'm really all about new, awesome, original content that still feels like home.

I don't feel like it, but I know others will. If converting levels requires almost no work, then I expect almost all 400+ Descent 3 levels to end up in Core Decision in one form or another within a year. Abend2, anyone?

The game's life history will be quite different if there is plenty of variety (even if it's recycled variety) suddenly available shortly after it's released. (Note: I'm speaking of only MP levels in this post, not SP.) Descent 3's was stifled and limited because the really good levels didn't come out until somewhat late in its life (thank you D3Edit for being horribly buggy and incomplete...), after players had begun to leave in mass, so most were playing the official levels because they didn't like what else was out there.

Most people are extremely excited about this game, so I'm sure a few at least will jump on this. So, if we actually started to develop levels now, then what should we know that we already don't?

Sep 06 15:08:46 <[8]Ferno> Say a ship is 10 meters wide... Will it feel like the corridor is fifty meters wide?
Sep 06 15:09:22 <[8]Ferno> That about right, Sky?
Sep 06 15:09:27 <[D3k]Skyalmian[]> Yeah.
Sep 06 15:09:33 <{HighOct}Alex> If the ship is ten meters wide and the corridor is 50 meters wide, the corridor will be 5 times as wide as the ship.
Sep 06 15:09:53 <{HighOct}Alex> And we'll do our best to make it feel that way.

This is quite important concerning level design. If the ship is realistically scaled to the level, unlike Descent 3 and its model RC-Pyro scale to everything, even the few humans that were seen, then most level detail will be miniscule, especially if the level was built in mind with people wandering around in it. This would make ported Descent 3 levels more than awkward because they're designed at a vastly smaller scale.

Or did realistic ship-vs-environment scaling change?

Textures are primarily 256x256 but capable of 2048x2048, with bump mapping, specular(?), and detail ("layered textures") thrown in for a wholesome mix, and no limit to the number of them. Is the format custom for the game or already available and widely used, like *.tga?

Audio is preferably 44Khz / 16-bit, but can be 196Khz. .mp3s and .wavs; any others allowed? FLAC is good; it's just .wav compressed by a whole lot.

Liquid surfaces and vapors / gases are in, but the ship can't handle water so it doesn't go below.

Are lights point- or texture-based, or both? If we build a huge room, can we light the whole thing without crunching the CPU?

Level shell specifics...does, for example, a light block need to be actually connected to the wall it's on, or can it be placed on it as though it's attached? (Outline Mode would show it's actually not.) Same thing for an octagonal pipe: can it just end at the wall like in Descent 3 or does it need polygons attaching it? Or, better yet, answer this instead:

Can an unmodified Descent 3 level shell be imported straight into Core Decision without a single error or issue?

Terrain making: is making the surface terrain the same as making a mine (a displacement mesh that is just more detailed)? What worthy-of-mentioning differences are there in making it? Is a "SKY" texture used (skybox)?

Physics objects: complex physics interaction isn't in last I heard, but if objects can still be somewhat moved around by weapon fire, then people may want to add non-static details to their maps by designing them ahead of time. The Q is: can such objects have set weights?

Anything else we might need to know? Doors, maybe?

TY

[Kyouryuu]

Actually, if you built a Descent 3 level on the same scale as a D1/D2 map (that is, 20x20x20 as a working unit), you could get similarly claustrophobic results. Unfortunately, most of Descent 3's doors don't take well to that scale.

In terms of the original post, it's great that you guys are using the relatively generic .obj format. I have nothing against brushes (except the way Unreal implements them ), but being able to make a level in a 3D application is always easier. I suppose the only question I have would be how might objects be instanced (i.e. props in Half-Life 2, or static meshes in Unreal)? If you use the same doorframe all over the place, can you instance the same frame around the map rather than treating each as a unique structure?

[d3jake]

If you model a level..and import it, won't the whole level be treated as a single room? Or am I thinking D3 terms..?

[Duper]

Actually, if you built a Descent 3 level on the same scale as a D1/D2 map (that is, 20x20x20 as a working unit), you could get similarly claustrophobic results. Unfortunately, most of Descent 3's doors don't take well to that scale.

YES! YES!!! THANK YOU!!!!


so. Is anyone interested in a "Core Keg Party"? ;D


(just kidding Just Kidding!!!) geez.. put the knives down.

[Kyouryuu]

If you model a level..and import it, won't the whole level be treated as a single room? Or am I thinking D3 terms..?

That's not limited to D3. What you're really talking about is a portal system. Most games use some kind of portal system to determine visibility for different areas of a level, so the entire level, including parts unseen, isn't drawing at once. It's critical to almost any engine that you can do this (HL2 easily reaches a crawling framerate if you don't).

Another common thing games do, especially console games, is level streaming. This is where a large level is divided up into smaller chunks, which are then loaded in and out of memory as needed. In many PC games (HL2, Doom 3, all Descents, etc), the entire level is loaded upfront. The advantage to streaming is a shorter if not concealable load time and the ability to make a virtually arbitrarily sized world. The downside to streaming is, because you are loading off a disk and moving things in and out of memory, things can get fragmented. In fact, it has been said that the PS2 game Shadow of the Colossus runs a defrag process on the PS2's memory on idle cycles! And also, streaming is notorious for quirkiness. If a player jams back and forth across a level load trigger, and programming doesn't compensate for this, bad stuff can happen. Likewise, sometimes the disk read can fall behind and be forced to "catch up" to the game. This is why in some games, like GTA: SA, you can sometimes "outpace" the streamer and see buildings with low-res textures magically become the higher-quality models when you get close to them. Destroy All Humans! is infamous for this effect. XD

Either can be acheived in a 3D modeling package, however. There can be a tool that supplements the package in placing them. There could be a naming convention for things that will serve as triggers. There could be a whole other tool that essentially does nothing but trigger and scripting placement - it's all in how you want to implement it.

[HighOctane_Jared]

If some of you plan on making levels, here is just a little guide


- Try to leave rooms and their decor as seperate objects as much as possible, for purposes of automatic occulusion and portals(occulusion meaning if you can't see it, don't render it).

-If you want a different texture applied to the same object, just create another material. But remember, one 2048x2048 texture is better then two 1024x1024 textures (less render passes)

-Leave repeating objects as seperate models, so they can be instanced. The objects have to instanced in the Engine editor currently, so you may only want to make one of the object, then duplicate it in the editor.

-We like normal maps and enviroment maps

-Layered textures can be created via a mip map

-.AVI's can be displayed as textures

-.OGG is one of the better sounds formats we work with

-Currently the 3DSmax exporter works the best. All the other exporters don't export lights...yet

-Objects can intersect, just not perfectly overlap, because that causes an ugly Z buffer graphical glitch (common in every engine)

-UV maps can be rescaled in the editor on a numerical horizontal and vertical basis

-Try to bake lights when you can. The engine supports point, directional, and spot lighting that can project textures, it just uses less resources to have a baked texture

-There is an automatic LOD feature, so no need to make a super low poly reference model

-The current skeletal system only supports IK. Bipeds don't work yet

-If you make terrain, break it up into sections, so occulusion can work properly. Terrain is based of a static mesh, not a height or displacement map

-There are excellent physics, but don't over do it. For objects like ropes, hoses, and wires, use an IK skeleton and it will be treated as a ragdoll.
For objects you want to break, just split the mesh into seperate peices and export it. When it is imported, then engine combine the object as one model, but with seperate model frames that can be converted to a breakable object. Glass will probably use a script to shatter, so just leave those for now.

-Objects can be animated, but if you want interaction you'll need to use skeletal animations. Vertex or blend shapes is not supported currently.

-Just animate doors as static meshes with keyframes.

-Try to make robots and such using a 2048x2048 texture, and pretty much the same with tilable textures.

Thats all that comes to mind...

[Skyalmian]

Ah, excellent!

Three more questions, though: what unit scale should we use for designing? Do you use English, metric, or generic units, and how big is the ship in each unit?

(A sticky for this thread would be nice.)

[Shadowfury333]

-If you want a different texture applied to the same object, just create another material. But remember, one 2048x2048 texture is better then two 1024x1024 textures (less render passes)

Wouldn't the equivalent be four 1024x1024 textures?

Also, refresh my memory, did you guys mention anything about supplying a map editor for the game, because I'm not particularily enthusiastic about using a piece of (often prohibitively expensive) 3rd-party software to build levels.

[Testiculese]

D3Edit

[Sirius]

There are some D3 levels that I just don't think should be ported.

(Okay, most of them.)

Some are worth a go, obviously, but considering it shouldn't take that long for experienced designers that know their stuff (admittedly a bit lacking in the Descent community, historically) to build entirely new levels, I'm not sure it's really worth it at the moment.

P.S. Blender is a good freeware modelling tool. Steep learning curve, but once you do it it's not all bad.

[Testiculese]

OtherOne's levels should definately be ported/recreated or whatever.

[d3jake]

So...Do we have to export .oof files to the CD level editor? or .orf?

I call dibbs on porting VV! HA!

What are the max size for the .avi as texture thing? Filesize wise? (I made a ryme...)

[HighOctane_Jared]

So...Do we have to export .oof files to the CD level editor? or .orf?

I call dibbs on porting VV! HA!

What are the max size for the .avi as texture thing? Filesize wise? (I made a ryme...)

Conversion of other game softwares textures are completely up to the users, but our engine supports nearly any format. .dds and .tga are preffered though.


As for max size on videos, I am not aware of one, though fully uncompressed videos are going to playback horribly in game just like they would on any media player. DivX seems to be a good working format right now.


Another note, for complex objects, a less complete collision mesh can be created and referenced to. The editor has build in collision shapes such as cubes, spheres, and pill shapes, but to lower the resource usage in collisions, it is best to create a secondary low detail mesh for collision purposes.

[HighOctane_Jared]

Ah, excellent!

Three more questions, though: what unit scale should we use for designing? Do you use English, metric, or generic units, and how big is the ship in each unit?

(A sticky for this thread would be nice.)

We currently don't have such a regimented scale, so if a level is going to be created, then do it with the scale you feel is right. It can then be easily ajusted later.

[Skyalmian]

Another note, for complex objects, a less complete collision mesh can be created and referenced to. The editor has build in collision shapes such as cubes, spheres, and pill shapes, but to lower the resource usage in collisions, it is best to create a secondary low detail mesh for collision purposes.

Inaccurate collisions. What You See is Not What You Get.

Half-Life 2 overdid that. Go to fire through a large open hole in an object only to have it hit an invisible wall.

Fortunately this isn't Half-Life 2 and we won't need to hide behind broken down vehicles and look for the perfect little hole to shoot through (only to find that there is actually no hole), so that won't be as big a problem as it is in that game.

But, I still won't be using collision meshes.

[psionik]

The way to make a level and import it:

You could model and texture the entire thing as one giant model with individual textures per object as long as the objects you want separate are not all connected, our editor will happily split it into prefabs for you.

That is how I do it most of the time.

The other option of course is to import just the shell pieces, make a bunch of prefabs and place them around the shell in the editor manually. (The shell should be broken up in such a way as to be suitable for occlusion purposes, I do this by adding bulkhead objects between segments of the shell).

[Einsiedler]

I'm not used to 3dmax & co.
Can I do something with google-sketchup and import it later to your leveleditor? Or is it better to wait for your leveleditor?

[Duper]

a 3D modeling program is thier editor. With any current game, that's pretty much the case save maybe UT and Q4 that have prefab obejects.

Got get Blender and Gimp and start playing and d/l some Tutorials. They are both free, mimic more more popular programs out there and have a good community for support.

[d3jake]

If you could PM me a link to those tuts (if you find that they help you out) That'd be nice. I'm interested in a non-d3edit modeling software that I can have without having to pirate it...

[d3jake]

I asked for a PM because it is a big no-no to post links to illegal software in the main forum(s)... Thanks anyhow.

[jshaner]

Sorry!

They are merely trials and nothing more; there is no explicit or illegal activity involved. I will keep what you said in mind though.

[d3jake]

Ah, sorry, my mistake, thanks then, I can see if maybe the OOF exporter will work with it...

[jshaner]

I think the OOF exporter only works with some versions, but i am not too sure. Worth a try!

[Ferno]

jake is right. I deleted the post that contained the link.

trials are on the company's website.

[jshaner]

No Ferno, he was not right, and that was why he corrected himself. I only found the 2008 trial on the company's site, not the others, and it is not illegal to post previous ones for other people to use.

[Ferno]

then state that it's a demo in your post.

Please exercise some common sense. you do understand that I cannot allow any kind of links to warez here.

[jshaner]

you do understand that I cannot allow any kind of links to warez here.

I understand that. I will label my links as what they are in the future then. I do not condone piracy in any way or form.

=These are TRIALS/DEMOS!= http://files.h2vista.net/software/3dsmax/

Check it out for yourself if you want.