Jump to content
UnitySpain

Yawin

Fosiles
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Yawin

  • Rank
    Iniciado

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sí, he aplicado lo que me dijeron y ha funcionado ^__^ ¡Gracias!
  2. ¡Ok! Lo miro ahora. En realidad no me importa no usar físicas. Me basta con que detenga su movimiento al encontrar un elemento sólido.
  3. Lo que uso es esto: using System.Collections; using System.Collections.Generic; using UnityEngine; public class Unidad : Actor { private Vector3 target; public float speed = 0.5f; public override void ActorStart() { pointingAction = new Action(go_to); } public override void ActorUpdate() { switch(state) { case 1: transform.LookAt(target); if(Vector3.Distance(target, transform.position) > 0.5f) { transform.Translate(transform.forward * speed * Time.deltaTime, Space.World); } else { state = 0; } break; } } void go_to() { Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition); RaycastHit hit; if(Physics.Raycast(ray, out hit)) { target.x = hit.transform.position.x; target.y = 0; target.z = hit.transform.position.z; state = 1; } } } Me anoto lo del navmesh. ¡Gracias!
  4. Hola a todo el mundo, estoy haciendo un prototipo para un RTS y me he encontrado con un problema bastante serio: el click del ratón. En líneas generales, mi problema es que al hacer click sobre el terrain (haciendo uso del Ray) las coordenadas de hit son siempre las mismas (las coordenadas del GameObject "Terrain"). ¿Cómo puedo hacer para que al hacer click vaya a donde he hecho click y no al transform.position del GameObject clickado? Por otro lado, he puesto RigidBody a dos GameObjects y al moverlos con transform.Translate() o bien se chocan y empujan mutuamente o bien (haciendo freeze a los ejes o haciéndolos kinemáticos) hacen como que no son sólidos y se atraviesan. ¿Qué puedo hacer?
  5. Mi planteamiento para el pathfinding es el siguiente: Los hexágonos que componen el mapa tienen varios bloques de información, y uno de ellos es qué tipos de unidades pueden atravesarle. Si es un hexágono de agua sólo le pueden atravesar barcos y voladores, si es de tipo grieta sólo voladores y si es de tipo campo abierto cualquier unidad (son sólo ejemplos, habría muchos tipos diferentes de hexágonos). A esto hay que añadir que los exágonos no serán celdas enormes en las que cabrá un bosque completo sino que serán hexágonos pequeños en las que no quepan más de un par de soldados. Entendiendo esto, lo que planteaba era que la unidad que quiere buscar un recorrido, se trace un recorrido de por qué hexágonos tiene que pasar y ya, cuando se mueva por ellos, perfilará su movimiento a través de ellos. Tampoco soy un gran conocedor de este tema, así que me alegra que tengáis otras maneras de verlo. Seguro que aprendo mucho. Y cuanto más aprenda mejor podrá ser el juego.
  6. Eso es. Al final, el hexagonal afecta al cálculo de rutas y a la colocación de edificios, más que a otra cosa.
  7. ¡Claro! Por eso lo he publicado aquí, para charlar y debatir sobre las distintas ideas. Independientemente del movimiento que se tenga (libre o no) cosas como la colocación de edificios o la decoración del mapa irán ancladas a la forma de las casillas que componen el mapa. Si escojo un modelo hexagonal es, percisamente, porque da más libertad y versatilidad. Al final, para el jugador, no será algo relevante; pero para el funcionamiento del juego creo que es mejor un encasillado hexagonal (generación de mapas, cálculo de rutas, etc...). El método de cuadrícula habitual de los juegos que has mencionado ha sido siempre algo que no me ha gustado en exceso. Complicaban, a mi parecer, cosas como los movimientos en diagonal.
  8. En tiempo real ¡por supuesto! Civilization lo menciono por el sistema del mapeado hexagonal. Hay mucho pensado, sí, pero aún queda mucho por pensar, diseñar y perfilar. ¡Muchas gracias por los ánimos!
  9. Hola a todos! Abro este post porque estoy empezando a diseñar un videojuego de estrategia y no me vendría mal tener gente con quien debatir ideas y diseños. El objetivo de este post no es presentar un proyecto definido, sino dar a conocer cómo defino un proyecto y, con ello, generar debate entorno al mismo. La idea Desde que tengo recuerdos amo con pasión los juegos de estrategia; no sólo los videojuegos, aunque estos siempre han sido los que más me han gustado. Pero en todos he encontrado cosas que no me gustaría que hubiera o faltas en cosas que creo que habría de haber. Por ejemplo: la limitación de población de los "Age of" siempre me traía de cabeza; ¿con una población máxima de 200 quién puede hacer un ataque a gran escala? Por eso, y desde hace mucho, ando ideando el que creo que sería mi juego de estrategia ideal. Por supuesto que aun hay muchas ideas sin concretar y muchas cosas que seguro que necesitan un par de vueltas. Por el momento lo que tengo es, más bien, un listado de ideas: - El mapa es de casillas hexagonales. Siempre he pensado que tiene más sentido que el mapa sea así y da más versatilidad a cómo concebir el espacio en el que se desarrolla la partida. - La cámara debe poderse desplazar no sólo en vertical, horizontal y haciendo zoom sino, también, alrededor de los objetos del mapa. - El objetivo es que se puedan dar partidas muy largas. Ya hay muchos juegos para partidas cortas, a los amantes de los juegos de estrategia nos vuelven locos las partidas que no parecen acabar nunca. - Las victorias deben poderse catalogar como: por guerra, por investigación, por religión y por economía. - Al estilo de videojuegos de estrategia evolutiva, no hay una "cuenta común de recursos". Los recursos se deben almacenar físicamente en almacenes, graneros, etc... y las unidades que requieran de estos recursos para trabajar deberán desplazarse a por ellos. - Habrá disponibles unidades de transporte, edificios de almacenamiento e incluso, con las investigaciones adecuadas, sistemas para automatizar la adquisición de recursos y transporte como cintas transportadoras, autómatas recolectores, etc... (como en juegos como Factorio). - No todos los recursos serán "eternos". Algunos elementos, como la madera o el hierro, podrán estar almacenados en cualquier lugar, de cualquier manera y durante el tiempo que se quiera; pero otros recursos serán perecederos (ej: comida), otros requerirán de transportes y almacenes especiales (ej: uranio). - Los recursos perecederos se transformarán en otros recursos que no siempre serán aprovechables. Por ejemplo: la comida se transformará en deshechos orgánicos. Si se ha investigado algún modo de hacer uso de dichos deshechos orgánicos o de alguna manera de tratarlos se podrán aprovechar. Si no, el jugador verá cómo deshacerse de ellos: vendiéndolos, destruyéndolos, enviándolos a algún almacen a modo vertedero, etc... - Habrá un resumen de propiedades que recuente los recursos que se posean a modo estadística ayudándote a saber cuánto tienes de qué recurso e, incluso, dónde lo tienes. - Los recursos se podrán depositar en el suelo, en vez de algún edificio, pero estos no contarán para el resumen de propiedades. - A diferencia de en otros juegos, sólo habrá una civilización. Sin embargo, a medida que se investiguen ciencias, políticas y demás avances los distintos jugadores irán teniendo divergencias en su desarrollo que deriven en civilizaciones distintas. Así, a medida que avance el juego, los jugadores se encontrarán separados con diferencias estéticas, tecnológicas, etc... Esta idea se basa en asumir el desarrollo de la civilización como un árbol de decisiones. Algunas investigaciones de cerrarán ramas de investigación, o encarecerán/ralentizarán algunos desarrollos. Por ejemplo: un jugador decide potenciar los avances en religión porque está sufriendo muchos ataques en esta dirección y esto le ayuda a contraatacar; sin embargo, esto le cierra las puertas a algunas ramas de investigación científica y le ralentiza otras. Esto puede dar lugar a que, empezando en las mismas condiciones, dos jugadores acaben tan diferentes como que uno use una civilización enfocada a la magia y la otra, en cambio sea una suerte de diéselpunk. Además, al ser los jugadores quienes deciden este desarrollo, son quienes deciden las fortalezas y debilidades de su civilización; haciendo así que uno no pueda aprenderse de memoria las fortalezas y debilidades de tal o cual civilización. - Aunque las diferencias estéticas permitirán a los jugadores experimentados conocer la línea general de evolución que ha seguido su contrincante, no podrá conocer con exactitud su desarrollo real obligando así a los jugadores a emplear métodos para conocer estas cuestiones como el enfrentamiento directo o el uso de espías. - Todos los edificios proporcionarán un área de influencia. Este área no se tiene que entender como el sistema de fronteras de juegos como Civilization, sino más bien como rangos en los cuales lo que sea que haga el edificio tenga efecto. - Para que un edificio funcione necesitará trabajadores (al estilo Stronghold Crusader o como las granjas de los "Age of"). En la medida en que estos puestos de trabajo queden cubiertos, el edificio tendrá un rendimiento de funcionamiento. - A menos que se indique lo contrario, los edificios que produzcan unidades quedarán excluídos de la mecánica anterior. - No todas las tecnologías serán bélicas. Las distintas investigaciones también permitirán mejorar la investigación, religión, recogida de recursos, mecanización, transporte, etc... - Se guardarán automáticamente las repeticiones de las partidas; las cuales serán parecidas a las del juego "Planetary Annihilation". Ideas para un posible multijugador: - Para jugar online se tendrá que disponer de una cuenta válida. - Los servidores de juego (y por extensión de cuentas) estarán federados. Esto significa que quien lo desee podrá montar su propio servidor y que con tener cuenta en un servidor se podrá acceder a cualquier servidor (siempre y cuando ambos servidores se encuentren federados). [Nota: en el mundo de los servidores federados a veces pasa que un servidor no está de acuerdo con el funcionamiento de otro y por tanto lo añade a su lista negra. Esto lleva a que los usuarios de ambos servidores no pueden conectar entre ellos] - Al crear la partida se indicará la versión de juego y los mods (en caso de que los haya) a emplear; haciendo fingerprint de los clientes conectados con el fin de garantizar que no se hacen trampas. - Las partidas se podrán pausar, guardar y cargar en el propio servidor para que los jugadores puedan tener varias sesiones de juego. - Las repeticiones de las partidas se podrán almacenar en el servidor y podrán ser públicas de modo que otros puedan visualizarlas, comentarlas e, incluso, puntuarlas. - Los usuarios podrán desarrollar IAs que se almacenarán en los servidores de modo que otros jugadores puedan escoger jugar contra IAs de terceros e, incluso, puedan montarse competiciones de IAs. Dicho esto, ¿qué tal pinta le veis? Ahora mismo estoy enfrascado en plantearme los diagramas UML básicos por los que empezar a plantear el motor del juego. P.D.: Aunque he posteado este tema aquí aún no he decidido qué lenguaje/motor/framework voy a usar para hacerlo y, por tanto, entiendo que esto tiene un valor más teórico que práctico.
  10. A ver, os cuento: Lo que estoy haciendo es un "plugin" o, mejor dicho, un conjunto de scripts que faciliten a mi equipo de desarrollo la tarea de hacer el videojuego. Mi filosofía al hacer esto es a través de clases con miembros estáticos. Así, por ejemplo, puedes poner "FadeTransition.FadeTo("Escena 1", 5.0f, Color.Black);" y el juego cambia a Escena 1 haciendo un fade a negro. Del mismo modo, ahora mismo hacemos "SoundManager.PlaySong(AudioClip);" para lanzar una canción. Mi idea es que los programadores tengan que poner "SoundManager.PlaySong("w1.scene1");" y este Sound Manager busque en una lista de canciones la que se llame así y la ejecute. De este modo, el sonidista, todo lo que tiene que hacer es abrir el editor del Sound Manager y añadir los AudioClips a medida que los vaya añadiendo al proyecto. Utilizar singletons van totalmente en contra de la filosofía que estoy empleando para hacer esta api. Ni mi script de localización, ni el de guardado/carga de partidas, ni el FadeTransition, ni el SoundManager mantienen nada instanciado durante toda la ejecución para mantener algo cargado en memoria. Para eso ya están los miembros estáticos. Lo que podría hacer es guardar en un fichero el contenido de la lista a medida que el editor la modifique y cargarla al iniciar la ejecución. Edit: Vale, aunque no he solucionado lo que preguntaba, he obtenido una resolución satisfactoria a mis necesidades. En la carpeta Resources he creado una carpeta llamada Audio y dentro he metido los audios. Luego, hago un Resources.Load<AudioClip>("nombre del audio"); y solucionado.
  11. ¡Hola a todos! Estoy haciendo una ventana de UnityEditor para gestionar la lista de AudioClips de mi SoundManager. Tengo hecha la ventana, tengo hecho que cuando yo asigne un audioclip se guarde en la lista; pero al darle a play se borra la lista. ¿Qué puedo hacer? ------------------------------------------------------------------------------------------------------ Estos son los códigos que se ven afectados: SoundManagerEditor.cs using UnityEditor; using UnityEngine; using System.Collections; public class SoundManagerEditor : EditorWindow { [MenuItem("Window/Red Fez Studios/Sound Manager")] public static void ShowWindow() { EditorWindow.GetWindow(typeof(SoundManagerEditor), false, "Sound Manager"); } void Update() { Repaint(); } public int songsArraySize; public bool songsCollapsed = true; void OnGUI() { EditorGUILayout.Space(); EditorGUILayout.Space(); EditorGUILayout.LabelField("Music List"); songsArraySize = SoundManager.Songs.Count; songsArraySize = EditorGUILayout.IntField("Size", songsArraySize); if(songsArraySize != SoundManager.Songs.Count) { while(songsArraySize > SoundManager.Songs.Count) { SoundManager.Songs.Add(new AudioClip()); } while(songsArraySize < SoundManager.Songs.Count) { SoundManager.Songs.RemoveAt(SoundManager.Songs.Count-1); } } for(int i = 0; i < SoundManager.Songs.Count; i++) { SoundManager.Songs[i] = EditorGUILayout.ObjectField("Song "+i,SoundManager.Songs[i], typeof(AudioClip),false) as AudioClip; } } } SoundManager.cs public class SoundManager { private static Snd_FX instance; public static List<AudioClip> Songs = new List<AudioClip>(1); public static void PlayFX(params AudioClip[] clips) { int randomIndex = Random.Range(0, clips.Length); GameObject sndFX = new GameObject(); sndFX.AddComponent<AudioSource>(); sndFX.AddComponent<Snd_FX>(); sndFX.transform.name = "SndFX"; sndFX.GetComponent<Snd_FX>().Play(clips[randomIndex]); } public static void PlaySong(int songID) { if(null == instance) { GameObject sndFX = new GameObject(); sndFX.AddComponent<AudioSource>(); sndFX.AddComponent<Snd_FX>(); sndFX.transform.name = "SndSong"; Object.DontDestroyOnLoad(sndFX); instance = sndFX.GetComponent<Snd_FX>(); } instance.ChangeMusic(SoundManager.Songs[songID]); } }
  12. Gracias por la bienvenida!
  13. Hola a todos! Acabo de descubrir que la cuenta que tenía en el 2010 ya no está; normal, llevaba desde entonces sin pasarme por aquí xDD Pues se me conoce como Yawin aunque mi nombre real, como podéis suponer no es ese. Soy programador, especializado en videojuegos; y, de hecho, actualmente trabajo en un pequeño estudio de mi ciudad. Aunque llevo 6 años conociendo Unity hace sólo 4 años que sé usarla de verdad. Acabé necesitando que un profesor me explicara conceptos como el de las scenes para que pudiera terminar de entender el motor. Ahora mismo estoy prototipando un par de ideas con el objetivo de, si funcionan, formar un grupo de trabajo para hacer un videojuego. Para terminar y como simple dato esta es mi web personal: http://miguelalbors.noip.me
×
×
  • Create New...