Is there a way to use Love/Hate without relying on GameObjects?

[Nosteme]

Hey again, sorry to bug, but I realized I might have a bigger issue regarding my game.

Because there's no need for coordinates or concepts of positioning (2D and 3D stuff) in my project, I'm wondering how to best use Love/Hate with my project. All of my data doesn't use any monobehaviour, so ideally I could associate instances of FactionMember with instances of my NPC classes, and handle all that in code rather than in the editor. It then becomes obviously troublesome trying to use things like a custom emotional model because of it needed to be a component on a gameobject sharing a FactionMember component.

Having everything not use monobehaviour except Love/Hate is really not the way I'd like to organize my project, so I'm wondering if there's a better way to go about this? Is there any functionality (existing or planned) that might allow me to still utilize Love/Hate without relying on gameobjects and component interaction?

I really really love this plugin and want to use it, but I'm also really opposed to remaking my entire project just to use it. So, any ideas?
Thanks in advance for reading this far.

[Tony Li]

You could create a single GameObject in code. For example, say you have a variable "myDatabase" that refers to a FactionDatabase, and an array "myCharacters" of a custom Character class. The Character class has at least two variables: "factionName" and "factionMember" (which will point to its FactionMember instance). Then you could do something like this:

Code: Select all

// Create FactionManager:
var factionManager = new GameObject("LoveHate").AddComponent<FactionManager>();
factionManager.factionDatabase = myDatabase;

// Create FactionMembers:
foreach (var character in myCharacters)
{
    character.factionMember = factionManager.AddComponent<FactionMember>();
    character.factionMember.factionID = factionManager.GetFactionID(character.factionName);
} 

There's no strict requirement that every FactionMember must be on a separate GameObject, so in the example above I just put them and the FactionManager on an empty GameObject named LoveHate. You end up with plain variable references factionManager and a character.factionMember for each character, and you don't have to work any further with GameObjects.

[Nosteme]

Hey, that's not a bad idea at all! Though would a gameobject with potentially hundreds of attached FactionMember components actually work? Or am I misunderstanding?

[Tony Li]

To be completely honest, I haven't had a chance to check it yet. But if you're not using the default CanSee or the default Greeting/Gossip/Aura Triggers, there's no reason why it wouldn't work. Other than the aforementioned delegate and triggers, FactionMember doesn't do anything specific to a GameObject. It's just a place to hang instances of the script and also get the features provided by MonoBehaviours such as coroutines. (FactionMember runs a coroutine to age out its deed memory.)

[Nosteme]

Huh. Well if that's the case, this might just work

Wait, what about components like StabilizePAD and EmotionalState? Using those components on the same gameobject would make it apply to every NPC right? I don't necessarily need a solution to have those work for only individual NPCs (unless you have one), but I'd like to know how applying those components to the same master NPC object would affect things.

Also, side question regarding deed memory and time: I saw in another post that you were planning an update where the user could define their own definition of how time passes. Is that update already out?

[Tony Li]

The update for custom time isn't out yet. The Asset Store recently changed their art specs, and I'm waiting to release the update until our artist has finished updating the product image for the new specs.

If you're using StabilizePAD, etc., you can just put the FactionMembers on child GameObjects in code:

Code: Select all

// Create FactionManager:
var factionManager = new GameObject("LoveHate").AddComponent<FactionManager>();
factionManager.factionDatabase = myDatabase;

// Create FactionMembers on child GameObjects:
foreach (var character in myCharacters)
{
    var characterGO = new GameObject(character.factionName);
    characterGO.transform.SetParent(factionManager.transform);
    character.factionMember = characterGO.AddComponent<FactionMember>();
    character.factionMember.factionID = factionManager.GetFactionID(character.factionName);
    
    // Add other components:
    characterGO.AddComponent<StabilizePAD>();
    characterGO.AddComponent<EmotionalState>(); //etc.
} 

[Nosteme]

Thanks! That solves a lot of problems for me.

I assume then that I could just create a list of gameobjects, add components in code, and access them whenever I need them, not bothering with what's in the scene, right?

As for the update, I'm looking forward to it

[Tony Li]

I assume then that I could just create a list of gameobjects, add components in code, and access them whenever I need them, not bothering with what's in the scene, right?

Right.

I'll post on the forum when the Love/Hate update is available, hopefully next week.

[tylerwsavatronix]

This might be a lifesaver for our project.

We've seperated all our core code from Unity code. So, for example, our NPC class has no references to or even ideas about anything to do with Unity.

The Monobehaviors/gameobjects instead act as the "driver" of the NPC (i.e. the NpcGameObject script has a reference to its associated NPC script, and calls into NPC to execute functions in reaction to Unity specific events like animation events, or interactions and such).

We decided to start doing things this way to both make unit testing much, much easier as well as to allow our NPCs to persist and be "driven" by a simulator when they're out of the players range.

One of the things I'll be taking a look at in the next week is how to best integrate Love/Hate with this model so that we can also maintain (as many of) the things Love/Hate does.

Sounds like, at least with this approach, we'd want to move the faction member component (and/or any other components except triggers) to another game object when we unload the NPC's gameobject, and maybe have the NPC class keep a reference to the necessary scripts in case it needs to act on them?

[Tony Li]

That sounds like a good approach. You could even put the Love/Hate components (such as FactionMember, DeedReporter, etc.) on a child GameObject that you can detach when you unload the NPC's GameObject. It's probably easier to reparent this GameObject than move its individual components. So something like:

• Main NPC GameObject
  • Rig
  • Mesh
  • Love/Hate components GameObject (reparent this when unloading NPC)

Alternatively, given that many other assets and built-in Unity operations rely on the GameObject architecture, you could put your unloadable components on child GameObjects like this:

• Main NPC GameObject with data-oriented components like Love/Hate (always keep around)
  • Unloadable components GameObject
    • Rig
    • Mesh

BTW, the update to Love/Hate mentioned in my previous post has been available since September 20.