Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Give yourself some flexibility with Component-based Game Entities

Author
Message
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Aug 2011 17:20 Edited at: 5th Aug 2011 02:43
Discovered about a week ago that I was implementing a Component-based Entity System for S3GP's Game-User Interactivity System. I had no idea that paradigm already existed. From my research component-based entities are popular amongst the Commercial Game Developers such as Gas Powered Games (Makers of Dungeon Siege).



The main advantages to component based entity systems are:
1. No programmer required for designers to modify game logic
2. Circumvents the “impossible” problem of hard-coding all entity relationships at start of project
3. Allows for easy implementation of game-design ideas that cross-cut traditional OOP objects
4. Much faster compile/test/debug cycles
5. Much more agile way to develop code



My approach to component-based entities revolves entirely around the Graphical User Interface System IOU.
Interested in getting started with Component-based Entities? Take a gander at Cistron: an open source component-based object framework: Forum|SVN|Example.

References: 1,2,3,4,5

JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 8th Aug 2011 06:06
Hello, TechLord.

I myself have been researching the same concept for about the last month and a half or so. I'm not convinced that this approach is the correct one for a couple of reasons. As such, if you don't mind, I'd like to start a discussion - if for no other reason than to get your opinions!

First off, I've checked out those sites you provide (thank you) as well as some others for other's to reference too. I am only now able to respond due to the passing of my mother... Anyway,

The Component based game engine design had led to my second: the Elephant Game Framework.

A third, by Scott Shumaker (I don't recall how I found it); and another two part series: Component Based Entity System Design Part 1 and Component Based Entity System Design Part 2. There were others, including Why I switched from component-based game engine architecture to functional reactive programming (which, admittedly, even with my further research I still don't quite understand).

Anyway, it seems to me that the whole idea of Component-Based-Entity-Design is just a stripped down version of Microsoft's Component-Object-Model (remember QueryInterface(), Addref() and Release() - that they tried to force down our throats in the early '90s?) - DirectX was built upon it! Back then, they were pushing for Aggregation as opposed to Inheritence - which appears to be the same concept that CBES is striving for...

Furthermore, while I agree that the Visitor Pattern is truly inefficient; the Observer Pattern seems (to me) more appropriate, even though that the proponents of CBES see the Observer Pattern is inadequate.

Isn't this *really* what's happening? Observers ("components") are "listening" for changes in their parent object's state-changes?

Why should I consider CBES over Observers/COM objects (besides the provervial smart_ptr<> implications?


Just some thoughts that I've been thinking,

JTK
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 8th Aug 2011 07:53 Edited at: 9th Aug 2011 12:52
Hi JTK,

My condolences to you.

To kick off the discussion, let me say that I'm not a hardcore paradigm guy. I intermix multiple programming paradigms and patterns to achieve goals. Components can use OOP, and OOP can use Procedural Functions. So for me, there is no `correct` way, I'm just looking for one that is flexible, easy-on-the-eyes, and gets the job done. The DOSP project is open-source, and its my desire for the Engine Framework and Scripts to be easy for new C++ programmers to digest. C++ Gurus can tweak to their hearts content.

I sorta stumbled into Entity/Component Model by accident while developing my 100th iteration of 3D GUI. My GUI utilized event handling, messaging, and process optimizations that I figured all Game Entities could use. At that time, I thought I had come up with a completely new concept. I called it Interactive-centric design. I later discovered that the concept already had a name and was adopted by some commercial development houses as the Entity Component Model.

Messaging is key and I was under the impression Entity Components implement the Observer Pattern. Even if its not, that is the approach I'm going to use. I'm looking into Signals and slots Implementation. As far as can tell Entity Components for Games are not directly byproduct of CBSE.

I started to write S3GP's Components System today and I have to say that I'm excited about it. Components will make the Engine Framework way easier to manage/modify and simplify the process of creating various Game Entities. This puts S3GP one step closure a professional engine design in my opinion. I'm designing my Components based on the following paradigm definitions:

* Entities, which are just global unique IDs (usually implemented as integers for obvious reasons, but they can be anything that can uniquely identify each one).
* Components, which are chunks of data (equivalent to structures in C/C++ like languages, or classes with no methods in languages like Java that force OOP).
* Systems, which drive the whole program. These are normal OOP classes. Each system ideally operates on all components of its type, for example: the Render System will probably operate mainly on Render Components (of course this is just ideal, as you'd probably have some other components to take into consideration, like a Position, or Animation, or whatever).



I'm rewriting all of the Engine Framework to use Components. Here is my current untested work in progress:

Component Declarations


Systems Component Class Declarations


Framework Construction


TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 10th Aug 2011 17:14 Edited at: 21st Aug 2011 16:28
I'm closer to electing the publish/subscribe model for message handling. The Intercom is implemented as a specialize entity component (module).



1. Create a Channel.
2. Build Subscriber List on Channel; Channel Maintains list of of Subscribers.
3. Build Message.
4. Publisher Submits Message to Channel.
5. Channel Pushes Message to Subscriber's Message Queue.
6. Clear Channel.

JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 11th Aug 2011 05:45 Edited at: 11th Aug 2011 05:55
Here's my boggle with this setup:

First off, presumably you have a publisher that creates a channel that specializes in some *cluster* of messages such as PhysicsCollision Messages for example.

Next, you have a subscriber that registers itself with the channel to receive those PhysicsCollision Messages.

Have I got it so far?

Questions:

Given then, that the publisher / subscriber are independent of each other, and in-fact may know nothing (*don't worry, more to come - please keep reading) about each other; then how can we assume that a publisher *knows* that there is one-or-more subscribers listening for them?

Furthermore, again, given that they don't know of each other, how can a subscriber be sure that *something* will be publishing those messages that it needs?

Finally, why should the publisher be posting messages when there is *nothing* in the system that cares?

Why-Nots:

First, there is an implied relationship between the publisher and subscriber - via the Channel. Both the publisher and subscriber needs to know that such a channel *should* exist. Taking this route means that you are creating a stronger-coupling between the publisher and subscriber that should know nothing about each other but both are required to know about even the *generic* channel - which can't be too-terribly generic *if* both know that *the one* exists that suits their needs...

Secondly, we both know that having a publisher posting messages when there is *nothing* system-wide that cares about it is a waste of valuable resources: CPU, Network-bandwidth etc...

This situation can best be described in the Publish/Subscribe link the you provided above:

Quote: "As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones. These manifest themselves as instabilities in throughput (load surges followed by long silence periods), slowdowns as more and more applications use the system (even if they are communicating on disjoint topics), and so-called IP broadcast storms, which can shut down a local area network by saturating it with overhead messages that choke out all normal traffic, even traffic unrelated to pub/sub."


Take-Aways:

I just wanted to give you a little more fat to chew on before you commit to a design philosophy. As I have been keeping up with your DGDK Open Source Project something tells me that this is not going to be what you need - given the goals that you have set for yourself!

I do have ideas that I am trying to formalize - but at this point, I can't do much to describe them...

What I can say, if you think it will help, is that you are on the right track with the Component-Base-Game-Entities. Only I think that we need to think of those *entities* (read Game-Objects) more as what they really are State-Machines (or more specifically: Hierarchical State Machines).

In that sense, my thinking is more like "Component-Based-State-Machines" where *most* of the ideas are the same but instead of *components*, we're really dealing with *states* that can change dynamically.

As I said, I can't do much to describe them...

I have been searching, for a few days now, for an article I read about two-years ago that I think will help me formalize this concept. I can remember bits and pieces of it; the bits and pieces that, at the time, I thought was a waste of energy but have now began reconsidering. I'm not sure if the article will help to explain what I'm thinking but for some reason, it's ringing a bell...

Like I said, just something to think about before you commit...


JTK
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 11th Aug 2011 14:34 Edited at: 12th Aug 2011 13:17
Quote: "Questions:

Given then, that the publisher / subscriber are independent of each other, and in-fact may know nothing (*don't worry, more to come - please keep reading) about each other; then how can we assume that a publisher *knows* that there is one-or-more subscribers listening for them?

Furthermore, again, given that they don't know of each other, how can a subscriber be sure that *something* will be publishing those messages that it needs?

Finally, why should the publisher be posting messages when there is *nothing* in the system that cares?"


Events trigger Messages. I failed to mentioned my Engine revolves around its GUI and you can manually wire up channels and messages from entity-to-entity in script. The system is also suitable for inter-communication between components. I would suspect these channels to be dedicated to the Entity. I just have to figure out what the messages will be.

Quote: "As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones. These manifest themselves as instabilities in throughput (load surges followed by long silence periods), slowdowns as more and more applications use the system (even if they are communicating on disjoint topics), and so-called IP broadcast storms, which can shut down a local area network by saturating it with overhead messages that choke out all normal traffic, even traffic unrelated to pub/sub."


My messaging is based on the pub/sub pattern but implemented in similar fashion to the Observer pattern in code. I believe the quoted disadvantages apply to Pub/Sub Web Application's which are not applicable to my implementation.

TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 11th Nov 2011 13:36
The starter framework for XMLFile & File Component is completed. In fact I redesigned the implementation of the XML Parser with improved flexibility and features in the process Moved on to Goal A::Task c of the S3GP Roadmap: Integrate OgreBullet (BulletPhysics) for Components to replace Box2D 2D Physics, add 3D Physics. It presented a small challenge in the setup, but, its coming along nicely.



TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 17th Nov 2011 13:55
I'm curious if anyone has attempted to implement Component-based Game Entities with DGDK. In my opinion, DGDK does a good job of compartmentalizing its library for objects (dbLight, dbCamera, dbMesh, etc) for components and using integer IDs for referencing Game Entities and their components. This is a pretty powerful architectural design pattern and worth discussion.

Mr Bigglesworth
16
Years of Service
User Offline
Joined: 4th Mar 2008
Location:
Posted: 17th Nov 2011 15:29
Well, currently I would like to start experimenting with Cistern, it looks like a pretty cool system.
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 6th Jan 2012 21:13 Edited at: 6th Jan 2012 21:15
The Summation of Entity Component Objects

1. Gizmo = Shape + Sprite + Sound2D
2. Pointer = Shape + Sprite + Mouse
3. Key = Keyboard
4. Keyboard-map = {Key} + {Key} + {Key}
5. 1st Person Character = (CharacterController + Camera + Mouse + {Keyboard-map}) + (Mesh + Shape)
6. 3rd Person Character = (CharacterController + Camera + Mouse + {Keyboard-map}) + ((Mesh + Shape) + (Mesh + Shape) ...)

Login to post a reply

Server time is: 2024-11-19 04:36:48
Your offset time is: 2024-11-19 04:36:48