AIPlayer Animations
by John Klima · in Torque Game Engine · 06/20/2005 (10:06 am) · 5 replies
Continuing to work with the AIPlayer, i have six bots. i reworked the "stuck" code so it actually fires an onMoveStuck callback, as well as an onMoveUnStuck callback. however quite often the walking animation that plays seems to just "shuffle" along. it usually occurs as the bot is trying to find it's way around an obstacle, but quite often the shuffle occurs for no apparent reason, when there is nothing in it's way.
aesthetically, i'd rather the bot just run in place when in this state, but i can't seem to find where in code that walking animation is triggered and/or rewound, to produce that shuffle outcome.
any idears?
j
aesthetically, i'd rather the bot just run in place when in this state, but i can't seem to find where in code that walking animation is triggered and/or rewound, to produce that shuffle outcome.
any idears?
j
#2
indeed, that is why the animation "shuffles," as it should, but the real problem was in the server packet rates and size. increasing the rates and sizes in my prefs for my game fixed the problem. it also fixed another problem with multiple bots jerking and pausing.
06/20/2005 (3:14 pm)
Thanks,indeed, that is why the animation "shuffles," as it should, but the real problem was in the server packet rates and size. increasing the rates and sizes in my prefs for my game fixed the problem. it also fixed another problem with multiple bots jerking and pausing.
#3
06/21/2005 (10:53 am)
So now it sounds like we need to figure out why the bots are causing such a network load. This probelm is of some concern to me as well... my game will eventually (God willing) have quite a few enemies coming at the player at any given time... should we ever get that far.
#4
In the RTS Starter Kit, we made a super lightweight RTS Unit class based on the player. This allowed us to handle hundreds of units at once...
I suggest trimming unnecessary features out. :)
06/21/2005 (11:08 am)
Because they can do a LOT of stuff, which concordantly requires a fair chunk of network bandwidth.In the RTS Starter Kit, we made a super lightweight RTS Unit class based on the player. This allowed us to handle hundreds of units at once...
I suggest trimming unnecessary features out. :)
#5
http://www.garagegames.com/docs/tge/engine/classAIPlayer.php#r0
Now that would be a handy little tool: Some kind of "where'd the bandwidth go" monitor... %x of the last second's traffic were from THIS, %y from THAT, and so on.
Is there such a beast already? Or how feasible is it to build one? Going by the pack/unpack system, it doesn't look like each type knows its own size in the stream... so "type" markers are whatever byte[s] happens to be next?
So some data collection would have to be built into all the pack/unpack calls... which reminds me of an overhaul I was thinking about: Develop a "transmittable data" interface, with all the various transmitted basic types as subclasses... then you can build a container of transmittables, and your pack/unpack become little more than a couple std::for_each(begin, end)/for_each(reverse_begin, reverse_end).
In fact... the classes wouldn't need their own pack/unpack, they'd just need to add the appropriate ITransmittables to the base class's collection in their constructor.
I'm liking this idea more and more (not that I have any code for it yet). The interface itself would probably only require 2 public functions (read & write)... and even those would be pretty simple. It might even be template-able (though tagged strings may be An Issue, haven't really looked at their underlying C++).
06/21/2005 (1:23 pm)
How many of these private member vars are being transmitted?http://www.garagegames.com/docs/tge/engine/classAIPlayer.php#r0
Now that would be a handy little tool: Some kind of "where'd the bandwidth go" monitor... %x of the last second's traffic were from THIS, %y from THAT, and so on.
Is there such a beast already? Or how feasible is it to build one? Going by the pack/unpack system, it doesn't look like each type knows its own size in the stream... so "type" markers are whatever byte[s] happens to be next?
So some data collection would have to be built into all the pack/unpack calls... which reminds me of an overhaul I was thinking about: Develop a "transmittable data" interface, with all the various transmitted basic types as subclasses... then you can build a container of transmittables, and your pack/unpack become little more than a couple std::for_each(begin, end)/for_each(reverse_begin, reverse_end).
In fact... the classes wouldn't need their own pack/unpack, they'd just need to add the appropriate ITransmittables to the base class's collection in their constructor.
I'm liking this idea more and more (not that I have any code for it yet). The interface itself would probably only require 2 public functions (read & write)... and even those would be pretty simple. It might even be template-able (though tagged strings may be An Issue, haven't really looked at their underlying C++).
Torque Owner Mark Storer
Try running your code on perfectly flat terrain. If I'm right, the problem will go away.
If I'm wrong, you'll have one less area to look through.