Hello! This isn't a specific question, I just need some general advice on how to structure the code of a game.

Basically, I have been trying to write small games for a while and I eventually give up/start again because the code gets too tangled to keep working on it.

Right now I have written a sort of 'base game' that doesn't have anything game-like in it right now, mainly just the structure I would use to write a game. To me it seems like it could work, but am worried it is going to trip me up later on because I have no idea if what I am doing, if it is right or wrong, or if it resembles how actual games are structured.

So I am just looking for a pointer in the right direction before I do a game, so I know what I am doing is generally the right idea and I don't waste time making a massive mess.

Base game

There is quite a lot of code there but, like I said, I just need general guidance on the structure rather than the specific details, which are probably shit as well but oh well.

Thanks a lot!

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 = 0

Position = 0.0 0.0

Health = 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?

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?

Inputs are handled per update and is much more complex than that.

Since you're using a existent library and have no idea of how handle it, just handle it on the beginning of each logical update. Make sure to have some kind of keyboard class that owns the state of the keyboard (which keys are up, down, etc.).

I believe SFLM already does it internally, so you can consider using the existing keyboard class.

I also would recommend not handling input directly on the player class. Instead, on each game state update you ask for what inputs. Key "A" is down? Make the player move in the direction that you want; do not mix SFML with your game objects. The game state can know what SFML is, not the game object.

The game-state drives the game logic for the moment (you don't have a scripting system yet).

Also, where would you create the game objects? As public members of the game class?

The game objects need to be created in the class that is managing the game objects. I'd recommend to create on the game-state or the scene.

The game class it is only a state machine, and the game calls: stateMachine.Update( this ), the this pointer is the game itself.

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?

Well, the scene doesn't actually need to contain the player information in a more well designed architecture, but since you're beginning it actually doesn't matter because you won't get a 100% system anyway. Don't worry, you're not following a bad approach. The levels are:

Game-State (high-level)

Game (high-level)

Player information to a scene is generic information. The scene would contain the sprites that are actually fixed in the game (the ambient, etc.). The game would contain the player information that is persistent across the game like score, number of tries, etc.

A game has a state machine that drives the game itself;

The game-state machine has game-state objects—one of time, or a stack of states.

The GamePlay state has the player, the scene (or more).

That said, you need to implement a game-state machine. Read this article and be happy.

I had similar problems, which vanished when I read this:
http://gameprogrammingpatterns.com/component.html

Now my scripts are long at most 500 lines of code.

Before, it was in the thousands.