I found it interesting. It's comforting to know how often people change their minds during development!
Still, think of how far along the game would be now if you'd've put all the time into the game development instead of drawing new graphics 
Yeah, I like to look at the progress albums for the same reason. (And it's also pretty interesting to look at my game's progress too!
)
Yep, the game would be a lot larger and more developed. But think how far along it would be if I worked on it full time? Or if I didn't spend so much time posting about my progress/reading some stuff on reddit/etc.?
There's a lot of reasons for a game taking long to develop. Doing art for yourself is just one of them. And previously I didn't like it (even hated it sometimes). But now I'm pretty okay with that, lots of times I even have lots of fun drawing art. I've just accepted as a fact that finding an artist who's willing to work for revenue share is almost impossible, so all I can do for now is to deal with it!
@nebula, thanks!
Progress updateFinally I've figured out the way to store components continuosly in memory. It may not give the significant speed up (but I'll post the results of testing!) but it will be very helpful for the future. (And for other games I'll work on using the same engine).
I'm still working on this, but
I will post the source code soon (probably this month) so people can use it for their own games. I would also love for people to propose some ideas about how I can make this system better.
Note that I won't post the source code of my engine. It's a completely separate prototype project with some tests but it would show most of the stuff I'll integrate into the game later.
The main principle is what someone later proposed in this thread.
I have this class:
class IComponentList {
...
};
and this class:
template <typename T>
class ComponentList : public IComponentList {
...
private:
std::vector<T> components;
}
and then this map:
std::map<std::type_index, IComponentList*> componentLists
where key is std::type_index is std::type_index(typeid(T)) where T is a type of the component a corresponding value (a component list) holds.
I can currently get the list I need like this:
auto& list = ComponentManager::getInstance().getComponentList<SomeComponentType>();
The entity class interface remains the same, though. I still have:
class Entity {
...
std::vector<Component*> components;
}
But now the entity points to components inside the component lists.
This is harder to implement than it looks, because:
1) Changing the position of a component in a component array invalidates the pointer in Entity so I have to change it manually
2) If I insert some new components in some vector L and the size of the vector is more than it's capacity, it will reallocate which means that every component pointer (of component type which L holds) in every entity becomes invalid.
This is not a big problem, though!
The first problem is easily solvable. The second is a bit harder, though.
I can fix it by reserving enough memory for each component vector so it won't reallocate again when the game is running (vectors would need to change it's sizes during level load but this is not critical, changing some pointers is not that hard during that.)
How can I know how much components of each type there will be? Easy. I have a list of every entity on the level in a level file which means that I can count how much of each component time I would need.
What about entities which could previously create entities when the game was running (like bows which created arrow entities). I won't do this anymore! Allocating memory on when the game is running is bad anyway.
So, each entity can explicitly show that it can create new entities and each component list would get additional size to allocate.
For example, you won't see more than 1-2 arrows flying from the same bow on the screen. This means that I can reuse the same arrow entity over and over again. I will create arrow entity for each bow entity when the level loads and there's no need to create entities during gameplay anymore.
So, those limitations lead to some great improvements of other things! There are more aspects which I'll cover later.
P.S. Anyone knows any good articles about C++ templates? Especially about header dependency aspect of it. I want to make templates the way that they won't cause more recompilation then necessary (this is very easy to make if you're not careful).
