Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


C-E SYSs, L2 OPTs, and the big picture


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Norman Barrows   Crossbones+   -  Reputation: 2349

Like
0Likes
Like

Posted 09 August 2013 - 03:36 PM

i've been thinking and researching about "game engines" recently. i know! bad me! i should be building games, not engines! <g>. but i have a number of titles in the works and am looking to streamline the development cycle.

 

i currently have a low level in-house "game parts" library that provides graphics, audio, timers, dice, etc.

 

i have a second library that implements an "entities list", movement, collision, and  AI which i'm redesigning for use in future titles.

 

i've been thinking of redesigning as a component entity system such as:

 

array of locations, array of rotations, array of world transform matrices, etc.

 

and a main loop like:

 

run_ai_all

turn_all

move_all

update_world_transform_all

 

there would be lists of different entity types, such as players, enemies, missiles, dropped objects, etc.   terrain and static objects (buildings, etc) would be handled separately. objects used for scripting such as triggers would also be handled separately.

 

i suppose an entity would just be a list of indexes into the appropriate arrays.

 

nice and L2 friendly - so far so good.

 

but in the big picture, graphics will still be the bottleneck. 

 

i mean, the game with the most entities in the way of just players, enemies, missiles, etc. these days is probably the Total War series, with about 2000 combatants active at once.

 

which makes me think: 

 

for a _PC_ (consoles may be different), FLEXIBILITY ASIDE, the performance gain alone for a c-e system may not be worth the hassle, compared to say, an array of entity structs where each struct holds all components, and one array for each entity type.

 

i can understand its appeal when dealing with c++/oo syntax issues, but given that a typical game will have at most 2000 or so dynamic entities, with one or two basic types in all cases ("target" - a player or enemy, and "missile" for games with non-instant missile weapons), the performance gains don't seem worth it, especially compared to the performance overhead of drawing 2000 entities! <g>.

 

note that my current "entities library" uses arrays of entity structs with all components in a struct, has two lists of entities: static and dynamic, and is implemented with C code, so no c++ syntax issues. also, i don't really care about the flexibility of C-E systems (being able to add/ remove components from entities on the fly, letting non-coders define entities via tools, etc).  so i'm really only interested in c-e for the performance gain of L2 friendly data layout.

 

and from that standpoint, the c-e optimization seems like overkill. optimizing the iteration and processing of targets, when drawing targets is the bottleneck. time better spent on shaders i would think.

 

of course, once you've optimized all your drawing, and your "total war killer" that does 10,000 guys at once still runs too slow, then it might make sense as a desperate attempt to get a few more clock cycles and maybe therefore a couple more fps.

 

but until you reach that point, it doesn't seem to make sense to use it, EXCEPT as a way to deal with c++ syntax issues and to allow non-coders to edit entities.

 

 

 

 

thoughts? comments?

 

 

 

 

 

 

 

 

 

 

 

 

 


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 10422

Like
0Likes
Like

Posted 09 August 2013 - 07:07 PM


the performance gain alone for a c-e system may not be worth the hassle

I've never heard of performance as the reason to go for a component/entity architecture. The two are really not overlapping concerns.

 

The general reason to move to a component/entity architecture is because you want to move to a data-driven model. A data-driven model can significantly speed up your development cycle, by allowing non-programmers to edit the game, and reducing the amount of time spent compiling...


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#3 Norman Barrows   Crossbones+   -  Reputation: 2349

Like
0Likes
Like

Posted 10 August 2013 - 01:43 AM


The general reason to move to a component/entity architecture is because you want to move to a data-driven model. A data-driven model can significantly speed up your development cycle, by allowing non-programmers to edit the game, and reducing the amount of time spent compiling...

 

interesting,

 

my understanding was that the benefits were three-fold, depending on implementation:

 

1.for OO implementations:  

its a way to deal with the difficulties of oo/c++ syntax and game architecture  IE class hierarchy issues and such. this tended to be the primary emphasis.

 

2. if entity types are soft coded:

its a way to allow non-programmers to create entity types without coding (IE soft coding of data, or "data driven" software, not to be confused with data oriented / driven design). but this is more a soft coding than entity-component advantage.

 

3. if components are stored as arrays of data structures, and processed all at once with no branching:

you get a "data oriented" or "data driven" design (not to be confused with soft coded or data driven software), resulting in a cache friendly data layout that can run significantly faster (on the order of 400+ clock cycles per component faster).  this was only mentioned in some places. in many places they implemented components in a manner that was as or more cache unfriendly than traditional objects.

 

 

i'm dealing with c code, so no c++ syntax issues.

 

soft coding of entity types is really only required for a generic engine or a non-coder. for a single title and a single developer, the entity types will be determined early on, will change little, and can easily be changed if needed with a recompile. really its only needed for a generic engine like unity. in a title specific engine, again the entity types will be determined and declared early on and will change little over the course of development.

 

otoh, i'm constantly adding more variables to a player or enemy struct.  but that doesn't necessitate a c-e system.   for a c-e system, you have to declare and implement the the component types in code in the "game engine". then you can create entity types from the component types, either by hard coding or soft coding. soft coding smacks of generic engine (unity, unreal, etc). hard coding entity types would be about code organization (c++ syntax woes). i think only one source used cache optimization as the reason to do it. but the argument was MOST persuasive if you use traditional c++/oo architecture (which, thank god, i do not). 

 

well i definitely don't need to implement a c-e system just so i can soft code entity types. i have exclusive source code access in my case. sometimes it nice to be an army of one.   ; )

 

and so far, arrays of structs have been plenty fast.    so it looks like i don't really need a c-e system.

 

so just how many things like c-e systems in game development are really about letting non-programmers edit the game?

 

it strikes me that a lot of effort goes into things like that (which technically only non-programmers need), and stuff like checking for errors that won't occur once the game is completed and correct, and making the game reusable and easy to modify, when you don't have plans for a sequel. in general, over-engineering things. i'm not saying c-e is over engineering, but it may be for an indie.

 

i've been debating how to split up the list of game objects/entities, etc:  

static and dynamic entity lists,

component entity systems,

separate list for missiles,

separate list for emitters, 

one big list for everything,

and so on.

 

given that c-e is more about configurability and code organization than speed (although it can be a speedup if implemented correctly), and given that arrays of entity structs are running plenty fast for me right now, i may go with one big list for everything. it would definitely simplify the design.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS