What seemed to be confusing me was ambiguous language. Thanks guys it's really helpful to get some feedback on this - I think I've finally properly understood this idea. The major thing I aim to accomplish is framework that is as streamlined as possible - or in other words, as consistent as possible, with as few caveats as possible. I had another, simpler solution in mind already that I can fall back on if it seems that a full-blown ECS might be overkill. Is it worth setting up an ECS architecture when I can only identify one time it is going to benefit? I'm not sure, I'll just try it out. In a survival game with pretty much set in stone rules I dont see an immediate benefit - however this example where i need to get data from a couple components and do something with it definitely seems like the cleanest solution. It seems the major benefit of this structure is flexibility in a game where I am likely to make many imaginitive changes to game rules during production.
Systems is just some sort of logic that is going to identify components and then do stuff with the data.Īnd entity is just a pointer to some object in the game which might hold onto various components. Unity already has some inbuilt tools for that so it's no problem, but some of the articles I was reading were using c++ or other languages to demonstrate so I was trying to just get the principle.
If we strip away game engines and specific languages, all this means is that there is some sort of container which has some data nuggets in it, and the container is a thing that might be easily identified. Probably not worth the effort to try and identify what they were.īut my understanding now is that this is actually a pretty simple setup:Ĭomponents are just data. So after I read that article and a couple others a few more times, I realize I had a few misconceptions. Just looking for any thoughts, opinions, guys.
In thinking about designing a game framework that will be easy to maintain, I think consistency is probably the most important thing. To my mind, even if the clothing component and bodytemp component would always be used in conjunction, it still seems consistent and logical that these two components remain separate. I don't see any problem with that, but I just wonder if that isn't sort of going against the premise of how it's all meant to work. I guess you can make some branching checks, like check if the entity is using the Clothing component, and if so, then get the insulation value to be used for calculating temperature. that sort of defeats the point of separation? But if one component needs data from another. As I understand it, the point of using this ECS (entity component system) design is that different components have broad usage and aren't tied to a class. This data about the clothing - it's insulation value in this example - might be stored as float that could be used as an input over in the BodyTemp calculations. The Clothing component might be responsible for equip/unequip clothing which would be changing some visual elements but also getting data about the clothing. Two factors in this equation should be the ambient world temperature and the insulation provided by your current equipped clothing. BodyTemperature component and Clothing component.īodyTemp component should calculate your characters current body temperature. Suppose you have two components in a survival game.
0 kommentar(er)
