Comment

Comment by ursus_bonum

This looks like a lot of complexity up front with no foreseeable payoff.

Why are we implementing a whole dynamically allocated stack for states before doing anything domain specific?

How many states could you possibly be expecting to have in a full game? 3? 12? 100? The examples of states were like the menu, action screen, and pause screen. So it sounds like very few. Drop the realloc'ing and free'ing and just statically allocate N states and be done with it. Save this complexity for something that really needs it.

Plus are you going to free the stack any time other than when you quit the app? I doubt it. The OS will free everything for you when you quit so there's no reason to waste time on that either.

The code so far looks like mostly a waste of time.

parent ursus_bonum 7 years ago

No comments yet

Be the first to share your thoughts.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton