I'm trying to model the evolution of a player's energy in a game.

  • I have an "alive" state, and a transition to it from the initial pseudostate that has the effect of setting the initial energy to 100:

(initial) ---( / energy = 100 )--> (Alive)

  • The player loses 1 energy point for each step he takes which I modeled with a self-transition:

(Alive) ---( when (step) / energy -= 1 )--> (Alive)

  • If the player doesn't move for 3 minutes, they should lose 2 energy points
  • Every 15 minutes, the player gains 10 energy points.

I'm not sure how I should represent these last two. My initial, naive idea was to use an after (3 min) self-transition, but that would mean that the system actively waits for the time to pass, so it's wrong.

One suggestion I received is that I should have an external "trigger", and make use of internal and external activities.

Edit: I should add, for completeness, that there is an additional transition to the final pseudostate when the player's energy reaches zero.

  • Are you sure you should be modeling this on a state diagram? It seems like the object is still in an Alive state, but that other things are happening. Perhaps a timing or activity diagram is more suited to what you want to model?
    – Thomas Owens
    Nov 14, 2022 at 13:09
  • @ThomasOwens I've been asked to use a state diagram, specifically, although I do recognise that other diagrams may be more appropriate Nov 14, 2022 at 14:56
  • I would ask why you're being asked to use a state diagram - which seems to be an inappropriate diagram type for communicating this information - over other diagram types which are designed to communicate this information. It tends to be seen as a good practice to use the right tool for the job.
    – Thomas Owens
    Nov 14, 2022 at 15:08
  • 1
    Course work is very different than the real world. You'll probably have to work with your professor on this. We don't know what your professor is looking for. I know that it is an inappropriate use of UML state diagrams. Perhaps there's a non-UML solution or something else that your professor wants. Seeking help from us likely won't result in something that aligns with your professor's expectations.
    – Thomas Owens
    Nov 14, 2022 at 19:02
  • 1
    Maybe the alive state is compound with moving and stationary internal states? Nov 15, 2022 at 4:55

1 Answer 1


State diagrams are indeed an effective way to model the event-driven behavior of a single object.

Relative time event

The relative time interval after(3 minutes) requires the player to not move. Whenever the player moves, for example making a step, the interval is reset.

The easiest way to model this is a self-transition for the move events, and a self-transition for the timing event. This way, every move re-enters the state and the timer starts anew.

Important remark: the after(delay) does specify a time related event. It does not impose any way to implement such an event. In other words, you are not forced to actively (and inefficiently) monitor the passing time, and could very well use some efficient timer event of your OS.

Repetitive time event

The "every 15 minutes" is also a relative time event, that could be expressed with after(15 minutes). It's just that its count-down cannot be disturbed by any other state transition.

One way of modeling this, would indeed be to have a separate very simple state diagram for an object that would send the periodic events, e.g. Tick15 to the Player object. In your state machine, you would then react to such a Tick15 event with the appropriate transition. The inconvenience is that you loose the oversight (and have a more complex model with more objects).

A typical alternative is to keep the logic in your single object and use a composite state with nested orthogonal state machines. This allows separation of concerns: One orthogonal region would model the lifecycle around an Alive state, and would only capture the repetitive time events. Another orthogonal region would be for tracking movement-related events around an Idle state.

Other tips

Instead of going directly from Alive to the pseudo-end-state, you may prefer to add a state Dead that could care for things such as showing some animation of the player's end, showing the game score, or whatever. This state would then fire a transition to the pseudo-end-state upon its completion (outgoing arrow without any event).

The when(condition) expresses a change event if the condition is true. So you'd typically use it to detect the end of the game: when(energy<=0). But you would not use it for when(step) since it's not about a boolean expression. If step is an event, just write step.


The diagram could look like:

enter image description here

Plantuml url

(At any given time, each orthogonal region has one active state, so Alive and Idle are active at the same time, each having independent state transitions, until a transition of the enclosing composite state is fired)

  • I have some doubts. I miss some info here. For example. What's the initial state? Idle or Alive? What are the supported transitions between Idle and Alive? What are the possible transitions between those 2 and Dead? What does mean step? If step means activity, then why the Player remains Idle? Wouldn't idle be a substate of alive? Etc...
    – Laiv
    Nov 15, 2022 at 13:03
  • @Laiv Thanks for the opportunity to clarify: when entering the composite state PlayerState, each orthogonal region represents a nested state machine having each one active state at the same time (sorry if plantuml doesn’t render the dashed region separator nicely). For more info: sparxsystems.com/enterprise_architect_user_guide/15.2/… - in case of any residual doubt, see the UML 2.5.1 specifications.
    – Christophe
    Nov 15, 2022 at 19:22
  • Good point. The UML spec also matters. I'm quite outdated when it comes to UML notation.
    – Laiv
    Nov 16, 2022 at 9:35

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.