Re: Question about development of prototyping tools.
Javier Arevalo <jare <at> iguanademos.com>
2011-04-21 06:56:55 GMT
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
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.
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com