Perdon,estoy un poco verde en este tema de redes. Te cuento un poco la forma en que estoy implementandolo. La idea es crear la partida con el matchmaker de forma automatica, ocultando el networkmanagerHud. Una vez este creada la partida se iran uniendo ahi los siguientes jugadores al iniciar juego hasta llenar la partida. Todo lo estoy haciendo con el networkManager de unet. No se si es una buena solucion. Seguro que habría algunas opciones mejores. O sea en resumen, estoy usando las funciones que te da la NetworkManagerHud de unet sin que el jugador sepa que la esta usando. Creare mis propios botones adaptados a mi menu.
 
Basicamente la idea es que el jugador abra la apk,vea un espacio donde meter su nombre,elija el tipo de muñeco que quiere selccionando un boton de entre 3.Y entre a la partida en la que ya habra jugadores jugando.La unica diferencia con el famoso Slither.io es que en el nuestro antes de entrar tienes q elegir un muñeco entre 3 tipos.

Bien, entonces primero deberias definir bien la estructura del proyecto, la información requerida para la representación de los cliente, por ejemplo, si tienes 3 diferentes "Objectos de Jugadores con sus configuraciones" supongo que tienes de estos 3 prefabs, el error que se comete habitualmente es crear un Objecto Network Identity por cada una de las configuraciones, para que todos los clientes sincronicen el tipo de jugador que seleccionaste primero deberias establecer una regla de sincronización, es decir, cuando un cliente nuevo se conecta al servidor pasaría esto.
 

1. 
      Cliente se conecta al servidor.
   


2. 
      Servidor envía información los diferentes setup de player template con sus configuraciones, esto puede ser en JSON. 
      
   
   
   1. 
               {Id: 1, ObjectPrefab: "Player/PlayerA", AttackTime:1, AttackDamage:10}
            
   
      
   
   


3. 
      El cliente interpreta la información recibida y muestra en pantalla las diferentes opciones.
   


4. 
      El paso 2 y 3 se pueden obviar pero de esta manera evitas infracciones en la información.
   


5. 
      El Cliente envía al servidor su selección -
   


6. 
      El Servidor envía al cliente un conexión a la partida.
   


7. 
      El Cliente se conecta.
   


8. 
      El Servidor spawnea el Object del Cliente con todas sus configuraciones, seguido a esto, envía a todos los clientes la informaciones del cliente, para que estos puedan tener un instancia del mismo.
   


9. 
      El Cliente confirma que tuvo éxito en la instancia y carga de recursos y el cliente le da el "Ok" para empezar a interactuar.
   


10. 
       Desde aquí empieza la arquitectura del cliente/servidor propia del juego.
    

Tienes que recordar algo, la información dentro del cliente puede ser modificada a gusto, por lo cual tenes que asegurarte de que el cliente tenga siempre un información actualizada, es por esto que se crean múltiples backend para este trabajo -
 

• 
     Servidor de recursos
  


• 
     Servidor de datos
  


• 
     Servidor de salas
  


• 
     Servidor de partidas
  


• 
     Servidor de sesiones
  

Entre todo estos servidores existen diferentes métodos de conexión, es por esto que UNET no sirve para trabajar debido a que compartimos el servidor con el cliente para que este pueda funcionar. Si el cliente HOST modifica la información entonces todos los clientes se verian afectados -
 
----------------------------
 
No es necesario utilizar NetworkManagerHud, ya que lo único que hace este mismo es utilizar funciones de NetworkManager, La función para iniciar el servidor es StartHost y para el cliente StartClient, luego tienes múltiples configuraciones para cada una -
 
En estos dias voy a compartir un tutorial básico sobre esto, en este momento no tengo tiempo para terminar de acomodar algunas secciones que no me gustaron mucho como están, pero de a poco iré liberando información obvio por UnitySpain y mi blog personal el cual ya cuenta con información sobre UNET 
 
http://unitydoc.blogspot.com.ar/
 
 

francoe1, he pinchado en tu blog y al final me he visto los 5 videos de sistema de armas. No me valen para nada pero tengo que decirte que eres muy bueno y explicas bien. Deberías hacer mas videos de estos para gente que empieza pq verdaderamente lo haces bien.

Otro detalle es que no es necesario que los objetos hereden del networkgameobject de unet. Se envia los datos de partida (via json como dice francoe) y cada participante crea los objetos necesarios sin tener la "magia" de autocrearlos con el sincronize que viene de serie. Vamos que con ser un monobehaviour de toda la vida vale.
 
Ademas te ahorras enviar datos inutiles en la mayoria de casos (toda la clase "player", cuando solo quieres colocar el player en pantalla) 

Cita de: J_L date=1516615463francoe1, he pinchado en tu blog y al final me he visto los 5 videos de sistema de armas. No me valen para nada pero tengo que decirte que eres muy bueno y explicas bien. Deberías hacer mas videos de estos para gente que empieza pq verdaderamente lo haces bien.
   

Gracias, no seguí metiendo información por temas de horario, nunca tenia tiempo, pero ahora tengo un material aceptable y una propuesta con @pioj que quedo en el aire, por lo pronto estoy viendo de que manera lo puedo compartir gratuitamente y obtener ganancias aceptables.

@francoe1, tengo muy presente esa propuesta. Estoy buscando la forma de llevarla a cabo... 

Cita de: pioj date=1516645248@francoe1, tengo muy presente esa propuesta. Estoy buscando la forma de llevarla a cabo... 

Genial, gracias!! 

 
 

Cita de: francoe1 date=1516581759Entre todo estos servidores existen diferentes métodos de conexión, es por esto que UNET no sirve para trabajar debido a que compartimos el servidor con el cliente para que este pueda funcionar. Si el cliente HOST modifica la información entonces todos los clientes se verian afectados.O lo que quieres decir que con unet no se puede hacer como backend para este trabajo:
   

entonces quieres decir q para mi modelo de juego no valdria usar UNET porque si por ejemplo,un jugador consigue nivel 2.todos los jugadores tendran nivel 2 porque todos los clientes se verian afectados?
 
O es porque no se puede crear ese backend (varios servers dedicados cada uno a una cosa)?
 
Que otra herramienta podria usar entonces?Photon por ejemplo?
 
Muchas gracias por las respuestas,cuando te canses de tanta pregunta me lo puedes decir jajaja q soy un poco pesado.Pero es que tiene tela el tema del online

Cita de: ebenknot date=1516878981 
   
   
      entonces quieres decir q para mi modelo de juego no valdria usar UNET porque si por ejemplo,un jugador consigue nivel 2.todos los jugadores tendran nivel 2 porque todos los clientes se verian afectados?
   
   
      O es porque no se puede crear ese backend (varios servers dedicados cada uno a una cosa)?
   
   
      Que otra herramienta podria usar entonces?Photon por ejemplo?
   
   
      Muchas gracias por las respuestas,cuando te canses de tanta pregunta me lo puedes decir jajaja q soy un poco pesado.Pero es que tiene tela el tema del online
   

No, lo que quiero decir es lo siguiente, cuando pretendes compartir un servidor a los clientes deberias de estar consciente de que estas compartiendo la estructura del mismo, esto quiere decir tu bases de datos, tus configuraciones, dll, etc.
 
Entonces, si tu compartes esa información los usuarios podrán modificarla a gusto, por ejemplo, si cuando juntas X objeto te da 100 puntos el cliente servidor podría modificar para que te de 1000, pero esto se debe a que estas compartiendo el cliente, ahora si piensas hacer Matchmaking con Unity y tener algunos valores generales como Ranking de jugadores esto supondría un gran problema.
 
En los juegos multijugador solo deberias compartir la lógica del cliente -
 
Las capas serían las siguientes -
 



      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   


      
      
   

Server	Shared	Client
Data Provider
Sesion Provider
RoomProvider
Logic Provider
Network Provider
	NetworkTransport
		Network Provider
		Network Logic
		Network Hanlder
		Logic Provider

Si tu creas una estructura con UNET estas compartiendo todo con el cliente, a diferencia de si lo creas con un clásico Servidor/Cliente - Tendrias que crear tu propio sistema basados en Socket (se puede utilizar eNet), mas las capa NetworkTransport que es la que se encarga de conectar el cliente con el servidor y transportar tu información, aqui se encriptan los datos, se aplican las reglas de compresión, el tratado de paquetes etc.. 
 
¿Se entiende?

Perdon por la tardanza.Muchas gracias por la ultima respuesta,nos has ayudado mucho.Creo que ya vamos bien encaminados,la verdad es que necesitabamos empezar a diseñar un poco el juego para ir tirando con el tema online.Era una locura empezar solo pensando en la estructura del online.Si tengo mas dudas te molestaré un poco mas jejeje.Mil gracias

Buenas,perdon por volver tan tarde a este post pero esq estabamos terminando el juego y funciona todo bien. El juego es estilo el slither.io .la parte multijugador funciona igual,o al menos eso queremos. La semana que viene tenemos q llevar el juego a la Gamepolis de Malaga y tenemos el problema de que creamos una partida con el matchmaking de unet(server) y se unen maximo 20 jugadores (clients),ya que tenemos version gratuita de unity. A los pocos minutos se cae la partida(digo yo que será porque unity te dejara un trafico pequeño para q puedas probar). Es asi?? o se cae la partida por otra cosa?  Mil gracias por la ayuda , (><) vamos contrareloj....

Escribime por MP y te doy una mano.

Vale Francoe1,muchas gracias