Jump to content

  • Log In with Google      Sign In   
  • Create Account


Reflecting on implmenting coroutines in a massively state driven game.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 AverageJoeSSU   Members   -  Reputation: 516

Like
0Likes
Like

Posted 06 February 2014 - 12:20 PM

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, 06 February 2014 - 12:26 PM.

------------------------------

redwoodpixel.com


Sponsor:

#2 NoAdmiral   Members   -  Reputation: 503

Like
0Likes
Like

Posted 06 February 2014 - 03:36 PM

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).


Inspiration from my tea:

"Never wish life were easier. Wish that you were better" -Jim Rohn

 

herwrathmustbedragons.tumblr.com


#3 AverageJoeSSU   Members   -  Reputation: 516

Like
0Likes
Like

Posted 06 February 2014 - 04:42 PM

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.


------------------------------

redwoodpixel.com


#4 NoAdmiral   Members   -  Reputation: 503

Like
0Likes
Like

Posted 07 February 2014 - 01:30 AM

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.


Inspiration from my tea:

"Never wish life were easier. Wish that you were better" -Jim Rohn

 

herwrathmustbedragons.tumblr.com


#5 Sandman   Moderators   -  Reputation: 2079

Like
0Likes
Like

Posted 07 February 2014 - 08:29 AM

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).



#6 AverageJoeSSU   Members   -  Reputation: 516

Like
0Likes
Like

Posted 07 February 2014 - 05:25 PM

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

------------------------------

redwoodpixel.com





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS