Sign in to follow this  
Vast

General game engine questions

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
@FBMachine: Huh? As far as I know a lot of games are using LUA/Python/etc to handle all the AI and game logic for their games. Our engine has hooks for Python in it but we'll likely be using C# as our scripting language for PC development. The slight speed hit you take using scripting languages is more then made up for in the speed of development. The fact most designers that don't know C++ can pick up Python or the likes in a matter of days reduces the need for coders to work on things like UI/AI and frees them to do more important things for the game.

Who cares if the AI slows you down 2%, it can be modified on the fly if you want. No lengthy recompile to test needed, just to change a few things. To me this is well worth it. Heck you mention using C#, some might argue it slows you down speed wise (I'm not a big believer in that myself).

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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Epic themselves recommend not putting code in the think/tick/update functions as much as possible, for the reasons mentioned above. Script your ass off in event functions, with the assumption that the events dont fire every frame. If you don't then you will see your scripting system using significant cpu time.

Share this post


Link to post
Share on other sites
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 ...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Hmm it seems the post has turned into a bit of an argument regarding scripting, but nontheless, thank you for your help guys. I was hoping the most for an answer to my event/message system question, and now that I know that it is widely used I will look really deep into it. Althought.. I was actually hoping to see a discussion about that system far more than that about scripting :)

Also, the thing is, I have dropped nearly all of my game logic into scripts, such as camera (entirely), AI (which I just started, but still) and the rest, all from the script, without a message system. I just have my global "input" class, and my say.. player class, goes into input, checks if input.getStateKey('w') equals to 1 (its pressed), and then moves the player in the direction of the direction vector, so I mean my input doesn't send anything anywhere, but my outside classes seem to dig into it all the time. Thats pretty much my current system for everything, and I can't imagine how something could work in a different fassion.

Considering I rely on scripting so much, most of the memory management is done from there too, such as having a reference counter and everything free memory when it's not used and.. well the usual. So THAT could be a reason why I never needed a memory manager.

Thanks again for all the suggestions/answers/encouragments (even those I havn't mentioned in this reply). Please keep them coming.

Regards,
Tima

Share this post


Link to post
Share on other sites
Quote:
Original post by Vast
Hmm it seems the post has turned into a bit of an argument regarding scripting, but nontheless, thank you for your help guys. I was hoping the most for an answer to my event/message system question, and now that I know that it is widely used I will look really deep into it. Althought.. I was actually hoping to see a discussion about that system far more than that about scripting :)

Sorry for spinning it off in the wrong direction. :D
Some things you can use events/messages for instead of polling:

Colliding objects - When the collision detection system detects a collision between two (collidable) objects, it sends a message to those objects telling them so:

event Collision( Entity otherEntity )
{
// this entity collided with 'otherEntity'
GiveCooties(otherEntity);
}


You could also have tagged events that are sent to all entities that are listening for that tag. As a simple example, you could have an event called something like 'BossKilled', and trigger this event within the boss AI:


// event called in boss AI when it dies
event OnDeath()
{
TriggerEvent( 'BossKilled' );
}


And you could have the grunt AI listen for this event:


// somewhere in init code
AddEventListener( 'BossKilled' );

event TaggedEvent( string taggedEvent )
{
if( taggedEvent == 'BossKilled' )
{
RunLikeAWuss();
}
}


Or something like that... Hope that gives you some ideas at least. :)
Daniel

Share this post


Link to post
Share on other sites
Quote:
Original post by Vast
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.


If something "fails", you fix it or you scrap it. Realistically, you can only work on one thing at a time, so there is not much benefit in working on redundant systems simultaneously.

One of the reasons that up-front design is important is that it reduces the chances of failure. Figure out ahead of time how everything works and you will end up with fewer suprises when you are implemnting.

Modularity is another important way to reduce the risk of failure. One common mistake is mixing game code with rendering code. If you do that, then even a simple change to the game could require you to rewrite the rendering, and vice-versa.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this