Re: dynamic runtime responsiveness (was: Sweng-Gamedev Digest, Vol 54, Issue 1)

Visual Studio does edit-and-continue of both C++ and C# code. The main
problem comes when you want to change a data structure (add a field, or
whatnot).
Python, and similar redefine-global-names-at-runtime languages, also have
that problem -- if you're duck-typing, and want a member named "foo," and
it's not there, you will throw, no matter what.
It turns out that exhale-update-inhale actually allows you to make bigger
changes than edit-and-continue / global-replace, because you can keep the
serialized format compatible across data structure changes.

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.



On Mon, May 3, 2010 at 9:30 AM, Jon Frisby <[email protected]> wrote:

>
> On May 3, 2010, at 10:16 AM, Brandon Van Every wrote:
>
>  On Mon, May 3, 2010 at 9:45 AM, Jon Frisby <[email protected]> wrote:
>>
>>>
>>> On May 3, 2010, at 8:29 AM, David Black wrote:
>>>
>>>
>>>>>>>  1) Unity3D builds serialization/deserialization of scene objects
>>>> in at a very deep level and can in many circumstances reload your
>>>> game code (which is all C#/UnityScript/Boo-based) on the fly by
>>>> recompiling when a file has changed, serializing the running
>>>> scene to a temp file, loading the new code, and then
>>>> deserializing the scene.  Generally this happens quite quickly
>>>> and causes only a minor hiccup, although the automatic
>>>> compilation process can get pretty slow if you have a lot of game
>>>> code -- one game of mine takes a good 10-15 seconds to recompile,
>>>> and several seconds to reload during a running game.
>>>> <<<
>>>>
>>>> Just how much game code are you talking about? I find I can recompile
>>>> 200k lines of C# (with the MS compiler...) in less than 5 seconds.
>>>>
>>>
>>> About 15,000 lines of code, but this is being compiled with a customized
>>> Mono build, while the game is running (and generally chewing up more than
>>> a
>>> full core), on a Mac laptop with a fairly slow disk (5400 RPM).
>>>
>>
>> The performance of a dynamic modification language under a full system
>>
>
> Strictly speaking, in this instance the 'dynamic' features of Mono / CLR
> are not being used -- it's basically just doing the analogue of "build
> project" whenever a source file changes, then doing a serialization shuffle.
>
> However (to keep this on the original point), many languages can manage
> code reloading / code modification on-the-fly with without such complexity.
>  Ruby, while generally not a good fit for a (runtime) scripting language for
> a game has language / engine features that facilitate this to good effect.
>  (See:  Ruby on Rails in Development mode, for example.)
>
> -JF
>
>
> _______________________________________________
> 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