I’m not sure I’m going about this the right way, so I thought I would pose the question and maybe you guys could help me out.
I’m trying to develop a framework for turn-based role-playing type games to run on top of jME. I decided to go extend the AbstractGame with my own class which implements Runnable so I can use it as a threaded process. The logic portion of my framework I am putting into its own Runnable implementation so that the two can run concurrently, but neither waits on the other. I wanted to do this for a couple of reasons:
- The ambient animations should continue while waiting for user input during the player's turn.
- The programmer shouldn't have to worry terribly about how many cycles the artificial intelligence is taking up. Well okay, they should, but I don't want it to affect the animations if they aren't careful enough.
[/list:u]
I realize the first item, which I initially thought would be a problem, can be easily taken care of using stuff that already exists, but I think that a thread solution to it is a little more elegant ... or at least easier for me to grasp.
So is there a much easer way to go about doing this, or am I on the right track? Has anyone else pondered this and come up with a reason why threads aren't a good idea?
Using threads is fine. Just my opinion, but I think it fits well with what you’re wanting to do. Be warned though: jME is not thread safe. This means all rendering and changing of jME’s values must be done in one thread.
It should be safe to run jME and when needed run an AI “thinking” (but not doing) thread. The jME thread could poll the “thinking” thread during update to ask if it’s done and if it is take whatever information it has created and use it. Just be sure your AI thread doesn’t use any jME classes.
To be honest, I dont see how the animations are NOT tied with the AI.
In my AI implementation, they are tied in order to control the animation. E.g. the AISystem says to the character to run, so it sets the animation to run and walks forward…
I think he’s talking about his AI will take like… 30 seconds to finish thinking. If that thinking is in the same thread as jME, render will not be called for 30 seconds while update thinks. He’ld like to have some “waiting” animation for his characters while the AI thinks. At least that was my interpretation.
He'ld like to have some "waiting" animation for his characters while the AI thinks
Exactly. Perhaps not initially, but I'd like the option to be able to have maybe a heavy breathing animation while the guys are fighting, or a toss the weapon into the air and catch it, or a check the gun for bullets type of thing, or leaves falling from trees, but that the animation would play all while the AI or player was thinking. Something that could be kicked off by an "idle" timer or something.
But definitely in some cases the animations are directly tied to the AI or player having already made a decision (your example of running somewhere).
My issue with waiting for input arose because I was using a simulated sort of tick timer mechanism for my turn-based system. This is kind of complex, and probably didn't have to be, but what I did was set each action to take a certain number of "ticks", and then the "timer" would set that agent's next turn to be after that number of ticks had passed, but it isn't tied directly to time. When the "timer" reaches a player (rather than AI), it waits for input. I know this could be put into the game loop, but I thought it was much easier to deal with in its own separate loop running in its own separate thread.
Anyway, I'm still throwing the idea around, though I still think the multi-threaded approach is sounding best to me. I really do want criticisms or alternatives though.
I think he's talking about his AI will take like... 30 seconds to finish thinking. If that thinking is in the same thread as jME, render will not be called for 30 seconds while update thinks. He'ld like to have some "waiting" animation for his characters while the AI thinks. At least that was my interpretation
Couldn't agree more. ( Pathfinding is one potential, when incorporating obsticles, and other critical decision making pathfinding issues, like if your NPS can swim, or can it jump, just a few to mention).
While the first thing that i have learned when doing games is that you stick with your main loop, i think when it comes to AI, this might change a little bit, as long as both threads are irrelated like Cep said.
Imagine this:
You have a movmenet system , that is reposible of updating the NPC's in the game, and world that renders entities, at any given time the world could query the position of some NPC, or just ask the movSystem to find the sutable path for NPC. Of course your movSystem will run in another thread.
Just what i am currently thinking.
Here is something you might find usefull. ( See micro-threads )
ive seen that article before about micro-threads. But micro-threads are near impossible to do as it requires some assembly programming. And Java doesn’t have an assembly interface unless you go through JNI to C then to Assembly…
If it takes 30 seconds to think the AI, then fair enough. But make sure the animation setters are synchronised so that if you do set an animation from the jME thread and another one from the AI thread, they dont interrupt each other.
If it takes 30 seconds to think the AI, then fair enough. But make sure the animation setters are synchronised so that if you do set an animation from the jME thread and another one from the AI thread, they dont interrupt each other.
My plan is to pass messages from the AI thread to the rendering thread, so that only one thread was responsible for handling anything to do with rendering.
I've coded most of it already, I'll let you know how it goes when I get something working.
Thanks for the suggestions/encouragement/warnings.