Creating game architecture
Creating game architecture
For some time I've been trying to create some rudimentary hack'n'slash game. I didn't want to use ready game engine because I consider it more of an exercise in programming a game than an honest attempt at creating one if that makes sense. So I started with SFML.
Along the way I've recognized the need for loading settings from files(Json library), logging, map editor(ImGUI) etc and it's posing a questions to me for which I struggle to find answers to.
For example let's consider map editor. Currently loading/saving the map to file is done by TileMap class itself but I don't know if it should be. If the map is not as big as render window, should it itself be responsible for centering it or class/function using it should do it? What about scrolling map bigger than render window?
Another example is I have Entity class (player, monster can be entity) which can have Graphics, Physics component etc and it is responsible for rendering itself. But I don't know if it's the right approach. I would like to have logic separate from drawing but Entity essentially merges the two with some extra steps
Add to that is that I would like to painlessly inject debug enabled logging into different parts of this code and I'm afraid I will end up with spaghetti monster for code
What this long windup is leading to is a question. How do I write render independent, reusable game architecture? Where can I read more about this so I can make better decision about what I'm creating.
Now that I've read all of this before submitting it seems to me like what I'm really asking is "how do I make a game engine?". And this was not supposed to be exercise in creating one, at least I didn't think so when I started
There is no right answer. Every game and game engine gets tailored at some point or another to solve a problem unique to the game being made. Making a game is as much of an art form as it is a science. If you’re in it for the journey, you will spend the rest of your life optimizing and refactoring for ever diminishing returns and technology and techniques will forever outpace you. Just enjoy what you have accomplished and move on to the next most critical thing. Focus on 80/20. This will keep you moving and you’ll actually learn more by the things you realize in hindsight rather then getting stuck trying to plan for imagined scenarios that may or may not happen.
That said…
Tilemap: pick a spot that makes the most sense at the moment and just write your initial logic. Don’t worry about optimizing. If you’re not sure what to optimize, then you need to define bounds and stick to them. Let the game rules define the technology requirements, not the other way around. If you need to center, just write it, if you need to scroll, do it there too. Eventually you’ll get to the point your class does a few too many things and you can reconsider refactoring. In the meanwhile, just get it in, build a level and see if that’s even what you really need. Don’t be afraid to deprecate code.
Entity: Ecs is a great pattern. The question you should be asking is whether your game runs under this pattern acceptably. If your goal is 90fps let’s say, and you are hitting it, then don’t worry about separating your graphics component into a seperate system. You’ll gain nothing but a longer task list out of it.
That said, if you are after knowledge, consider a study of unreal to learn how they organize their threads and components. You might pick up a few tricks. They use a dedicated render thread that basically takes proxy data from the previous main game logic frame and runs alongside the main thread.
The first thing I ever learned in programming was never to reinvent the wheel. If you already aren't a pro at making your own engine and you didn't set out to make an engine, why are you making your own engine when there are plenty that have everything you need to start doing what you really wanted to in the first place? I myself have a desire to make an engine; but I can't even find a justification to try because there isn't anything I think I could do better than what has already been done, and nothing I could add thay I couldn't just put into an existing engine.
I don't understand your reticence in not using a game engine. If you do this by yourself you are trying to recreate 40 years of game engine best practices by yourself. Or you can have a look at how some of the other engines do it and then try to recreate something similar. Just take a day to learn each one's architecture.
Here are the main architectures that game engines use:
- Actor based: heavy inheritance with hierarchy based composition. Unreal, Godot
- Component based: composition is encouraged at the entity level, reducing the need for inheritance. Unity
- Entity Component System (ECS): No inheritance, clear separation between data and logic. Bevy, Unity DOTS
Each approach has a different solution the problems you are mentioning.
I do not want to recreate 40 years of best practices, I want to understand them and try to implement them. That’s why I’m asking for some reading, educational material. It’s not that I’m averse to using an engine, it’s just not something I set out to do