🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Script & Game Design
Author
figured this was the right forum. at least i'm hoping so . . .
anyway, i'm making a game in C++, and i'd like to use Lua to implement / drive it. i'm simply confused on how this is done - i've coded all the classes / structures in C++ to be able to be created and modified by Lua, and i've implemented most of the "details" (i.e. specific object creation) in the Lua script. however, i'm lost on how to actually drive the game. of course, this is based on an the assumption that lua ( or whatever script is being used ) is supposed to drive the game framework, i got that assumption from some vague article i read awhile back. the way i implemented the c++ framework is based on that assumption; although i made it very flexible in case i was wrong, [grin] which happens often . . . so it can just as easily be implemented in c++, straight up, if need be.
anyway, to cut this short, what i'm trying to ask is a) is the assumption i made plausible / correct ? if so, then how is this accomplished ? i'm not asking for an implementation (nor do i want one), simply an overview - whats a good layout for the script, in terms of OOD ? should it be like c++, with a figurative "main" function / class that pretty much controls everything, or should it be more spread out ? i'm certain there is an obvious answer, but i just can't see it. any input or insight would be deeply appreciated.
[Edited by - stormrunner on July 24, 2004 1:12:26 AM]
I don't know how you would do it the OOD way, but the procedural way is simple: Whenever an even happens (player moves, player clicks the mouse, monster spawns, etc.) call the associated LUA script, which in turns calls C++ functions to get the job done.
I'll think I'll join the stormrunners question.
Do you suggest that the input would call spesific scripts, that again would "do" stuff in the engine? So you would have an event driven world in the same way the "message que" callback function in win32 programming does?
Would that mean you create scripts for every events from mouse, keyboard, joustick and the OS system itself? I guess you won't need much scripting to recive messages like "quit", but you get my point.
.. Because I was wondering wheter the script would run my game like a traditional C style main{ .. }, or the system would run the scripts..
Do you suggest that the input would call spesific scripts, that again would "do" stuff in the engine? So you would have an event driven world in the same way the "message que" callback function in win32 programming does?
Would that mean you create scripts for every events from mouse, keyboard, joustick and the OS system itself? I guess you won't need much scripting to recive messages like "quit", but you get my point.
.. Because I was wondering wheter the script would run my game like a traditional C style main{ .. }, or the system would run the scripts..
When I go the scripting way, I almost always follow an event-based model. That is, the game will call certain script-side functions at key points in your game.
So, when you've loaded up the basics of the game, I will probably call an "game_onInit()" script-side function. If an entity (say Alien) needs an init method then that too will also be called when created in the game "Alien_onInit()".
As for actually driving the game, I have a game_onUpdate() method and perhaps a level_onUpdate() method (plus the associated terminators / destructor *_onDestroy() ).
What I do is check if the funciton exists in the script, if so - call it, if not, just carry on with the default game behaviour. This may not be the best way to do things, but it works ok for me [smile]
So, when you've loaded up the basics of the game, I will probably call an "game_onInit()" script-side function. If an entity (say Alien) needs an init method then that too will also be called when created in the game "Alien_onInit()".
As for actually driving the game, I have a game_onUpdate() method and perhaps a level_onUpdate() method (plus the associated terminators / destructor *_onDestroy() ).
What I do is check if the funciton exists in the script, if so - call it, if not, just carry on with the default game behaviour. This may not be the best way to do things, but it works ok for me [smile]
Just asking here. I'm am mostly brainstorming since I have little experience in creating script engines.
But what kind of events would you have in a game engine?
I belive these:
System messages, like exit, focus, start, ...
Input (from direct input I guess)
- Keyboard
- Mouse
- Joystick
Game Messages, like triggers in map, or happenings in game
Game System, like .... my head stopped
Game Network, multiplayer messages ....
Game Scripts, Scripts should be allowed to trigger other scripts
But what would you NOT classify as events, or something that should NOT trigger scripts?
But what kind of events would you have in a game engine?
I belive these:
System messages, like exit, focus, start, ...
Input (from direct input I guess)
- Keyboard
- Mouse
- Joystick
Game Messages, like triggers in map, or happenings in game
Game System, like .... my head stopped
Game Network, multiplayer messages ....
Game Scripts, Scripts should be allowed to trigger other scripts
But what would you NOT classify as events, or something that should NOT trigger scripts?
It depends on how heavily your game is scripted and how 'fine' you want your control to be over the game. Generally, your game will probably not need Game_onFocus() because you'd handle that in code and not script (you could, if you wanted though).
Bear in mind tht scripting is often a lot slower than actual code, so the more time you spend in script, the slower your game will become. I would write the majority of the game in code and then pass out certain events to the scripting engine. So all joystick/keyboard, etc events would not be sent to the script (unless, of course, you need them to be).
As for event types, in Manta-X my engine itself is based on a series of messages between systems. The events here are things such as input messages, network messages, sound messages, etc. As for game messages, these are spcific to the type of game you're creating, but generally you want to know when something has been created, destroyed, killed, picked an item up, collided with, performed an action, etc, etc. I'd personally say that it's these sort of game events you'll be wanting to expose to the scripts and not engine-level events. It is, however, a total matter of choice though; some people may want to hook everything into script - it would ultimately become a tradeoff between flexibility and speed.
Bear in mind tht scripting is often a lot slower than actual code, so the more time you spend in script, the slower your game will become. I would write the majority of the game in code and then pass out certain events to the scripting engine. So all joystick/keyboard, etc events would not be sent to the script (unless, of course, you need them to be).
As for event types, in Manta-X my engine itself is based on a series of messages between systems. The events here are things such as input messages, network messages, sound messages, etc. As for game messages, these are spcific to the type of game you're creating, but generally you want to know when something has been created, destroyed, killed, picked an item up, collided with, performed an action, etc, etc. I'd personally say that it's these sort of game events you'll be wanting to expose to the scripts and not engine-level events. It is, however, a total matter of choice though; some people may want to hook everything into script - it would ultimately become a tradeoff between flexibility and speed.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
