Sign in to follow this  

Engine Restructure

This topic is 3105 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on the engine for my next game and so far thought that it was structured properly but as I code more I realize some items aren't in the correct spots. I'm going to take this weekend and clean up the structure but before then I'd like to get some input on one piece of it. I have an Avatar class that is a child class of Character. Currently I'm testing collision and have it implemented within the avatar class though I know this isn't the right spot and can't think of where a proper spot would be. Possibly in Character? Also, I'm eventually going to have all the design elements to code in (level, HP, etc...) Would it make sense to create a CharacterInfo class and attach that to the Character instead of putting all the data inside Character? (I suppose that's partially over classing it when that could all be inside Character and inherited easily since all characters will have those properties) I'm at work now but later tonight/tomorrow if I have any other structure notes I'll mention them. Any input is appreciated.

Share this post


Link to post
Share on other sites
My suggestion would be to componentize everything.

For example your character collision. You should have a character collision class, it's a part of your physics library. By instantiating one of these objects and registering it with the physics engine, the character collision object will interact with the world.

Then in your character object class, you maintain one of these character collision objects and extract and inject data into it as necessary.

For ex:

struct CharacterObj {
CharacterPhys physicsBody;
GraphicsMesh graphics;

CharacterObj() {
//you're gonna wanna register it to a specific system
PhysicsSystem::RegisterBody(&physicsBody);
RenderingSystem::RegisterRenderable(&graphics);
}

void Update(float dt) {
//very simple example
graphics.Transform = physicsBody.Transform;
}
};

As you can see, CharacterObj has no idea about how to do collision, or wether or not the physics body is even being updated. All it knows is that the resultant transform from the physics representation is where the graphics representation should be.

You could very easily add more components to the CharacterObj for stats as you mentioned, and network presence, input system. The character object should be thought of as an Entity and could be written like this:

struct Entity {
std::vector<Component*> Components;
};

Merely a collection of components which are all simply "keys" into their respective system. The CharacterPhys is just a key into the physics system. The GraphicsMesh is just a key into the graphics system, likewise for input, networking, scripting, sound, effects, animation, etc. All that would get very complicated if it were all implemented in the character.

When you compose things with components it's like building blocks that can be reused as often or as little as you want.

Share this post


Link to post
Share on other sites

This topic is 3105 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this