« first day (3155 days earlier)      last day (30 days later) » 

2:23 AM
o/
 
 
8 hours later…
10:20 AM
\_/ o
 
 
3 hours later…
1:15 PM
What's up!
 
nwp
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?
 
nwp
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?
 
nwp
1:30 PM
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; };.
 
I actually started messing with something that uses an ECS yesterday
A few weeks ago I wrote a quick implementation myself but decided to just use something existing and work on actual game stuff instead
 
nwp
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
 
Yeah it's that template wonkery that sort of scared me, I was also basing my system on typeid and felt like that wasn't maybe the best choice
 
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>>.
 
nwp
1:36 PM
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).
 
nwp
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
 
nwp
@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.
 
nwp
1:44 PM
I would probably prioritize rethinking the design. Or using one of the ready-made ECS libraries available.
Then again maybe you don't actually want an ECS.
 
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.
 
nwp
@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.
 
1:46 PM
I'm using entt currently, I don't have a lot of experience with it but I can say it's pretty easy to get into
 
@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.
 
lol
 
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.
 
I spent yesterday night porting in my mysterious tilemasking code over from GunHero so I have something pretty to look at
 
1:53 PM
Nice.
 
My current design ideas are "procedural worlds" and "destructible terrain"
 
nwp
Terraria 2 :P
 
probably something more towards spelunky but dunno
 
@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++."?
 
1:59 PM
yup
 
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.
 
nwp
EnTT does look really good.
 
 
3 hours later…
5:02 PM
Basingstoke free on Linux. Great game, I recommend it!
 
5:27 PM
In an ECS, where are game rules? Where do you put the game logic?
 
Systems?
 
Hmm, that must be it, you're right.
But then, is everything a component or a system?
 
Both? That's why I sort of find ECS annoying
 
How can something be a component and a system at the same time?
 
I didn't mean that, I mean that a feature implementation requires both a new component for the data, and a system for the actual logic
 
5:30 PM
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.
4
 
I have this naive idea that writing an ECS would be a lot nicer in something like C# that doesn't need two separate files for everything
 
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.
 
hmm yeah for components
 
5:54 PM
aight finally got collisions and movement fixed, now i can hop around with my red rectangle
 
All using entt?
 
yup
 
Nice!
You use SDL again?
 
yup, don't really know anything else
 
If it works for you, no need to use anything else. And you wrote your own physics?
(/collisions)
 
5:58 PM
"physics"
but yeah
 
Yeah, "physics" is enough :P
 
6:28 PM
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.
 
@Almo no that's not ECS specific, that's C++ specific
 
6:41 PM
Does it make sense to make a component when there will only be one instance of it?
 
6:52 PM
Where else would the data live? In the system?
 
Yeah, the system that would use it.
 
man i dunno
what's the actual use case?
 
I dunno.
Our software has been in-between multiple architectures over the past 3 iterations. I'm trying to see if we could go toward a single architecture.
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.
 
7:14 PM
@Tyyppi_77 I mean that the two file shit doesn't make ECS any harder than anything else.
 
Sort of? Since every feature requires a component and a system
 
7:41 PM
it's not 1:1 relationship between components and systems
 
 
1 hour later…
8:48 PM
Hello...
 

« first day (3155 days earlier)      last day (30 days later) »