One of the pitfalls for your current method is that you're likely going to be writing a lot of "GetType() checks" (and other various virtual calls) in your code as you iterate across your entities vector. A way around this is to organize your object lists in a way that minimizes or eliminates the need for virtual calls. Employing a Component/Entity/System approach can help achieve this.

Seeing that so many intermediate programmers get snared on CES, either by overabstracting and over-engineering, or simply not understanding it, I'd suggest the OP holds off on exploring that avenue. :)

Probably the easiest way forward, depending on the number of different entity types, is simply to have a different container for each broader type.

Player player;
std::vector<Wall> walls; //If a box is just a wall that can be moved, then pass a bool 'movable' to the Wall class.
//There can be different types of enemies, defined by passing variables into the Enemy class without the need for inheritance.
std::vector<Enemy> enemies;

To the OP: Since I'm not sure how many completed projects you have under your belt already, I'd suggest a primary goal of completing a game rather than engineering it perfectly, and then using that knowledge to figure out what went right and wrong in the big picture. Code cleanly, but from an architectural standpoint, I'd suggest KISS.

One of the pitfalls for your current method is that you're likely going to be writing a lot of "GetType() checks" (and other various virtual calls) in your code as you iterate across your entities vector. A way around this is to organize your object lists in a way that minimizes or eliminates the need for virtual calls. Employing a Component/Entity/System approach can help achieve this.

Seeing that so many intermediate programmers get snared on CES, either by overabstracting and over-engineering, or simply not understanding it, I'd suggest the OP holds off on exploring that avenue. :)

Probably the easiest way forward, depending on the number of different entity types, is simply to have a different container for each broader type.

Player player;
std::vector<Wall> walls; //If a box is just a wall that can be moved, then pass a bool 'movable' to the Wall class.
//There can be different types of enemies, defined by passing variables into the Enemy class without the need for inheritance.
std::vector<Enemy> enemies;

To the OP: Since I'm not sure how many completed projects you have under your belt already, I'd suggest a primary goal of completing a game rather than engineering it perfectly, and then using that knowledge to figure out what went right and wrong in the big picture. Code cleanly, but from an architectural standpoint, I'd suggest KISS.

Thought of doing that, however I wanted to make a reusable engine so that I wouldn't have to change much code when making a new game, but I guess I'll just make a game for now.

I wanted to make a reusable engine so that I wouldn't have to change much code when making a new game, but I guess I'll just make a game for now.

Thought of doing that, however I wanted to make a reusable engine so that I wouldn't have to change much code when making a new game, but I guess I'll just make a game for now.

If you make a game, and take the 'engine' (guts) out of it, and reuse it (improving it and rewriting the parts you now know don't work while using it for the next game), you got yourself a reusable reused engine and a game. :P

The more (finished) games you reuse it for, the better it becomes (assuming you improve and refine it for each game), and when you do scrap it and eventually write a new one from scratch, you'll be alot more knowledgeable about what realistically is needed, and how to architect it.