Jump to content
  • Advertisement
Sign in to follow this  
skwee

Game Entities, Up to Down

This topic is 2864 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

Hi,
I'm trying to break Game entity from up to down.
So the highest object in my game will be the Game Entity.
1. First question: Should I separate movable and animated game entities (characters, npcs) from static game entities (walls..) and from other game entities (triggers, lights..)?

Each Game entity will have its game parameters: hp and etc.
Also each game entity will have other parameters like physics parameters for physics subsystem, render parameters for render subsystem and etc.

What is more interesting for me now is the render parameters. Assume there is something that contains the entity vertices (mesh its called?), textures, material and etc.

Now what I have troubles with is building the entity up-down or down-up. I'm very confused here. This is how I see it

*Game entity will contain something like Entity render parameters.
*Entity render parameters will hold the possible textures for entity, materials, and vertices (mesh?) loaded lets say from a file.
So when you create two game entities A and B from the same render parameters (lets call it a model file like md3 of quake) the textures, materials and mesh will be created once and reused both in A and B.
*Mesh (vertices and etc) will contain Vertex Buffer for further rendering.

Am I missing something? Is something wrong? Do you maybe can suggest something to read on the topic of game entities?

Thanks a lot for help!

Share this post


Link to post
Share on other sites
Advertisement
I generally use an entity/component structure for games or game engines I work with. Have an entity with a map/list/vector of all of the components registered with it. Have most major functionality accessible through the components.

Each component is responsible for an interface to a major function of any object. So, to interface with rendering aspects of your entity, you would have a RenderComponent. The render component would have all the functions needed to interface with your render mesh. Similarly, for physics, you would have a PhysicsComponent with all the functions needed to interface with your physics body.

Also, to keep your different components and interfaces from being too tightly coupled, I highly recommend a messaging system. A message system allows you to send messages between entities, or between components on a single entity, without having to include all kinds of headers or have other developers know much about the underlying functionality of each component class.

I would recommend against putting any render info into the entity class itself if that is indeed the lowest level base class. For example, some entities may not render at all, like an invisible trigger volume that could react to a player or other object entering it. Same with something like physics, because some models may only need to render and never collide with anything. The entity should be fairly empty IMO, and exist mostly to give a common interface between all components on the entity, as well as do things like call some kind of Run() method on each component each frame.

Here's the full source/demo of the last engine I worked on, it uses an entity/component hierarchy and messaging system. Feel free to look at it if you'd like:
http://quickstartengine.codeplex.com/

Share this post


Link to post
Share on other sites
Thanks, that sounds great!
But I still feel that Entity as I see it, is wrong. I.E. there should be more higher entities like MovableEntity, StaticEntity. Am I correct?

More suggestions on this topic will be helpful.

Thanks!

Share this post


Link to post
Share on other sites
Quote:
Am I correct?
I would say no.

In a component-based system (which I would recommend over a more traditional inheritance-based system), there's no need to create different 'named' entity classes like MoveableEntity, StaticEntity, etc. An entity's characteristics and behavior is defined by the components that make it up, so there's really no need to also have multiple entity classes with different characteristics. (In fact, that would largely defeat the purpose of using a component-based system in the first place.)

Share this post


Link to post
Share on other sites
Yes jyk you are right!
It was my mistake. A static entity is simply an entity without the AnimationComponent in it.
I think I start to understand how it works!
More comments welcomed!

Edit:
One more question. Assume my entity system is component based now, and one of the components is PhysicComponent which contains the position of the entity in the world. My scene graph no longer needs to hold the position for nodes? How do I tie the entity with scene graph?
With the old design of entities without components, I'd have a SceneNode with position and entities attached to it. What do I do in the new approach?

Thanks once again.

[Edited by - s.kwee on July 20, 2010 3:16:26 AM]

Share this post


Link to post
Share on other sites
Quote:

One more question. Assume my entity system is component based now, and one of the components is PhysicComponent which contains the position of the entity in the world. My scene graph no longer needs to hold the position for nodes? How do I tie the entity with scene graph?
With the old design of entities without components, I'd have a SceneNode with position and entities attached to it. What do I do in the new approach?

Thanks once again.


Position and rotation are two of few things I end up putting into my Entity class. I felt that whether or not an object has physics or a render component, it may still need a position. I have cases where objects have either physics or render, but not both, and if I had put position into the physics component I would've had no position without having physics.

In my Run() method in the PhysicsComponent I ask the physics body what its position is, and I set the Entity's position to whatever that is. I do the same for rotation/orientation. This allows the physics simulation to move the Entity. Conversely, if the Entity's position or rotation is changed from a non-physics method, I end up pushing those changes to the physics simulation.

Share this post


Link to post
Share on other sites
Quote:
Why not having PositionComponent for example?
You could do that if you wanted. How far you want to go with the component system (and how granular you want to make it) is really up to you.

Personally though, I wouldn't bother having separate components for position, orientation, etc. IMO, it makes more sense just to have a single 'transform' component.

As to whether the transform component should be 'optional', that's also up to you. To really go all the way with the 'component' paradigm, you would probably make it optional (after all, there could easily be a game entity - such as an entity whose sole responsibility was to play a background music track - that wouldn't need a transform component). Like lordikon however, I've found it convenient to make the transform component intrinsic to the entity. (In my system it's still a component like everything else, but it's added automatically and all entities have one.) Other component-based systems I've seen seem to handle this the same way.

Share this post


Link to post
Share on other sites
Thanks jyk!
I also tough about doing a force add to the position component, simply because I couldn't find an example for entity that does not have position, but your example of the background music proofs the opposite.

I'm definitely going to think more over it, and probably even draw it, before I start to code.

More comments are welcomed!

Share this post


Link to post
Share on other sites
I've chosen to use a PlacementComponent which provides the global (i.e. world related) position and orientation as both vector / quaternion and composed matrix. Any automatic changes to the placement is done by a plugged in Controller instance. I'm used to define the traditional parenting (i.e. a local space) also by a Controller, namely the ParentingController (you guessed it). However, that is another story. The placements itself are managed by a subsystem called the SpatialServices. This is fine because a dense storage of related data structures gives normally a good cache usage (if the entire batch can be updated at once). The SpatialServices drives the update of the (obviously non-static) placements by invoking the plugged in Controllers. It further allow queries for vicinity of objects and such things.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!