Re: Sweng-Gamedev Digest, Vol 54, Issue 1

Bit late to the party :)

I did the first one for the Conviction engine, within Unreal and in C++. We built the engine from scratch and hence had very fast compile times (completely isolated from the Unreal codebase, custom windows header, DLL with minimum dependencies, etc). At one point you could load a level within UnrealEd while iterating on some C++ code, hit build and link - this would complete within 2-3 seconds - and then see your changes reloaded within another couple of seconds. If you wanted you could sit editing code for hours (changing data structures, adding/removing functions, etc) without bringing the game/editor down, maintaining the ability to step-debug it. It was stupidly powerful but not fully developed... though certainly proved that "hot-loading" C++ code changes is more than possible and rea
 lly should be the standard these days.

To give a good example of scripting performance and use, however; on Lucky Luke (circa 1998-2000) we had a scripting language (SOOL, IIRC) which most of the gameplay logic was built in. From memory, there was 5% C++ code (VM and language bindings), 30% C code (engine and gameplay systems) and the rest of the game logic was written in SOOL by the majority of the programmers on the team. This was capable of running on the trusty old 33MHz PSX, although was heavily event-based. I only remember the PC performance figures, which was 2% of the frame in the virtual machine on an average machine for the day (200MHz?).

Cheers,
- Don





________________________________
From: Jon Frisby <[email protected]>
To: [email protected]
Cc: [email protected]
Sent: Mon, May 3, 2010 12:26:22 PM
Subject: Re: [Sweng-Gamedev] Sweng-Gamedev Digest, Vol 54, Issue 1

Some examples here:

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.

2) REPL ("Read, Eval, Print, Loop") tools are commonplace in a lot of script languages, and many frameworks will extend such tools to include code reloading where the language supports it.  (Ruby has "irb", Mono has CSharpRepl -- "csharp" for the CLI version, "gsharp" for the GUI version, and I even managed to wedge a version of the former into Unity's IDE.

-JF


On May 2, 2010, at 8:49 PM, Shaun Stamper wrote:


>>Edward Corlew wrote:
>
>I think with some languages you can even adjust
>>some parameters while the game is running and see the effect in game.
>> I'm not sure if this is true.  Can someone comment on that?  
>>
>Yes, a fair few scripting languages allow for editing parameters on the
>fly. A lot will also allow the script code to also be edited and
>reloaded while the game is running, or even just have arbitrary code
>executed from a Quake style console.
>
>
>_______________________________________________
>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