For my current project I have an Entity class that all game objects are inherited from.
Heavy use of inheritance is a rather brittle way of structuring your entities. These days, it's all about object composition instead, and structuring your data to be cache-friendly and batchable, rather than as an indirection hell of virtual pointers and jumps.
I also have an EntityManager class that keeps a list of pointers to all the game objects created. The idea being that this list will be used for updating and drawing all game objects to the screen.
This also might not be optimal, as these two tasks (updating and drawing) are fundamentally different, thus requiring fundamentally different data structures behind the scenes to operate efficiently.
I find myself struggling to find the best way to design all of this.
How do I make sure all game objects are added to the EntityManager list?
Many people will use object factories for this. The factory is responsible for building the entity.
How do I make sure that when an object is deleted, all other game objects that might have a pointer to said object are not now referencing deallocated memory?
Google for shared_ptr and weak_ptr. In essence, you would wrap an allocated pointer into a shared_ptr, and anywhere you wanted a "strong" reference to the object (ie, a reference that would prevent the object from being deleted if all other references were cleared) you would use a copy of the shared_ptr. In places where you need a "weak" reference to the object (ie, a reference that will be cleared if all strong references are cleared) you would use a weak_ptr.
During cleanup I delete all the Entity objects in EntityManager, and therefore they all need to be heap objects created with the new keyword. How do I make sure none of the pointers point to a stack object?
Your pointers aren't going to magically point to stack objects unless you explicitly point them at a stack object. So just, you know, make sure you don't point any of them at a stack object.
Right now I am doing this project alone, and ultimately the easy way out to most of these questions is for me to just remember things and don't make mistakes.
"Just dont forget that all entity objects need to be made using new."
"Just dont forget to add all Entities you make to the EntityManager list."
But that is bad programming right? What if I was on a development team...that wouldnt fly! The other devs would not know all the catch clauses of what not to do and what may cause a bug with my code. Thats the whole point of classes and privacy and encapsulation ect...to make code that is hard to break and easy to organize.
I'm trying to improve my skill as a designer and programmer...am I overcomplicating this? Somebody help me.
This is why you document your code. Most of your code should be self-documenting (ie, broken up and structured in such a way that it is easy to read, methods and members named appropriately, etc...) and where necessary commented. Things like "Just dont forget that all entity objects need to be made using new"
are no-brainers, because there will probably only be one place that objects are constructed, and that's in your factory. Or, at any rate, you probably shouldn't be randomly new-ing entities all over the place. Leads to spaghetti.
Might want to read a book or two about basic design patterns, before you start making assumptions on what is good programming and what is bad. Also, don't let what the "professionals" do be your only guide; even pros can turn out some shockingly bad code in the name of Ship It!