New Release: TrueState 2.3 and TrueState Plus Beta


Hey Gamemakers!

The new, 2.3 version of TrueState is now available for download.  The changes are pretty minimal.  I wrapped all of the functions into a single script resource, so now you just need to bring in resource to have your project ready to use TrueState.  I also added an additional helper function, primarily for debugging: truestate_draw_history.  This function allows you to draw the history of states to the screen much like the example project already did... but now it's available for everyone with a simple function call.   A few minor bugs were also fixed.

Do note that due to some issues in GMS2.3 truestate AS IS will not work with HTML5, though the issue is known and will likely be fixed in GMS 2.3.1. 


But the big news here is the beta version of TrueState Plus!  

So what is TrueState Plus?  

TS+ is a free "expansion" of TrueState that allows more advanced users the ability to have multiple finite state machines running parallel on the same object.

Why on Earth would anyone want that?

Well, the most obvious example is AI.  You have one state machine that controls the decision making and logical states of an AI, and a second state that controls the behavior of the character and its interaction with the controls and the world. 

But with added power comes added complexity.  And this complexity is the reason I've released this as a "beta".  I'd love for you to examine the example project, try out the new system, and see what you think about the implementation.  Is it overly confusing?  Is it overly complicated?  Do you have some ideas for how it could be improved?  

Obviously there is no new documentation or tutorial videos or anything for this yet, as I wanted to get some feedback beforehand in case I needed to make some major changes before official release.  But here's the basic setup.

Create Event
Call truestate_system_init() as normal.  Afterwards you need to define your "layers" using truestate_create_layer().  Layers are what I call the different true state machines that run in parallel.  In the example project I define two: ts_behavior and ts_ai.

You then need to define your states PER LAYER.  Many of the functions and variables that used to be prefixed with "truestate_" are now just your layer.function().  state_create() is one of these.  So instead of saying "truestate_creat()" and defining your state that way, you have to define it in the context of a layer.  ts_behavior.state_create();  Take a look at the "truestate_create_layer" function to see the struct that is built for each layer and the containing variables.

Cleanup & Begin Step Events
These remain the same, just call the appropriate truestate function for the event.

Step & Draw Events
It is no longer enough to call truestate_step() or truestate_draw()  Now you must pass the layers as arguments.  If you look at the character in the example project you'll see in the step event I call them separately.  If the AI has control, I call truestate_step(ts_ai).  And regardless I call truestate_step(ts_behavior).

In the draw event you can see another use for these scripts.  I call truestate_draw(ts_behavior,ts_ai).  Both truestate_draw and truestate_step accept any number of layer arguments.  The layers will be executed in the order they are passed, so you can prioritize layers in this way if needed.

Working with State Scripts
State scripts are still very similar to what you had before.  An Event argument comes in, we have a switch statement, and you have cases like TRUESTATE_NEW and TRUESTATE_DRAW.  Nothing about that has changed, but a second argument has been brought in: Layer.  Layer isn't 100% necessary, to be honest.  If you know you are in a state defined in ts_ai, then you can just use ts_ai in place of the layer argument.  But it's a shortcut so you always know which layer you are working with.  This gives you access to all the built in variables and functions which that layer owns.  Your "state_switch" function now lives under this layer argument.  So if you wanna change states: _layer.state_switch() is what you want.

Variables also live under the layer.  _layer.vars is the old truestate_vars[?] ds_map,  _layer.current_state holds the ID (macro, enum, string) you used to define the current state,  _layer.timer is your state timer, etc.

You can even access state information from one layer in another.  Notice in the AI states, I detect when the character is in a "wall slide" state.  I can use that information to perform a wall jump when that state is detected.

Conclusion to big boring blog post
Obviously, this is a big change, but can unlock a LOT of power and potential for those who need it.  I still think the original TrueState system has a place for it's power and accessibility to newer developers, but I'll be interested to see the response to TrueState Plus to gauge whether it's worth to continue maintaining a more complex system like this, or if I should just expect developers to build their own version of TrueState Plus that more accurately fits their needs.

Any and all feedback is welcome through Comments Below, Twitter, Discord, or the GM Forums.

Thanks for reading.  Now go make something awesome!

Files

TrueState Plus Beta Project Source 607 kB
Sep 21, 2020
TrueState 2.3 Project Source 761 kB
Sep 21, 2020

Get TrueState - Finite State Machine for GMS2

Download NowName your own price

Comments

Log in with itch.io to leave a comment.

I didn't look into Truestate Plus yet, but reading your post I guess I can use it for my camera state ?

Like :

  • Behaviour layer. Where I put stuff like zoom, views type, follow, based on player's actions
  • Effect layer. Where a can trigger shaking, shaders and other fun stuff based on player's reaction to danger or player's condition (is poisonned, low life, full power mode, etc)

Am I right ?

I suppose it could be used like that.  Basically any time you can have two states at the same time, you can use those for layers.
Another example would be for Samus from Metroid.  Samus can stand run and jump, but all the while her gun can be aiming in multiple directions and be in multiple modes like missile or gun mode..  Now those things could just be an instance variable, but then it would need to be managed in every single state.  With layers you can just handler her gun in its own state machine while her running and jumping is handled in the other.

Precisely what I though.

I got another question :
- If I want to use the Draw Gui event, is it safe to add a TRUESTATE_DRAWGUI macro and a truestate_drawgui function in the system or is it better to put the truestate_draw function in the Draw Gui event ?

You can easily extend the system to support any events you need!

Hehe. Just to be sure :D
Thanks.

So I'd like to look at TrueState+ but I bought the 2.0 version on the YoYoMarketplace and the new version is not available there.  Any way for me to get it? My yoyogames user name is the same as on itch.io.

Sure.  I'll DM you a key for the itch version

Today I learned itch does not have a private message system.  Hit me up on Discord or Twitter and I'll get you a download key!

I'll try to check it out soon. I've been using a modified version of TrueState and really like it. I was curious if your next update would try to get rid of the enums in TrueState because of the recent changes and I was wondering how you might use some of the new features. Looks like the new changes didn't compel you to redo anything but I'm curious about TrueState Plus. I can see how you can't initialize multiple state machines on the same object with the old way of doing it so I'm intrigued...