Question on game state vocab

Re: Question on game state vocab

Fri, 20 Feb 2015 03:38:27 +0000

Thanks everyone for the tips. I think Persistence sounds great because it is short and conveys the idea of pushing or pulling data from a more permanent saved source.

My use of the word state to track and transition the displayed screen should be renamed to either ScreenManager or ScreenController I think. It is definitely in line with the controller part of the MVC pattern.

Re: Question on game state vocab

Thu, 19 Feb 2015 19:56:24 +0000

To clarify how I use state, state for me is the classes and data structures that represent the current state of the game. This sometimes includes the menu state, but sometimes I pull that out into some sort of menu state subcomponent. To put it a different way, it's the model in a model view controller (MVC) pattern, or a model view viewmodel (MVVM) pattern. At that layer, it contains the data structures as well as the game logic to make it run. It does not include rendering code, but it's far more than just a list of things to draw. There are, of course, lots of alternate ways you could structure this, and each has their own strengths and weaknesses.

I think I'd definitely call the file IO stuff something different. Probably something along the lines of persistence. The rest of the game doesn't care how it gets saved (database, online, different file formats) just that it can store it and retrieve it on another run.

Re: Question on game state vocab

Thu, 19 Feb 2015 19:14:59 +0000

That's a particularly good question. I also use (used to, I'm in transition at the moment - or thinking about it anyways) state to represent the stuff that is to be drawn to the screen (CreditsState, GamePlayState, MainMenuState). Normally I'd put those in a folder within the project by themselves called 'States'. I also use a simple class that maintains which state is currently running, and switches between them when needed called the 'StateManager'.

I found working on RB's first couple of collaborations a little difficult, because he also uses State, or GameState, but it represents something completely different. His GameState is a collection of items to be rendered at any one given time, and from what I understand he simply changes the objects within GameState. Strange, eh?

So, personally I agree with Marcus on keeping the GameState stuff as it is. It actually took me a while to understand what was going on with just it, and seems like a good fit since when the 'state' changes, so does everything being rendered.

I'd probably change the file stuff to 'FileManager'. I use the Manager moniker pretty often on different aspects… like the StateManager. To me, it represents a higher order, or collection of the sub-objects, kind of like a distributor in a car, and manages their actions. It links to a bunch of other parts (states, or in this case spark plugs), and tells each part when it's their turn to do something. I'm actually using a FileManager in my text game, but in this case, it loads and parses the text data file into the various game objects that represent 'rooms'. It could also easily be used to load or save a 'gamestate' representing the players progress. I think I'd probably agree with Marcus on that too - to make things easier to follow I'd probably use something like SaveData or perhaps PlayerProgress.

Well, thats my 2 cents, hope it helps!

Re: Question on game state vocab

Thu, 19 Feb 2015 16:21:33 +0000

If it were me, I would probably change the save-game handling namespace to something like Data, SavedState, or the like, and leave the enum and/or class as state or maybe something a bit longer, like GameState, but, of course, you're free to do whatever you want. =]

Question on game state vocab

Thu, 19 Feb 2015 13:32:04 +0000

Not too important, but while writing code for the current competition, I ran into a bit of a naming issue.

I often use the word 'state' to represent reading/writing permanent data to a file (like a save game). I also use 'state' to represent how the program tracks and transitions which screen to draw.

This leads to a bit of naming issues when I have a namespace called 'state' that deals with reading/writing save files and an enum and class that have the word state that deal with tracking and transitioning which screen is being displayed. Does someone have a better naming scheme for these two areas?

I figure if my naming convention is confusing me, it will most certainly confuse others.

-Brett