Menu
Pardon my noobness. I'm making a game in which several characters have relationships with each other and they need to be able to interact with each other and store some relationship data regarding how they feel about each other.
I have an object for each character. Is it bad for each of those character objects to have an array of all the other character objects in order to perform these interactions? Is there a better way to do this?
EDIT to answer questions: My language is C#.
What I was thinking is that the setup class would make an array of all characters and then pass that array as a parameter to the constructor of each character.
As for the types of relationships, there are five characters, but I would like to make it extendable in case more are added later. The characters have conversations with each other. What they say is affected by their mood and how they feel about the character. Also, what another character says to them affects their mood and how they feel about the character. They can have one-on-one conversations or talk in groups, so character A could say something to character B, C, D, E, and F all at once.
By the way, I'm learning so much for from this thread. Thank you SO much, everyone!
648
Of course you can have objects reference each other. You could simply pass the this pointer in both objects to each other, which is perfectly valid.
These include: design patterns, abstraction, encapsulation, modularity, polymorphism, and inheritance. When not to use OOP: Putting square pegs in round holes: Don't wrap everything in classes when they don't need to be. Sometimes there is no need and the extra overhead just makes your code slower and more complex.
Poor naming of classes. Use of too many design patterns in a small space. Working too hard (rewriting functions already present in the framework, or elsewhere in the same project) Poor spelling (anywhere) and grammar (in comments), or comments that are simply misleading.
Even though OOP promises to address modularity and improve reusability, it fails to deliver on its promises (more on this later). OOP code encourages the use of shared mutable state, which has been proven to be unsafe time and time again. OOP typically requires a lot of boilerplate code (low signal-to-noise ratio).
It's not bad practice for objects to retain references to each other - it's not uncommon for nodes in a tree graph to keep a reference to their child nodes, and for the child nodes to keep a reference to their parent node.
One thing that might become an issue is what you describe as each character keeping references to all other characters. That's an NxN matrix, and will explode your memory use as the number of characters increases.
An alternative to storing a list of all character objects in each character object might be to set up an associative list or dictionary where the key is (character 1, character 2) and the content is the relationship. This list could be global and store all relationships between all characters. The advantage here is that it grows linearly with the number of actual relationships, not exponentially with the number of characters in the system.
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
