Controlling many objects/enemies/NPCs
Author
Hi all.
I am currently working on a real-time game, where lots of agents (enemies, NPCs etc.) will be strolling around, each class having their own control code, of course. It's actually a multiplayer game, but could also be a single player one.
What is the common way to let a lot of objects run their own code? Creating a thread for each object is not feasible. So what do you do? A constantly repeating external loop that calls update functions for each object (maybe along with the current time so they can react on the time that has passed)?
Comments?
Regards,
tin
Quote:Original post by tincup
What is the common way to let a lot of objects run their own code? Creating a thread for each object is not feasible. So what do you do? A constantly repeating external loop that calls update functions for each object (maybe along with the current time so they can react on the time that has passed)?
That's how it's usually done, yes.
If you're dealing with a lot of objects, all with complex logic, you could perform logic culling, updating objects that are farther away from the player(s) less frequently, or calling a cheaper version of their update function. I'd run some stress tests before actually doing this, though - you'll want to make sure you're solving an actual problem rather than a perceived one. ;)
Author
Hi. Thanks for the answer.
Yes that complex logic came into my mind. An alternative to the cheap update would be something like a "major update" every, let's say, 2 seconds for direction changing, thinking etc. And then a "minor update" function just for moving etc.
I think the disadvantage of this approach is moving basic server mechanisms into the code of the game agents.
Any advice on how to perform the repetition? Use system timers?
Tin
[Edited by - tincup on February 14, 2010 9:49:30 AM]
Yes that complex logic came into my mind. An alternative to the cheap update would be something like a "major update" every, let's say, 2 seconds for direction changing, thinking etc. And then a "minor update" function just for moving etc.
I think the disadvantage of this approach is moving basic server mechanisms into the code of the game agents.
Any advice on how to perform the repetition? Use system timers?
Tin
[Edited by - tincup on February 14, 2010 9:49:30 AM]
Any advice on how to perform the repetition? Use system timers?
Have a bit in your render loop that calls timeGetTime() and updates the game if it should. That way you can be sure the game state won't change halfway through a render.
Have a bit in your render loop that calls timeGetTime() and updates the game if it should. That way you can be sure the game state won't change halfway through a render.
Author
Hi.
With rendering you are referring to the graphical displaying of the game state, right? I am currently only dealing with the central game loop on the server side.
Tin
With rendering you are referring to the graphical displaying of the game state, right? I am currently only dealing with the central game loop on the server side.
Tin
Updating "major" decisions less frequently is not that uncommon. It is also possible to break a decision making into pieces where just one piece is handled per frame, so that the decision finding again durates several frames. It all attempts to not run the entire process for each frame.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
