Quote:Original post by The Reindeer Effect
Just out of curiosity, what are your current plans for how to implement this?

I'm looking at two methods; one's going to be a simple command-style language that again will be loaded as a list of actions that can be 'triggered' by a user-definable event.

The other way I'm going to look at it is to use a real scripting language instead (probably GameMonkey Script or SpiderMonkey). Think of how &#106avascript is added to HTML "onClick" events are declared, or some kind of .NET delegate. I'll have a section in the XML that allows the user to define their own events and provide a script method to call; each script method should have automatically pass a 'sender' and a 'trigger'.

Note that all scripting is in GameMonkey script for this pseudoexample.



Here I'm likely to make scripting work like HTML/&#106avascript eg: each 'call' will effectively be a mini-script that will have the 'this' and 'triggerBy' objects made available to the sandbox. Notice that here, in script, I can use the attributes as they normally appear. This could be done in real-time when checking for the attribute using GameMonkey script (because it's cool [wink])<br><br><br><br>Thinking in the dynamic/data-driven mindset, my native methods for events won't be normal method calls, they'll be events that need to be registered with the entity. Sure, these events will call native functions, but that's not the point. What I'm going to do to my current message/event system is allow an entity to keep a list of <b>overrides</b> for a given event. If an event is marked as overriden, a special (native) method will be called to pass the relevant parameters to the script and call the scripted function.<br><br>So, I could potentially hardcode a generic spaceship entity class but override the <tt>OnThink</tt> method with a scripted method to give it some unique kamikaze behaviour [wink].<br><br>Like I said, this is currently WIP and so have no idea about how effctive it'll be... But if it works it could really make things really cool in my games... And anyone else who'll want it too as I release most of my stuff as open-source.<br><br>Edit: <br><br>I forgot to add; each entity will have a native method to allow it access to the scripted functions. Something like <tt>Entity::CallMethod("name", this, that)</tt> - this then opens up the scripted overrides to the programmer who wants to work totally in script for things like AI, etc.<br><br><!--EDIT--><span class=editedby><!--/EDIT-->[Edited by - evolutional on February 10, 2005 2:37:56 PM]<!--EDIT--></span><!--/EDIT-->

Quote:Original post by evolutional
...

A while back I was implementing pretty much what you described in the first one. Sort of think ... Starcraft campaign editor. You deal with a whole bunch of predefined, hardcoded commands that you combine to create your logic with. I also looked into the scripting-combined-with-xml approach, but I really didnt like it as I started to work with both XML and a scripting language. It felt so natural to do one or the other, but for some reason I just never got to far into it. Maybe if I managed my scripts and data better it would have been nicer, but as it was I just sort of overloaded. I have been playing around with lisp alot lately, and I plan on using it for my next project. The cool thing is that it is so natural to merge process and data. I will be using pure scripts, not much need for XML since I can do it all the lisp way. Of course this sort of locks me into lisp, but if worst comes to worst I can just use lisp as my own version of xml and then have the rest written in C++/C#/whatever. Don't think I would do that, but its a possibility.

Although whatever gets the job done, I just wanted an excuse to use lisp more.

Quote:Original post by The Reindeer Effect
A while back I was implementing pretty much what you described in the first one. Sort of think ... Starcraft campaign editor. You deal with a whole bunch of predefined, hardcoded commands that you combine to create your logic with.

I can see this as being painful as well. Mainly because of the logic-aspect of it. Whilst it works for XSL it could be too cumbersome for use in a game.

Quote:I also looked into the scripting-combined-with-xml approach, but I really didnt like it as I started to work with both XML and a scripting language. It felt so natural to do one or the other, but for some reason I just never got to far into it. Maybe if I managed my scripts and data better it would have been nicer, but as it was I just sort of overloaded.

I'm using this method for another project, jsInvaders, and it's not too bad. However, it probably would be good to have both data and process mixed in with script; GameMonkey script is a lot like Lua so allows you to do just this. Either way, I'm likely to create versions of all three approaches and see which one works best for me - I'm going to hazard a guess that each one will be context-dependant on how suited it is to a task.

The first approach would probably be better for level editing as it'll allow no-brain scripting without ability to code as a requirement, however it'll be restricted to the actions the programmer puts into the game. The second approach would allow for decent editing ability and will give the user more freedom in creating their own actions, but the downside is that the user will need to be more capable at coding as it will no longer be drag/drop. Finally, the second approach could potentially be like 2 with more power, but the user will have to be competent at coding in order to see the benefit. It also raises questions about level editing tools being smart enough to deal with the scripts.

Quote:
Although whatever gets the job done, I just wanted an excuse to use lisp more.

[grin] - Exactly, I'm just looking for things to play around with. I've never used lisp and haven't really ever considered doing so, maybe I should take a look some time. Thanks for your comments :)