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.
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.