Advertisement Jump to content
Sign in to follow this  
AverageJoeSSU

Unity Reflecting on implmenting coroutines in a massively state driven game.

This topic is 1806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am full steam ahead with a game I am making with a team, and we are approaching the point of no return on one of our subsystems/architectural choices, and my lack of experience with it is frightening me.

 

It is Coroutines. We have implemented our state management using coroutines, and while i feel we have an excellent grasp of exactly how Coroutines in Unity behave, I am not, as you would say in poker, "all in" quite yet.

 

The main thing that bugs me, is that while Coroutines make state switching so so easy, there are a couple of operations that become non trivial (at least i think they are non trivial, maybe I'm wrong). The best way to describe our implementation using Coroutines is that it is a State Stack, with the option of having another state run in parallel. This description is terrible as the very word "State" is misused, but alas i think you get the point.

 

The issue at hand with a State Stack is our ability to plain ole switch to x state from y state where y is not above/below x on the stack.

 

It requires a check in every state between the two in order to make that switch. Now, in a JRPG, this might be fine, as mostly you progress from one state to another, and in a very few cases need to change to something as I previously described.

 

To that end i have provided an interface IState, which has prepare, validate, and clean methods. Every state in the game must prepare values for the state to run, and every frame validate that it is the correct state to be in, and on exit, clean itself up. The saving grace of the above is the Validate() method, for it will allow multi-state traversal across a stack. And if we take care as to how we cleanup a state (for example all Major state transitions: ExploreMode, CombatMode, WorldView Mode, Menus. If all of these modes cleanup with fading out the camera, then theoretically they all can go from one to another with no problem.)

 

Anyways, I certainly do not want to turn this into a rant smile.png. Thanks for reading and any thoughts are welcome!

Edited by AverageJoeSSU

Share this post


Link to post
Share on other sites
Advertisement

Is the stack static? Maybe I'm naive--or confused--but I've always thought of the state-stack as a dynamic (no set order) list of states where only the "top" one is updated. When you're ready to switch states, either pop the top one off (reverting to whatever the previous state was) or adding a new state on top (when you pop that it returns to whatever the current one is) or both.

 

A default state can be run alongside the stack (this lets you do maintenance routines and whatnot that need to be updated independent of the current state).

Share this post


Link to post
Share on other sites

Is the stack static? Maybe I'm naive--or confused--but I've always thought of the state-stack as a dynamic (no set order) list of states where only the "top" one is updated. When you're ready to switch states, either pop the top one off (reverting to whatever the previous state was) or adding a new state on top (when you pop that it returns to whatever the current one is) or both.

 

A default state can be run alongside the stack (this lets you do maintenance routines and whatnot that need to be updated independent of the current state).

 

It is dynamic.... let me give you an example.

 

With a non coroutine API you would expect to be able to do

 

SwitchState(A, data);

SwitchState(B, data);

SwitchState(C, data);

SwitchState(A, data);

 

For a JRPG:

SwitchState(StartMenus, data);

SwitchState(Exploreing, data);

SwitchState(Battle, data);

SwitchState(Exploring, data);

 

Or also:

SwitchState(StartMenus, data);

SwitchState(Exploring, data);

SwitchState(Battle, data);

(you die in combat)

SwitchState(StartMenus, data);

 

with coroutines, since it is a stack, you would have to do the following to get back to start menus.

the following now becomes abstract psudo code:

 

with coroutines:

SwitchState(StartMenus, data);

SwitchState(Exploring, data);

SwitchState(Battle, data);

(you die in combat)

SwitchState(Exploring, data);

SwitchState(StartMenus, data);

 

In my original post i addressed this with a Validate method that is called EVERY frame when a state is run. This would allow the code with coroutines to maybe set a desired location and the couroutines would validate and bail out. I'm not really a fan of this though.

Share this post


Link to post
Share on other sites

I still don't understand really what the difference of "coroutines" are, as you explain them. This is more along the lines of what I'm suggesting (or as is illustrated in Mat Buckland's Programming Game AI by Example).

 

Sorry I don't seem to be of much help.

Share this post


Link to post
Share on other sites

I don't really understand what this has to do with Coroutines either. 

 

The issue seems to be a fundamental issue with using a stack (a graph is a better model for state transitions).

Share this post


Link to post
Share on other sites
I think you guys are right that our implementation is wrong.

Reviewing the code shows states called within other states which we are doing everywhere and shouldn't be.

The main states should be called in a loop and exit when a state changes. A stack of coroutines is a special case not the norm

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!