Design patterns in NES programming

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
RJM
Posts: 55
Joined: Mon Jul 27, 2020 11:56 am
Location: Rzeszów, Poland

Design patterns in NES programming

Post by RJM »

Hi folks.

I'm wondering how do you handle more complicated state logic in your games? Inspiration for this post comes from the awesome blog about the state pattern: https://gameprogrammingpatterns.com/state.html. Highly encourage you to read it!
In my case reimplementing hierarchical automata in C ( from the article ) nicely simplified the whole logic and made my code more extensible.
What about you? How do you handle state logic? More general, do you use any design patterns in your NES games?
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Design patterns in NES programming

Post by Oziphantom »

FSM is basically the only method. The push/pop system is great but how does it handle jumping while firing? what happens when you fire while standing on a moving platform etc. Rather making the gun its own FSM and let it update after the player.
User avatar
RJM
Posts: 55
Joined: Mon Jul 27, 2020 11:56 am
Location: Rzeszów, Poland

Re: Design patterns in NES programming

Post by RJM »

Oziphantom wrote: Sun Feb 06, 2022 9:31 pm FSM is basically the only method. The push/pop system is great but how does it handle jumping while firing? what happens when you fire while standing on a moving platform etc. Rather making the gun its own FSM and let it update after the player.
Sorry, I was referring to a different pattern from the article: https://gameprogrammingpatterns.com/sta ... e-machines.
In my case hierarchy means that a "child" function can invoke a "parent" function if it has no idea what to do with an event.
I've implemented the pattern using a struct of function pointers.

Code: Select all

typedef void (*enterState)(void);
typedef unsigned char (*handleEvent)(unsigned char);
typedef const unsigned char *(*animate)(void);
typedef void (*move)(void);
typedef void (*exitState)(void);

typedef struct {
  enterState enterState[STATE_COUNT];
  animate animate[STATE_COUNT];
  move move[STATE_COUNT];
  handleEvent handleEvent[STATE_COUNT];
  exitState exitState[STATE_COUNT];
} state;

void transition_state(state *state, unsigned char *playerState, unsigned char event) {
  unsigned char nextState = state->handleEvent[*playerState](event);

  if (NO_STATE_CHANGE!=nextState) {
    state->exitState[*playerState]();
    state->enterState[nextState]();
    *playerState = nextState;
  }

  currentAnimation = state->animate[*playerState]();
  state->move[*playerState]();
}
rethunter3000
Posts: 28
Joined: Sat Jan 22, 2022 1:25 pm
Location: UA Ukraine, Dnipro

Re: Design patterns in NES programming

Post by rethunter3000 »

I would like to express my gratitude to the user RJM and the whole of Poland. On the second day of the war, he wrote to me and offered help and shelter at his home! Incredible Poland and its help to Ukraine! Poles, we are proud of you!
Thank you very much, dear RJM!
Post Reply