Hey everyone, I've reached a couple of design issues. Question #1: In game engines, does anyone use message and event systems? How do you use them? Does it integrate well with a scripting system? Are there certain advantages/disadvantages to this kind of approach in game development? How easy is it and would it be advantageous to implement such systems in a nearly complete game engine? Question #2: How do you run games based as heavily as possible on scripting? Do you have a main function, then run different aspects of the game (perhaps in multiple threads) from there? (please do not criticize me on whether I should lay off most of the logic on the script side, although if it is ever so horrible, I would appreciate if you'd tell me, and preferably why) Question #3: How big of a role does memory management play in a game engine? Is my engine doomed if I never even thought of implementing one? I mean, I do free memory as I go from unneccessary entities and such, but I didn't dedicate an entire system for it, I just destroy objects when say they die. Question #4: I am currently using ODE for the physics part of my engine. It is playing a crucial role in my engine, it is the only thing responsible for my collision detection, dynamics, etc. Should it have such a big impact on my engine/game? I mean, it is so necessary at the moment, its becoming scary, and I don't have any alternate systems for collision detection, because I don't think anyone would really want to use absolutely basic physics after good FPS titles like Half-Life 2, which basically almost live off of physics (no comments/flames please). At least I know I don't want to make a game without heaving some nice, attractive, entertaining physics. Personally, I don't want any "system" I implement in my engine/game to have an absolutely crucial role in my software, considering if something fails the entire system fails, but then again I don't wish to write 3 different alternatives for everything I develop, so yeah, a suggestion on what I should do about parts of the engine that are growing out of control would be greatly appreciated. I think this is all at the moment, I may need to come back here to ask some more questions. Thank you, - Tima P.S. Hope the post isn't too lengthy to ignore

I'm not some expert guru at game development, but I'll try to give good answers to some of these:

1) Message/event systems are in wide use in games. In fact, I think it's a crucial for decoupling systems (otherwise, some function that takes keyboard input will typically have to go in and update game logic, which is bad style IMO). So yes, it IS used a lot, and it IS a good thing.

2) I have yet to look into this stuff, but I would guess that like most other components, the script interface would talk via messages (post messages to make stuff happen, and listen to messages to react to stuff). I would expect it to get more complicated than that if you want to do nontrivial stuff like AI, as that would require your script to have better access to game state. Like I said, I haven't really thought about this much.

3) What you need to remember is that the default OS memory manager is optimized for general purpose applications (as opposed to games specifically). So a lot of mass market game companies will create their own memory managers, which are optimized for games.

But your project isn't doomed if you don't do this. To be honest, this can get very hairy. I'd say, unless your game needs huge amounts of data to run, you can probably allocate everything you need between levels, so that you don't end up doing any memory allocation/deallocation during actual gameplay, which needs to be smooth and fast.

4) I haven't used any third party physics tool before (haven't really needed to think about it for the simple stuff I've written), but for a more complicated game, physics will be pretty important. If collision detection is implemented for you with what you're using, then I don't see why that's a problem. Unless this physics library is like swatting a fly with a sledgehammer (i.e. super powerful but really huge or something), I wouldn't worry TOO much about it.

On the other hand, if you only need to do something very simple, you can probably get away without it, but it sounds like you're doing something a little more ambitious.

Quote:
Question #1:
In game engines, does anyone use message and event systems? How do you use them? Does it integrate well with a scripting system? Are there certain advantages/disadvantages to this kind of approach in game development? How easy is it and would it be advantageous to implement such systems in a nearly complete game engine?

Question #2:
How do you run games based as heavily as possible on scripting? Do you have a main function, then run different aspects of the game (perhaps in multiple threads) from there? (please do not criticize me on whether I should lay off most of the logic on the script side, although if it is ever so horrible, I would appreciate if you'd tell me, and preferably why)

Handling messages/events are probably the best use of scripts in games imo. You have to remember that scripting languages ( be it lua, gamemonkey, angelscript, unrealscript, etc ) run much slower than native code, so the more heavily you rely on them, the less performance you can expect from your game. In other words, favor things like this ( in a hypothetical AI script ):

OnSeePlayer(player){   if( IsEnemy(player) )   {      SetEnemy(player);      SetTactic(TAC_Evasive);      SetFireMode(FM_ShootLikeCrazy);   }}

over something like this:

PerFrameUpdate(deltaTime){   foundEnemy = false;   newEnemy = None;   foreach player in PlayerList   {      if( IsEnemy(player) && Trace(Position,player.Position) == TRC_Clear )      {         foundEnemy = true;         newEnemy = player;         break;      }   }   if( foundEnemy )   {      // insert complex logic here   }}

Scripting languages aren't really suited to this sort of thing being run every frame for every entity in the game. You REALLY shouldn't be thinking "how can I make everything be heavily scripted", you should be thinking "how can I make my scripts as concise as possible, and preferably call them as infrequently as possible".
When you start using a scripting language as a programming language ( rather than as a high level event based "script" ), you have to ask yourself why you're not doing it in C++/C#/D/etc.

Quote:
P.S. Hope the post isn't too lengthy to ignore

It's not too lengthy to ignore, it's just too lengthy to try to give a response to all of the questions. ;)
Daniel

Heh there's no post too lengthy to ignore! :-D

Quote:Original post by Mike2343
Who cares if the AI slows you down 2%, it can be modified on the fly if you want.

I always wondered about the actual performance hit you take. Do you have some kind of quantitative data for this (ballpark should be fine)?

The reason I ask is, while the performance hit may be minimal, if your game is rendering at 60Hz, and the performance hit pushes the loop iteration to just a little over 1/60 of a second (causing you to miss every other vsync), your framerate will drop to 30Hz.

Then again, I'd expect the "script tick" would be much longer than a game tick/loop iteration, so you would only really execute it (say) 3-4 times a second, so your avg frame rate would still be high... But then, I think missing a vsync a few times a second would be noticeable in the game (since characters would jump ahead ever so slightly on a regular interval, to make up for a 2 frame deficit instead of just the one).

Quote:But I don't think the guys at Epic would have used UnrealScript so heavily in so many games if it was a speed issue.

If you look at what they're actually doing in script, you'll see they avoid doing a lot of logic per tick, a good portion of it is event driven. Of course this is a general guideline, which I myself have broken quite a bit in practice when it's saved me time, but it's still an important point to keep in mind ( and even Epic suggests this ). In fact, we had to refactor quite a bit of our code and move it over to native code for performance reasons, because we went overboard with writing all our game logic in unrealscript. It CERTAINLY doesn't only give you only a 2% hit in performance, unrealscript generally runs about 20 times slower than native code ( this figure coming from the guys at Epic ). C# is another beast entirely, it's optimized much heavier than your average scripting language.
Daniel

Or write your scripts in C# and have them compiled at level load time :). There was a thread about how to do that quite recently ...

Since no one else has touched on it I'll add my two cents.

Use ODE if you want. A number of commercial game companies do.

I would just think about wrapping the ODE code in your own class structure or something so that, if you need to upgrade to a new release of ODE, you just change your interface wrapper, not all the code that touches physics.

- S