What options do I have to Entity–component–system?

shackra

Hi!

I wanted to think this through and see what options I have to avoid ECS, my reason being that maybe I could go with something simpler for my survival zombie game.

I'm looking for ways to share "behaviors" between different "things", i.e.: "bread", "water bottle", "gun", "ammo" are different things that can be picked up and store in a bag that the player carries, yet these things have other uses and effects like the "bread" and the "water bottle" can be consumed, the "gun" can be equipped and the "ammo" can be combined with the gun and so on. There is a lot of behavior that I would like to implemented but also make it sharable. My first impression was that making scenes and attaching scripts to them could work for implementing behaviors and making use of them through composition, but I'm not sure how feasible this idea is and how I could, trigger things in game to make it work (like displaying UI for combining "ammo" with my "gun", or picking up items and storing them in a container or bag, how that would work in code).

Other requirements I have is "things interactive among themselves" that my game can simulate some interactions like, flammable things getting in contact with fire, things in the world getting wet due to the weather, and so on. This could be more of the same with the addition of something external to the nodes implementing the behaviors actualizing the simulation, but I'm not really sure how to approach that either.

I mention ECS because AFAIK, this architecture allows simulating things and share behaviors, as to why I would like alternatives to ECS is that the only library or add-on I know for ECS in Godot is Godex which requires re-compiling the game engine, is still in development and ECS is for me a new concept overall.

Calinou

See this article: https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine It's very unlikely that you actually need to follow a strict ECS approach to implement the kind of game design you're after.

You can implement ECS-like behaviors by adding and removing child Nodes with scripts attached to them while the project is running.

Erich_L

Here's how I'd approach your problem in Godot as a godot novice.

Have your root node for these types of objects be a very generic "object". Have only the attributes that are shared amongst all objects be in this node: weight, size, object name, and location. If all objects can be picked up, throw pick_up() in there too.

Give it a function called take_action(funct : String, params : Array ). When you send it an action, look through the children of the node to see if any of them .has_method(funct). If it does, use .call(funct, params) on that child.

So, for example if you were trying to call "eat()" on an object, it would search through the children and see if any had an eat() function and call the ones that do. So if you wanted some objects to be editable, give them a generic "edible" class in a script with attributes like "calories, bites left" and a function eat() and through it on a node.

If you're producing a menu of actions you can take on the object then you could ask the root node to go through the children and collect accessible functions. For example, in your edible class:

func getActionable(): if bitesLeft > 0: return "eat"

berarma

As I understand it being someone new to Godot but not to programming, you can use composition to add behaviors. Bread can be a scene with a generic Thing node, and some of its child nodes can be behaviors, each behavior having its own functions.

The Thing node could do things differently depending on the child nodes it has, or you can access the child nodes (behaviors) and interact directly with them.

Behaviors can be reused by creating them as custom nodes or saving them as scenes. You can then create scene instances where you need them.

Scene inheritance can help in case you want your game items to share a common node tree.

TwistedTwigleg

Godex seems to be an ECS system written for Godot. Its in active development and seems to be thoughtfully designed for Godot and ECS-style programming. I haven’t tried ECS programming or Godex myself, so I cannot say from experience the pros/cons of ECS in Godot, but I wanted to mention it as it seems useful if anyone wants to try ECS in Godot.

shackra

Alright, I still need to implement this, but I got an idea:

I'll have behaviors and also interactions in the game, a behavior is something a parent node can do, the behavior will be written in the script of the "behavior" node itself. The interaction is a node --like the behavior node-- that tells the parent node how to interact to a given behavior. The behaviors and the interactions will know who needs to know what through global signals.

I think this solution is fitting because I was worried about "teaching" different subjects how to interact with other subjects that have different behaviors, duplicating code.

Thoughts?

Erich_L

@shackra IMO 90% of programming is just getting the logic to work in your head. When you're there you're there. I don't think I understand your behaviors/interactions plan without an example.

cybereality

This is sort of like how they made The Sims. I can't seem to find the interview where they explained it. Basically, from what I remember, they coded the logic and interaction of each object (say a toaster oven, or a sink) into the object itself. So, the toaster would "know" what could be done with it (insert bread, start toasting, etc.). The AI characters could walk up to the toaster and they would "learn" how to use it. They even went has far as embedding the animations into the toaster, which the AI would take when they interacted with it. This avoided having to code/animate everything upfront and bake it into the characters (which would have been hell as there are thousands of objects and new expansions all the time). I thought this was a cool idea but never had any project that needed it.