koobas.hobune.stream
Nicknames in multiplayer
I've some problems with nicknames creating in multiplayer.
Can anybody give me a clue how do i have to do it?
Do you mean your trying to make different users or accounts and display there usernames?
Post the relevant portion of your script. It's impossible to tell what you're doing wrong from the amount of information that you gave.
Basically you'd need to share the name with other players using RPCs like Bunny83 said. To learn how to use Unity built in networking, I suggest you check out the Unity Networking Zero to Hero Guide here:
If you want to make a custom server for use with Unity, check out the video series here:
Basically it's done like this:
When a client joins or changes it's nickname he has to send it via RPC to all other players.
The server (which is also a player) stores the names for each player.
When new client connects, the server sends a nickname update only to this new player for every other player the server has on his list.
Now it depends on where you store the nicknames. When each player has a player object, it's probably the easiest to store it in a variable of a script on that object.
That's how a player script could look like. Each player object needs of course a NetworkView and in this case it's owned by the respective player.
//C#
using UnityEngine;
public class PlayerObject : MonoBehaviour
{
private string m_NickName = "";
void Start()
{
// maybe reload the last used name from PlayerPrefs or generate a random name
BroadcastNickName();
}
public void BroadcastNickName()
{
networkView.RPC("UpdateNickName", RPCMode.All, m_NickName);
}
public void SendNickNameTo(NetworkPlayer aPlayer)
{
networkView.RPC("UpdateNickName", aPlayer, m_NickName);
}
public void ChangeNick(string aNewNickName)
{
if (!networkView.isMine)
return; // We can only change the nick when we are the owner of this player object
m_NickName = aNewNickName;
BroadcastNickName();
}
[RPC]
void UpdateNickName(string aNewNickName)
{
if (networkView.isMine)
return; // We don't want others to change our nickname
m_NickName = aNewNickName;
}
}
On the server you would have a manager class which holds a list of all connected players and their player objects:
//C#
using UnityEngine;
using System.Collections.Generic;
public class Manager : MonoBehaviour
{
private List<PlayerObject> m_Players = new List<PlayerObject>();
void OnPlayerConnected(NetworkPlayer aPlayer)
{
foreach(PlayerObject P in m_Players)
P.SendNickNameTo(aPlayer);
}
}
Of course the Manager has to keep his m_Player list up to date, so when a player object is created he has to add it to the list and when he leaves he has to remove it.
When ever a client wants to change his nick, just use ChangeNick();
It depends on how and where the Player objects are created. Maybe you have to do the SendNickNameTo calls a bit later when the new client is ready to receive all nicknames.
may have misunderstood...
"When a client joins or changes it's nickname he has to send it* via RPC to all other players. The server (which is also a player) stores the names for each player."
Surely, when a client joins, that new client sends a nickname etc. to the server only. The server then sends it to everyone.
Well, of course all communication goes through the server, but RPC$$anonymous$$ode.All effectively sends the RPC to everyone. A client can also send an RPC to another client so it's only executed on this particular client. The RPC passes through the server, but the server doesn't execute the RPC, it just redirects it ;)
"Well, of course all communication goes through the server"
well of course! it's obvious! :)
it's important that the New Networker understands that the server does everything.
I think, a good thought for new networking programmers is that conceptually the clients should be as dumb as possible, and conceptually one should adhere to a hub-and-spoke model as much as possible.
As you say, technically on this system it is possible that ... "A client can also send [a message, effectively directly to] to another client"
Sure, but you can also program with globals and infinite loops!
the hello-Networking-Program$$anonymous$$g formula for "nicknames" is something like
for clients...
when you connect tell the server your desired nickname
have a function "the server has told me my nickname..."
have a function "someone else's nickname is..."
have a function "someone has left the game..."
for servers...
have an Array (jk) holding all the nicknames
have a function "someone's told me their nickname"
have a function "someone's has dropped off or said goodbye"
have a function "tell everyone someone's nickname"
have a function "tell everyone someone has left"
As a wise man said about $$anonymous$$P networking "at every step you have to engineer as much stupidity as possible into clients"
(Hopefully this benefits Noob Networking Friends.)
Thinking about $$anonymous$$P networking ......... it's very much like remembering ..... being in a war :-O
Of course I'm a big friend of authoritative servers, but things like Network.Instantiate works against this concept. So basically Unity's network is designed to be non-authoriataive in the first place. I would say 90% of the people who first head into networking in Unity will do an non-authoriative approach as suggested by most examples in the docs.
The golden rule for the server-client model is usually "never trust a client" but that's not always applicable.
Even a 100% authoriative server (like Quake, my favourite example :D) does not prevent cheating. I would even guess around 20-30% of all players on Quakelive use cheats (wallhack, smooth aimbot, triggerbot, ...). After i found a cheater in my own clan i stopped playing QL.
"but [unity's approach] works against this concept..."
"Unity's network is designed to be non-authoriataive in the first place.."
"say 90% of the people who first head into networking in Unity will do an non-authoriative approach..."
Yeah, I understand exactly what you mean when you explain it that way. O$$anonymous$$.
(Naturally I just ignored / did not really notice :) the non-spoke aspect of Unity, worked around it, and produce normal networking concepts! :) )
Indeed - the same applies with apple's humorous "game kit" system. It leads to the phenomenon where you get kid programmers who think it's normal to converse client-to-client. And then later they are curious about the almost-impossible difficulties that brings.
So, if what you're saying here is 1, 2, 3...
(1) as it happens, Unity's networking presents a very non-spoke face. For that reason,
(2) the fact is every new programmer learning with Unity will whackily grow up using non-spoke networking concepts
(3) it's pointless trying to tell them that this is raving macabre bizarreness, might as well go along
Well fair enough, (2) overrides everything.
Now you mention ..
"Even a 100% authoriative server [ ] does not prevent cheating"
Well that's a bit basically completely wrong dude. You know about online casinos as well as smaller online systems like eg. the world's stock markets, and credit card switches, AT$$anonymous$$ networks, and so on!!! Heh!
Sad to hear quake has gaps in it!
If you're saying (further) that games like quake must logically have some sort of gaps (I can't think off the top of my head how that could possibly be, but if so I believe you) then ok. (Is that what you're saying? It sounds very strange and beyond-Turing you know?!)
{Obviously in for example realtime games there are incidental matters where you don't CARE if the code is gappy. But I can't see any reason that some concept has to be gappy.}
Finally, you say "Network.Instantiate works against [networking]"
I'm not entirely sure that's true. You can set velocity in Unity physics... but that hardly works against using physics. There's jut one line of documentation somewhere that mentions "oh you probably wouldn't normally do this, it's not physical". Similarly you could have a line of docu somewhere that says "oh normally only the 'server' would Instantiate stuff"
