I haven't look too deeply into this not even sure if there's an open source version of this stuff.

I'm just curious as to how the maps work and what the game actually needs in order to load a new map. Disregarding tools completely. Like if we were to just start making files from scratch what is the backbones of the files that make a map loadable and playable. Like if we were to have a barebones nothing in the map file. Then what is needed to add objects, ai, gfxs, etc..

I haven't look too deeply into this not even sure if there's an open source version of this stuff.

I'm just curious as to how the maps work and what the game actually needs in order to load a new map. Disregarding tools completely. Like if we were to just start making files from scratch what is the backbones of the files that make a map loadable and playable. Like if we were to have a barebones nothing in the map file. Then what is needed to add objects, ai, gfxs, etc..

It all revolves around Call of Duty: World at War, using modtools. I'm not sure if you can make your own map, excluding the modtools, if that's what you're asking.

The only thing that you need to get a map to load is a .FF that has a .bsp with the same name. A playable map however requires a map .gsc file that calls the usual functions(_load.gsc, _loadout.gsc(unless you override it)).

Things like models, fx, ai can potentially be spawned in via script. Assuming the .bsp is blank/has nothing in it, you'd have to use x,y,z coordinates to spawn something in the level. However, some assets, such as models and fx, must also be included within the .FF and preached in order to be spawned via script.

So like this:

ent = spawn("script_radius", (0,0,0), 0, 64, 64);

Which you could then use or turn it into a trigger if you wanted too.

1. I'm just curious as to how the maps work

2. and what the game actually needs in order to load a new map.

3. Like if we were to just start making files from scratch what is the backbones of the files that make a map loadable and playable.

4. Like if we were to have a barebones nothing in the map file. Then what is needed to add objects, ai, gfxs, etc..

1. The map is decoded d3dbsp information based off the quake 3 engine (if i remember correctly). This contains the information for the geometry and lighting. Then we load scripts from .ff which changes the view of the player from spectator (which is engine default) to a body. It also spawns ai which we tell what to do via scripts, but the functions we use are also engine defined.

2. Like i said earlier, all you need is the b3dbsp information to load a map (technically), but it will look weird without the scripted objects/nodes interating with the scripts. I forgot who, but someone on my skype has the bsp information for other cods.

3. When we use radient, the tool to make maps, we are technically inputing data for the geometry like the x-axis,y-axis, z-axis for each vertex point and depending on where they are located in the group determines whether its along the x column or the y column of the mesh. As for structs, they are just data points to tell the engine that we are going to put something there. The pathnodes are a series of triangulated paths that are connected together to deterine the best path for the ai to follow without glitching through solid meshes/collmaps. The spawners are a spawner for ai that is engine based. With scripts, we can determine when they should spawn an ai or what type should spawn there. Lights can be placed to illuminate the map in places where the worldspawn settings' light cant hit it. Finally for the simple stuff there is triggers which are meshes that will "trigger" and event on a certain condition.

4. The barebones maps have to have a skybox which is predefined or else your map comes off as currupt. from there it will just spawn the person a (0,0,0) in spectator mode because there is no infromation for the map (that is if its really barebones and has the minimal amount of scripts needed). If it has the zombie scripts in it, it will either spawn the player in spectator mode or spawn the player at (0,0,0) and let them fall endlessly. The further away from the origin, the foggier it will become, this is handled by the engine to allow your computer to have less work. The same tactic was used in Transhit. They used fog to hide the maps so that consoles would not have a drop in FPS.

1. The map is decoded d3dbsp information based off the quake 3 engine (if i remember correctly). This contains the information for the geometry and lighting. Then we load scripts from .ff which changes the view of the player from spectator (which is engine default) to a body. It also spawns ai which we tell what to do via scripts, but the functions we use are also engine defined.

2. Like i said earlier, all you need is the b3dbsp information to load a map (technically), but it will look weird without the scripted objects/nodes interating with the scripts. I forgot who, but someone on my skype has the bsp information for other cods.

3. When we use radient, the tool to make maps, we are technically inputing data for the geometry like the x-axis,y-axis, z-axis for each vertex point and depending on where they are located in the group determines whether its along the x column or the y column of the mesh. As for structs, they are just data points to tell the engine that we are going to put something there. The pathnodes are a series of triangulated paths that are connected together to deterine the best path for the ai to follow without glitching through solid meshes/collmaps. The spawners are a spawner for ai that is engine based. With scripts, we can determine when they should spawn an ai or what type should spawn there. Lights can be placed to illuminate the map in places where the worldspawn settings' light cant hit it. Finally for the simple stuff there is triggers which are meshes that will "trigger" and event on a certain condition.

4. The barebones maps have to have a skybox which is predefined or else your map comes off as currupt. from there it will just spawn the person a (0,0,0) in spectator mode because there is no infromation for the map (that is if its really barebones and has the minimal amount of scripts needed). If it has the zombie scripts in it, it will either spawn the player in spectator mode or spawn the player at (0,0,0) and let them fall endlessly. The further away from the origin, the foggier it will become, this is handled by the engine to allow your computer to have less work. The same tactic was used in Transhit. They used fog to hide the maps so that consoles would not have a drop in FPS.

I think Sparky released a tool to dump all the scripted or relevant  stuff from a running map into a separate .map already. The only thing it did not do was the geometry

Maybe check that out?

I think Sparky released a tool to dump all the scripted or relevant  stuff from a running map into a separate .map already. The only thing it did not do was the geometry

Maybe check that out?

it was a script AAnywaysi dont need it

it was a script AAnywaysi dont need it

yea but it dumps it to a .map file? So whatever logic it does to do that, is the same process he would need to construct his own .map types

yea but it dumps it to a .map file? So whatever logic it does to do that, is the same process he would need to construct his own .map types

the thing is... it only converts the non geometric data, so unless u want size of the map or to see how they scripted something, its useless