> If I understand your statement correctly, that rotor is too powerful, it > means that it's too complex and difficult for the simple needs of scripting. > I want to provide a set of "built-in" classes for the people who script the > game. These people would work with this pre-built set of game classes and > objects at a very simple level; the pre-built scripting code underneath > would handle the complexity.
That is what they do in Terrium(sp), although the scripting is done external to the game and compiled to dll files. Although there is a very limited scope for what procedures can be called and allowed built into the game engine itself. > This robust environment will assist in making more complicated and > interesting behavior for my game. Robust is good. But it should be limited by the game Engine itself. IOW you don't need a language that can write the game itself available as a scripting language. You need a language that works within the scope of the engine. That would be true of any implementation of a language, be it Python, Ruby, C#, or roll your own. I don't agree that there would be a performance hit in useing the CLR over a Interpretive engine myself. (maybe upfront as the JIT compiles the code) But personally, I would limit the script to one language if using the CLR. And prevent it from access to several classes that it doesn't need access to. Based of course on the scope of the game. > I like the idea of machine independent code for my engine. I see myself > having a set of "thin" game engines running on a variety of platforms and > having a single set of scripting and art collateral running on them all. > Maybe that's naive of me. nope that is exactly how Unreal tourn runs. Although the Game engine is tailored to both Windows and Linux depending on what platform you are running in. > I want to get this running on a PC and a Linux box. Maybe this is also > naive of me. > > With this said, let me ask you a couple questions. > > If the people who script the game keep things simple, do I still get a > performance hit compared to other scripting engines? I still don't think you will get a performance hit. I have seen preliminary games programmed with direct x libraries brought in as managed code taking very little performance hit running in .net framework. There is the intitial hit of JIT compiling. which can be big if there is alot of code to jit. But you see that in Unreal tournament(loading a level) and other games. While a scripting engine taylored specifically to your game engine will have the lowest performance hit. I do believe that Rotor can bring a good scripting engine, If you take the time to taylor it to your needs. The ability to comile to native code will be a performance boost over a pure Interpretive scripting engine. But then there is other concerns in that. I do know that you don't want a General Purpose language for a scripting language. I personally wouldn't allow anything but integer math in a scripting language for example. Perhaps allow only one type of loop. Case based decision trees would probably not be a good thing in scripting languages. those type of limitations would have to be looked at to maintain performance goals. (of course with a JIT that compiles to native machine code, those limitations could be overlooked) > I'm not really married to the idea of using Rotor, just looking for > opinions. What other engines would perform better? IMO, any scripting engine will be a performance hit over one natively written for the game engine itself. In light of that, it would be how much of a performance hit is acceptable. Experimenting with the implementation will not hurt. If you find the performance suffers to much, you could roll your own at that time. I personally would look at one that can compile over one that is interpretive. But each implementation has it benifits. > I read an article on the UnReal scripting engine. They also do garbage > collection. It doesn't seem to bother them. garbage collection is a good thing;) there is a performance hit using it. but the overall gains outway the loss in performance hit by a long shot. Almost every engine since the concept of a game engine has come into existance(doom) has some type of garbage collection. > Thanks for helping me clarify these issues for me. I am eager to hear your > opinions. Rotor, IMO would be a good choice, if you take the time to tailor it to the needs of your game engine. While the scripting language can be Robust, It does't, and shouldn't IMO, be a General Purpose language. Such things as handleing noninteger math, for instance. There are several books that talk about scripting languages. The game programmers gems series contain a few. la monthe(sp) books on game programming. An article in next months MSDN mag talks about ms current scripting engine. 5.6. (although that would break the cross platform goals) http://msdn.microsoft.com/msdnmag/issues/02/05/wsh/wsh.asp it even talks about the next version of wsh, that will be .net aware. Douglas
