Friend Mechanic
I want to create a mechanic to friend people, I'll use my own database for this.
What is the best way to approach this?
I want to spawn a prefab on the avatar that triggers the friend mechanic, this prefab has it's avatar ID, an visual effect and a collider to trigger friendship connections.
Is it better to include this in the player avatar prefab in the hyrarchie and activate it for a specific avatar using a networked event.
Or is it better to instantiate a whole new networked prefab object with the desired behaviour?
Bit lost on the best way to approach this.
11 Replies
Hi @Mikameel. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I'll help you implement a friend mechanic in your NormalVR application. Based on the knowledge sources, there are two main approaches you could take:
Option 1: Include in Player Avatar Hierarchy
You could include the friend mechanic prefab as part of your player avatar hierarchy and activate it when needed. This approach works well because:
- RealtimeAvatar components already track and synchronize avatar information across clients
- The ownership model ensures only the appropriate client can modify their avatar
- It's more efficient for objects that are always associated with an avatar
As mentioned in the Avatars documentation, RealtimeAvatarManager keeps track of all avatars in the room and provides events like
avatarCreated
and avatarDestroyed
that you can use to manage friend requests.
Option 2: Instantiate Separate Networked Prefabs
Alternatively, you could instantiate separate networked prefabs for the friend mechanic:
- Use Realtime.Instantiate()
to create a prefab that contains your friend request UI/collider
- Set ownership appropriately so only the right client can modify it
- Connect it to the relevant avatar using the clientID
This approach is described in the Realtime API documentation for synchronizing prefabs.
Recommendation
I recommend Option 1 (including it in the avatar hierarchy) because:
1. It's more efficient - no need to create additional networked objects
2. Ownership is already handled through the avatar hierarchy
3. The friend mechanic is conceptually tied to the avatar
You can implement this by:
1. Adding your friend request prefab as a child of your avatar prefab
2. Keeping it disabled by default
3. Creating a custom RealtimeComponent to activate it when needed
4. Using the RealtimeAvatar's clientID to identify which avatar to friend
For the actual friend request trigger, you could use a custom RealtimeComponent with a model that tracks friend request state, similar to the approach shown in the Synchronizing Custom Data documentation.
If you need RPC-like functionality for the actual friend request event, you could follow the pattern in the RPC Events Recipe, though as noted there, it's generally better to use synchronized state rather than RPC messages when possible.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@365574199844274177> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant write me a script that activates a gameobject on specific avatar in the scene.
Let me check the knowledge base for you again. One moment! :books:
----------------------
I'll help you create a script that activates a GameObject on a specific avatar in your NormalVR scene. This is a common requirement when implementing friend mechanics or other avatar-specific interactions.
Here's a script that will allow you to activate a GameObject on a specific avatar based on their client ID:
To use this script:
1. Add it to a GameObject in your scene (ideally the same one with your Realtime component)
2. Assign the Realtime and RealtimeAvatarManager references in the inspector
3. Make sure your avatar prefab has the GameObject you want to activate (named "FriendRequestObject" by default, but you can change this in the inspector)
4. Call
ActivateObjectOnAvatar(clientID)
whenever you want to activate the object on a specific avatar
For this to work in a networked environment, you'll need to ensure that the activation is synchronized across all clients. You can do this by creating a custom RealtimeComponent that manages the activation state, as described in the Synchronizing Custom Data documentation.
Remember that according to the Common Questions documentation, scripts on your player prefab will run for all avatars in the scene, so you'll need to use isOwnedLocallyInHierarchy
if you want logic to only apply to certain avatars.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@365574199844274177> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant does the client ID changes everytime someone connects to the room or is it consistent accros sessions?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the knowledge sources, the client ID in Normcore is assigned by the server when a client connects to a room, and it is not consistent across sessions.
When a client connects to a room, they are assigned a unique client ID for that session. If the same user disconnects and reconnects to the room (or connects in a different session), they will receive a different client ID.
This is particularly evident in the offline mode documentation, which states:
This indicates that in normal online mode, the client ID is dynamically assigned by the server rather than being a persistent identifier tied to a specific user across sessions. If you need to maintain consistent identification of users across sessions for your friend mechanic, you would need to implement your own user identification system using your database, as you mentioned in your initial question. You could store a mapping between your persistent user IDs and the temporary Normcore client IDs during each session. For your friend mechanic, you'll need to consider this when designing how users identify and friend each other, since you can't rely on the Normcore client ID as a persistent identifier. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------Realtime.clientID
andRoom.clientID
will always return0
.
<@365574199844274177> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant okay, but like a colorsync model placed on a realtime avatar. Can't I just manage a list of bools that are networked for each avatar? as this list of bools is a child object of the avatar. it will automatically be synced for each avatar right? just like the transform of a avatar
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, you can definitely use a networked list of bools on each avatar, similar to how ColorSync works. This approach makes sense for your friend mechanic.
When you place a RealtimeComponent (like ColorSync) on an avatar, it becomes part of the avatar's hierarchy and follows the same ownership rules. As mentioned in the documentation about RealtimeComponents:
RealtimeComponent documentation
Here's why this approach works well:
1. Ownership is already handled: Since the RealtimeAvatar sets ownership of the root RealtimeView to the local client, any components in that hierarchy will follow those ownership rules. As noted in the Common Questions documentation:
"RealtimeAvatar sets the ownership of the root RealtimeView to the local client. This is to ensure that only the local client can modify the avatar."2. Automatic synchronization: Just like RealtimeTransform synchronizes position data, your custom component can synchronize friendship status booleans. 3. Efficient: This is more efficient than creating separate networked objects. You would need to create a custom RealtimeComponent with a RealtimeModel that contains your list of booleans (or perhaps a RealtimeSet or RealtimeDictionary depending on your exact needs). Each avatar would have this component, and it would track which other avatars are "friended." Just remember that since client IDs aren't persistent across sessions (as we discussed), you'll need your own user identification system in your database to maintain friendship relationships between sessions. This approach is very similar to the ColorSync example from the Synchronizing Custom Data documentation, but instead of syncing a color, you'd be syncing friendship status. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@365574199844274177> Kapa.ai is still learning and improving, please let me know how I did by reacting below.