วีดีโอ

Agreed. I'm self-teaching atm and looking for a good ecs-tutorial/explanation which is why the first episode just stuck with me, easy explanation and good summary. But filtering the 1 minute of information out of 30 minutes of what seems like a TDD tutorial (ngl i already dislike TDD) is getting exhausting.

That's a way to look at it yes but UUIDs take up more data then this and can't be targeted for example I will be using Index:Phase in the following example. If I have an array of 2 components and then I might have handles like this 1:1 2:1 but say I use the 1st element and then "delete" it. I would not want to actually delete the data because that would impact preformance but I also don't want anyone using the handle 1:1 to access the data because it's now invalid and may be being used by a new entity in a new way. So I would advance the phase of the entity thus invalidating the handle and now 1:1 would return null and 1:2 would return the component that is index 1. Does this make more sense now?

@@eforencreates548 I don't think the ESC system actually needs to de-allocate the component(s), the array is kept as-is (allocation wise). It's just that the UUID is cleared (or reused) on the component and when you try to access the component with the old entity UUID, the UUID's no longer match and you get a null. Note that the UUID can be a simple counter as long as you do not have independent threads/machines creating entities that need to be shared. Edit: Again, it is very very similar(if not the same) to your 'phase' in that respect, but I think you don't need that extra concept if you define entities in terms of just their ID. In that case the entity's ID == your 'phase'.

@@erwinmulder1338 you are not talking about a UUID an Universally Unique ID is different even if 2 separate computers make them. What your describing sounds like you have GUID and UUID mixed up a Globally Unique ID has a limited context of safety like a simple counter would. As for why we can't just use an ID it's slower your lookups become atleast 2n instead of just 1n because you have to look up what component index your looking for and then you have to look up that component where as with the phase we are using here all you do is you jump directly to the exact position of the array in the phases array then you check that if it's right your all good and you jump to the actual component you wanted in the component arrays. This is much faster because you don't have to search every element in the array of id's to see if it matches the ID you passed in. Just think how brutal that would be on your timing if you were to do an array for each lookup every time you wanted to access any data because no direct reference to the data should be used because then that ref may nolonger contain the correct data how ever with the phase handles you can pass around the Handle which is effectively a direct reference to the data because it contains direct references to the data but it also contains a reference to the phase that it checks before it let's you use the ref

Can you give me some examples of things your having trouble with?

This is a great question! Ok so normally yes I support that { bar == false } is better then { !bar } this is how ever only because its harder to confuse the two. The reason your taught to use == instead of != is because of the fact that they can be confused how ever this is mitigated with code editors that use support lignatures because it can turn != into ≠ instead which you will not mix up with ==. How ever all of this has nothing to do with performance nor the reason I say that we must use != in this video it is all to avoid human error reading the code. The backing to my claim is that when you use == or != on an object that is not a base type you are actually calling a function so when you say { foo == bar } conceptually your actually saying something like { foo.==(bar) } and the same with != and so because we are testing our code that overrides the operators == and != we need to make sure we are actually testing the right function. For example imaging we wrote all our tests with { !(foo == bar) } instead of { foo != bar } we would never actually test the method != that we are writing. Also to be clear I am not asserting anything on the use of == over != in the normal flow of a program but because we are dealing with overloading those 2 ops in this test we must use both or we will not be testing our program correctly. Please let me know if this makes sense? If please tell me what does not make sense to you.

@@eforencreates548 oh, that makes complete sense. It's better in this case to have them completely independent since the testing of it needs to test each individual part rather than a culmination of parts.

@@lleytonmorris6305 Bingo! We need to make sure we test each part of it as in a vacuum as possible in it.

Thank you for mentioning the rest for curious viewers

Ruby is not a multiple inheritance language. stackoverflow.com/questions/10254689/multiple-inheritance-in-ruby

@@I3UCKWHEAT fixed

Can Do and Should Do are very different things.

What makes you think that? I would say that it is very solidly ECS

Oh, hmm, I thought it didn't actually use the "Systems" part of it, just Entities and Components?

How would it do anything without the systems part of it? How ever I did not talk about the systems in as much detail as I did the entities.

Sorry, you're right! Just rewatched it. I've been looking at so many varying ECS patterns/ideas/implementations that my head's spinning. :)

Your entities will be data only thus no logic. All the logic goes in Systems that scan the data for the conditions they want to change. For example a Velocity system might scan for any entities with both a position and a velocity and if an entity has both change the position by the velocity you may also have a drag system that runs after the velocity system that takes any entities that have a drag and a velocity and modifies the velocity by the drag. This allows the 2 systems to not care at all about the other and to function totally independently but effect the same entities the velocity system does not care about drag and the drag system does not care about position

Funny thing is I am not moving over to C++ my self lolz

In the first tutorials we deal with the data portion of the ECS the data and logic are very separate in later tutorials I will be working on the systems... System... I need a better way to say that... But all the logic is in those

Shablo5 I am just calling it Uber ECS to give it a name so that the Github repo can be found for example it is an ECS. I do feel that I have made some important changes that some other libs have not implemented like for example no precompile steps and having handles. Those are 2 huge quality of life changes over some other implementations

FacePalmProductions thank you for your comments on this I have gone back and forth with that my self and want people to feel like they can do it them selfs because I know some people are really negative about their work and look at the tutorials with everyone doing everything correct the first time and it sorta hides the reality of programming! Programming is really just making some code and then fixing your mistakes until there are not mistakes (that you know of) when you really think about it.

Dilan Shah sorry that's just editing the process I used was typing 3 \ which created the documentation area then I typed in the comments I wanted for the method but I hemmed and hawed a lot about it so I cut all that out it was long and drawn out I didn't think anyone would want to watch me muse over that lol

Eforen Creates cool, thanks for responding. Will Visual Studio auto-populate the tooltips that appear when hovering over a function name with your cursor with comments written?

Dilan Shah yes it will assuming that you wrote the comment correctly you will notice that there is some xml like syntax in my comments you need that and you need to use the 3 slashes if it's only 2 it will not parse the comment.

But this is mindboggling. Unity does not endorse OOP for gamedev. The whole paradigm of MonoBehaviour is called component-object model and it's more or less the same thing as ECS. Whoever is making an OO game in Unity is terribly wrong right off the bat, and even though C# itself supports it and inheritance is mandatory for clever structuring and non-redundant codebase, Unity has never endorsed it for game development since day 1. I'll repeat, this is why it has COMPONENTS, a TAG SYSTEM, and you typically write managers (which are called systems in ECS). So I don't get what's the big fuss about this?

Care to elaborate on what you meant by that? The way I see it, ECS pretty much is OOP. All the entities and components are objects with their own methods and properties.

Its more the inheritance system that sucks for game development rather than object oriented programming itself, i think. There are many useful features of object oriented programming even without using the giant entity tree of inheritance

So basically, the message is "multiple inheritance is bad for entities/components" vs "OOP is bad for game development". I see "OOP is bad in games" (or even more surprisingly, "OOP is bad in general") a lot, but it seems like approaching many aspects of engine (or just game) design *without* OOP would be an exercise in unnecessary masochism with minimal (if any) performance gains, since most of the heavy lifting in a game is the real-time rendering which executes on the GPU rather than the CPU anyways. I totally get how multiple inheritance is bad for entity/component architecture, I just feel like it's a pretty big leap from that to "OOP is bad for game development", and I see similar statements disturbingly often.

I am glad you have been enjoying it so much I have just been a little busy starting a new job and stuff and getting ready for the hardware engineering tutorial I am planning to make. I will hopefully be getting some new episodes out soon but I am also going to be moving to a new house this month so everything is a little crazy right now!

oh also its worth noting that I spent a weekend and coded like a crazy person and know where we are going for several episodes I just need to record them and edit them and stuff

He said 6 months ago...

>.< Sorry I got busy with my fully time job and some other stuff! I want to get back to it and make some more of these and make some electronics content too! Like for example I am making an IOT device right now and may make a video on it.

@@eforencreates548 He said 6 months ago :)

Thank you I am glad. I was worried that it would be too long and drawn out. I am glad it was easy to understand. Have you watched any of the other content? If so how was the other content does it all make sense?

The only thing that bothers me a bit is that the tests that are not running are still somewhat on the screen, so my eyes instinctively wander to them and get distracted. I think that this method is good enough for what you are doing. The fact that you explain the test after you enable them covers the main objective. So as it stands, I say is a decent solution. Do you have any particular gutt feelings about what's bothering you?

First off sorry for being gone so long my personal life has kinda flipped upside down... I am working on the next episode now though so it should be out soon. As for my feeling about whats bugging me I think it is like you said that them being on screen is kinda distracting... I could just totally comment them out... But I don't know I don't want someone to forget to uncomment one...

@Eforen Creates I do like the systematic flow of one new test at a time. However, I do feel at this point that this is more of a four part series on "How to do unit testing" and although I understand the necessity OF testing the code, and I ALSO am learning a lot about unit testing, I was watching this for the purpose of learning ECS... If you catch my drift. Maybe do the unit testing as a secondary series (more content 😊) and the ECS framework in this series. 👌🏼

Its basically Handle h = (Handle)obj; The difference is that this code will throw an InvalidCastException if obj is not actually a Handle, where as "as" will not instead in the same situation as will simply return null instead of throwing an exception. Does that make sense?

Eforen Creates Yes! Thank you

jonathan bodling awesome I am glad I could help :)

That’s a really good Question in this system each component only has data, unlike the Unity components which have both data and methods (logic). In our system we are building, the methods are located in systems. If we want to make a ridged body component we would not do it like in unity where a method on the ridged body is called whenever an entity is hit. Instead we would likely just make a tag “rigidbody” and a component “massVolume” to indicate we want it to be processed by the Collision System of the Physics which would watch all the things that have positions and massVolumes then if they collide it would add a component “collision” to the entity that would contain the information about what collided into it and forces involved or what ever you want your physics system to have and there would be another system maybe “rigidbody system” that would watch for any entities that have both a rigidbody and a collision object on it. That system would then loop through all of them doing whatever you wanted. With all of this setup you could have an entirely different system that maybe is “Paddle Hit System” that system watches for any entities that are tagged with “Paddle” and have a “collision” component and which loop over any that are available and then check the entities collision components to see if the thing that hit it is tagged as a “ball” at which point you just grab the handle that you placed inside your collision’s data and flip the velocity’s x or y component. You have just made a simple pong or breakout clone.

Unity uses the word "component" to mean something different than what it usually means on an ECS. So when you hear Entity, Component, or System, don't try to compare it with unity terminology. Simply think of 3 plain c# classes. In a very simple ECS, an Entity is a simple class with an array of Components, a Component is a simple class with a few properties (hp, position, etc), and a System is a simple class that contains 1 method "update" which takes a list of Entities and updates the entities that contain a very specific set of components while ignoring the ones that do not. That's an ECS at its core, of course building it like that would be really slow and difficult to work with lol.

That was really well put thank you :)

I believe for collisions specifically I would rather go with an event than with the ecs.