Hola,
 
@TheBullet yo lo hago servir al revés, es decir, de Game Data y de ahí es de dónde voy creando los objetos. En tu caso tendrás algo similar a esto.
 
Pero encuentro que es estupendo para crear ya en él las relaciones e interacciones. Por ejemplo, yo tengo:
 

 
Y como puedes ver ya creo las relaciones directamente en tiempo de diseño.
 

 
Con lo cual aparte de crear las clases directamente desde aquí, ya veo como se van linkando las relaciones en tiempo de diseño, con lo que veo los errores rápido, aparte de que una vez consiga crear la herramienta, puede ser un editor de escenas o de niveles rápidisimo. El problema viene cuando tienes muchas clases ya linkadas. Te encuentras con un pastel como este:
 

 
Como puedes ver, se ha perdido toda la facilidad de seguir y comprobar con un vistazo y de generar rápido relaciones, escenarios y/o niveles. Quizá es un poco deformación profesional. Hacía años que no programaba. Tras años de programar en C++, hace años que lo más cercano que he hecho es el diseño y administración de bases de datos, con lo cual lo concibo como tal y lo diseño del mismo modo y es la función que me viene como anillo al dedo, ya que así es como me encuentro como pez en el agua.
 
Aún me faltan por averiguar cosas, como si los cambios en las clases se reflejan en el ScriptableObject en tiempo de ejecución (Vamos, si es lectura/escritura o sólo lectura) o si puedo hacerlo servir como SaveGame, o si caerá mucho el rendimiento cuando le meta chicha de verdad, pero vamos, que son cosas que trasteando iré averiguando, el caso ahora mismo es conseguir racionalizarlo para poder seguir trasteando y hacer pruebas y ver hasta dónde se puede llegar.
 
 
 
@lightbug Bueno, lo hice así por qué así lo había visto en varios sitios. De ahí había sacado la conclusión de que el área era persistente hasta que se sobreescribía, ya que de otro modo no le encontraba sentido. Ya me extrañaba que de ser persistente no hubiera modo fácil de referenciarlo.
 
Bueno, como serán varios, un toogle exactamente no, quiza un SelectionGrid o algo similar se adaptara más. Pero me lo anoto y en cuanto pueda lo pruebo, Gracias, ya veo que era un concepto erróneo una vez más.
 
Puedes ver un ejemplo en la respuesta al compañero, justo arriba de este post.
 
Por un casual no sabrás dónde se han de poner los Scripts con los PropertyDrawer? Si es así ya te invito a una cerveza o a lo que quieras!!! 

Buenas, vuelvo nuevamente con un montón de dudas, la mayoría seguramente tontas, pero llevo una semana y pico trasteando con el tema y me parece que cada vez más perdido.
 
Para ponernos en situación, tras que @GSG3D me descubrieran esa maravilla del ScriptableObject, que se adaptaba como un guante a mis necesidades, he puesto codos en el tema, y he rehecho mi proyecto. El caso es que es sencillo, intuitivo y funciona fantástico como base de datos, lo hace todo de maravilla. Ahora bien, al emplearlo como base de datos, tiene un problema, y es que al manejarlo desde el inspector, para que nos hagamos a la idea, tengo una clase que referencia a otra clase, y esta a otra y esta a una colección de otras clases y así, con lo cual a la hora de establecer las referencias en el inspector es un caos de desplegables y datos que es muy difícil ir siguiendo.
 
Bueno, así que empiezo a buscar por dónde puedo racionalizar la edición de toda esta información. Y aquí es dónde empiezo a liarme como un trompo. Bien, primer paso lógico, la documentación oficial. Ahí me encuentro con la posibilidad de crear Property Drawers. Sobre la claseA puedes crear:
 
[CustomPropertyDrawer (ClaseA)]
 
class ClaseADrawer : PropertyDrawer {}
 
Bien, hasta aquí bien. El caso en que no he conseguido encontrar en ningún lado que digan dónde se ha de meter el dichoso script para poder jugar con él. Digo yo que será en la carpeta editor, pero no me funciona. En la clase original? También he probado y me ha tirado muchos errores. Seguro que algo hago mal, pero no puedo saberlo a ciencia cierta si de buen inicio no sé dónde se mete.
 
Por otro lado, investigando esto, doy con la posibilidad de crear tu propia ventana del editor, Bien, estupendo. La verdad es que encuentro información muy buena y es sencillo de hacer. Ahora bien, a la hora de dotarlo de contenido... Ahí nuevamente no me salgo. Pienso hacer una ventana con tres secciones en vertical, la de la izquierda, tendrá unos botones de arriba a abajo con los diferentes tipos de clases que tiene mi proyecto. La idea es que al pulsar el botón de una determinada clase, se listen todas las instancias con sus propiedades y referencias, como en el editor (Y con sus Property Drawers cuando consiga hacerlo) y que al hacer clic sobre una referencia se listen todas las instancias del tipo de la referencia en el panel de más a la derecha, para poder seleccionarlas con un simple clic. Consigo dividirlo en tres con la propiedad BeginArea y EndArea y queda bien. Pero al insertar el BeginArea dentro del if(GuiButton) como dicen en la documentación me desaparece y temo que es porqué la crea como un subarea dentro del primer área. En fin, que voy más perdido que un bacalao en el Sahara. Si alguien pudiera echar un poco de luz, me diga si voy bien encarado o estoy confundiendo cosas, o conoce algún tutorial que vaya un poco más allá de simplemente poner un botoncito y alguna cosa más, algo más elaborado, estaría muy agradecido.

Vaya, lo veo tarde.
 
Lo cierto es que considero que aún estoy muy verde, y por si fuera poco, dispongo de poco tiempo, pero sería una oportunidad estupenda de aprender si me admitís. Me podría encargar de ese código tedioso que nadie más quiere hacer...

En mi caso, hasta ahora, creaba un GameObject ControlDeJuego, el cual guardaba todas las referencias de los objetos en diferentes diccionarios y se encargaba de las interactuaciones entre ellos (así las quitaba del Update y en vez de hacerlo en cada Frame, lo hacia cada X tiempo). La verdad es que los prototipos funciona estupendamente, el problema estaba cuando se empezaban a multiplicar los objetos, caía el rendimiento en picado. Por eso pensaba de segmentar para no tener siempre todos los objetos y tener sólo una representación de las agrupaciones de los mismos. De ahí mi duda de como hacerlo del modo más conveniente. Así pues ahora usaré ScriptableObject como Base de Datos para guardar todos los datos del juego, ya que la estructura invita a ello, y cargaré los GameObjects a través de prefabs y los alimentaré de datos desde el ScriptableObjects según convenga. Aún hay algunos puntos que no veo bien como resolver, pero el conjunto lo tengo más que claro.
 
La verdad es que inglés aunque lo entiendo tengo la sensación de estar perdiéndome cosas... Y en castellano no encuentro nada de nada... Pero bueno, poco a poco de ir viendo como hacen me voy quedando con la copla y espero no perderme mucha información esencial...
 
Nuevamente muchas gracias.

Cita de: GSG3D date=1489438392http://answers.unity3d.com/questions/999455/difference-between-monobehaviour-and-scriptable-ob.html
   

 
 

Cita de: lightbug date=1489438592Hola, q preguntita jaj.
   
   
      Lo que te puedo decir es que "Monobehaviour" es un "Behaviour" quie es un "Component" que es un "Object", en teoria es un Objeto mas de Unity, como transform, meshrenderer, scirpts, etc. Si creas tu clase "pura" como decis, ya no seria ningun objecto de Unity, es decir que dentro de dicha clase no podrias referenciar nada. Podes verlo como que tenes los nombres pero no la funcionalidad. Fuera de dicha clase (en monobehaviour) podes referenciar los datos de la clase pura. Pero creo que no es de mucha utilidad, la clase pura la utilizarias como una clase de datos, como cuando guardas una partida o algo parecido.
   
   
       
   
   
      Tener muchos monobehaviours nunca es recomendable, no pensaste en emplear un ScriptableObject para mantener los datos de las unidades y demas, es super util sobretodo si tenes pensado hacer un RTS.
   
   
      Saludos
   

Hola, gracias a los dos por las respuestas. Digo poco, miles de gracias.
 
Es por esto que me gusta hacer preguntas retóricas, siempre aprendo cosas que ni sabía que existieran.
 
Llevo toda la semana leyendo la documentación, viendo el Training y haciendo pruebas y la verdad es que se adapta como un guante a lo que necesito. Es una pasada, prácticamente se puede armar el juego ahí, estructurando los datos a la perfección.
 
Aún así siento que hay cosas que me pierdo, quizá por qué no domino el inglés tanto como quisiera y busco documentación y veo que hay bastante poca al respecto. Es como si fuera una parte que no todo el mundo conoce o que no acostumbren a usar... 
 
Si por un casual alguien conoce algún tutorial completito lo agradecería. Y si es en castellano, ya hago un monumento!!!
 
Nuevamente, miles de gracias.

Hola,
 
Bueno, os explico esa duda o medio duda que me ha surgido así de pronto, a ver si me se explicar bien.
 
Imaginemos un juego que se compone de centenares o miles de objetos, todos con unas determinadas características que me permiten por un lado crearlos fácilmente de una una docena de familias de prefabs y por otro lado agruparlos para controlarlos en un único objeto en determinadas circunstancias, de forma que no necesito esa sobrecarga de miles de objetos arriba y abajo por todo el juego (para hacernos una idea, como los ejércitos en el Total War, que en el plano estratégico son una sola pieza y no es hasta descender al plano táctico que cada unidad toma entidad, o por poner otro ejemplo, una flota de centenares de naves, que tomando la velocidad y el destino, no necesitas las naves individuales hasta que se encuentran con una flota enemiga)
 
Así que la idea es generar un pool de unidades/naves o lo que toque, y moverme en el plano general con unos pocos GameObjects que contendrán la información de conjunto (numero de naves/tropa, total de cada subtipo, velocidad de conjunto, salud promedio y cosas así) y en el momento que sea necesario tomar los GameObjects necesarios del Pool y alimentarlos con los datos para darles la entidad.Hasta aquí el planteamiento en sencillo. Creas uno o más diccionarios para guardar todos los datos de las naves/unidades simuladas, y en el momento necesario en que una agrupación/flota/ejercito pasa al plano táctico, seleccionas de los diccionarios los objetos involucrados a través de LINQ y pasas los datos adecuados a cada uno de los objetos activados del pool. Hasta aquí todo bien. Pero aquí se me plantea la duda.
 
Los objetos guardados han de ser "puros" o heredados de MonoBehaviour.
 
En el caso de objetos puros, puede que necesiten tener referencias a GameObjects y otros elementos particulares de Unity. Pueden tener objetos que no hereden de MonoBehaviour referencias a Objetos propios de Unity?
 
En el caso de heredar de MonoBehaviour, bastaría con añadir directamente el componente seleccionado al Prefab instanciado, pero al hacerlo, no estaré sobrecargando el sistema con datos innecesarios? Tener miles de Componentes con MonoBehaviour, incluso para clases sencillas de un par o tres de datos, puede ser en si mismo una burrada por toda la cola que puede traer el MonoBehaviour? Puede tener efectos secundarios por la acumulación?
 
Reflexionando sobre ello, me he dado cuenta de mi ignorancia al respecto, y buscando tampoco he sabido encontrar nada que me indique como es mejor encarar el tema...
 
Muchas gracias a todos.

Cita de: ytinU date=1484418501No sé si es lo que buscas sobre los segundos, pero puedes usar IENumerator.
   
   
       <
   
   
      private void Start()

          {

              //Llamar al IEnumerator

              StartCoroutine(cot(4));

          }

          IEnumerator cot(int a)

          {

              yield return new WaitForSeconds(a);

              algunmetodo();

          }

          private void algunmetodo()

          {

              print("Hola");

          }
   
   
      >
   

Pues parece buena opción. Voy a informarme a ver si por ejemplo permite fracciones de segundo (Sólo necesito milisegundos para que cargue los datos) y si muchas de ellas cargan mucho el sistema, ya que lo voy a tener que implementar en muchos gameobjects. Gracias!!! 

Cita de: ytinU date=1484417508Gracias, entonces de ese modo podré ver las salas que se creen y podre hacer un sistema para que se vean las salas?
   
      Algo así quiero que sea,por eso deseo saber si las preguntas van bien encaminadas.
   

No lo que te estoy diciendo es lo que necesitas para que sea accesible desde el mundo mundial. Lo que configures o lo que haga el software que programes es otra cosa. Con una Ip fija pública cualquier usuario podrá acceder si por ejemplo registras esta ip en el software cliente, te permitirá que pueda conectar cualquier dispositivo con internet. Luego ya si quieres rizar el rizo, puedes comprar un dominio (tipo www,midominio,com) y así los clientes podrían acceder por DNS, y en caso de cambio de la IP no necesitarás actualizar todos los clientes, sólo el registro DNS.

Cita de: ytinU date=1484410751No tenia idea de que funcionara así, ya me parecia raro de que no tengan lag xD, entonces no debo preocuparme mucho de que mi juego sea algo robusto.
   
   
      El ejemplo de los 8000 jugadores aclaró muchas de mis dudas, pero surgió otra duda..No sé como se organiza un juego online, me refiero al tema de los servidores, no sé explicarme así que daré un ejemplo:
   
   
      -Un juego online el más básico es que tu seas algo como tu propio servidor, lo cual indica que alguien que no este conectado a tu misma red no podrá acceder, si yo rento un servidor este podrá ser como una red global?, donde podrán acceder los que no esten en mi red dentro del rango del servidor rentado?.
   

Te contesto la parte del servidor que es lo que domino un poco más. Si rentas un servidor, hazlo con una IP fija pública. De ese modo será accesible desde todo internet.

Hola, seguro que muchos os habéis encontrado en un caso similar, y seguramente la solución es fácil, pero no consigo dar con ella.
 
Veréis, el caso es el siguiente, en un GameObject creo un diccionario, en otro cargo los datos y finalmente en un tercero los leo para su uso. El caso es que en todos uso el Start para cargar las referencias entre objetos y componentes. Lo hago en el Start para estar seguro de que todos existen (Se han generado) y no me va a fallar por ahí. Pero el caso es que en el momento de lanzar el juego, la función del tercer objeto me da error en el diccionario, casi seguro por qué el segundo elemento aún no ha cargado los datos en el diccionario (Aparte del error que me lanza, es que si aguardo que me salte el error y continúo todo me va perfecto) y mi pregunta es, hay algún modo de indicarle a Unity que ejecute el Start dejando algunos GameObject los últimos o por un orden(esto sería ideal) o de decirle dentro del Start que aguarde aunque sea un segundo? O alguna función que se ejecute una única vez tras el Start? No quiero meterlo en el Update por qué me forzaría un if, y tendré que recurrir a este método en muchos más GameObject y eso serían muchos if por frame para algo que seguro que existe un método mucho más elegante de resolver.
 
Cómo lo solucionarías vosotros?
 
Nuevamente muchas gracias a todos.

Ok. Entiendo. Entonces es un error de concepto, creí que el Canvas si era un GameObject y por lo tanto podía aplicar todas sus funcionalidades. Gracias por sacarme del error entonces. Me hubiera seguido estampando sin remedio.
 
Creo que a grandes rasgos comprendo el código, aunque excede un poco mis conocimientos actuales de Unity. Una buena oportunidad para investigar y poner codos y aprender una nueva parte, así que ahora mismo me pongo.
 
Nuevamente muchas gracias, @kingtrase.
 

http://schema.org/Person" style='box-sizing: border-box; font-size: 20px; color: rgb(0, 0, 0); line-height: 1.2; font-weight: 400; display: block; margin: 0px 0px 3px; word-break: break-word; word-wrap: initial; overflow: hidden; text-overflow: ellipsis; font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: center; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);'>
 

Hola a todos.
 
Llevo un buen rato con un problema muy tonto y no me salgo. He revisado el foro y la documentación oficial y no consigo salirme. Seguramente me estoy dejando una chorrada pero el caso es que no consigo encontrarla.
 
Me explico. Se trata simplemente de que dentro del Canvas, creo un panel y dentro de este panel diversos paneles más. La idea es que los paneles actúen casi como botones. Llevan un texto que va variando dinámicamente según las circunstancias del juego, etc. El caso es que los paneles hijos, no me detectan el mouse. Ni el evento OnMouseDawn, como tampoco el OnMouseEnter, etc...
 
He revisado que esté dentro del Layer UI, que entiendo que no ignora RayCast, a la desesperada le he metido un BoxCollider, he metido debug para verificar que simplemente no entra en las funciones y que no se trata de un código mal hecho, etc...
 
Pero haga lo que haga, simplemente, no me detecta el Mouse, como si lo ignorara por algún motivo y ya no sé que más hacer. He de añadirle algún componente para que lo detecte? La idea de que un panel de la Ui detecte el mouse es una animalada como concepto?
 
Seguramente es que de tanto pelearme con el tema ya estoy espeso, y será una chorrada, pero ni modo. Si alguien puede darme una idea de por dónde tirar lo agradecería, por qué estoy clavado con este tema.
 
Muchas gracias a todos.

Hola,
 
Si esto lo pones en la roca y no estoy equivocado, está buscando el Script en el GameObject roca. Tendrías que tener una referencia al GameObject jugador.
 

   
       
   
   
      public GameObject _jugador;
   
   
      ControladorJugador _cj;
   
   
       
   

[/quote]
 
Así desde el inspector mismo le lanzas el GameObject Jugador. Ahora ya si puedes hacer:
 

   
      _cj = _jugador.GetComponent<ControladorJugador>();
   

[/quote]
 
Creo que es ahí dónde está la cuestión si no voy herrado.

Windows 7 o posterior?
 
Yo probaría a restaurar sistema a una fecha anterior al upgrade y me quitaría de problemas. Al menos es lo primero que probaría.

Bueno, al final lo conseguí... Gracias por la ayuda.