Re: Question about development of prototyping tools.

You're right but if you consider the whole pipeline (from audio to 
packaging to testing), this is very focused pb.

Not easy but quite focused, hence likely to be manageable. In my old 
days, we were scripting the game to get the env cube map for each 
buildings. Looks similar.

Lionel.

On 04/21/2011 02:06 PM, Oladotun Rominiyi wrote:
>
> 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

-- 
Best regards,
Lionel Barret de Nazaris
Gamr7 - CEO
===
Create bigger cities faster with Urban PAD <http://gamr7.com>.
follow us : blog <http://urban-pad.posterous.com/rss.xml>, twitter 
<http://twitter.com/Gamr7>, facebook 
<http://www.facebook.com/pages/Urban-PAD/124363971359>

Disclaimer: This message contains confidential and legally privileged 
information. This information is intended only for the addressee of this 
message. In case you have received this message in error, you should not 
disseminate, distribute or copy it. Please notify the sender immediately 
by e-mail and delete this message from your IT system.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com