 So, after Saturday's little show and tell talk, I thought it was about time to actually address a subject related to engines and stuff. Rather than get started on graphics, which Conor has pretty much got down, I thought I'd start talking about scripting. When you say scripting in the presence of certain pairs of ears, a holy war is started where the disciples of Python wreak vengeance on the the followers of Java, who get more than a little annoyed at people who think C is the best way to go...it gets a bit messy. Scripting, with respect to computer games, is the method of controlling what happens in the game. The word 'scripting' means different things to different people. I always thought of it as a run-time interpreted language, which is parsed and executed on the fly. Thus, by my definition, JavaScript is a scripting language, Java isn't. However, the meaning has got a bit blurred, and now scripting languages in games can be sorted into several distinct categories: Quake II adopted a core-code level approach. Mod authors wrote their mods in C, compiled down to .dll files which were linked at run-time with the Quake II executable. There were both good and bad things in this approach. The mods were extremely flexible, but lacked a safe "sandbox" environment. A sandbox is where a mod author can do anything in his script, and is guaranteed not to trash the program. A well written mod shouldn't worry about these things, but at development time it was quite possible to screw things up quite badly. The lack of a sandbox also meant that potentially malicious mods could be written. Some trust was involved on the part of the mod users. Unreal went the other way, and implemented a byte-code based language. Because the developer of the engine wrote the virtual machine, which was responsible for running the mods, he could control what was done to the engine, including controlling the memory access the mod was granted. Thus all mods were guaranteed safe to the system. Tim Sweeney (Unreal guru) actually went the whole hog and designed and implemented a whole new scripting language, UnrealScript, that was designed for game content control. It included several new language features, such as class states and latent functions, and was ideal for a game content control system. My work with the Crystal Space engine at the moment is on the content-control system. The problem I faced was designing a system that fitted in well with Crystal Space's metaphor of "let the user decide". Because Crystal Space is being developed by so many different people, some people are going to want to use the core-code level approach, while others (myself included) will be more interested in a purpose-built environment. So how to do this? The first design step involved encapsulating the functionality of a content-control (CC) system. I defined the Game Object to be a developer controlled object that represented a 'thing' in the real world. This is a pretty fuzzy definition, but one which allowed the developer to approach the object hierarchy at whichever level he liked. This game object (csGameObject in Crystal Space) maps onto in-engine equivalents. A 'lamp' object in the game maps onto a csLight and a csSprite3d object. The CC system I developed handles these mappings correctly, and synchronises the csGameObject and its in-engine equivalents. So updating a variable 'x' in the csGameObject causes the 'x' variable in the csLight to become updated as well. The internals of this are a little convoluted with the present implementation, I'm looking to smooth that out a bit. Some other plus points of the csGameObject system is that they are fully plug-and-play, easily loaded and saved. But the big Good Thing is that they can be controlled whichever way you want. A core-code developer can just create descendants of csGameObject that have the functionality he wants, knowing that they will be synchronised with the in-engine object. A scripting language can control these externally, a byte-code based system can utilise them transparently to the script. There are drawbacks. Mainly, that the csGameObject metaphor enforces an object oriented programming methodology on the script writer. I think this is possibly a good thing: procedural programming doesn't quite cut the mustard for CC IMHO. Also the implementation is a little kludgy. I hope this will change, but is probably a product of my desire to write code and get things working quickly. Anyway, the moral is: general solutions are the Right Thing, but don't be afraid to close off areas that don't fit in with your methodology. A happy medium is the best thing. H. p.s. comments, questions? Ask me p.p.s. Now there are four of us. Thanks for the welcome, Conor, it's good to be here. 
|
