Is a game view "stack" really a Stack?

Question

Given the academic definition of a Stack as "A data structure where items are added in a FILO manner and accessed in such a way that only the top item may be examined or removed to be modified."

Game view implementations that call them "stacks" where each view is pushed onto the top or popped off the top and each view below it is visible seems to violate the above definition. The first part is valid, views are only added/removed from the top but the fact that each other view in the stack is still visible from top-down seems to violate the principle that only the top is accessible for examination or modification.

That said, are these implementations actually Stacks in the data structure sense of the word or just wrapped fully accessible arrays with fancy methods called pop and push added to them?

Answer 1

are these implementations actually Stacks in the data structure sense of the word or just wrapped fully accessible arrays with fancy methods called pop and push added to them?

That depends on how you implement your scene stack. I have used stacks that were std::stack and I have used fancy wrappers for vectors due to the need to check other scenes. So it boils down to the specific needs of a game, both are valid and are used out there.

Answer 2

Imagine for a second that you have a bunch of plates.

You can stack plates, by putting them one on top of the other. To add a plate to the stack, we push it on top. To remove a plate from the stack we pop it off the top. We can however reach into the stack and take out any plate, its just harder and requires lifting all the other plates out of the way.

The important thing to note is that, when you stack a bunch of plates, the plates you've stacked are still there, they don't become non-plates once you stack them. The stack really defines the way we access the plates. Also, you can in most cases peek at a plate within the stack. (a bit like tipping the stack up so we can see what plate has what written on it).

We're more concerned with access patterns, than overall implementations. And using a stack implies you're going to use it a particular way, rather than how it was implemented.

So yes, it's still a stack, regardless of implementation. It's about access patterns.

Answer 3

Stack is indeed nice way to do implement screen manager. However, it really depends on you, what you want for it. I had to create little bit different kind of solution, because of few problems that arise, with single stack.

Stack is nice, because if you automatically route input to top view and draw it too, it makes developing a game, very fast process. There is few problems thou. What if you create GUI view, that should be drawn on top, but should not take input away from the actual game screen? What if you create popup view, that darkens game world and shows some panel/window with information, still allowing game to be drawn and update, but no input. Because of this kind of problems, my screen manager has multiple stacks. I have Gui stack, gamescreen stack, background service stack and few others. My view has flags, that are set when it's instantiated. Flags can be Update, UpdateAndDraw, NoUpdateDraw,BackgroundService,PopUp,GUI etc. With these, my manager automatically pushes and pops stuff in out from stacks.

TL;DR; Yes, it really can be stack. Problems come when you wanna restrict running of certain view, either by stopping update or drawing, it forces you to design some controlling system.

Answer 4

It is a stack data structure from the user interaction perspective. They have to get rid of the window on top to access the next window down, and clicking a button may open a new window on top of the current one.

As far as the implementation goes maybe, maybe not. A stack would probably be the easiest to get up and running but wouldn't look as neat as it could without some kludges. So I would start with a stack to keep it simple but go with something else of better visuals later.