I’m not sure if this is this the best place to ask this question, but here we go!
This isn’t exactly a black and white question, so I do not expect a black and white answer:
How do you handle you video games back end?
Game engines do a wonderful job of showing their features and capabilities, but what about the back end? The gears and mechanics of what the player does not see… What the player does not see is as important for the game to function properly, right? How do y’all handle things such as:
I was first thinking that you were talking about servers and network infrastructure, which is typically what back-end means, as opposed to front-end which is the client/game.
But yeah, I see what you mean. The way you structure your game logic, your files, your naming conventions and so on can be seen as the game back-end, the things the player doesn’t see or think about when playing your game.
Some developers will say that it is not important how you structure your code. As long as you understand it yourself. The developer behind Celeste shared the source code for the player logic. A 5000+ lines beast of a file: https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs
Is 5000+ lines of code in a single file good or bad? I would perhaps try to split that up somehow, but the game shipped and it was a huge success so who cares?
One thing I can say though is to think about the structure of your game data. What do you need to save and load? And can saving and loading be done efficiently without traversing hundreds of game objects and files to collect what needs to be saved.
On the topic of loaders and controllers I think it is a good idea to have a loader collection which references the various screens/scenes in your game using collection proxies. The loader collection will be responsible for loading and unloading scenes, optionally showing a loading indicator of some kind. Another option is to use something like Monarch to deal with the actual loading and unloading, bu the need for a loader collection still stands.
I would also strongly recommend that you try to design your game in such a way that you can set almost any collection as the bootstrap collection and it should still work. This will let you quickly test parts of your game without having to tap through a bunch of menus etc.
I prefer to use the same naming convention as Lua itself. This means snake_case for variables and UPPER_CASE for constants.
yes! my game is pretty simple, and it did not take long to realize I needed some kind of controller. Collection proxies being totally separated in terms of collisions/physics sounded like it would be an issue, but now I realize that its actually very handy to have a “separation of concerns”.
ah that makes sense! i was wondering what was the deal with UPPER_CASE. I like camelCase because its faster to type, but I must admit, I still fumble while reading it, so i stick to snake_case generally.
