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.
This robust environment will assist in making more complicated and interesting behavior for my 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. 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'm not really married to the idea of using Rotor, just looking for opinions. What other engines would perform better? I read an article on the UnReal scripting engine. They also do garbage collection. It doesn't seem to bother them. Thanks for helping me clarify these issues for me. I am eager to hear your opinions. Regards, Alan > -----Original Message----- > From: Douglas and Elena Husemann [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 3:34 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET-ROTOR] Rotor as a game scripting engine > > > I agree on this. Although the next version of the scripting engine > is suppose to be based on the CLR., At first it will only support > vb.net and jscript. but eventually it will support c# and possibly > managed c++. It is unclear if it is crippled implementations of the > .net framework. Although I would imagine it would have to be. > > I will also agree that a General Purpose language is to powerful > for a scripting engine. So if Python or Java is implemented, > implement them in ways that are only needed to accomplish the > scripting that is needed for the game. > > Of course looking at dungeon siege, where the entire game is scripted > a JIT based scripting engine that allows compiling to either machine > code or down to game engine code. > > Another choice may be Ruby. It allows you to rewrite the language. > so If you are use to C for instance, the keywords and the like can be > reformated to look like C. In doing so you can make a very compact > scripting language. Although Like Python or perl or tcl for > that matter > it is an interpreted language, natively. > > Douglas > > > In my opinion, you are over shooting with rotor & the CLI - it's got a > wee bit too much power for a scripting engine. Depending on > your needs, > you may want to look at some of the ways you can host the windows > scripting host etc that will give you JavaScript and VB Script as > languages. > > What sort of scripting functionality are you looking for? > > -- > http://www.codevoid.net > Microsoft MVP > > > > > > > > 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. > > > > Thoughts? > > > > Regards, > > Alan > > > > >
