LÖVE

How do you make an actual game? By that I mean a game that is professional and can be released. There seems to be a lot of stuff going on, like gamestates, menus, graphical effects and a lot more, doesn't the code become cluttered? How do professional game developers structure their games?

Question, are you looking for answers only from pro game devs, or can others risk an answer as well?

Doesn't matter, as long as the answer is helpful

As you get better and better at programming you'll learn tricks and methods to make your code structured and optimized, one major thing being OOP.

If you're looking to make and release a game, try to have the minimum amount of content. That is, dont "waste" time on good graphics, music, a professional menu, a huge story, Just make the game mechanics, make it fun.. And thats it.

And just go on like that, make games, try new things out, learn what works for you, add new content like menus, and just learn from there.

It should boil down to how the game plays, not how nice or readable the codebase is.

Granted, keeping the code clean helps the programmer's work, but as an example of the opposite; Minecraft is certainly not popular because of the obfuscated code, now is it?

As for how one should structure the game, it's really up to who's designing it; it depends on a variety of factors, from the scale of the project to how it should present itself, &c.

One could separate external libraries, internal modules, game entity data, map data, tile data, whatever else into elaborate folder hierarchies; in the game, using game states to change from menus to other menus and into the game(s) proper.

Each game does it differently, for whatever reasons, technical (limitations) or purely by choice (or lack thereof).

Edit: Of course, one other factor would be the size of the team making the game, which matters too!

Making a "real, complete" game is like running a marathon. It requires accumulated experience and stamina. You cannot go from "not doing any exercise at all" to "running a marathon" without any steps in between. You start running 1kilometer. The next week you do 1.5 km. And so on.

For games it's the same thing. It is not physical, but mental. But that's the main difference. You also need to "extend your resistance gradually".

That is why everyone says "start small." (And then gradually make more complete games over time). There's no "shortcut" to skip this, or at least I don't know it.

Good luck!

I would also recommend reading the brilliant book by R. Martin - Clean Code, to get an idea how to write and maintain clean code, which should help with structuring too.

one word: modular programming.

I've seen a lot of code for complex games made in Lua, they all have this in common. Also Object Oriented Programming makes everything a lot shorter to code. You then have script objects for example player.lua, enemy.lua, boss.lua, mydog.lua e.t.c.

Then the main function looks something like this You don't even see any variables in main.lua unless they are MACROS (very key global variables like units)

Thats for a "real game".

So you should go check out Meta Tables and Object Oriented Programming in Lua as well as Scope and Modules. You can then expand the game for ever and ever without worrying about clusters and repeated code. Also you can work more with division of labour, some work on the player module, others work on the enemy module and then the lead programmer works on the main function. Its even possible to work with people across the globe thanks to github fork it. You can then really expand on your ideas and blow things up but even then you need a solid prototype and some dedicated testers. (bugs are a harder to catch, you change one module and then you have to keep up consistency or the thing will just crash and burn)

Hope that helped.
https://en.wikipedia.org/wiki/Modular_programming

From a practical standpoint, it doesn't make sense to spend your time trying to make your code 'professional' or super-optimized.
Basically, you release something and if people want to play it - you go back, refactor and rebuild.
With many indie games a lot of the development is done after release.

As for the overall structure, try to keep the content (levels, images, sounds) separate from the code (scripts, modules, ai, physics).
This way you can expand the game without rewriting old parts of the code.

Also, keep in mind the limits and the features of the framework/engine you are using (most likely löve, if you're here, but there are exceptions ), decide what your game needs, and if the f/e lacks it, implement it yourself in a way you find it usable. It's slow? Then rewrite that small piece of code, assuming you wrote modular code, and you wrote it fast, like you were prototyping.

Full disclosure, the above sentences don't apply to me, i like to throw away whole engine ideas because i'm like that. A reason why i don't have any completed games yet (just a few small "0-player" things i did for fun )