Coding basic Entity Component System but I am dumb. Game Engine ep. #3
Вставка
- Опубліковано 14 тра 2024
- Am I moving backwards or forwards? Nice to see you again for another time in the C++ engine series. This was an "adventure" to say the least and I hope that you were pleased. This was more of a theoretical video in terms of what you saw, but we will soon get to use this more in practice.
Thank you for watching!
Resources:
github.com/SanderMertens/ecs-faq - has a lot of general information and links around the web for existing ECS implementations.
/ ajmmertens - lots of articles from the same person about ECS.
0:00 Intro
1:08 The Plan Failure
2:12 Why New Architecture
3:11 Data Oriented Design
4:21 Firewood Analogy Interlude
5:24 ECS Basics
7:04 Me Admitting I'm Dumb
7:29 The Grind Starts
8:15 Experience Sharing Interlude
8:53 My Own C++ ECS
10:51 HashMap Querying
11:48 Component Archetypes
12:05 Remapping Component Indexes
12:43 A Small Demo Scene
13:09 Future Plans
13:46 I Know That I Know Nothing
Music:
Intro:
Iron Jack-o-Lantern - TeknoAXE
Guitar Interludes:
Sardana - Kevin MacLeod
Background:
Awake - Emmit Fenn
Vibing Over Venus - Kevin MacLeod
On The Rocks - TrackTribe
Staycation - Corbyn Kites
Use tuples instead of vectors. Tuples allow you to have a dynamic array that contains multiple types.
Thanks for the tip. I will be sure to include tuples in my analysis once I come back to this in the future vids.
No I don't think this is a good if you want to go with an ECS architecture. You want the components to be stored continuously, for each component type. So going with a single vectors for each component is exactly the right way to go. Then you want to iterate over the components vectors individually when updating the game/simulation state. That way you have the most cash benefits.
Code duplication can be avoided with templates. Looking up components can also be implemented with linear or binary search and will probably be fast enough in most cases. Dealing with hash maps brings their own draw back, but I guess it can be done and might be needed in some cases.
The internet historian style video but for programming. I love it! Keep up the good work, man!
This is really helpful on my own ECS journey. I've been struggling with the whole magic layer of "linking components to entities".
Glad to hear I helped someone
Good job man. I've been battling the same problems 😅
I feel your pain. I am currently on my countless'th iteration of ECS for my game. Every time I almost get a Eureka moment, I run into a problem with my ECS system.
i am loving it 👍🏻👍🏻
Nice, another guy who loves low level programming².
Oh, I'm already a subscriber to your site, I didn't even notice 🤔
Keep it up champ💪
Best video so far ,,🔥💪😎
shadow wizard money gang
God programmer is back at it again. When you were explaining why you moved to ECS, is there any reason why do you think you need separate classes for Physics Sphere or Physics Trail Sphere? Can't you just have some parameters in Sphere class that can be set on or off for each functionality? Or even do dependency injection for components if they share some common base.
Amazing video as always tho!
There is nothing inherently special with ECS that allows to solve this and you likely could make it work. In my case having separate classes in OOP would ensure that you are not wasting memory by having properties on objects that should not have these properties (like physics) and passing parameters to enable functionality would likely still have the same memory overhead issue.
I did not even consider doing something like injecting components (I guess ECS is kind of similar in a sense?), but I would have to be honest that I had my mind set on ECS without much consideration for OOP to begin with since I have plans for large scale simulations.
looks cool :D cant find anything dump
Hopefully someone will. I need to live up to the title
Deciding what type of int the ID of an entity should be sure is the most difficult part of ecs
I think I will switch to size_t later :')
🤷 "promo sm"