crancran

I can't comment on your first three questions. It's really hard to quantify the time involved because it's highly dependent upon your own comprehension and devotion to learning the language well. It's also based upon whether you have prior experience with other languages too.

As for myself, I do love programming. I was fortunate at a very young age to have been exposed to programming. My father introduced me to Basic at age 7 and sometime between then and age 10, I was programming in Pascal and by early teens, I made the leap to C/C++. Programming has always been a passion of mine. I've been in the industry professionally for almost 15 years and that passion continues to burn today as strong as it did at 7.

I use pointers to the base component class to work with derived component classes. I only use RTTI casting when a base class pointer needs to access a member of the derived class. My initial reason for this approach was make my life easier wrapping objects from 3rd Party libraries like Ogre::Mesh into a Component. A Derived Component inherits from both the Base Component and Ogre::Mesh Classes or contains members to work Ogre::Meshes directly. I'm relatively new to C++ and still trying to wrap my head around a components implementation.

A cleaner solution would be to treat the ogre mesh as a property of your derived component and through an interface, keeps the Ogre API out of the ECS framework.

/* Base mesh object */
class IMeshObject {
};
/* Ogre mesh object */
class OgreMeshObject : public IMeshObject {
};
/* CryEngine mesh object */
class CryMeshObject : public IMeshObject {
};
/* Base component */
class IComponent {
};
/* Renderable Component */
class IRenderComponent : public IComponent {
};
/* Mesh component */
class MeshComponent : public IRenderComponent {
public:
  void setMeshObject(IMeshObject* meshObject);
  IMeshObject* getMeshObject();
};

If you wanted to keep it simple and refactor later, you could avoid wrapping the ogre API if you wanted and simply use get/set methods for the Ogre::MeshPtr object; however, I certainly would not inherit from any render API classes when creating my ECS components.

So what you're getting at is having a fully generic entity type, but attach behavior and controller decorators to it? Do you have any sample code that demonstrates this technique (or a reference to a paper describing it?) I'm intrigued.

Your code you posted on the previous page was close to what Swift was describing but instead of deriving a class from Entity; you simply leave Entity as the final class. The entity class serves as a means to hold control information about the entity such as a unique ID, possibly a name/tag, and the list of components and behavior that give that entity instance it's unique traits and functionality.

The aim with ECS frameworks is about being data-driven. We can extract the pieces needed to construct a car entity and the instance values used by car entities from code. A lot of games do this by having a file that describes the template used to construct an entity by name/type and then another file that describes instance specific values based on an entity name/type. This "file" could also be a factory class if you want this managed inside your code or even a SQL database when we consider online games, but the goal here is that the data-aspect of an entity is completely isolated

I chose to use XML files for my first pass implementation. I have a template XML file that describes all components needed to create my entities, which provides similar functionality to your Create() method on your Car class. The second XML file is for instance specific values that describe data such as location, min/max velocity of my entity, scale of the model, etc. This way if I want to mass produce 500 entities of a car I could easily do so by having my entity factory load my template of a car entity once and then clone it the number of times needed. Afterward it is a simple setting of instance specific properties.

But at the core, you have 1 entity class that is generic and you allow the data to drive the aspects contained within.

HTH

Model – Gameplay (game entities, eg. Player, Weapons)
View – Rendering
Controller – Input and non-gameplay flow (menu’s etc)

It's certainly a good idea to keep these separate and loosely coupled. But don't get hung up on it. Most MVC and assorted pattern wisdom has its heritage in the enterprise [web] applications world, the usage patterns of which don't really align with video games.

Agreed. The only time I've seen MVC expressed in game engines is shown below

Model - btRigidBody, MovableObject/SceneObject, AIObject
View - RigidBodyComponent, RenderableComponent, AIComponent
Controller - PhysicsSystem, RenderSystem, AISystem

Controllers manage components and the components hold a reference to a model object. Often these model objects are the lowest representation used by the internal framework that the system wraps. For example, btRigidBody represents a bullet physics engine rigid body for collisions. The component holds a reference to this object and the physics system simulates physics by stepping the bullet engine at a fixed rate interval each game loop.

Thanks you very much
I'm already coming up with way to implement the components, so it will be a thing to add down the line; going to keep hierarchies for now.

Clockwork, there is a good amount of merit to stick to aggregation of a hierarchical approach. It does seem complicated at first and particularly when you're trying to think non-object oriented, it's not an easy approach to grasp, but the beauty of it is that once the foundation is set and is solid, the ease of dropping in new features cannot compare to the level of time and effort you'd have to deal with by implementing it in a typical class hierarchy approach usually.

There are several ways a component-based entity system can be implemented and there isn't a real right way to go about it. A chunk of it boils down to how decoupled you wish to design your code.

Some developers are satisfied with the modular design that aggregation provides that they're ok coupling their components together explicitly. This is done a lot of times by having an entity class that holds a map of components that make up that entity. Then components get another component's interface by calling some templated GetComponent method on the entity and then use the component to obtain properties needed. For example, my renderable component needs to know position, so it gets the transform component from the entity by calling GetComponent<TransformComponent>().

Others would rather not couple their component systems together at all and obfuscate any relationship that would otherwise be visible between them by using a mediator, observer, or combination of both patterns in conjunction with events/callbacks. Often this approach is realized where there is no real "entity" class but rather an identifier for an entity. The components themselves are managed in separate subsystems of the entity system and reference the entity by id. The benefit is that so long as a component or component system handles and/or emits the same events, i can change the internal implementation, to the point of replacing Bullet with PhysX for physics and the remainder of the code remains as-is, no changes and the level of effort is considerably lower than when things begin to be coupled in more traditional programming patterns.

Regardless of either approach, the lifetime of the components is that of the lifetime of the entity unless a component is temporary and added/removed based on game logic events that are triggered in game-play. Typically, once an entity is removed from the world and destroyed, either an event fires that the component systems (in the case of second approach) receive and then deallocate the components to that entity id or the entity's destructor deallocates the components if they're not managed by a subsystem when the entity object is deleted.

Either way, use what works best for you & good luck.

Each of us here could take precisely the same courses, studied from the same books, researched the same articles and been given the same assignment requirements and the professor will be presented with answers that are each unique and different because we all interpret assignments differently, and our analysis, thought, and experiences/knowledge we gained along the way influence the end result. With that, what you call a "game engine" may appear to be an engine but to someone else it's not. What i call good object oriented programming may not be to my coworker because we all have our own unique way of looking at things. In a collaborative environment, this is a god send because it keeps our minds clear and focused and we are less likely to get side tracked.

Just like with any project, you must have a set of requirements, a scope that confines those requirements, and a deadline. It's easy to fall victim of trying to do more in the time allowed than trying to focus on the tasks at hand to meet the deadline with the requirements and tools provided. If my employer asked for a certain feature, provided both a set of requirements and scope and dictated a deadline, then I'd have a number of tasks on my plate to work out. First, it is to research what I need to do to adhere to the requirements, determine if there are any scope constraints or flaws in the design based on the current architecture, and then outline what the next steps are in order to accomplish the goal within the time allowed and constraints dictated. No where in this process should I even consider adding more than the initial requirements. Experience has taught me that when deadlines exist, it's best to focus on the tasks at hand and complete them timely first because you never know what hurdles may come your way because you're bound to overlook something in your analysis process. Guaranteed!

It isn't bad to want to try and make something your own; however there is a time and place for that. Just be sure you aren't jeopardizing your studies and ability to deliver the requirements of your course for the sake of experimentation. I can easily take some open-source tools and mash them together in a few days have something with some meat of a game, but that would be ridiculously far from an engine.

If you go out and research what's in an engine, you'll find similar results - AI, Physics, Input, Rendering, Scripting, Networking, Events, Platform IO, etc. If you develop each of these 'pieces' in their own vacuum, then you have the early stages of a framework of which if you design it based on solid interfaces; then you can easily plug in Nvidia PhysX instead of Bullet for the physics simulation engine and nothing else would know the difference. Beyond that, once you start tying these framework pieces together, then you begin to form the basis of an engine; but be careful to understand that the engine should have NO game-related coding. Again, the engine provides a higher level tool-set to create a game with where-as the framework is the lowest-level meant for the engine internally. Point is there is a lot of code and effort that goes into making what the presently game community calls "an engine", so be sure you understand the scope of what you are trying to accomplish. What you can likely achieve is only the tip of a much larger iceberg .

Anyhow, I must echo others here in that we'd all be doing you a disservice if we didn't usher you to reconsider your opinionated stance of writing your own engine rather than using the tools provided by your professor. Think of it like this, use the provided tools and write your game. If you get it done early, then that's the time you can then experiment with your own engine. As you experiment, you may find new was to handle something that you could backport to your game project to turn in at the deadline to make it better. Now, you have the assurance your task is done plus the time to possibly work on a dream of yours without the added risk you're exposing yourself to presently.

Whatever your choice, best of luck. We've honestly done all we can in this thread to show you otherwise.

EDIT: typos and walls of text crit me so bad :S

Your professor's advice may have been true 10-15 years ago; however, the pay scale of programmers (naturally dependent upon location and experience of course) tends to be higher than that of analysts because as technology has advanced, there is a much broader burden on the programmer to make things work in a heterogeneous systems environment that often soars well above your analysts ability to truly comprehend. In most companies, the analysts are there to add buffer and a communication conduit between the more technical "programming" team and the "visual and creative" business and market teams. I stepped into that role over the years and it isn't one which I personally have enjoyed as it tends to be less technical in nature and more conceptual. It lacks the hands-on vibe I prefer to have when it comes to day to day work.

But when it comes to pay, naturally we all want to excel at our job and make lots of cash while doing it; however despite what cash can do for you now, it isn't the answer to happiness. Starting out, I'd advice you to reach for the stars while also trying to expand your mind in as many areas as you can. Do be afraid to experiment, don't be afraid to try atypical options even if it means sometimes doing it on your own time to prove or disprove any theories you or others may have. It's often a rewarding effort because you will likely learn several things along the way which you will be able to reuse in other projects or solutions down stream and already be familiar.

As for the hire/fire scenario, I wouldn't be too worried about that. As others have pointed out, if that were to ever happen, that's typically a reflection on the hiring manager and not the new hire themselves and that wouldn't be a company I'd want to work for anyway. Most companies are aware that newcomers from college have little real-world experience because we all know that college unfortunately doesn't teach you real world scenarios; college gives you tools for you to solve and apply at real world situations. So be brave and strong and don't fret about things like this. There is a lot of "on the job" training that happens with people who are new employees, even those who aren't right out of college.

My advice is simply if you enjoy programming, then that's where you should go. Don't do it because of the money. Do it because it is what you find passion and enjoyment from it!

If you look at the history of C/C++/C#, we first saw the introduction of the C-language in 1972 by Bell Labs. In 1979, Bjarne Stroushrup began work on an enhanced C-language at Bell Labs. The language hit mainstream in 1983 when it's named changed from C with Classes to C++. At this point is when the computing industry was really starting to take off and the rise of computers began. It took nearly another 20 years before Microsoft finally released the "Cool" (C-like Object Oriented Language) which later was renamed to C#.

There are still many applicable uses of the C-language today, it just all depends upon the industry and aspect of work you are in. Languages come and go with time as clever and talented people design better and more efficient ways to accomplish tasks without concerns of so much "boilerplate madness"; hence why we have C# today. But that doesn't mean that C++ is out by any means, in fact there still exists a high demand for C++ developers because legacy code was written in that language and often finding libraries or wagering the cost to port a product from one language to another is simply not worth the effort.

For those very same reasons is why one of my first programming gigs out of college was at a bank. It blew my mind that this bank had core critical systems that were part of their main livelihood as a company using languages like COBOL. They preferred having a small dedicated team of programmers that knew COBOL to keep those mission critical systems up and operational at all costs. Looking back, first thought is certainly job security . But it goes to show, there is a sea of languages out there and each bring something different to the table that makes tackling a problem easier or harder depending upon the language of choice.

I wouldn't spend time getting caught up in whether a language is going to die anytime in the future because reality is the spotlight shifts from one to another as time moves on. That doesn't mean that language is dead or has no applicability, but that something better has come along that is newer, maybe provides a better approach than it's predecessor and eases the job of the programmer to spend more time being creative than having to worry so much about boilerplate stuff .

I'm still working towards a component based design, so YMMV, but I opted to have a single spatial component, per object, which is handled by a spatial subsystem. what has really tripped me up so far is how something common to many components, like position, should be handled. So far my idea has been that components hold no data of their own, only functions. the data is stored in kv map of belonging to the entity as generic data. this way the entity has no original data(or unused data) only what has been added to it's map via it's components. I've not reached the light at the end of the tunnel, but this has definitely been my most reusable attempt so far.

Well this is certainly an interesting approach. It seems like the polar opposite to mine because my components hold no functions, only data (virtually all component processing is handled by the subsystems). I'm currently wondering whether it would be feasible or practical for each subsystem to hold its own scene graph. Perhaps this would only be necessary for certain subsystems.

You are going to likely find that some subsystems will have their own "view" of the virtual world. The render engine cares about the scene graph so that objects are rendered properly. The physics system will likely use an organization pattern that best fits determining collisions and callbacks to notify the affected entities. You will likely have some spatial subsystem where either transform components or some representation of a transform component is represented in an organized tree/structure so that when say entity A wants to yell or determine nearby enemies, it can query that subsystem, get that information and take an action appropriately such as aggro onto a nearby player that just walked by .

Short answer, they should be different.

Whenever you are coding a particular class/object, you should always refer to two principles.

The first is called Separation of Concerns. This principle is often used when it becomes evident that an object needs to be re-factored into smaller distinct features that should overlap as little as possible. The term concern can be defined as a focus, interest, feature, or behavior depending upon your context. The second is called Single Reponsibility Principle. This principle basically outlines that every object/class should have a single responsibility, and that all its services (methods/functions) should be narrowly aligned with that responsibility.

So if we think back to what we're trying to do with a component-based design, we are trying to isolate and narrowly defined set of functionality or feature/behavior into classes that are as self-contained within reason. This way should we need to change the behavior of a component and its managing subsystem, we can with as little risk or need to decipher additional lines of code that have no relevance to the feature we're trying to enhance or bugfix .

Those two principles should always be relied upon and you will find it is much easier to make modifications over the life cycle of any programming project. Of course it's my opinion and others mileage may vary in how strongly they feel about those two principles. .

This is certainly a decent first pass; however here are some suggestions.

First, rather than iterating over your game entities and their components in a heterogeneous fashion, why not consider a more homogenized way. Essentially your components are also maintained by a secondary object called a subsystem. Typically subsystems manage a particular type of component and so there is somewhat of a 1-to-1 relationship. This subsystem holds a reference to each component that was created that it manages in an internal vector and when your game loop iterates, you iterate like components together. This also allows you to perform updates on your components in an ordered fashion, regardless of how they may have been inserted into your entities component vector during creation time.

class Entity
class BaseComponent
class BaseSystem
class RenderComponent : public BaseComponent
class RenderSystem : public BaseSystem

Your game loop:

void CGameEngine::update(void timeSinceLastFrame) {
  m_System1.update(timeSinceLastFrame);
  m_System2.update(timeSinceLastFrame);
  m_AnimationSystem.update(timeSinceLastFrame);
  m_PhysicsSystem.updatePass1(timeSinceLastFrame);
  m_System3.update(timeSinceLastFrame);
  m_PhysicsSysetm.updateFinal(timeSinceLastFrame);
  m_RenderSystem.update(timeSinceLastFrame);
};

As you can see above, our physics system (only as an example) performs two passes over it's components, and it could be that the system manages two different types of components as well but they need to be updated in a specific order. This approach allows us to step those entities in order. Additionally, if one subsystem finds an entity should be placed in a 'dont update me so often' state, that subsystem can move that component from one vector to another and maybe only update that secondary vector after a particular amount of time has passed while the remaining components are updated with each loop iteration.

This modular approach makes it easy to change and maintain logic and functionality in it's own little area of the world without imposing logic on your entity class during its update() method or your entity manager class during its update() method. To boot, this design typically is far more performing too.

HTH

In designing my event notification framework for my Component-based entity system, I primarily focused on inter-communication among the components of a single entity using boost signals2. I then realized that I was only scratching the surface of what my event system truly needs to represent, particularly when we start to consider full scale level design where an entity reacts to another entities' conditions.

For example, we could design a small level where there is a hallway that leads to a room. Right before the room, there is a door that is open by default. Inside the room exists a big bad boss and a door behind the boss that is initially closed. In this scenario, the entry door will want to subscribe to the bosses' ENTER_COMBAT and LEAVE_COMBAT events to trigger closing/opening the door. Similarly, the exit door will want to subscribe to a DEATH event triggered by the boss when he dies, so that the exit door will open under that condition.

In the above example, the exit door's DoorOpenTriggerComponent (or some game logic component such as a script) would have some code that resembles this:

void CDoorOpenTriggerComponent::OnInitialize() {  
  EventSystem::getSingleton().addListener(EventSystem::E_DEATH, &CDoorOpenTriggerComponent::OnDeath);
}
void CDoorOpenTriggerComponent::OnDeath(GameEvent& evt) {  
  if(evt.senderEntityId == bossEntityId) { // how would we get boss' entity id???
    m_doorState = OPEN_STATE;  
  }
}

Lets add a bit more complexity to the above scenario. Every 60 seconds our boss spawns a minion randomly in the room while it is alive. The player must kill this minion or else they'll continue to spawn and overwhelm the player. But if the boss dies while a minion is still alive, we have two options. Either the minion would despawn with the death event or the minion must continue to be killed.

Under the first scenario (despawn); the above open door trigger logic would still continue to work. However, under the second scenario, the logic would need to be a bit more complex because not only should the door open when the boss dies; but when the boss and all his spawned minions have been killed too.

How have others connected the dots in this scenario to make it work in your experience? In the above scenario, the E_DEATH event for all creatures are interpreted by the above component (which I'd rather avoid and thus have the subscription specifically only fire if the E_DEATH was related to the boss entity itself). But how does the door obtain information necessary to tell the event subsystem that it only cares about entity id X of the boss? Is this done using a parent/child hierarchy of entities with the boss being the parent and the doors and all spawned minions being children of the boss entity so that this logic can quickly traverse the entity tree and get the root entity?