Is there ever a "correct" set of way to make a game?

[ivan]

I'm just a beginner.

Based on the issues you have described in your post, I don't think you are a beginner. Learning to design your game on a big scale is a difficult problem.

I scroll through the playlist and found somethings like Event Manager, Entity Manager, Tweens, State Machines, ECS, etc. I searched throughout the internet if there are something similar to this and I found A* Algorithm, Minimax Algorithm, Heap Priority Queue, etc.

One of the pitfalls for developers is to add libraries and design features simply because they seem cool. My suggestion is to build/add features as needed, not because they are available.

If I coded the game the way I understand it will it be considered a "good" way ? Not only that, will the performance of my "understandable" code can be considered great ?

There are always compromises to be made when programming. Usually the most clear and easy to maintain code is not going to be the best in terms of performance and vice versa.

Having said that, you absolutely need to learn to read other people's code, because that will make you a better developer.

[knorke]

I agree with Nikki and some others.
It seems you are at a point where watching/reading more tutorials will not give you any more insight.
Reading tutorials is nessecary but it will only get you so far: At some point you have to start writing code.
Your goal is to make Tetris. Not the control software of a nuclear reactor. Do not overthink it.
Who cares if the code is bad? As long as you have written it yourself you will have learnt something.

Programming tutorials, or any tutorials really, are not something that you watch in one go and then you will know what to do. Instead you read the first chapter, run the tutorial code, make small modifications to the tutorial's code to better understand it.

[MrFariator]

The issue with tutorials often is that they're (perhaps rightfully) fixated on a single topic, and show to do that one thing. Sometimes for the sake of simplicity, such tutorials may implement things in a way that's not necessarily scalable, or might even require significant tweaking to make it work in any other project.

In order to start understanding some more important topics like how to structure your codebase (it doesn't have to be pretty, just do whatever feels comfortable to you), how to make things play nicely with one another (it's one thing to make a single class, it's another to make several that don't crash and burn when introduced together), and so on and so forth, you'll just have to bite the bullet and start making a project. It could be a small test game like tetris or pong, doesn't really matter, so long you're doing something to improve your knowledge, and gain valuable experience.

[Karai17]

While I would say there is no one true way to make a game, there are conventions in place that have evolved over many decades of people trying to figure things out. While conventions are not strict rules or specifications, they are helpful when learning and when requesting assistance since more people will be able to read and understand your code, more quickly.

A common issue I've found when helping people who are very new to gamedev is that their code is often difficult to read or follow because they haven't learned about certain conventions or, in some cases, their code isn't idiomatic so it doesn't "look" or "behave" in a way that a language tends to. A common example of this in LOVE/Lua is the use of global variables. Globals should be avoided unless absolutely necessary as it makes following your code's execution very difficult and opens you up to a whole class of bugs (accidentally overwriting global values in different parts of your code).

So with that being said, I would suggest looking through some high profile open source projects on github to see what you can gleen from their code structure. A common convention for example would be to have all your source code in a "src" folder, all your library code (code that you import but never edit) in a "libs" folder, any binaries that you may need (such as love) in a "bin" folder, all of your assets (images, sounds, music, textures, maps, models, etc) in an "assets" folder, any files that don't make it into the game but are necessary for the game (such as photoshop files) in a "res" or "resources" folder, and your final output should get compiled out to a "dist" folder. markdown, shell scripts, dot files, etc should sit on the root of the project with your main.lua file.

Code: Select all

/project
   /assets
      /bgm
      /maps
      /sfx
      /textures
   /bin
      love.exe
      lua51.dll
      etc
   /dist
      my_game.exe
   /libs
      /bump
      /sti
   /res
      player_sprite.psd
   /src
      /systems
      /ui
   .gitignore
   build.sh
   LICENSE.md
   main.lua
   README.md