@asser_fahrenholz it is “one constructor to rule them all” basically. So, with one constructor I can use any combination “of parameters”, in any order, and only the ones I set will be applied, the others will be ignored (that’s what the Runnable was used for). The class is quite simple and not complicated I think, but it is still a kind of monster I guess
But that seems like a ton of work to set a few parameters… and not very well “documentable”.
I fail to see the benefit of this over a constructor with 3 or 4 parameters. (If your components have more than 3 or 4 fields then it’s usually the sign of design problems… not always, but frequently.)
Yes, I am aiming for 10+ fields, but I may break into more components if it proves to work better indeed.
I wonder if there is some example out there showing how a component with many fields actually worked better after spreading the fields into more components? I guess I have to try it anyway to actually understand that.
That many fields means that one system is communicating 10+ fields to another system… and that other system uses all of those fields. It’s a sign that they are really one system.
If, on the other hand, you have one system producing this 10+ fields component and one system using 3 of them, another using 4 different ones, a third using some of the first three and some of the other 4, etc… then you really have multiple components and have saddled systems with additional burden that they didn’t need.
The one rare exception where fields should be correlated in this way is when they are transformations of one another and must absolutely match at an atomic level. A case for this is when I build grid IDs into my Position components. The grid ID is derived from the Vec3 position and must always always always match. If I set a new vec3 location then I need to update the grid ID also. So even though only some of the systems ever need the grid ID, in this rare case it makes sense to keep them together.
fluent styled setters are possible, you can create a lombok.config setting it up as you want. Nice thing is (at least with intellij) that your auto completion and refactoring tools works as usual.
so, is the component solely a way of communicating data to other systems in a read-only way?
In other words, this means: should I make the component constructor private?
and any facilitators to “update” components fields should also be private? to no allow logic that can update them ouside the system?
and, whatever I would use exclusively inside of the system, should never be stored on a component? like toggables and limits options, where many are user accessible ones.
and not necessarily, the components are intended to be on a savegame? this means, I shouldnt bloat it with savable data either, just because they are to be saved?
[details=I dont mean to be repetitive]I am just bringing it all toguether to try to have an overview of the best basic practices.
I think some of these statements, if they are correct, should be frontpage somewhere.
sometimes restrictions are good to increase our code clarity and prevent troubles later on, mostly for newcomers (like me :)).[/details]
[details=About constructors again]4 or 5 fields would annoy me enough I guess… some bad things (on my developer side) IMHO:
- having to maintain one constructor per specific usage situation, that truly annoys me from a long long date…
- having to pass many nulls in case of a big-all-fields constructor, for ignorable fields or with defaults.
An workaround (not for components) is an empty constructor and to use many setters after, but that may leave some loose conditions, like things that should be setted together, or before another, would only be detected dynamically, not being a good option.
And I think that will happen to the component with bean I created, and to counter that I would have to create setters with 2+ params with these few being usually not null, what would put me almost like again in the same place I was with many constructors’ fields’ combinations. But at least would put me away from constructors’ maintenance, have to experiment how that will be
I watched its video and it was on eclipse IDE! so most probably it will work great I guess;
I wonder if lombok could provide a combinatory bloating-auto-creation of constructors too? that would be quite useful I guess
intellij </3 blabering
I am unable to use intellij with the same nimbleness I do at eclipse luna. Also their non opensource license bothered me a bit concerning our privacy, despite I believe it would be only related to commercial relations, I didnt like it much. Considering the slowness and my disgust I gaveup on it
Lol it’s raining a lot with thunders and I need to stop thinking right now dammit! xD
Correct. Those all sound like not game objects. Entities and Components are for game objects… not user options.
I meant to gather them all here:
But I couldn’t remember them all when I made that page quickly.
-components should generally be immutable (else you have to deal with your own multithreading issues and that’s best just avoided)
-components are generally used to communicate between separate systems.
No. That’s silly.
This is probably true. It just so happens that in all of my games, most of the game state is in components as everything else is easily reconstructed. But yeah, like if I had long user-entered descriptions of stuff or whatever, I wouldn’t use components for that as it’s not really game data. No systems need it.
I think 95% of the time you only need to save what the systems are using… ie: components.
I think my Position component is the one with the most arguments… and that’s three at most, I think. I have a couple constructors and a few “change” methods that mutate one or two parameters in a newly returned Position object.
I have trouble thinking of a component where I’d have more than four parameters on a constructor. On the other hand, the whole new Bean thing is quite verbose and creates extra garbage. (Note: you could use groovy which would give you easy map-based constructors and avoid the whole thing, too.)