o/

\_/ o

What's up!

I learned that I should be getting paid but was not.

Also you seem to not avoid inheritance at all cost. Consider doing that :D

Also I'm getting a new graphics card because the strategy "It's Linux and graphics doesn't matter" didn't work out after getting Magicka2.

@nwp How do you create an inheritance-free Entity-Component architecture? What do you get out of?

You just do. ECSs do not require inheritance at all and give you regular ECS functionality.

template <class T>
std::vector<T> components;

That's the backbone of an ECS. In practice you would swap out the vector for plf::colony or something that allows erasing from the middle/front in O(1).

Add a template <class T> std::vector<int> entity_ids; and a bunch of boiler plate for insertion, lookup and iterations.

Hmm, so your point is that you make sure that all your components, instead of inheriting from a common class Component just have those methods that would be in the Component class?

There is no component class and components do not have common methods besides being move-assignable and move-constructible.

And destructible I guess.

A typical component is struct Speed { float speed; };.

It does require quite a bit of template wonkery and I enjoy doing that, but I can see how others may not.

I wanna make game stuff again :o

But tiiiimeeee

It's technically not an ECS where E is just an id, C is just data and S work on these components. We have Entities that "own" the components and other entities, but we have non owning 'component managers' that update the components.

These 'component managers' have std::vector<std::shared_ptr<Component>>.

Well, entities owning components is normal. Adding an entity as a component is a bit strange but I don't see why not. Component managers are normally covered by the systems, but basically the same thing.

The core of the logic is in the update method of the components, and in the 'non-component-managers' (MgrFetchTheInputsFromJoystick, MgrPerformPhysicsSimulation, MgrDrawTheSimulation).

That seems weird but not incompatible with a regular ECS. You can put functionality and inheritance in your components if you really want to.

We're re-building that thing because we need to be able to build the components in a data driven way. I don't like the inheritance nor the shared pointers either, but that's the first step, I guess. I'm looking forward to profile once it's completed :P

So you think it's an ECS?

@Kevin Yeah, what's that? :P

@AlexandreVaillancourt Doesn't matter. It has to do what you need it to do, and being an ECS is not one of those things.

Yeah, for now it sorta works, but I'll probably want to put everything in there. Our main "update" method will look ugly until then.

I would probably prioritize rethinking the design. Or using one of the ready-made ECS libraries available.

TBH, though, that's not where we need the most speed. Our physics simulation and the rendering are our bottlenecks.

@nwp Any ECS libs you that recommend?

Oh, we had something very ugly before, what we have now is much more flexible.

@Pikalek No. I looked at EntityX and didn't like it and wrote my own. Would not recommend that either though.

@AlexandreVaillancourt Why choose between the two? My component system is both flexible and ugly.

@Pikalek We had a hammer. Everything was a GfxObject that had GfxObjectComponents. Then when you wanted to add something else, you inherited from those to get a SimObject and SimObjectComponents. That was ugly.

@Tyyppi_77 East Northport Table Tennis Club? No, Bing, this is why we are not friends.

I relied on skads of YAML files, some interfaces and, because I started it before they adopted static function declarations in interfaces, assumed factory methods.

It worked, but lacked type safety among other things.

I guess technically the interfaces were akin to C++ multiple inheritance.

Nice.

Terraria 2 :P

@Tyyppi_77 looks clean, yeah. I'll take a look at the code, eventually.

Also nice. You can play the "I don't need to guarantee connectivity cause you can make you can make a tunnel to fix your own darn map" card.

That card was dropped from MtG due to the length title.

But it's a really nice card.

Presently, I'm shooting for the lesser bar of alterable rather than fully destructible terrain.

@Tyyppi_77 Is this the one: "EnTT is a header-only, tiny and easy to use entity-component system (and much more) written in modern C++."?

yeah, that probably works better than tennis.

My C++ is is probably now old enough to be dangerous, but I'm still interested in reading through their API for hints about better design. Thanks for the tip.

EnTT does look really good.

puppygames001.itch.io/basingstoke/devlog/70568/…

Basingstoke free on Linux. Great game, I recommend it!

In an ECS, where are game rules? Where do you put the game logic?

Hmm, that must be it, you're right.

But then, is everything a component or a system?

How can something be a component and a system at the same time?

Oh! Okay!

I find the idea of using ECS too rigid for game programming.

Personal opinion though

ignore as you will :D

Well that's the thing. Once one gets a hammer, they tend to see everything as a nail.

Why? With the example NWP has written above and the one on that entt README.md, components appear to be only defined as structures of data: no methods, so no need for a cpp file.

All using entt?

Nice!

You use SDL again?

If it works for you, no need to use anything else. And you wrote your own physics?

(/collisions)

Yeah, "physics" is enough :P

I don't think two seperate files has anything to do with ECS

"partial class" is fucking evil though.

no end of mess can be made with that.

Does it make sense to make a component when there will only be one instance of it?

Yeah, the system that would use it.

Our latest iteration has the logic in the components, and in some other "managers" that are not really involved with the component architecture.

So our main-loop is not fun to look at.

@Tyyppi_77 I guess you would not need a component for that; just stick it in the system.

@Tyyppi_77 I mean that the two file shit doesn't make ECS any harder than anything else.

it's not 1:1 relationship between components and systems

Hello...