Buenas aver si esto podeis resolvermelo
tengo mi clase Jugador
using UnityEngine;
using System.Collections;
public class Jugador
{
private int vida;
private int experiencia;
private int acciones;
public GameObject objeto;
public Jugador()
{
}
public Jugador(int v,int nivel,int accion)
{
vida = v;
experiencia = nivel * 10;
acciones = accion;
}
public int Vida
{
get
{
return vida;
}
set
{
vida=value;
}
}
public int Nivel
{
get
{
return experiencia/10;
}
}
public int Acciones
{
get
{
return acciones;
}
set
{
acciones=value;
}
}
public void Iniciar(GameObject obj)
{
objeto= GameObject.Instantiate (obj, Vector3.zero, Quaternion.identity) as GameObject;
}
public IEnumerator Mover(Transform destino)
{
while(objeto.transform.position!=destino.position)
{
objeto.transform.position=Vector3.Lerp(objeto.transform.position,destino.position,1*Time.DeltaTime);
yield return null;
}
}
public bool PuedeMoverse()
{
if(acciones<1)
{
return false;
}
else
{
return true;
}
}
}
Y luego mi Script principal
using UnityEngine;
using System.Collections;
using Random=UnityEngine.Random;
using System.Collections.Generic;
public class Game : MonoBehaviour
{
private float velocidad=10;
public GameObject objeto;
private Jugador jugador=new Jugador();
public Transform destino;
void Awake()
{
jugador.Iniciar (objeto);
}
public void Move()
{
print ("hola");
jugador.Mover (destino);
}
}
La cosa es que no se mueve el gameobject, no se si es que esta mal la corutina o que. alguien me puede ayudar? nose como mover el objeto (sin rigidbody) suavemente hasta el objetivo.
Bueno, 1º me faltaba llamar a la corutina, despues lo unico que la velocidad no es estable. Me imagino que la unica solucion es ir comprobando la distancia entre los 2 puntos, y cuando sea poca, aumentar la velocidad para mantener la misma velocidad en todos los puntos, un coñazo , pero bueno.
Ten cuidado con esto:
objeto.transform.position!=destino.position
Le estas diciendo cuando sea exacto exacto, quizas puedas controlar la precision y tal vez darle un margen:
Mirate esto:
http://answers.unity3d.com/questions/395513/vector3-comparison-efficiency-and-float-precision.html (http://answers.unity3d.com/questions/395513/vector3-comparison-efficiency-and-float-precision.html)
¿porque utilizas corutinas para el movimiento? utilizando la función Update y Vector3.Lerp o Vector3.MoveTowards seria suficiente y tendrías buenos resultados.
Cita de: kalua66 date=1433521371Ten cuidado con esto:
objeto.transform.position!=destino.position
Le estas diciendo cuando sea exacto exacto, quizas puedas controlar la precision y tal vez darle un margen:
Mirate esto:http://answers.unity3d.com/questions/395513/vector3-comparison-efficiency-and-float-precision.html
lo he probado. su uso por ejemplo
vector3.lerp(origen,destino,velocidad *time delta time) no solo se mueve de golpe prácticamente , sino que nunca llega al destino, ya que el 3º argumento (float), al pasarle el delta time, le da siempre 0,34 o asi que es el tiempo del frame. para que el movimiento sea fluido, el float tendria que ir desde 0 (para que el lerp coja el origen) hasta 1 (el lerp coge el destino).
usando corrutinas, si que va mejor.
Estoy con @francoe1 (http://unityspain.com/profile/18127-francoe1/) , lo correcto sería que usaras el método Update() o el FixedUpdate() para esas cosas. Forzarlo como llamada asíncrona no significa necesariamente que lo estés optimizando, que lo sepas....
Cita de: pioj date=1433534214Estoy con @francoe1 (http://unityspain.com/profile/18127-francoe1/) , lo correcto sería que usaras el método Update() o el FixedUpdate() para esas cosas. Forzarlo como llamada asíncrona no significa necesariamente que lo estés optimizando, que lo sepas....
Tienes toda la razon, pero fue la unica solución que se me ocurrio. Llamo al metodo mover, que es de la clase Jugador, que no hereda de Mono, con lo cual no tengo update...
Puedes usar un While, al estilo vieja escuela, aun que no seria optimo, si entiende que nuestra función Update es global al final del proyecto, pero si tus practicas son simples, el uso de While de forma no sincronizada seria un alternativa no viable, pero fácil de llegar.
Cita de: francoe1 date=1433538680Puedes usar un While, al estilo vieja escuela, aun que no seria optimo, si entiende que nuestra función Update es global al final del proyecto, pero si tus practicas son simples, el uso de While de forma no sincronizada seria un alternativa no viable, pero fácil de llegar.
no entiendo nada.
Cualquier Gameobject relacionado directamente con la lógica de gameplay del videojuego (mover el personaje,etc) debería derivar siempre de MonoBehavior, ya que para eso está pensado así.
Puedes usar un While, al estilo vieja escuela, aun que no seria optimo, si entiende que nuestra función Update es global al final del proyecto, pero si tus practicas son simples, el uso de While de forma no sincronizada seria un alternativa no viable, pero fácil de llegar.
[/quote]
Básicamente dice que sustituyas el Update por tu método propio y lo llames siempre, pero que haciendo eso estás desaprovechando los métodos que te proporciona Unity por defecto... (La verdad es que me ha costado entender a qué se refería XDD).
¿Hay algún motivo por el cual quieras que tu Gameobject de la escena no derive de MonoBehavior? No hablo de la clase, hablo de la instancia del jugador, lo que realmente queremos mover...
Cita de: pioj date=1433546941Cualquier Gameobject relacionado directamente con la lógica de gameplay del videojuego (mover el personaje,etc) debería derivar siempre de MonoBehavior, ya que para eso está pensado así.
Básicamente dice que sustituyas el Update por tu método propio y lo llames siempre, pero que haciendo eso estás desaprovechando los métodos que te proporciona Unity por defecto... (La verdad es que me ha costado entender a qué se refería XDD).
¿Hay algún motivo por el cual quieras que tu Gameobject de la escena no derive de MonoBehavior? No hablo de la clase, hablo de la instancia del jugador, lo que realmente queremos mover...
Te comento, a ver si me puedes ayudar.
Todo este royo viene a partir de los tutoriales "intermedios" de unity, los del scripting, que hablan de herencias y demas, y del tutorial del roguelike en 2d, que crea clases que heredan de otras para usar los mismos metodos etc.
Yo estaba acostumbrado al método por componentes. Basicamente el Gamemanager, busca lo que tenga que mover, o comprobar , lo que sea, cojo su gameobject o script, get component e interacciono. Pero en todos estos meses que llevo, siempre veo que no es recomendable el tema del Get component, despues tambien como digo, veo estas nuevas técnicas (para mi), de crear un objeto en código. Yo creaba un prefab con un sprite, le creaba un script con las características y listo. Claro, luego veo que puedo crear una clase con sus constructores y demás y asignarle un gameobject, todo con una simple creación de clase desde mi script principal. Por eso queria probarlo y me decidí a crear la clase Personaje, en un script aparte y darle las funcionalidades que después usaría.
El problema es que haciendo pruebas, al crear la clase no puede heredar de Mono, porque en mi script principal, si heredaba de la clase creada y esta ya venia con Mono, me daba error. Todo esto hizo que no le pudiera meter la función update a la clase. Me estoy dando cuenta ahora, que creando la clase Jugador:Monobehaviour , no creo que de problema al construir un objeto de esta clase desde el script principal.
Queria desde el Gamelogic, crear la clase jugador, (con su representacion grafica) y así olvidarme de lo demás, todas las referencias ya estarian dentro del script, porque lo he creado dentro, y pense que seria mejor en temas de rendimiento (que no me hace falta, pero pense que se trabaja asi...) Pero no si si esta bien esto o no.
Porque podia haber creado un prefab de jugador y en el script principal hacer una variable publica y pasarle el prefab, tendria que crear tambien otro script para el jugador, pero bueno, es lo mismo que crear yo un script suelto con una nueva clase. Como digo era por probar el tema de OOP.
Tengo tambien un lio con el tema de Lerps para mover cosas. Antes usaba rigidbodys, y les metia velocity, le pasaba un vector y listo. Ahora al mover directamente el transform con lerp me lio con el delta time. Porque nunca se mueve al punto exacto, osea no llega al vector. si quiero que vaya de 0f a 1f, al hacer lerp(0f,1f, v*time.deltatime) delta time siempre va a ser 0.xx, y lerp , como decia antes, te da el valor a, o b, depende si el float es 0 o 1, al no llegar este a 1, nunca te da el destino. ese es el problema que estoy teniendo.
Volviendo al tema y resumiendo, no se si esta forma que estoy orientando la programación es correcta, o seguir con la de componentes. Pero tanto estos lios como mierdas de novato que pregunto antes, me pasa porque las paso ***s aprendiendo yo solo. Son ya muchos meses viendo vídeos en ingles, y desespera no tener a nadie en tu idioma para preguntar dudas. Agradeceria mucho una recomendacion sobre COMO afrontar un proyecto, como se tendría que trabajar y orientar la programación.
Un saludo.
@biztor (http://unityspain.com/profile/25907-biztor/)
Hola he leido tu comentario y bueno la verdad que sobre el tema de
MonoBehaviour no te puedo ayudar porque al igual que tu estoy acostumbrado a utilizar el
GetComponent, lo que si puedo intentar ayudarte es en el tema del
movimiento, si no quieres usar "
rigidbody" se me ocurre la siguiente forma:
Debes mover el Personaje en la direccion donde esta el destino (
Transform.Translate + condicion de parada) :
var Direccion : Vector3 = new Vector3(destino.transform.position - personaje.transform.position) //(Solo nos interesa la direccion);
if(Direccion.magnitude < MARGEN_ERROR){ //Con esto le indicas que en vez de llegar a un punto tiene que llegar a una pequeña zona pues es muy dificil que caiga justo en ese punto como te comentaron mas arriba.
personaje.transform.Translate(Direccion.normalized * Velocidad * Time.deltaTime,Space.World); //Le indicamos que mueva en esa direccion en el Mundo no en Local.
}
Otra alternativa es sustituir "
Direccion.normalized" por "
Direccion" cuyas consecuencias seran:
1.La velocidad no sera constante.
2.Cuanto mas cerca mas lento se movera, ¿por lo que crea un efecto mas "fluido"?
3.Puedes tener problemas si esta a una gran distancia pues se movera realmente rapido (deberias controlar un maximo).
Sinceramente creo que la opcion mas viable y efectiva en tu caso es la
primera... te permitira mover el personaje a una velocidad constante en la direccion que deseas, pero recuerda la condicion de parada.
Hacerlo asi ademas te ayudara a cuando quieras "sprintar" , "agacharte" pues solo deberas modificar la "Velocidad" -> Velocidad *= 1.5; //Sprint
Espero que me hayas entendido y te sea de ayuda, sino puedes preguntar!
Creo que el problema está en que malinterpretas o exageras 2 cosas, a mi parecer:
- "El GetComponent() es malo, no debe usarse!".
A ver, abusar del GetComponent no es bueno, como tampoco lo es de abusar de cualquier cosa, en general. Pero de ahí a declararle la guerra, tampoco hace falta. Es una forma de recoger el script y sus métodos vía código si por algún motivo no puedes asignarlo previamente desde el Inspector. De ti depende el programar lo suficientemente mal un script o algo del juego, como para que el GetComponent sea el culpable más evidente...
- "No se pueden derivar Clases de datos a MonoBehavior".
No es del todo cierto, se puede hacer añadiendo las clases que hereda seguidas por una coma (,) . Pero eso no viene al caso...
La cuestión está en que lo que se hace normalmente es , por un lado tienes la Clase con sus métodos,etc; y luego por otra parte, lo que le asignas al GameObject de la escena es un MonoBehavior que instancie de una Clase. Por ejemplo, crear una clase de
dato_complejo, y luego en un GameObject crear una Lista ítems de tipo
dato_complejo.
Yo es que creo que te estás obsesionando con el tema. Si lo que pretendes es hacer una App de móvil, o algo más complejo o serio que un videojuego, igual Unity no es la herramienta más adecuada para eso...
@ProgramacionWH (http://unityspain.com/profile/27156-programacionwh/)
Voy a probar y comento a ver que tal, gracias
@pioj (http://unityspain.com/profile/18485-pioj/)
Si la verdad que me habré obsesionad, tengo que usar las cosas según haga falta y no imponerme un solo modo de hacer las cosas. Gracias.
Si la verdad que me habré obsesionad, tengo que usar las cosas según haga falta y no imponerme un solo modo de hacer las cosas. Gracias.
[/quote]
Bien por tí!
Cita de: ProgramacionWH date=1433637432@biztor (http://unityspain.com/profile/25907-biztor/)
Hola he leido tu comentario y bueno la verdad que sobre el tema de MonoBehaviour no te puedo ayudar porque al igual que tu estoy acostumbrado a utilizar el GetComponent, lo que si puedo intentar ayudarte es en el tema del movimiento, si no quieres usar "rigidbody" se me ocurre la siguiente forma:
Debes mover el Personaje en la direccion donde esta el destino (Transform.Translate + condicion de parada) :
var Direccion : Vector3 = new Vector3(destino.transform.position - personaje.transform.position) //(Solo nos interesa la direccion);
if(Direccion.magnitude < MARGEN_ERROR){ //Con esto le indicas que en vez de llegar a un punto tiene que llegar a una pequeña zona pues es muy dificil que caiga justo en ese punto como te comentaron mas arriba.
personaje.transform.Translate(Direccion.normalized * Velocidad * Time.deltaTime,Space.World); //Le indicamos que mueva en esa direccion en el Mundo no en Local.
}
Otra alternativa es sustituir "Direccion.normalized" por "Direccion" cuyas consecuencias seran:
1.La velocidad no sera constante.
2.Cuanto mas cerca mas lento se movera, ¿por lo que crea un efecto mas "fluido"?
3.Puedes tener problemas si esta a una gran distancia pues se movera realmente rapido (deberias controlar un maximo).
Sinceramente creo que la opcion mas viable y efectiva en tu caso es la primera... te permitira mover el personaje a una velocidad constante en la direccion que deseas, pero recuerda la condicion de parada.
Hacerlo asi ademas te ayudara a cuando quieras "sprintar" , "agacharte" pues solo deberas modificar la "Velocidad" -> Velocidad *= 1.5; //Sprint
Espero que me hayas entendido y te sea de ayuda, sino puedes preguntar!
De esta forma funciona perfectamente, gracias
Me alegro, para eso estamos