The discussion of Rotor as a game scripting engine brought up what I think is a very interesting question. Along with using Rotor as a cross-platform scripting engine (for gaming or anything else) comes the question of library factors.
One of the very compelling design decisions for the CLI specification was the inclusion of a class library factoring right from the get-go. That is, different platforms will have different requirements, and hence implements different factors which have as few horizontal dependencies as possible. The idea behind this is that you have a predictable chunk of functionality available that can be targetted as a unit and which doesn't contain more than is necessary. This affects a lot, including how you architect your binaries. I'm guessing that it would be a mistake to architect a DLL which contained pieces of multiple library factors unless you want to hard-wire those factors together, because otherwise when the DLL is loaded into memory you'll carry more than you need if you only want functionality from one of the factors. So here's where my question comes in: in a situation where a lot of efficiency is needed, you won't want to carry along any more information than is necessary. Since the game engine is basically a platform unto itself (a platform whose audience is limited to the developers of game script), it has its own factor requirements; furthermore, those requirements might be more specific (and eclectic) than normal. For example, a game engine might use bits and pieces from many of the ECMA-established class library factors, but in this case you wouldn't want to include all of each factor 'sampled' from. The solution, in my mind, is to create a custom class factor which has its own binary architecture and its own class inclusions. This is impossible with the MS .Net CLR, but it seems to me that it would be entirely viable with a codebase like Rotor. So after too-long a preamble, here're my questions: 1) Am I off base here? 2) Is there any way to make such a thing easily done using the Rotor code-base? 3) If this were formalized as one goal of the Rotor project (i.e. that the Rotor code base lend itself to refactoring), might that not give it a much wider, and more useful, application to other projects? What do you all think? -----Original Message----- From: Discussion of the Rotor Shared Source CLI implementation [mailto:[EMAIL PROTECTED]] On Behalf Of Ken Alverson Sent: Sunday, April 14, 2002 5:55 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Rotor as a game scripting engine > From: Alan Cabrera [mailto:[EMAIL PROTECTED]] > Posted At: Sunday, April 14, 2002 1:51 PM > Subject: Rotor as a game scripting engine > > I'm looking for a scripting engine for my game and was wondering if Rotor > might be a good candidate. I'm currently looking at Python and Java. I'm > not interested in rolling my own. I think a lot of the responses on this list are overestimating the need for speed in a game scripting engine. Generally, a high performance 3d game will spend over 90% of its time doing rendering and 3d manipulation, and that code is usually native. If the game logic takes 10% of your time, even a quadrupling of the logic speed would only give you a 7% overall speedup. And while a few percent is not insignificant, the effort could probably be put to better use optimizing the 90% case, which will have a better payoff. It helps if you have a prototype you can profile, but I understand that's difficult during the planning stages. Ken
