Update ecs.md #83

AlbertSnows · 2023-10-17T03:11:48Z

I edited the TODO section of the ECS chapter that contained commentary on OOP criticisms to "clean up" the text and have it flow in a (hopefully) more readable style.

Fixes #82

I edited the TODO section of the ECS chapter that contained commentary on OOP criticisms to "clean up" the text and have it flow in a (hopefully) more readable style.

Partmedia

Thank you for working on these docs. I've left a few comments for you.

Partmedia · 2023-10-20T03:47:42Z

src/en/robust-toolbox/ecs.md


-Edit all this text into something proper for a doc... Sigh
+Let's first take a look at inheritance. There are many problems and inflexibility that come with complex inheritance trees. Refer to the tree diagram above, and imagine we had no components. Instead, we have large inheritance tree. In this tree, we have a "machine" base class that has power consumption. We also have a different "mob" base class that has various player-controlled mechanics. Notice that both of these objects are on two separate branches of our component hierarchy. This poses our first design dilemma; what if we want some machines to have mob qualities, or some mobs to have machine qualities? Our system is designed in such a manner where you cannot make a mob have machine qualities or vice versa without making ugly hacks, or a common base for both "machine" and "mob". 


This duplicates a lot of what is already written starting on line 18. It would be better to work any additions you have into the existing text instead of repeating it.

Partmedia · 2023-10-20T03:50:38Z

src/en/robust-toolbox/ecs.md

-I'm more saying like... Rather than have logic in components change stuff, we want entity systems to operate and modify components. So instead of having:
-`HandsComponent.Pickup(ItemComponent)`, you would have:
-`HandsSystem.Pickup(UserEntity, ItemEntity)`.
+Inheritance may be perfectly fine in nuanced circumstances, such as small, self-contained inheritance trees (see something like `SoundSpecifier` for example). However, at scale its benefits become detriments quickly. Especially when you have a game as large and complex as ss14.


It's not really about scale, it's about the object-oriented model running into problems modeling in-game data objects. It may be helpful to link external resources, too.

Partmedia · 2023-10-20T03:51:53Z

src/en/robust-toolbox/ecs.md


+Now let's take a look at encapsulation. OOP associates data and behavior in the same class. Such classes only expose certain properties or methods to external parties via access modifiers. That is, fields such as `public`, `private` and `protected`. Encapsulation is good for cases such as our toolbax engine; which specifically needs to obscure/prohibit access to some data or methods. But for game and data logic, it doesn't make that much sense. For example, the `StackComponent` in SS14 has no private fields or properties and any owner is free to read or write the values as they please. However, this is not the recommended way to interact with stacks! 


How would you respond to the question, "it sounds like SS14 is using access modifiers wrong by not hiding private internal data fields?" OOP is also about encapsulation. What is different between StackSystem.Split() vs a stackInstance.Split() method?

Partmedia · 2023-10-20T03:53:41Z

src/en/robust-toolbox/ecs.md

+
+`StackSystem` has a few methods to operate on `StackComponent` and change its values. To use a certain amount of things on the stack, you use `StackSystem.Use`. To split the stack, `StackSystem.Split`; and so on. `StackSystem` acts as the orchestrator, and is responsible for acting on this component to express behavior. For something as simple as splitting a stack, this may seem like overkill. That is until you consider that as our features grow in complexity, changing the stack amount value isn't enough. As requirements expand, we will also need to accomplish additional tasks. For example, dirtying the component for network syncing purposes, setting the appearance value, raise a `StackCountChanged` event, and more.
+
+The way to accomplish this in E/C (a similar, alternative architecture) would be to put all of that logic in an "amount" property on `StackComponent` with an access method. Then you could `private` the actual "amount" number away. However, putting logic of any kind in a component class brings us back to the troubles of OOP as was mentioned prior. Take a step back for a moment to think about what it is, exactly, that we're bulding. Our game system is built on two principle concepts: entities and systems. Entities are composed of components. Systems transform components. As such, systems transform entities. If we need to express a *change* in the state of our game, that's what our systems are for. Components should only have data in them, and no logic whatsoever. It is our systems that should give the entities their behavior, when they have the appropriate components. 


It could be helpful to explain why. This explanation is not quite it since we don't in fact private the actual "amount" number away.

AlbertSnows · 2023-10-20T04:32:49Z

Thank you for working on these docs. I've left a few comments for you.

I will try to address these when I have time, or someone else can beat me to it.

Jezithyr · 2024-03-04T08:09:48Z

Closed as part of the docs repo cleanup. If you are still actively working on this PR feel free to reopen it.

Update ecs.md

119788f

I edited the TODO section of the ECS chapter that contained commentary on OOP criticisms to "clean up" the text and have it flow in a (hopefully) more readable style.

github-actions bot added the English label Oct 17, 2023

Partmedia reviewed Oct 20, 2023

View reviewed changes

Jezithyr closed this Mar 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update ecs.md #83

Update ecs.md #83

AlbertSnows commented Oct 17, 2023

Partmedia left a comment

Partmedia Oct 20, 2023

Partmedia Oct 20, 2023

Partmedia Oct 20, 2023

Partmedia Oct 20, 2023

AlbertSnows commented Oct 20, 2023

Jezithyr commented Mar 4, 2024


		Edit all this text into something proper for a doc... Sigh
		Let's first take a look at inheritance. There are many problems and inflexibility that come with complex inheritance trees. Refer to the tree diagram above, and imagine we had no components. Instead, we have large inheritance tree. In this tree, we have a "machine" base class that has power consumption. We also have a different "mob" base class that has various player-controlled mechanics. Notice that both of these objects are on two separate branches of our component hierarchy. This poses our first design dilemma; what if we want some machines to have mob qualities, or some mobs to have machine qualities? Our system is designed in such a manner where you cannot make a mob have machine qualities or vice versa without making ugly hacks, or a common base for both "machine" and "mob".


		Now let's take a look at encapsulation. OOP associates data and behavior in the same class. Such classes only expose certain properties or methods to external parties via access modifiers. That is, fields such as `public`, `private` and `protected`. Encapsulation is good for cases such as our toolbax engine; which specifically needs to obscure/prohibit access to some data or methods. But for game and data logic, it doesn't make that much sense. For example, the `StackComponent` in SS14 has no private fields or properties and any owner is free to read or write the values as they please. However, this is not the recommended way to interact with stacks!


		`StackSystem` has a few methods to operate on `StackComponent` and change its values. To use a certain amount of things on the stack, you use `StackSystem.Use`. To split the stack, `StackSystem.Split`; and so on. `StackSystem` acts as the orchestrator, and is responsible for acting on this component to express behavior. For something as simple as splitting a stack, this may seem like overkill. That is until you consider that as our features grow in complexity, changing the stack amount value isn't enough. As requirements expand, we will also need to accomplish additional tasks. For example, dirtying the component for network syncing purposes, setting the appearance value, raise a `StackCountChanged` event, and more.

		The way to accomplish this in E/C (a similar, alternative architecture) would be to put all of that logic in an "amount" property on `StackComponent` with an access method. Then you could `private` the actual "amount" number away. However, putting logic of any kind in a component class brings us back to the troubles of OOP as was mentioned prior. Take a step back for a moment to think about what it is, exactly, that we're bulding. Our game system is built on two principle concepts: entities and systems. Entities are composed of components. Systems transform components. As such, systems transform entities. If we need to express a change in the state of our game, that's what our systems are for. Components should only have data in them, and no logic whatsoever. It is our systems that should give the entities their behavior, when they have the appropriate components.

Update ecs.md #83

Update ecs.md #83

Conversation

AlbertSnows commented Oct 17, 2023

Partmedia left a comment

Choose a reason for hiding this comment

Partmedia Oct 20, 2023

Choose a reason for hiding this comment

Partmedia Oct 20, 2023

Choose a reason for hiding this comment

Partmedia Oct 20, 2023

Choose a reason for hiding this comment

Partmedia Oct 20, 2023

Choose a reason for hiding this comment

AlbertSnows commented Oct 20, 2023

Jezithyr commented Mar 4, 2024