Thanks for the replies.
Basic recommendations (while doing it correctly):Switch from "all these game-state switches" to a more OOP (each game state is a object).The game is a state-machine. Search on the forums: "game state-machine" and you'll find 10^10 of information.The game-state contains the game logic of the game and generally four functions: Enter(), Leave(), Update(), Render().Creating small classes in order to achieve the logic of your objective (such the player class, entity class, game-state class) helps staying in tune with the Single Responsibility Principle (SRP) which you'll use as a good programming practice for the rest of your life as a game programmer.Do not hard-code scenes, read them from a file. It doesn't need to be a good file format such .json, .lua, etc. it only needs to be loaded (search for "simple text parser using streams") in order to become familiar with the data-driven design.Example:File: Scene.txt[Sprite]Type = 0Position = 0.0 0.0Health = 0.0[/Sprite]
With the four functions in a game_state: Enter(), Leave(), Update(), Render(). Would you handle input in the update() function which would delegate it out to the objects in that state? Like the player or a button/ menu / piece of interface?
Also, where would you create the game objects? As public members of the game class?
As for scenes, would they only contain data about the game world like the player position, items the player has, world size etc. If there was a pre-made level made of a grid of tiles, would that all be loaded in in the same file?