[ape_key]

You absolutely should learn about state machines.

Also event-driven programming. (especially the idea of delaying effects, e.g. so in an RPG someone can perform a Reaction which disables the effects of an Action performed by another character before they’re applied).

Learn about stacks.

When you’re ready to make your brain bleed a little, try designing on paper the data structure to make D&D turns work.

Hints: player initiative is a circular array, reactions are a stack, actions/reactions are events. Actions are events which modify characters, reactions are events which modify other players events.

Ignore abilities which e.g. create new terrain or whatever. Ignore movement, positioning, targetting entirely.

This will be fun!

Also I can recommend the free book Game Programming Patterns. It’s useful for programming concepts even if you don’t make games

[wonger_]

I agree: take the time to learn about state machines.

I remember the first time hearing about them and being totally confused by the wikipedia page. I think the first article that made sense to me was this one, because it used a webapp example: https://www.infoq.com/articles/robust-user-interfaces-with-s...

And then developing a few sample applications, especially with Elm or another language with custom types, really completed my understanding. The diagrams and math notation are more intimidating than the actual code.

[ape_key]

Nah, diagrammatic reasoning is part of it. Separate yourself from syntax.

Doodling on paper (or just mentally envisioning a data structure) is way more fun than writing actual code.

I certainly would dissuade the OP from trying Elm. Not as part of learning state machines at least. Too many things at once and not necessary.

[solardev]

Thanks for sharing that link! I've tried reading about them in the past and always walked away more confused, but this article seems more readable. I'll give it a thorough read this weekend. Thank you!