Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Edding3000]

Hi cameni,

As you might know (i've said it a few times before) i'm busy with my own engine. It seems that you and i are doing completly different stuff. Your'e very busy with terrain and atmosphere's where i'm quitte busy with lighting, effects/materials, scenegraph's (for eventualy animation), spatial searches and so on.

Are you interested in some idea's/code/solutions of others? If so i would gladly share these with you.
Also if others are interested i'd be happy to share some of my knowledge of these subjects!

[cameni]

Do you have a blog or something like that where I could read more about your engine and the techniques you are using? I like to read about stuff people are working on, sometimes finding nice or ingenious ideas in it. I think it's a good idea to set up such a resource for others to find when they need it. Usually when I'm going to work on a particular engine component I google the topic, but there are few blogs that I read regularly just to catch those ideas to be stored on the background for later use.

[Edding3000]

Just to give a brief update on my own work. Because i'm a hobbiest i dont have a deadline, and that leaves room for experimenting (a lot).

I've begon working on sort of a new system because my current engine is kind of a mess... The result of experimenting and failing utterly.
Although some very nice programming has come out (which can be re-used of course).

My new project is to make a kind of a entity/component type engine, in which entities are defined by a list of components. Entities are just containers for components. Components have properties and event handlers. Components can subscribe to other components for event listening.

Subsystems implement the logic for the components. And they also can subscribe to components to listen to messages.

The problem is the overlap between components, which makes it hard to create subsystems 1:1.
For example: the Rendering SS needs a Orientation, Position, Bounding, Rendering, etc component.

Well, i'll keep things updated here a bit (and maybe show some).

Here a peek of my (former) not-engine planet renderer:

[cameni]

That looks good. Why did you decide to make an engine out of it?

The entity/component model (as described for example here) is certainly a way to go, although it can have many approaches. We often use code generators for various stuff, so I guess we'll use one for the game entities too. As I said also elsewhere, our engine is rather monolithic, an optimized special purpose world renderer.

I would certainly not break the components to such small atoms like a separate Orientation and Position.
Another thing is that the engine should be designed to allow for effective batch processing in rendering (or physics; anything that can be processed in parallel on GPUs), so the componentization should reflect that too. It will probably require a clever management of entities' data.

[Edding3000]

That looks good. Why did you decide to make an engine out of it?

The entity/component model (as described for example here) is certainly a way to go, although it can have many approaches. We often use code generators for various stuff, so I guess we'll use one for the game entities too. As I said also elsewhere, our engine is rather monolithic, an optimized special purpose world renderer.

I would certainly not break the components to such small atoms like a separate Orientation and Position.
Another thing is that the engine should be designed to allow for effective batch processing in rendering (or physics; anything that can be processed in parallel on GPUs), so the componentization should reflect that too. It will probably require a clever management of entities' data.

I've given things some more thought and have decided to go for this way:
components register to some sort of interface for the subsystem. For Example: RenderInterface. This renderinterface manages the required component and lets the subsystem access them, without knowing of the components.
In this way you can easily decide to add another component to the interface and implement it in the subsystem.
The rendering subsystem would for example render but would also sort and batch the geometry.

I do like the idea of a seperate position component because the components in my implementation arent actually components. They are data containers with events, that can communicate to other components, and subsystems, via a broadcast/listener system.
So the entity is nothing more than a container for components (nothing else).
The component have functions/properties ONLY for variables, and events. (they are like property/event containers)
Components register themself not to a subsystem but to a interface.
This interface handles communication from the subsystem to the component. (and of course a component can send a message when the subsystem decides to change something).

So for example:

- Entity
  - Name
  - ID
  - Decription
  - List

- Component
  - Name
  - Owner (EntityID)
  - Properties/Fields
  - MessageHandling

- Interface
  - properties (setters/getters) that handle components
  - It also manages things like: what if entity does not have component, etc etc.

- Subsystem
  - System where logic is.
  - Gets it's data from a list of interfaces
  - Does not need to check if components exist or not, interface handles this.

I think this will give a very solid base to build a engine upon. The main problem is to be very careful with selecting components, and what's in them (not too generic, not too vague).

[knackered]

well I think having an entity/component system is one thing, but you shouldn't tie it to the rendering. Rendering is a separate, much simpler task than such things as serialization and synchronization of components, RPC-type functionality etc.
Steer clear of scenegraphs, they're a blind alley. Graphs are useful for things like database synchronization etc., propagating changesets etc., but not for rendering. Keep the renderer as simple as possible, and keep it as far away from your entity system as possible.

[Edding3000]

The renderer itself is not in the entitySystem.
The rendering component (with parameters) registers itself to the renderer (rendersubsystem).
RenderSubSystem deals with the rendering of components.
PhyscisSubSystem with the physics. etc...

These subsystems use components indirectly, because they will only use some sort of interface class which handles what components are needed by the subsystem.

It has to be done this way. Otherwise how should i know who i need to render, and more specific: what should i render?


See it like this:

Entity: Player
Components: Position, Geometry, Render

Now the render component creates an interface. This interface knows what the rendersubsystem requires. It will search in the componentmanager for required components that have the same entityID and will include them in the interface. This interface is then registered to the rendersubsystem.
The subsystem doesnt even know it is communicating with components, it just communicates with the interface.

1. The rendering component creates interface and registers to it
2. The interface finds additional information (components) if required (position, geometry)
3. Interface cannot find bounding volume -> not needed -> set to null (or something)
4. the interface 'registers' to the subsystem (rendering)
5. rendering subsystem just goes rendering each frame. It uses the registered interfaces, and has all information it needs!

I think this is a good way to make sure components are not directly referred to by the subsystems.
Subsystems just do stuff with the interfaces.
Interfaces find info for the subsystem.


I've seen some other component based engine designs but they are all very complex and in my idea a completely messy system.
I try to simplify this by using some sort of hybrid variant, where you just create an entity, add some components with parameters, and the fun can begin!