Hiya During my nightly evaluation of my progress and writting down my ideas, I realized something that changed the entire way im going to make my game engine, this idea has been done with the Unreal engine but I never realized why exactly until last night. The unreal tournament engine is basically a 3d engine with a fiew generic game entity classes such as actor, weapon, terrain etc. The bulk of the game code is written in script, which means that to make a new game with the engine, you simple make a new collection of scripts (packages). With that said, my general design plan looks like this: engine.exe - windows code, input,sound,math lib, renderer (I may put the renderer in a dll), scene graph, entity classes, physics, script engine (lua), UI system (menus, hud etc), etc. The entity system, UI system, parts of the renderer and physics engine, math etc will be interfaced with lua. As far as scripting, I think Ill do something like this: CSomeGun = CWeapon:New() //CWeapon is found in the engine CSomeGun.filename = "data/models/weapons/somegun.ms3d"; ... then when you want to add a new instance of the CSomeGun class, obj1 = CSomeGun; obj1.SetPos(...); //automaticly set when the designer places it in the world. etc. Im not sure if you can do things like that in lua, although I dont see why not. Im still a bit unsure about how to handle the scene graph, I think that the objects when loaded into the engine, ill have them all added to the scene list. (Im already using a linked list tree for objects now, so the addtoscene function will simply be recrusive and add the children as well. Alrighty, well any comments, thoughts or ideas, feel free to share! ~Jason Edit: I would imagine that this is what is known as a data driven design, right? [edited by - no one on January 24, 2004 3:30:11 PM]

That was a design that I had worked with before. I had it working with Lua, and then changed to SpiderMonkey (Mozilla &#106avascript engine) for *somewhat* better OOP support.

The biggest issue is speed. Running EVERYTHING in scripts is a lot of extra overhead. Here''s a couple tips that might help:

1) Aim for a scripting language that supports some simple form of bytecode script compilation. Lua and SpiderMonkey kind of have this, it speeds the scripts up a little

2) Put as MANY functions you can into the engine to call from your scripts. I wouldn''t define too many functions in the scripts. I would make a massive library of useful functions in the engine, and just use the scripts for the logic and event handling for the games.

3) If you would like to finish off the engine exe and hardly go back to it ever, (do most work in scripts), perhaps write a DLL plugin system for your engine that could define new methods and register them with your scripting engine. That should keep your scripting libraries (DLL) and scripts separate from your engine framework

Hope that helps you out,

~Graham

----
while (your_engine >= my_engine)
my_engine++;

Awsome gwihlidal. Do you have any screen shots of your engine?
I will probably do what you said and write a ''massive lib of
functions'' in the engine or dll, whatever, and call them from
the script.

The game will be a 3D rpg which a few of my friends will be making data for. We want to have a ton of charactors, weapons,
powerups, etc so this method seems to be the best for our purposes.

Anyway, what about game monkey, angel script, xml, ... can any of those output bit code? Are they faster then lua? hmm. This could be a topic for a new post

Thanks again!

There was a game called Vampire:masqaurade that came out in 99 I believe that had a similar architecture.

Thay made dlls with all their core code. Then used JNI and &#106avascript to actually make the game. Therefor, all their menus and game logic was done in &#106avascript and called upon the C++ code for the core items. The game was pretty good, so your basic idea is not flawed. I think Gamasutra had an article on it.

Be warned that most scripting languages, notably Lua, don''t integrate especially well with any serious OO programming designs...