I have groups of controls to be executed serially, which are generated asynchronously by the data model of the game, and stored in a queue queried by the simpleUpdate function at every cycle. These controls carry out just one simple task - e.g. moving a spatial from A to B - and then get detached. I want the controls to be attached (or, more broadly, to affect the spatials) only if no controls belonging to the previous group are still attached to spatials. Controls belonging to the same group should instead be executed simultaneously.
I’m trying to find a way to wait for the controls of the current group to be done with their tasks before advancing to process those of a new group (which could be already waiting in the queue). My current solution involves numbering the groups and keeping track of the group being currently processed, and the use of a counter which is initially set to the group’s cardinality and decremented any time a control is detached from its spatial.
Is this a good way to get the job done? Is there any better / more efficient / more jmonkey-ish manner to design this code?
Thank you for your attention (and happy new year).
Make your controls notify something when they are done… then you don’t have to poll for state.
Well, that’s a much larger subject since this is all game logic stuff and so shouldn’t technically be part of a control in the first place.
The problems with embedding this game logic in a control are numerous and will extend beyond even your current issues. For example, what if something is in the way? What if you want to interrupt the walking because the mob was hit by a missile? Moving along way points or whatever is something better handled by (at least a minimal) AI. Even if it’s only a task queue or a behavior tree or something. Then every game tick, in addition to moving the current task along and moving to the next task if finished… you could also examine the conditions that might make the task irrelevant.
Actually I didn’t tell the whole story for the sake of brevity; the queue is a list of cached logic updates the representation should render visually (basically a list of lists), so the controls are the result of the view processing the lists and not the content of the lists itself. Is this the sort of task queue
It’s a turn based board game, so I don’t have mobs or missiles (et similia): a very limited set of things could happen to a spatial during a turn, all of which I can encapsulate in a control for rendering (they’re only three: spatial moved, spatial created, spatial destroyed). So once started, a task is of constant relevance until completely carried out.
Do these new info change something? Sorry if my question sounds silly but I’m still learning the basics and I just want to know if I’m walking the right path.
Personally, I still wouldn’t use controls for this. But JME’s cinematic animation system is based on controls I believe. It sounds like you could either use it directly or look at it for ideas.
…it does let you listen for events, though. Which is effectively my first answer.
Though given your description I’m not sure why you couldn’t just queue up all of the steps as a cinematic in the first place.
