Re: Question about development of prototyping tools.

Unless you are working on a stealth game where shadows are important, it
doesn't matter if the lighting is not 100% correct when editing the gameplay
of a level.
 
Morten

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Oladotun
Rominiyi
Sent: Thursday, 21 April 2011 10:06 PM
To: [email protected]
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: [email protected]
[mailto:[email protected]] On Behalf Of Morten
Brodersen
Sent: 21 April 2011 13:01
To: [email protected]
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: [email protected]
[mailto:[email protected]] On Behalf Of Javier
Arevalo
Sent: Thursday, 21 April 2011 4:57 PM
To: [email protected]
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
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com