I have just added a scripting system to the engine. Right now it supports Boo, but it will be extended to C# soon.

It uses coroutine in order to make scripting over frame/time very easy :

• "yield" will suspend execution until next frame.
• "yield StartCoroutine(coroutine)" will add a coroutine to the scheduler, and the calling coroutine won't be resumed before the called coroutine has finished.
• "yield Wait(3.5)" : the engine will wait for 3.5 seconds before resuming the coroutine

Simple example which move the camera every frame :

 class Test(IScript): 
    i = 0.0
    def Run() as IEnumerator:
        while true:
            rvs = SceneDesignerContext.Services.GetService(typeof(IRenderViewService)) as IRenderViewService
            rvs.Eye = Vector3(40 + i, 40, 40)
            i += 0.01
            yield
 

Latest days, I have spent some time playing with Windows Presentation Framework aka WPF, the presentation layer of the new .NET Framework 3.0/3.5, with Visual Studio 2008 Beta 2.

The learning curve is rather low at the beginning, but once you get used to the basis, it becomes totally exponential.

• Controls are built from other in a tree-like way. By the way, ever checked Microsoft Blend Expression ? It got an awesone PropertyGrid like control, in which you can bind every property to external sources. However, after some investigation, I realized that it should be relatively easy to do one like that in WPF thanks to this tree-like architecture. Note that care has to be taken due to airspace issues between D3D and WPF (a pixel can't belong to both). However, in an editor, controls should be in their own airpsace.
• System.Windows.Data also holds another big stone of their system : their DependencyProperty & Binding system. It could be a great architecture for a game engine (shader variables, entity variables, etc...). I started working on a similiar system. However, performance requirements (thousands of variables updated each frame) made me go the JIT way (binding are compiled at runtime with DynamicMethod).

All of this will be included in the engine some time in the future.

Until now, I was reluctant to go the C# way as it wasn't portable across console and garbage collection (GC) could behave too much nondeterministically for gamedev IMO (GC freeze during gen0 collection, etc...).

However, in C++, the lack of reflection, JIT and RTTI, coupled with the very slow compile time is really a pain for engine development. Especially since C++0x won't feature them as it wasn't ready (it will be 2009 for god sake, not even speaking of the delay for compilers and console compilers to support them !).

I recently discovered LLVM project and was delighted by their technology. After some investigation, I think it should be possible to write a frontend for C# relatively quickly, and with the help of C, assembler, PPC 64 or JIT backend, should be portable with amazing speed on different platforms, including console. Moreover, it provides a very nice framework for writing optimizations, specific allocator/GC, and extensions of language that would be targeted for gamedev. Needless to say that I started to write a little LLVM frontend for C#. I don't know if it will end some day (as Entropia is still priority #1 right now) but it looks very easy to integrate with LLVM. Thanks to boost::spirit I was able to write C# parser of the (nearly) full grammar in (non-full) 3 evening !