Gameplay State Machines Using Unions ⭐ Great Odin Feature

[@arma5166]

would love to see more of these kind of videos about game dev and odin, showcasing the code and explaining the thought behind it. good stuff!

[@karl_zylinski]

Thanks! More is coming! I'm on vacay until beginning of August, after that I'll make more videos.

[@jimmyporter8941]

That's nice. I think this feature is often called tagged unions in other other languages. I mostly use Swift and it calls them Enumerations with Associated Values. But I find them very unweildy in Swift. For a start as they are immutable values there, so they are useless in many cases.

[@RogerValor]

awesome, youtube recommended me this video just after i asked gingerbill about algebraic datatypes.

[@johnjohn12044]

Fantastic! I'm just getting into Odin, subbed! Looking forward to learning more on this channel, I'm still clueless overall. :)

[@karl_zylinski]

Thank you! I'm getting back from vacay next week and will start tinkering and hopefully making videos again :)

[@ar_xiv]

AHHH it actually makes so much sense. I am making a state machine for an enemy in C# and I keep thinking "should these states be types somehow?" but the thought of setting that up with Delegates or something filled me with dread. I am curious what your set_state function looks like. In what I am making the set state function does a lot of the work that maybe your types are doing, but I have to just have class fields that aren't really used anywhere else

[@karl_zylinski]

Hi. set_state sets the new state and then also switches on the newly set state so that the union variants can do initialization if they need any

[@ar_xiv]

@@karl_zylinski I see. I think I have similar functionality, just with the initialization inside a separate switch statement in my set_state function, along with class fields that aren't explicitly associated with that state, which is a bit messy

[@mrzoProductions]

Very cool feature!

[@vexedev]

Neat! What's your set_state looks like? does the player have a PlayerState field and you can just say p.state = PlayerStateNormal; and it knows how to assign that?

[@karl_zylinski]

Thanks
It's something like
set_state :: proc(p: EntityInst(PlayerCat), state: PlayerState) {
p.state = state
p.state_time = 0
p.state_start_pos = p.pos
}
when you call set_state you do like:
set_state(player, PlayerStateNormal{}). The second argument creates a struct PlayerStateNormal{}, but since it is part of the PlayerState union the parameter state: PlayerState is assignable from that struct.

[@ElGnomistico]

The feature is cool, but it would be cooler if it had a more Rust-like syntax where enum variants can have data associated with them, it reduces a lot of boilerplate.

[@karl_zylinski]

Hi. Isn't that just what the union in Odin does?

[@ElGnomistico]

@@karl_zylinski yes, but I'm talking about how the syntax looks like. In rust you could just do:
enum State {
Walking,
Climbing { surface: Surface, transition: bool}
}
You don't need to create a separate struct to have data inside you enum variants.

[@torginus]

You can kind of have the same thing in C# where you define a PlayerStateBase class, and create derived classes like PlayerStateHang, PlayerStateDashing etc, and then you can use type matching in switch case or if statements to write similar looking code.

[@Eugensson]

C# is getting the discriminated unions in the next release, most likely.