Re: Question about development of prototyping tools.

Thank you Jon, what you write makes a lot of sense.
Both approaches you mentioned were considered and I was going to move
towards those goals in the future. I suppose a truly robust save/load system
is the key. It now seems reasonable those two things together would be just
better than go figure about "state compatibility".

I will have to keep this in mind.

Massimo


2011/4/24 Jon Watte <[email protected]>

> On Sat, Apr 23, 2011 at 5:28 AM, Massimo Del Zotto <[email protected]>
>  wrote:
>
> I'd still want to support dynamic reloading again in some future iteration
>> so I'd like to read some directions on solving those issues.
>>
>>
> I've found two things being useful:
>
> 1) Use indirection properly. Assets are just data containers, and are
> exposed to the rest of the game through some abstraction (which could be an
> ID and a library call, if you're data centric, or an object if you're OO
> centric). Pointers straight into the asset data are only allowed by the
> abstraction, and not surfaced outside that point. When you reload assets,
> you reload the data, and patch up the pointers kept by the ONE THING that
> knows about the asset internals; the rest of the game accesses the necessary
> data through that one thing, potentially using temporary handles that are
> invalidated each frame (in debug mode, physically invalidated, so you catch
> people trying to keep them around).
>
> 2) Save/Load. If you have a "perfect" save/load system, then if you change
> too much for the state to be properly patch-able, you "save" the game (to
> RAM) and reload the level as if the user had done a "load" of the game. This
> does impact scripting, though -- you can't implement timed triggers using
> native coroutines, for example; you have to have enough data hooks into
> EVERYTHING that you can properly save and restore all the state that
> matters. It turns out that when all your state lives in data, rather than
> implicitly in active call stacks and stuff, there are some other nice
> structural benefits that come out of that, too, but it does require a
> different way of thinking about writing script code for someone who's used
> to banging it all out as sequential code.
>
> Sincerely,
>
> jw
>
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
>
>>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>

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