0
\$\begingroup\$

While trying to figure out how to implement platform agnostic input handling for a platformer, I've discovered the command pattern and I liked the idea so I wanted to take it a step further.

I got the idea of having a Command Queue System (I'm using ECS in my gameplay screen/state) which would expose a simple api for enqueueing commands which other systems could invoke and then the command system would execute those commands within a logic loop derived from Fix your timestep blog post.

While processing and implementing this idea, however, I've encountered a couple of issues where I'm not sure on how to proceed:

  1. Input processing is currently done with an abstraction over LibGDX's InputProcessor so input processing is event-driven and thus commands are queued as fast as events are emitted. This in turn causes the queue to fill up the command queue with more and more commands(40-50+) waiting for execution which, along with filling up memory, causes longer and longer delays. I've tried to mitigate this by removing oldest commands from the queue while the queue size is > 10 but that made gameplay really choppy since command removal was on the same thread and is blocking everything else until it's done(at least that's what I'm assuming is going on).
  2. Is a complement to issue 1. wherein if I use a single queue for all commands including all AI NPC's, enemies and the player, I only see massive delays while the systems processes all inbound commands. I could spin up new threads for every entity but then I'm not sure how could I get them to execute within the fixed timestep logic loop, and I'm not particularly fond of having dozens of threads for every single entity.

I really like the idea of having movement and interaction of characters represented as commands but I can't figure out how to implement this without greatly losing precision and performance. Can anyone steer me in the right direction?

| improve this question | |
\$\endgroup\$
  • \$\begingroup\$ I think that the real problem is maybe not your queue idea but the frightening amount of time you seem to spend processing individual commands every frame, then secondly how many commands you're generating per frame. Unless you're building games for a LCD watch built in 1970 you really don't need too worry about 50+ or even 5000+ commands filling memory. Have you run a profiler on a release build to find the hotspots yet? \$\endgroup\$ – Patrick Hughes May 22 '16 at 18:26
  • \$\begingroup\$ @PatrickHughes No, I haven't profiled the game, I'll try though. And my commands aren't really all that big. Most of them fetch the physics component of the passed in entity id and tell the physics system to apply forces to the entity body. These are usually really really fast actions and I've had no performance issues with them when I handled input directly without commands. Also commands are cached so gc shouldn't be doing much of anything. \$\endgroup\$ – MrPlow May 22 '16 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.