Skip to main content
gamedev.net
🔒 Locked

scripting architecture?

Started by TonyFish Jul 9, 2004 at 2:58 AM 2 replies 1.1k views
Original Post
TonyFish
TonyFish
Hi, I have been thinking about scripting architectures recently and have been getting very confused. Maybe you can help me! It's not so much the design of the actual scripting language which confuses me. That's OK. I already have coded the best part of a small compiler and virtual machine. Ideally, I would like to write a simple version of the Unreal engine approach. This (if I have understood it correctly) features a VM which gives OO scripts access to engine functionality like rendering etc.. which virtually all the game code is scripted. I'm having problems conceptualising how this can work from an implementation standpoint. The Wiki presents massive class tree (http://wiki.beyondunreal.com/wiki/Class_Tree_Listing_(U2)) but does not mention whether these are UScript classes or engine classes or both. Does the engine contain the same classes (Actor, Pawn etc..) as the scripts? I thought UScript was compiled to bytecode. In that case how does the mapping/binding to the engine (C++) occur. I am most confused! HELP!! PS: Please don't move this topic to the scripting forum! Many Thanks Tony
<Fish>{
Clash
Clash
I can't say anything for sure, as I havn't gotten around to implementing an OO scripting language. I have put some thought into it as its my next "big side project."

My conclusion is pretty much this: engine classes would be used as base classes for all scripted objects. Any invocation by the script of a function in one of those base classes would use the __thiscall calling convention. This implies that each instance of a script object also has an associated instance of its base engine(C++) object. Functions in the base engine object which should be virtual or pure, would instead be setup to invoke whatever script-code is associated with its instance.

So essentially, each engine function called from the script would require its C++ calling convention stored so it can be invoked properly by the VM. (For instance, non-member functions don't use __thiscall).

One way to easily expose the functions and their calling conventions would be via the DLL export table. There is an article in one of the Game Programming Gems that talks about how to walk that table and pull out the information about the various functions and classes. Doing this would allow you to export a class or function by simply placing a macro in front of it. Yay for automation.

Best of luck!
Jason Citron- Programmer, Stormfront Studios- www.stormfront.com
TonyFish
TonyFish
Groan.
My brain is melting.
I want a UDN login :(
<Fish>{
DesCr
DesCr
Quote:
Original post by TonyFish
PS: Please don't move this topic to the scripting forum!


Uh... why not? You'd probably get a better response there anyways :/

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.