Hi I'm interested in constructing a game level reminiscent of a World of Warcraft zone - in other words a large, fairly simple contained environment with topical features and static models. I want to place it in a game. Could I use 3ds max to model this or are there better ways? Additionally, is it common practice to model levels in the engine? Any pointers would be nice, I understand that there is an underlying aversion to newbies shouting off about making MMOs but I'd appreciate some help. I'm here to learn.

Sorry, place it in an engine. But 3DS max was the magic number.

With 3DS Max, you can create models or scenes. That's more or less game-independent.

Getting these things into a game depends on the game in question. What formats it uses, whether or not you can convert your 3DS files into those formats, and so on. Some games heavily rely on their own level-editors, others mostly use modelling packages and other tools. 3DS Max is frequently used however, so it's a safe bet. Still, doing some research and getting familiar with a level-editor if there's one available is a smart thing to do.

Currently, I use a single map, in AC3D file format (a good, low budget modelling application, with an easy to parse file format.)
I place an object down, with a string in the data to denote that its a placeholder, whereby a different object, from a seperate file, is then loaded in its place. e.g.

I just put in a big cube with the name "PLACEHOLDER shoe_shop_1" and, when loading the level, the shoe shop model is loaded, with the orientation data of the cube. The actual geometry of the cube is ignored. Then, I only have to model one shoe shop, and all shoe shops of that type are updated when I decide to put a revolver under the counter, for example, or change the texture for the floor. Via this method, I have turned my basic modelling application into an expedient level editor.

I've come up with loads of other hacks for AC3D and its file format, which I am known to talk about at any opportunity.

For small levels, and newbie games, just copy and paste. Efficiency is not your main goal, but rather the learning experience and the satisfaction of seeing a forest full of trees with alpha masked leaves.

Quote:Original post by speciesUnknown
Currently, I use a single map, in AC3D file format (a good, low budget modelling application, with an easy to parse file format.)
I place an object down, with a string in the data to denote that its a placeholder, whereby a different object, from a seperate file, is then loaded in its place. e.g.

Many level-editors use the same idea. I once implemented a similar system, though rather than interpreting an objects name as a model filename, I linked them to a script that defined their purpose. These placeholder blocks could be replaced by triggers, spawn placed, models, doors, etc. Inspiration for this was taken from Half-Life, although the Hammer editor allows you to modify all these properties in the editor itself, whereas my system had you writing script files outside the modelling tool.

Using a modelling tool for everything has another downside though: you won't see the exact placement of these models untill you run the game. A decent editor will show you the models right there. So, unless you heavily modify that modelling package with plugins and all that, nothing beats a specialized level-editor in my book. ;)

With this modelling app, you can add a data chunk of any size to each piece of geometry. Currently, this data chunk tells the loader what to do with the collision mesh. if the object has the word TRIMESH it will be sent to the physics system and attached to the objects rigid body list. If it contains the word RENDERED it will also go to the renderer. If it contains the word COLLIDE_BULLETS it will be allowed to collide with bullets. the word COLLIDE_ENTITIES means it can collide with characters and other objects. By using this simple, one word at a time scripting "language" I can put all the properties of my objects in the editor itself.

The same goes for 3DS Max, which is what my teammates used at the time. It works, sure, so if that's all you need, then just go for it. I'm not telling you that your approach is wrong or whatsoever, I'm just trying to get the point across that specialized level editors do have several features that make them superior to modelling packages when it comes to level-design.


For example, this approach gets rather tedious for more complicated systems: imagine a trigger, that opens a door when the player steps out of it. This door that rotates only 60 degrees, while playing a sound when rotating and another one when closing. A perfectly normal situation in an average shooter. The trigger could have the following line attached: "TRIGGER ONMOVEOUT=door1". The door: "DOOR NAME=door1 ROTATE=80 MOVESOUND=screek STOPSOUND=clang". I think you can imagine how annoying this becomes when you start working with more complicated setups (oh, I didn't notice the TRIMESH keyword between all the other 20 properties, so that's what I forgot to change!).

An editor that shows you all properties in a neat little window and highlights connections between game objects can make life a lot easier here. Not to mention existing compile tools that generate simplified collision meshes for you. At least I found creating these by hand and keeping them synchronized to an ever-changing visual hull quite annoying and labour-intensive.

Quote:Original post by Captain P
The same goes for 3DS Max, which is what my teammates used at the time. It works, sure, so if that's all you need, then just go for it. I'm not telling you that your approach is wrong or whatsoever, I'm just trying to get the point across that specialized level editors do have several features that make them superior to modelling packages when it comes to level-design.


For example, this approach gets rather tedious for more complicated systems: imagine a trigger, that opens a door when the player steps out of it. This door that rotates only 60 degrees, while playing a sound when rotating and another one when closing. A perfectly normal situation in an average shooter. The trigger could have the following line attached: "TRIGGER ONMOVEOUT=door1". The door: "DOOR NAME=door1 ROTATE=80 MOVESOUND=screek STOPSOUND=clang". I think you can imagine how annoying this becomes when you start working with more complicated setups (oh, I didn't notice the TRIMESH keyword between all the other 20 properties, so that's what I forgot to change!).

An editor that shows you all properties in a neat little window and highlights connections between game objects can make life a lot easier here. Not to mention existing compile tools that generate simplified collision meshes for you. At least I found creating these by hand and keeping them synchronized to an ever-changing visual hull quite annoying and labour-intensive.

Your dead right of course, but my game is currently just a level loader with a camera attached to an md2 character. Here is my fantastic scripting language:

PLACEHOLDER <STRING>;

-- object is replaced at load time with an object from the database
RENDERED;
-- object is added to the renderable mesh
PHYSICS;
-- object is added to the physics system. if not set, object will be static geometry.
TRIMESH; -- object will be a collision trimesh.
BOX <FLOAT> <FLOAT> <FLOAT>; --object will be represented by said box as its collision model, rotated by the objects euler rotation. obviously this needs more paramaters but it works
COLLIDE_ENTITY -- object will be allowed to collide with entities
COLLIDE_BULLET -- object will be allowed to collide with bullets

It works. I use something sort of like a finite state machine to scan the data chunk of each object. If I start needing more complicated stuff I will replace the whole thing with Lua/Python scripts. Physics wise, although this is mostly uniplemented, the idea is that each object is a compound object, where some child objects will be geometric primitives, and the rest will be trimeshes. I'm using ODE which gives me low level control over this stuff. Hence the BOX keyword, which means that object and its child objects will be treated as a single box by the physics system. (a television for example, with buttons and other complex geometry, is represented by a single box as far as collision is concerned.)

Also, I don't have anybody to do the modelling, so lots of objects currently have the data chunk "PLACEHOLDER heinz_baked_beans_can" and "PLACEHOLDER twisted_lump_of_metal". (twisted lump of metal is designed to test the heirarchial organisation of the file format, and the baked beans can is a nonstalgia thing. Its a recreation of my first polygon model.)

[edit] I'm really proud of my game idea, basically you pick up physics objects and hit zombies with them, in a GTA style city, and collect valuable stuff to sell. Ultimately, you need to build the ultimate computer, and therefore need to find parts.