Cita de: juanma_teso date=1536101419@francoe1 Yo creo que Unity busca facilitar al máximo el desarrollo de juegos implementando diferentes funcionalidades, un ejemplo son las físicas, otra el networking, te lo dan lo más mascado posible si usas sus componentes, esto trae como consecuencia que gente con pocos conocimientos en programación empiecen proyectos y hasta los acaben, pero ya pasaba antes de Unet, hay decenas de juegos iguales en las stores precisamente por la facilidad que ofrecen los engines, sigues un tutorial, le metes modelos descargados y subes tu App, no les importa que haya errores o que te peten la memoria...
   
   
      Por esto no usar Unet me parece exagerar, la HLAPI está hecha con la misma finalidad, le metes los componentes que te dan y que tire como pueda, si tienes más conocimientos usas la LLAPI, pero al final es otra librería que tienes disponible, lo único que me extraña es que digas que esté mal usar la HLAPI o que no se deba usar...
   

Entiendo tu punto de vista, y tenes toda la razón, Unity trae componentes que ayudan a los "desarrolladores" a la hora de trabajar con el Engine.
 
Pero en mi caso, si alguien intenta aprender no creo conveniente que llegue a resultados sin saber qué está pasando, si no, intentaría que se nutra de información acerca de la temática e intente explorar, en el camino va a aprender muchas cosas -
 
Dentro del Networking no solo te encuentras con problemas como mover un ascensor, eso es un problema de desarrollo a nivel aplicación, tambien existen otras problemáticas que UNET no intenta solucionar y tampoco lo va a hacer, como Master Server y Dedicated Server a nivel estructural, y a nivel de RED FÍSICA capa 3 para abajo existen muchísimos otros inconvenientes que están fuera del alcance de UNET, como por ejemplo el NAT, MTU, Split Data, Fix Header y otros miles de problemas que hacen que los juegos luego no funcionen y se pasan meses buscando información sin tener noción de por qué no funciona. 
 
UNET tiene graves problemas, por esta razón la capa de transporte se reprogramo ya 3 veces, el problema es que no quieren liberar el Server Library para vender los servicios que proveen (el negocios de los CCU y uso de datos), los Relay Server son lentos y al final el resultado es un juego donde es imposible controlar la información.  
 
Por otra parte, si desarrollas todo un proyecto mezclando las mecánicas con networking terminas creando algo que es insostenible e inescalable, lo mejor es siempre ir estructurado, cada etapa lleva su tiempo y conocimiento, lo importante es no desesperarse un buen resultado es fruto de un gran esfuerzo.
 
Mi recomendación sigue siendo Leer y Practicar hasta conocer los conceptos básicos, tanto como para Networking, Physics, Collisions, UI, Animations, IK, la temática es indiferente, pero la gente tiene que entender que desarrollar un juego no es descargarse un Engine meter 2 cosas hacer un build y listo - 
 
Saludos . 

Cita de: juanma_teso date=1536062867Me parece excesivo crear un GameManager para ascensores, y crear una estructura propia... no sé para eso ya está el networking de Unity, qué hay de aquello de "no reinventar la rueda"? @francoe1
   

No, ¡HLAPI de UNET intenta reinventar la RUEDA!. Los desarrolladores con bajos conocimientos en NETWORKING no deberían tener contacto con estas librerías sin antes entender conceptos tan básicos como el Modelo OSI, protocolos de conexión, serialización de información, y varios conceptos más necesarios para entender qué está haciendo.
 
Mi propuesta es que detenga el desarrollo, e intente armar cosas simples como Chats TCP luego pasarlo a UDP, intentar en JavaScripts utilizar WebSockets con Node.js y otras tantas prácticas que van a ir dando los recursos necesarios para luego saltar a una librería y comprender qué es lo que está haciendo, para poder utilizarla.
 
@juanma_teso Me parece interesante que propongas una idea diferente, y estaría bueno poder analizar las pro y las contras de cada situación para poder sacar una conclusión con fundamentos.
 
 
 
Saludos.

@juanma_teso No se trata de optimizar o no las cosas, se trata de hacerlas como se debe - Lo que estas proponiendo es totalmente erróneo.

Siempre dije que UNET haría esto...
 
Ese código nunca va a funcionar, si el cliente y el servidor no tienen ninguna conexión estas creando un objeto Network sin ningún sentido -
 
LA LÓGICA no tiene que convivir con la capa de RED. Por lo cual mezclar las dos cosas es la peor práctica posible.
 
Todos los Clientes activan el ascensor desde un boton, ese botón envia un mensaje al GameManager "activa el ascensor número 3", el GameManager detecta que estás en una partida en RED y le ENVÍA la solicitud al Servidor, el servidor valida la petición y envia a todos los clientes un mensaje "activar el ascensor 3", el cliente tiene un interprete para los mensajes del servidor, este reconoce el comando y hace la acción solicitada.
 
¿Se entiende? el Ascensor, el Botón, y el GameManager NO TIENEN herencias o dependen de componentes NetworkBehaviour.
 
NetworkBehaviour dejalo solo para crear una clase NetworkConn donde tengas todas las funciones necesarias como SendCommand, SendAction, RequestState, RequestEvent, etc... 
 
 

Nunca debes guardar la clave de tus clientes, siempre se guarda el HASH (código alfanumérico) generado por algoritmos como MD5 - AES-256, RAS-2048, ETC.Cuando el cliente intenta validar la clave vuelves a generar el hash y comparas con el almacenado -
 
No te preocupes en que descubran tus claves, lo más seguro es que nunca lo intenten, si lo que quieren es acceder al sistema, lo normal sería intentar romper el sistema de logeo con técnicas de "hacking" menos avanzadas de criptografía inversa.
 
Si quieres tambien puedes convertir todos los datos del archivo a bytes luego implementar un sistema de ordenamiento que se pueda revertir y guardar los bytes "desordenados" por lo que si alguien intenta evaluar el archivo tendría que invertir mucho tiempo, por ejemplo, podrias guardar en los bytes 1 y 2 los segundos y en último y anteúltimo los minutos y con ese código ejecutar el algoritmo inverso -
 
También tienes tecnimas muchisimo mas simples como XOR -
 
Sin embargo todo se trata de criptografía, simple de entender en terminología, complicado de aplicarlo en la práctica.
 
 

primero necesitas almacenar todos los objetos en un arreglo, y preferentemente ordenados manualmente en el orden que deseas que se muestren.
 

public Transform[] Objectos = new Transform[0];

 
Luego creas 2 funciones, una función Next, Back y una variable entera para almacenar el índice actual, esto sirve para recorrer el arreglo y activar/desactivar los objetos correspondientes.
 

public int ObjectIndex = 0;
public void Next()
{
ObjectIndex ++;
ObjectIndex = Mathf.Clamp(ObjectIndex, 0, Objects.Length - 1);
    Objects[ObjectIndex].gameObject.SetActive(true);
    Objects[ObjectIndex - 1].gameObject.SetActive(false);
}
public void Next()
{
ObjectIndex --;
ObjectIndex = Mathf.Clamp(ObjectIndex, 0, Objects.Length - 1);    
    Objects[ObjectIndex].gameObject.SetActive(true);
    Objects[ObjectIndex + 1].gameObject.SetActive(false);
}

 
Ahola solo bastaría con llamar las funciones -
 
Saludos. 

Cita de: Obscure Tales date=1535875062Para cambiar el layer solo tienes que referenciar el gameobject y llamar a su componente Layer
   
   

gameObject.layer = 2;

   
      Te dejo por aquí un enlace a la documentación
   
   
      https://docs.unity3d.com/ScriptReference/GameObject-layer.html
   

La asignación tiene que ser recursiva, creo que Unity ya tiene un función que lo hace.

Cita de: juanma_teso date=1535739350Todo es cuestión de organizar bien, todo lo que quieras que esté sincronizado debe usar el networking, es decir el script del ascensor debe heredar de NetworkBehaviour.
   
   
      Después debes conocer los atributos [Server], [Command] y [ClienRpc], para que el ascensor se mueva en todos los clientes debe ser el servidor el que llame la función "mover", para esto el cliente debe usar su player para llamar la función del ascensor desde el servidor, es bastante confuso al principio, pero intenta hacerte una idea:
   
   
      jugador (cliente) -> Command -> jugador (servidor)  -> ascensor (servidor) -> ClientRpc -> ascensor(local).
   
   
      También puedes hacerlo llamando la función en el ascensor en el cliente y sea éste quien se comunique con el servidor, de cualquier manera la complicación está en las referencias pues la inicialización con el networking no se limita al Awake y al Start.
   
   
       
   

No necesariamente tienes que heredar desde NetworkBehaviour, tambien puedes identificar cada asensor con un ID unico en la escena, y luego que el "boton" que activa el le solicita la acción al servidor, imaginemos el comando como. 
 

   
      useobject=IDDelAsensor => useobject=100
   

[/quote]
 
El servidor interpreta el comando aplica su logica y le envia  todos los clientes el mismo comando, cuando el cliente recibe este comando activa el asensor con x id.

Cita de: Alvaro95 date=1535404748Y en el caso que quisiera añadir otra animación y que mientras tanto se quedara en ese mismo estado como seria?
   

 
 

Cita de: Alvaro95 date=1535385951Seria que solo sonara cuando la animación se reproduce, no cada vez que le doy a la R
   

Creo que ya llegaste a tu cuota diaria de ayuda en el foro, no digo que este mal preguntar pero te estás quedando en un mismo lugar por no buscar información, estas cosas son simples, solo basta con entender cómo funciona, no busques la solución a X problema sin hacer el intento de aprender la herramienta, Unity tiene muchisimas secciones para aprender dentro del ámbito de las animaciones. 
 
Para aprender sobre esto te recomiendo la documentación oficial. 
 
https://docs.unity3d.com/ScriptReference/UnityEngine.AnimationModule.html
 
 
 
Saludos

Cita de: Mcloud date=1535408275Pues gracias a eso he conseguido ver lo que parece que me falla, me dice lo siguiente:
   
   
      <i>AndroidPlayer(samsung_SM-T813@192.zz.cc.xx)</i> System.DllNotFoundException: sqlite3

        at (wrapper managed-to-native) Mono.Data.Sqlite.UnsafeNativeMethods:sqlite3_open_v2 (byte[],intptr&,int,intptr)

        at Mono.Data.Sqlite.SQLite3.Open (System.String strFilename, SQLiteOpenFlagsEnum flags, Int32 maxPoolSize, Boolean usePool) [0x00000] in <filename unknown>:0 

        at Mono.Data.Sqlite.SqliteConnection.Open () [0x00000] in <filename unknown>:0 

        at AccesosBBDD.OpenDB () [0x0014b] in C:\Users\mgale\Documents\RTG\RPG\Assets\Scripts\AccesosBBDD.cs:46 
   
   
      Actualmente la libreria sqlite3 la tengo dentro de Assets\Plugins\x64\
   
   
      el resto cuelgan de Plugins, he probado a ponerla dentro de una carpeta "Android" pero nada, y colgando tambien de Plugins, pero tampoco...
   
   
       
   
   
      El path de conexion con BBDD lo tengo asi
   
   
      string path4 = "URI=file:" + Application.dataPath + "/StreamingAssets/Personaje.db";
   
   
      porque con string path2 = "jar:file://" + Application.dataPath + "!assets/Personaje.db";
   
   
      no me funciona en local, no se si he entendido bien el funcionamiento...si yo tengo en local mi BBDD con sus tablas, cuando hago la APK y lo instalo, debo crear una clase/metodo para qeu compruebe que estan creadas? porque no tengo nada controlado...entendia que iba todo en el pack....
   
   
       
   
   
      gracias de antemano 
   
   
       
   
   
       
   

A ver, el problema sigue siendo la ruta, puedes crear una condición para generar la ruta para diferentes plataformas, con flags o con código condicional.
 

public static string GetStreamingAssetsPath(string relativePath)
{
  if(Application.platform == RuntimePlatform.WindowsPlayer)
      return "URI=file:" + Application.dataPath + "/StreamingAssets/" + relativePath;
  else if (Application.platform == RuntimePlatform.Android)
       return "jar:file://" + Application.dataPath + "!assets/" + relativePath;
}

 
 

Cita de: Eskema date=1535386221Yo me he pasado al A* pathfinding de aaron granberg y es un buen plugin para el tema navegacion/pathfinding, luego sobre eso ya construyes tu IA y tirando millas.
   
   
      Los wheelcolliders yo los descarte e hice directamente un script de "rueda" con el tipico raycast al suelo para checkear las normales y con eso ya darle friccion a la rueda, distancia de amortiguador, etc, etc, la verdad es que me costo 1 mes el maldito script, pero menudo mundo en cuanto a velocidad de uso y de consumo de recursos. Para mi que los wheelcollider son para tener varios PCs de la NASA trabajando con multiples CPUs en cluster porque chupan rendimiento como si te regalaran las CPUs xD
   

Si, actualmente estoy trabajando en un sistema de WheelColliders propio, estoy un poco perdido con el deslizamiento horizontal, aun no estoy logrando algo decente, pero calculo que un tiempo voy a lograr algo mejor que Unity para el objetivo que quiero lograr. 
 
Si tienes por algo sobre el tema que explique pasame por MP jajaja, si no es molestia.

Cita de: Eskema date=1535385439Llevo varias semanas dandome con el tema de la IA + navegacion + local avoidance y he flipado en colores con el video. Y como dices, la documentacion aunque simplona (como siempre en unity) te da buenas pistas. Luego cuando lo dominas pasas del navmesh de unity y te pillas un plugin y vives mas feliz XD
   

Hace 4 días no duermo intentando sacar el demonio que tiene mi vehiculo con WheelColliders, estoy armando un sistema de físicas de vehículos haciendo uso de WheelCollider, y como todo lo que te da UNITY es de MALO para ABAJO, siempre me pregunte por que no mejoran o directamente lo sacan  - 
 
Hace varios años no toco NavMesh, pero me toco hacer un trabajo y la verdad es que es ¡HORRIBLE!  -

 
 
Se va un poco del TOPIC pero no gasten tiempo con NAVMESH utilicen A* o mejor aún si se trata de un juego simple puedes programar tu propio algoritmo basada en la teoría de grafos ... 
 
El punto que mas me molesto de NavMesh es la optimización, cuando tienes múltiples agentes, no se puede trabajar en hilos independientes, juegos como AoE hacían una cola para que el sistema resuelva una ruta a la vez, y esto era mas optimo, a esto se le aplicaba una resolución progresiva, es decir, resolvía de a diez pasos entonces al tenes muchas unidades no se veía afectado..
 
 

Cita de: Eskema date=1535384975Se nota claramente que el tipo no entiende lo que esta haciendo, mezclando conceptos como poner el obstacle, o quitar el rigidbody a un collider que luego mueves, forzando al sistema de fisicas a recalcularse y a perder mucho rendimiento.
   
   
      Gran tutorial sin duda alguna!!! xDDD
   

Pero, se fue por las ramas explicando algo que no tiene explicación.... LA DOCUMENTACIÓN de UNITY tiene todo explicado a lujo y detalle... no entiendo por que la gente busca en los lugares incorrectos.. 
 
Bueno.. Pero eso da más ventaja a los que estamos desarrollando... 

Cita de: Eskema date=1535384537He visto tutoriales malos, pero este se lleva la palma!!!, menudo monton de mierdas para contarle a la gente que luego dira "mi juego no funciona muy bien", seguro que no lo hace si sigues estas indicaciones..... 
   
   
      pioj tu antes molabas!! xD
   

¡Gran observación! 

Cita de: Mcloud date=1535382668 
   
   
      Si. estoy en ello gracias, había creado unas escenas y quería ver como quedaba en el móvil y la tablet y de ahí me ha salido el problema de la conexión con la BBDD, pero claro no veo mensaje ni nada, entiendo que es por eso porque se conecta cuando le doy al botón de continuar y....nada de nada, pero claro no tengo ningún mensaje, estoy investigando ahora para ver como dejar un log o algo
   
   
      Gracias
   

Para esto puedes utilizar la consola de Unity te podes conectar a los equipos a través de IP. y si no, programas una consola unity tiene los eventos de los debug públicos para capturar.