I'm not sure if this is a common quesiton in the list, but I think tool programming is a very overlooked issue of software engineering in game development.
So my question is, since many here have tremendous experience in the game industry and worked on huge projects, what kind of tools do software engineers supply to game or level designers so they can, for example, prototype a game stage before, say, 3D artists start working on a final version?

In more depth, games like Halo, God of War or Mario Galaxy for example have really complex scenarios, so complex that a height map or grid map editors do not suffice for prototyping. I can imagine that before 3D artists can start working on the final art, a simpler looking prototype must be created. I also can imagine that creating such prototypes need constant adjusting on the fly (a cliff may be too high, a room to small to fit the enemies, a target out of shooting range), so either special tools for editing stages are created or special plugins for integrating with, say, maya are needed? Also, is it common that game or level designers know how to work with 3D apps for stage design? or do engineers have to create special tools for them? If so what kind of tools?

Cheers!

Juan Linietsky

And here is the dirty secret:

 

In my experience it is a lot easier and faster to build the tools into the game. You already have the scene being rendered etc. All you need is to switch the game to "Edit Mode" and your tool(s) can take over, making the artist/designer make changes right there in the game, save and continue.

 

Even back in the old days when I was working on Banjo Kazooie for the N64 we could stop the game at any point, move spawnpoints around, add/remove objects etc., save and the restart the level with the player character starting right next to what you edited. In other words, the cycle time was a few secs. And that was using the (by todays standard) very limited N64 hardware. So no excuse today when we have access to hardware that is literally 100+ times more powerful

 

The key thing to keep in mind (from an architectural point of view) is to put a clear wall between "level definition" data and "level running" data. That allows you to edit the "level definition" data without touching the "level running" data => you can continue playing the game after you edit it.

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Gregory Junker
Sent: Thursday, 21 April 2011 3:36 PM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

 

 

In my experience it is a lot easier and faster to build the tools into the game. You already have the scene being rendered etc. All you need is to switch the game to "Edit Mode" and your tool(s) can take over, making the artist/designer make changes right there in the game, save and continue.

 

 

I would be careful though, which parameters (or at least which properties of a given parameter) your tool saves. TGE’s world editor (for painful example) would also save the state of, say, sound effects, so your level designer might run the level, change something, and find next time they restart the level that a seemingly random sound cue is playing.

 

Greg

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Javier Arevalo
Sent: Thursday, 21 April 2011 4:57 PM
To: sweng-gamedev <at> lists.midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

On 4/21/2011 7:16 AM, Morten Brodersen wrote:

And here is the dirty secret:

 

In my experience it is a lot easier and faster to build the tools into the game. You already have the scene being rendered etc. All you need is to switch the game to "Edit Mode" and your tool(s) can take over, making the artist/designer make changes right there in the game, save and continue.

 

Even back in the old days when I was working on Banjo Kazooie for the N64 we could stop the game at any point, move spawnpoints around, add/remove objects etc., save and the restart the level with the player character starting right next to what you edited. In other words, the cycle time was a few secs. And that was using the (by todays standard) very limited N64 hardware. So no excuse today when we have access to hardware that is literally 100+ times more powerful

 

The key thing to keep in mind (from an architectural point of view) is to put a clear wall between "level definition" data and "level running" data. That allows you to edit the "level definition" data without touching the "level running" data => you can continue playing the game after you edit it.

There are a few issues with this in the console world. Modern consoles may be 100x more powerful than a N64, but modern game technologies and content (for good or bad) are also 100x bigger:

- Game runtime data (even the definitions) is normally in a 'cooked' state, processed, compressed, etc. For example, your source level definition data may be some XML file, but your pipeline turns it into a binary memory image blob; scripts will usually be read by the runtime in bytecode compiled form; string identifiers will be compiled into binary hashes, etc. If your game is anywhere close to pushing the platform, you may not have memory (almost guaranteed on a certain platform's dev kit) to keep the source data and all the extra code that handles the source format.

- Even if you can plug mouse and keyboard to modern consoles, the kind of interfaces that you can build on a console may be too limited compared to working on a real windowing GUI with multiple monitors, all sorts of handy widgets, on-line help, etc.

These are the kind of reasons why many studios keep a PC version of their game running even if the game will not be released on PC. It's much easier to augment a PC version with the kind of tools Morten described (and not just production tools - debugging helpers as well!), and the effort of maintaining this PC version of the code may be worth because the tools will be orders of magnitude better.

The other alternative is, of course, building your tools on the PC and having a communications system where the tools can send hot-reloading requests to the game running on the console. But in this way, you have to code every feature that can be reloaded separately, and my experience is that many features will not support hot reloading until you realize you absolutely need it, and this support will be crude in many cases.
-- Javier Arevalo http://www.iguanademos.com/Jare

Message

But then you still run into the problem of having to deal with the baking factor if, for example, you’re moving objects around scenes, all your static ambient occlusion, shadows and radiosity will need to be re-baked…

 

From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Morten Brodersen
Sent: 21 April 2011 13:01
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

 

Console development hasn't fundamentally changed during the last 15+ years. Game runtime data then had to be as cooked and compressed as today. The details and data sizes are different but the issues remain the same.

 

Don't confuse gameplay editing with resource (model/texture) editing. There are excellent external industry standard tools for resource editing (3D Studio Max etc.) and it usually makes no sense to try and recreat that within the game. However the gameplay editing (placing of objects, characters, pathways, scripts, triggers, real-time lights, pickups, spawnpoints etc.) can with great benefit be edited in-game using a normal game controller.

 

Morten

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Javier Arevalo
Sent: Thursday, 21 April 2011 4:57 PM
To: sweng-gamedev <at> lists.midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

On 4/21/2011 7:16 AM, Morten Brodersen wrote:

And here is the dirty secret:

 

In my experience it is a lot easier and faster to build the tools into the game. You already have the scene being rendered etc. All you need is to switch the game to "Edit Mode" and your tool(s) can take over, making the artist/designer make changes right there in the game, save and continue.

 

Even back in the old days when I was working on Banjo Kazooie for the N64 we could stop the game at any point, move spawnpoints around, add/remove objects etc., save and the restart the level with the player character starting right next to what you edited. In other words, the cycle time was a few secs. And that was using the (by todays standard) very limited N64 hardware. So no excuse today when we have access to hardware that is literally 100+ times more powerful

 

The key thing to keep in mind (from an architectural point of view) is to put a clear wall between "level definition" data and "level running" data. That allows you to edit the "level definition" data without touching the "level running" data => you can continue playing the game after you edit it.

There are a few issues with this in the console world. Modern consoles may be 100x more powerful than a N64, but modern game technologies and content (for good or bad) are also 100x bigger:

- Game runtime data (even the definitions) is normally in a 'cooked' state, processed, compressed, etc. For example, your source level definition data may be some XML file, but your pipeline turns it into a binary memory image blob; scripts will usually be read by the runtime in bytecode compiled form; string identifiers will be compiled into binary hashes, etc. If your game is anywhere close to pushing the platform, you may not have memory (almost guaranteed on a certain platform's dev kit) to keep the source data and all the extra code that handles the source format.

- Even if you can plug mouse and keyboard to modern consoles, the kind of interfaces that you can build on a console may be too limited compared to working on a real windowing GUI with multiple monitors, all sorts of handy widgets, on-line help, etc.

These are the kind of reasons why many studios keep a PC version of their game running even if the game will not be released on PC. It's much easier to augment a PC version with the kind of tools Morten described (and not just production tools - debugging helpers as well!), and the effort of maintaining this PC version of the code may be worth because the tools will be orders of magnitude better.

The other alternative is, of course, building your tools on the PC and having a communications system where the tools can send hot-reloading requests to the game running on the console. But in this way, you have to code every feature that can be reloaded separately, and my experience is that many features will not support hot reloading until you realize you absolutely need it, and this support will be crude in many cases.

--

Javier Arevalo

http://www.iguanademos.com/Jare

_______________________________________________ Sweng-Gamedev mailing list Sweng-Gamedev <at> lists.midnightryder.com http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Oladotun Rominiyi
Sent: Thursday, 21 April 2011 10:06 PM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

But then you still run into the problem of having to deal with the baking factor if, for example, you’re moving objects around scenes, all your static ambient occlusion, shadows and radiosity will need to be re-baked…

 

From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Morten Brodersen
Sent: 21 April 2011 13:01
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

 

Console development hasn't fundamentally changed during the last 15+ years. Game runtime data then had to be as cooked and compressed as today. The details and data sizes are different but the issues remain the same.

 

Don't confuse gameplay editing with resource (model/texture) editing. There are excellent external industry standard tools for resource editing (3D Studio Max etc.) and it usually makes no sense to try and recreat that within the game. However the gameplay editing (placing of objects, characters, pathways, scripts, triggers, real-time lights, pickups, spawnpoints etc.) can with great benefit be edited in-game using a normal game controller.

 

Morten

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Javier Arevalo
Sent: Thursday, 21 April 2011 4:57 PM
To: sweng-gamedev <at> lists.midnightryder.com
Subject: Re: [Sweng-Gamedev] Question about development of prototyping tools.

On 4/21/2011 7:16 AM, Morten Brodersen wrote:

And here is the dirty secret:

 

In my experience it is a lot easier and faster to build the tools into the game. You already have the scene being rendered etc. All you need is to switch the game to "Edit Mode" and your tool(s) can take over, making the artist/designer make changes right there in the game, save and continue.

 

Even back in the old days when I was working on Banjo Kazooie for the N64 we could stop the game at any point, move spawnpoints around, add/remove objects etc., save and the restart the level with the player character starting right next to what you edited. In other words, the cycle time was a few secs. And that was using the (by todays standard) very limited N64 hardware. So no excuse today when we have access to hardware that is literally 100+ times more powerful

 

The key thing to keep in mind (from an architectural point of view) is to put a clear wall between "level definition" data and "level running" data. That allows you to edit the "level definition" data without touching the "level running" data => you can continue playing the game after you edit it.

There are a few issues with this in the console world. Modern consoles may be 100x more powerful than a N64, but modern game technologies and content (for good or bad) are also 100x bigger:

- Game runtime data (even the definitions) is normally in a 'cooked' state, processed, compressed, etc. For example, your source level definition data may be some XML file, but your pipeline turns it into a binary memory image blob; scripts will usually be read by the runtime in bytecode compiled form; string identifiers will be compiled into binary hashes, etc. If your game is anywhere close to pushing the platform, you may not have memory (almost guaranteed on a certain platform's dev kit) to keep the source data and all the extra code that handles the source format.

- Even if you can plug mouse and keyboard to modern consoles, the kind of interfaces that you can build on a console may be too limited compared to working on a real windowing GUI with multiple monitors, all sorts of handy widgets, on-line help, etc.

These are the kind of reasons why many studios keep a PC version of their game running even if the game will not be released on PC. It's much easier to augment a PC version with the kind of tools Morten described (and not just production tools - debugging helpers as well!), and the effort of maintaining this PC version of the code may be worth because the tools will be orders of magnitude better.

The other alternative is, of course, building your tools on the PC and having a communications system where the tools can send hot-reloading requests to the game running on the console. But in this way, you have to code every feature that can be reloaded separately, and my experience is that many features will not support hot reloading until you realize you absolutely need it, and this support will be crude in many cases.

--

Javier Arevalo

http://www.iguanademos.com/Jare