>>103288244
std::array

>>103288244
ECS is the last thing you should reach for, but there are no "alternatives" to ECS if you NEED what ECS provides

>>103289933
I mean what do you use for a small game that might scale up in the future?

>>103290091
Most indie games don't need anything beyond god objects. At the end of the day, all your objects are just blobs of data. No reason to treat them as anything else.

>>103288244
just go with data-oriented design and don't think too much.
Place all your game data inside structs. Use functions that'll call the necessary struct by reference and make changes to the struct as needed. Any performance hits will depend on how well you arrange these structs together a.k.a proper memory allocation strategy.

>>103291403
aren't you supposed to go with structs of arrays rather than arrays of struct?

I was thinking about having one giant scene struct which contains arrays containing all my component data. transforms, meshes, velocity etc... then have functions that operate on them as arrays.

but again sometimes you need component data grouped in different layouts for different systems to make optimal usage of CPU cache. ECSs address this issue with archetypes. but that's too complicated for my game I guess.

like the render system for example needs data in this layout

{{transform, mesh, texture}, {transform, mesh, texture}, {transform, mesh, texture}, {transform, mesh, texture}}

the physics system might need data in a layout like this

{{transform, physics, rigid_body}, {transform, physics, rigid_body} , {transform, physics, rigid_body} , {transform, physics, rigid_body}}

etc...

so this solution is not optimal

struct scene {
  std::vector<transform> transforms;
  std::vector<physics> physics;
  std::vector<mesh> meshes;
  ...etc...
};

>>103291471
just don't do anything obviously dumb and don't worry about it THAT much.
There is no solution that is optimal in every way in every scenario.
Maybe rendering takes 20 times as much time as running game physics, in that case optimizing memory layout for game physics would just be wasted effort.

>>103291471
>aren't you supposed to go with structs of arrays rather than arrays of struct?
this always depends on the problem and that is what I meant by proper memory allocation strategy.
>so this solution is not optimal
for the situation you mentioned, maybe not but it is in Odin language though. Check out the below link. The programming language will manage the memory as structure of arrays while still allowing you to use usual array of structs syntax.
https://odin-lang.org/docs/overview/#soa-struct-arrays

>>103291471
in some cases SoA might make sense but usually you don't work with just velocity or position, but both

>>103290091
OOP duh

>>103288244
ECS was invented to avoid multiple inheritance so... Multiple inheritance.

>>103290091
I use a tagged union.

has anyone ever done a multiple inheritance code-base before? its actually kind of comfy
I secretly enabled multiple inheritance in the compiler for an embedded project at work and wrote the entire on device system using multiple inheritance and OOP, fuck it!

>>103292145
isn't that terribly slow

>>103292182
not at all

>>103292182
There is nothing inherently slow about OOP. Unless you take theorized perfect ECS implementation as your standard.

depending on your requirements your ECS can just end up with your own runtime implementation of inheritance squatting ontop of it anyway, people too much act like the next great thing is just better in all cases and the previous design was a mistake or blunder

>>103290091
just do

typedef 
struct entity {
 int type;
 ...etc...
} entity;

and then

entity entities[ENTITY_MAX];

this is good for 99% of all games. If you're going to have a lot of bullets then make a bullets array too just for processing those.

>>103292405
polymorphism requires virtual function calls with are slower than normal function calls.
Polymorphism also requires more memory indirection through pointers since you can't store structs of different sizes in an array, which worsens cache locality.

>>103293798
And that still is going to have insignificant overhead at the end. There are more more important optimizations to do before you should start worrying about things like that. Do not do premature optimization, making games already takes huge amount of time.

>>103293958
I would generally agree with you, except that polymorphism is not a useful abstraction.
Not doing polymorphism isn't doing premature optimization. Its just not doing stuff inefficient stuff for nothing but making your code HARDER to reason about and harder to make performant.

And on a larger scale it absolutely does affect performance.

>>103290091
you know you can just make the array larger or create more arrays, and use multithreading for those right?
and what the fuck does "scale up" mean for small games? not a single game can scale infinitely, and all those who can handle impressive amount of game entities use compute shaders and multithreading.
if you mean multiplayer games, those have a widely different structure, and even then there's a hard limit on how many you can handle at once.

>>103294014
>except that polymorphism is not a useful abstraction.
how to tell everyone you've never written a complex program before

>>103290091
99% of games are one and done programs that don't need security hotfixes and endless corpo feature tickets.

>>103288244
Nothing because components are easier to reuse and modify over a clusterfuck of inheritance spaghetti where you touch one thing and you break ten. For games, where constant iteration is a must, composition wins over inheritance.

>>103293798
none of that matters. stop larping as oooptimizer, you're only slowing down your progress.

you need many thousands objects on screen to drop performance for most basic naive render loop where you switch context for every object.
you're not making AAA game. just stick with
class GameObject {
virtual void update();
virtual void draw();
}

>>103294737
>you're not making AAA game
AAA games use OOP

>>103292921
Agreed.

I've had projects that successfully scaled up through 32K objects active in a single scene, using that basic approach, without dropping frames. CPUs are hella fast these days; they don't even flinch at z-sorting that many objects.

>>103294748
I see no reason why ECS and OOP would be incompatible. The OOP bits could be typed wrappers around indexes into the ECS main storage, and (after standard levels of inlining) the code would work the same. Just because you have a class doesn't mean you have to keep all the data there.

>>103294788
>Just because you have a class doesn't mean you have to keep all the data there.
that's kinda what a class is, it contains data and methods

>>103294798
and said data could just be an index to your ECS system, please sneethe

>>103294807
Then what's the class for? Polymorphism? That goes against the grain of what ECS is supposed to do

>>103294821
ECS is just a allocation technique with a ton of mysticism surrounding it, you can do whatever you want anon

>>103294828
>ECS is just a allocation technique
No it's not, what do you think the Systems are?

>>103294737
I actually care more about the semantics than the peformance.
That the performance is better by default and easier to optimize without polymorphism is just further validation that its the right way to build things.
virtual void update(); and virtual void draw();
might seem nice at first, but they insidiously introduce restrictions and obscure things from you.
Data oriented approaches are not just more performant but also simpler and therefore easier to work with when considering the whole system, and not just individual entities.

>>103294798
In OO a class should explicitly not be understood as a data type.
It's a THING that you communicate with by sending messages. Which langs like C++ and Java mistakenly interpret to mean virutal function calls.
In OO, data ought to be "encapsulated" which is just a euphamism for obscured.

>>103294748
lead engine dev at Insomniac games seems to disagree

>>103294841
an allocation scheme implies an access scheme dunce

>>103294859
we've all seen the talk, and he doesn't work there anymore. also no one in this thread is writing AAA videogames for consoles.

>>103294859
>lead engine dev at Insomniac games seems to disagree
You are aware there's more AAA developers than Insomaniac games?

>>103294865
No it doesn't
You can allocate components in arrays then you can access them however you want, that's not ECS
It's ECS when you use systems with those components in the arrays

>>103294877
'systems' can be implemented in anyway you like, the only commonality being that they access the data that is stored as 'components' for cache locality. All of ECS design is centered around an allocation technique, like I said, and you refuse to admit because it makes you look stupid.

here's another one for you, the allocation scheme also implies 'entities'. mind blowing right?

>>103294899
You don't understand what ECS is
Systems are a specific thing which work in a specific way

>>103294921
post your ECS engine and ill post mine, we can compare notes

>>103294877
yeah and most of those don't use OO
Some definitely do, but hell will freeze over before you can prove just a correlation between "game studios that rely on OO for their game engine architecture" and "success".

>>103294929
I've never made one, ECS is stupid architecture, I'm just telling you what it is

>>103294932
>yeah and most of those don't use OO
Literally all of them do, even the few that use ECS

>>103294936
I understand what 'ECS' is better than you because I've actually written them from scratch and used them. go die pea brain

>>103294940
proof next thread?

>>103294944
This isn't something that requires experience, it's a simple definition. You can write code without knowing what ECS actually is, which you apparently did
Systems are functions which operate on tuples of components, they iterate over every row/entity that has all the required components. This is the S part of ECS

>>103294956
Do your own research you idiot

>>103294014
Having abstract classes like Entity, Enemy, BossEnemy, Pickup, etc and deriving from them is one of the most intuitive ways of managing game logic. Sure, you can hand roll everything into switch/function pointer spaghetti or fall into ECS meme but every hour spent doing that is a hour not spent improving your gameplay, characters, art, story, etc. Computers are fast, there is very good chance that dynamic dispatch is not going to be the bottleneck of your game.

>>103293798
>polymorphism requires virtual function calls
DYNAMIC polymorphism requires virtual function calls. STATIC polymorphism does not. You should be using static polymorphism as default, and only reach for dynamic polymorphism if you really can't deduce the type at compile time which in practice is actually very rare.

>>103288244
Not being a retard.

>>103296490
do you have any articles or tutorials on this?