0

I am creating a UML state diagram to help me plan the card game simulator I'm working on. At the moment I'm stuck on an issue where actions that can be performed from the "Main" state, the state where the game is simply waiting on the player to choose the next move, or as a result of the effect of a card.

For example: From the main state, the play can:

  • Play a card
  • Activate the effect of a card already in play
  • Attack with a card
  • Pass

Now, any of those actions may trigger one or more effects. If that's the case, the game will enter the "Activation Selection" state. In this state, the player can choose which effects to activate. However, these effects may cause the some of the above actions to be executed which may take the game into other states, but the exact action varies by card.

For example:

  1. Main state - A player activates a card on the field
  2. The activated card's effect is that the player may play a card from the hand
  3. Activation Selection state - The player chooses to activate the field card's effect
  4. The player selects a card to play
  5. When the new card enters play, it may attack immediately
  6. Activation Selection state - The player chooses to attack or not

Now, this is only a hypothetical situation, and I'm looking for a way to generalise this sort of interaction.

How can I represent this in my state diagram?

It's entirely possible that a UML state diagram is not the right tool for what I'm trying to do here, so if that's the case, what would be the correct type of diagram to use to plan out my game?

5
  • 1
    Who is the audience for the diagram? UML isn't a planning tool, it's a tool to communicate with people. As far as planning is concerned (being about trying to understand the size, scope and risk around a problem), I would focus just on capturing whatever task(s) you think need doing (a 'to-do list' or backlog) then try to look for the main risks/unknowns, also consider writing code (prototyping) as part of planning get a better understanding of the problems/size/risk/etc. Writing some testable code is often one of the best planning tools as it helps you test your assumptions/ideas. Feb 7, 2023 at 7:42
  • You may find State Diagrams or Nested State Diagrams (e.g. car transmission) helpful. But Ben's technique of learning about risk through rapid prototyping will likely produce the highest quality planning information.
    – J_H
    Feb 7, 2023 at 16:33
  • @BenCottrell This is for myself to plan ahead. My usual method of just starting to write isn't working for this project as I'm getting stuck in all of the possibilities and required actions, interactions and events. I'm effectively trying to diagram out the way the program will work and then use that to write the actual code. Given that there will be various states and actions in those states, a state diagram seemed appropriate. Feb 8, 2023 at 4:02
  • 1
    @BenJaguarMarshall It sounds to me that the root issue is being stuck trying to guess a lot of unknowable detail of an unmanageably large problem which just needs breaking down into much smaller pieces, so I doubt a diagram will help. Consider focusing just on an initial bare-minimum program which will do just enough to satisfy just one of the use cases you've listed (E.g. "play a card"), put tests in place covering expected behaviour for that use case, then keep iteratively adding individual use-cases along with tests for each, evolving/refactoring the code toward each piece of the problem. Feb 8, 2023 at 8:04
  • I think this is exactly the problem where a state machine can help. Maybe you need a statemachine for the game and for each of the cards. You should clearly distinguish which event triggers the transition, what optional guards must be true in order for the transition to fire, and what the effect of this is. Just moving to another state or starting a behavior or both. If you would share a diagram, I could comment on it. Feb 14, 2023 at 18:02

1 Answer 1

0

If the activation goes back to the main state it should be a self transition. The label might specify that it is an optional action triggered by the user.

Then the next outgoing action should go through a fork (was the field card's effect activated or not?).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.