Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 01 Oct 2012
Offline Last Active Oct 24 2016 03:48 AM

#5314135 Game Engine Questions (ECS)

Posted by on 06 October 2016 - 08:34 AM

By what is needed, I meant it passes a list of class references to its super constructor.


The system manager uses this list when you add the system to the manager, and checks to see if all systems in the list already exist in the system manager. If yes, it activates the system, if not, it doesn't. It rescans this every time you add/remove a system to the manager.


The system itself can only access the other systems through the system manager.


Systems being dependent on each other can happen for different reasons. A bad reason (one which I use though) is performance. Sometimes direct access to system specific data is faster, and easier. An example would be a PhysicsSystem and a BulletSystem. The BulletSystem would require the PhysicsSystem, and get a reference to it when activated. That way, it can directly do raycasts on the physics space within the PhysicsSystem, as opposed to somehow raycasting through creating entities and components etc.


It's both faster, and probably more understandable / debuggable.

#5314106 Game Engine Questions (ECS)

Posted by on 06 October 2016 - 05:30 AM

I've explored the ECS route for a while now, but haven't yet completed anything substantial - just a tip, my main bottleneck was trying to structure really low-level concepts within the ECS, I even tried to have VertexBufferComponents at one point, that was a dark period in my life. I now aim to have an engine running without the ECS, and the ECS is a high level layer over the concepts in the game engine. Now I have a SpriteComponent and either ImageComponent/ColorComponent, which is still relatively low-level, but works for now, trying to minimize that further.



I think the most important concept to understand in ECS, is that an Entity isn't an object itself, conceptually. It's main purpose is to just be an ID that ties groups of components together. How this expresses itself in my design, is that much like the systems/entities concept, which is the main/popular attraction of ECS for most people, the same inversion of control applies to entities and components.

I have a ComponentManager that has arrays of all component types (I use the class name itself, via reflection (not C++, but this still applies)), and each of those arrays are sparse arrays, where the component for an entity can be accessed via the entity id. The result is a 2d arrays, though I have a specific manager for each component type as well. In the simplest form, component access is:

`var componentA = types[componentA_ID][entity_ID];`

where componentA_ID is the id assigned to the ComponentA type, and entity_ID is self explanatory.


At this point, entities are purely integers, which is the case in my engine. They aren't objects. I have a helper class that wraps an entity id, and gives convenient component setters, but this is just an optional utility. I don't think "an entity OWNS components", but "there are components, and they are assigned to the same ID". Maybe that can be phrased better.


This way you have more control over component storage, rather than them being tossed around in Entity instances. Also, this gives you a centralized entry point into your components. In my system, View objects "attach" to the component containers directly, which ever ones they need:

`var view = new View<ComponentA, ComponentB>();`

That view would go to the component manager, and get references to the containers responsible for the ComponentA and ComponentB types. Whenever a ComponentA or ComponentB is set on an entity, the view is notified of the change, and it checks the entity if it's valid (in this case, if it has both ComponentA and B assigned to it). This way, setting ComponentC on an entity has no effect on the view, it doesn't care.This combined with keeping a bitflag for each entity of what components it has, means any changes to entities get propogated immediately to views, and only ones that care, for minimal cost.


To sum up my gibberish, component access is direct, no looping or anything, via the component_type_ID and entity_ID. (entity == entity_ID in my case).

Views selectively subscribe only to relevant component change events to keep a list of valid entities. (so, also no looping through entities at runtime to get the relevant ones)



Sort of relevant to the above, the concept of ECS for me is really just EC, and the S is an optional helper for structuring functionality. Technically, systems don't need to be actual objects, they just refer to pieces of logic that process entities (you could have an ECS-based game written totally in your main function, but that would be messy).


Anywho, I do have a system API to keep track of things. They extend a base class, and have 5 callbacks:

onInitialize, onActivate, onUpdate, onDeactivate, onDispose

The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose, and the delta_time gets passed to onUpdate.

The initialize/activate things are sort of specific, but initialize gets called when the system is added to the system_manager, and activate gets called when the system will actually start running. This is important, because my system_manager handles system dependencies - when declaring your system, you call the super constructor, passing in a list of system classes it requires. When the system_manager has all required systems added to it, then it will call the activate callback, at which point your system can get references to the required systems through the system_manager...did that make sense?


Generally my systems have a bunch of the above View objects, and they get initialized in the onInitialize callback, so I don't need direct references to the entity_manager (which is accessible through the system_manager). (BTW - the entity_manager holds a reference to the component_manager, so essentially: system_manager->entity_manager->component_manager)


This way, the system purely cares about itself, codewise/internally, but gets the references to the outside world and other systems through the system_manager, passed to the init/activate callbacks. If a system doesn't need the references during its update callback, then it doesn't even store a reference.


Not sure about your 3rd question, I haven't personally used octtrees in-depth.


I hope my splurge helps you...it's basically a raw braindump. I am by no means an expert, but I've gotten to this structure over several iterations of trying to make something with an ECS - the direct system to system communication was a big one, earlier I tried to do a pure hardcore approach where ALL inter-system communication should happen via components.



#4986319 Why games should be challenging?

Posted by on 03 October 2012 - 02:51 AM

You mix lots of things that it is difficult to understand your backing points...

First, you say that a player will play the first FPS they buy, but after playing many, they'll throw them away and not want to play anything similar. Then you admit that lots of players like FPS's, CoD and Battlefield, etc.. that don't have much challenge in learning (though they still have lots of challenge that is expressed through situations that happen because of the game mechanics (Unique stand-offs between players in some random location)). Rather than seeing that as a problem, I simply see that as defeating your argument.

Second, you get into the tangly world of "real games". How can you define a real game? Why isn't a real game the infinity runners, the physics shooters, the physics construction? Even while I don't agree with your definition of a game, Angry Birds still qualifies. The player learns the mechanics of the game, and what to do, and later on, the many levels are all tests on how much he has learned the mechanics. Your definition is extremely non-exclusive, but in my opinion at the same time limiting, since it enforces the common view that all games are meant to be built around being FUN, ENERGETIC, and CHALLENGING! (some are, some aren't at all)


#4986040 A Unique FPS Game

Posted by on 02 October 2012 - 06:42 AM

-A good gameplay with great mechanics
-A great story with an awesome voice acting
-I'm an Art guy so, graphics, unique, artist and "realistic in its own way"
-Competitive Multiplayer
- And for last, in single player games, Affection for the characters... the thing that I like the most in Metal Gear Solid.

Your idea to make a great game is "to make a great game"...You haven't even brought any ideas to the table yourself yet. Do you really think that all game designers and developers try to make another CoD? Have you seen any of the amazing, unique indie games already out there?

What I'm trying to say, is "making a great game to bring back PC gaming" isn't a crazy new idea you just had, it has been the main goal of 99% of developers since gaming started.

Offer something specific, or this thread has absolutely no point at all.