Author Topic: Design of game action systems/architecture  (Read 482 times)

dscreamer

  • Priest
  • **
  • Posts: 65
    • View Profile
Design of game action systems/architecture
« on: November 18, 2016, 03:28:36 AM »
(Disclaimer:  Simple action systems get the job done for most games. There's no need to make it more complicated than it needs to be.)

So, I've been taking a long look at game actions. Not the scheduling of future actions - just the actual execution of the actions taken by the player and enemies (and maybe other things).

I had a few goals:
- It should be easy to handle cancellation of actions, like when the player backs out from the targeting screen.
- It should be easy for an action to allow certain conditions to be overridden, like making an attack while ignoring all range limitations, or declaring that an attack will never result in a critical hit.
- It should not be fragile when things change, because things WILL change.

I have several pages full of text now, and I feel like I'm getting closer to something that'll work, but there are still some major design decisions to be made. Anyway, that's not what this post is about.

Those of you who have tried to handle action cancellations elegantly, how did it go?
What goals did you start with? I'm interested in exploring this space, to see whether some of these questions already have answers.
Thanks for reading.

Tilded

  • Acolyte
  • *
  • Posts: 49
    • View Profile
Re: Design of game action systems/architecture
« Reply #1 on: November 21, 2016, 04:18:45 AM »
Have input modes for each screen. Keep them in a stack, so entering targeting adds targeting onto the stack, and canceling takes it off. Events are passed to the topmost mode, and optionally can be bubbled down through the rest of the input modes.

dscreamer

  • Priest
  • **
  • Posts: 65
    • View Profile
Re: Design of game action systems/architecture
« Reply #2 on: November 21, 2016, 04:02:39 PM »
Have input modes for each screen. Keep them in a stack, so entering targeting adds targeting onto the stack, and canceling takes it off. Events are passed to the topmost mode, and optionally can be bubbled down through the rest of the input modes.

Sorry, I must have been unclear. That's a great idea for handling the UI (I think I do the stack part, but not the bubble part).

I was mostly curious about what it looks like after the UI stuff is all abstracted away - when it's just a matter of cancellations and other action results.

Krice

  • Protector of the @
  • *****
  • Posts: 1983
    • View Profile
    • Email
Re: Design of game action systems/architecture
« Reply #3 on: November 27, 2016, 08:31:02 AM »
Sorry, I must have been unclear.

I think you are talking about actions that are collected into some kind of stack before executing them? Or in other words event-based system. It's I think less common in roguelikes which more often are REPL (linear execution) based.

doulos05

  • Acolyte
  • *
  • Posts: 27
    • View Profile
Re: Design of game action systems/architecture
« Reply #4 on: November 28, 2016, 10:39:43 AM »
Why is your targeting routine adding an event to the queue before it finishes? If the player cancels, then your targeting routine should return without ever speaking to the event handler.