Cita de: francoe1 date=1502390969Jajaja, es la realidad, uno va tratando de perfeccionarse y llega un "NOOB" y destruye todos tus paradigmas!!!
   

Creere que soy el "NOOB"

Cita de: francoe1 date=1502390969Nadie conoce la verdad, siempre hay una forma diferente de hacer las cosas, a veces mejor o peor, pero a fin de cuentas diferente.
   

Sin embargo eres tu mismo quien dijo cosas como "olvidaros de utilizar Monobehaviour", "nunca hay que utilizar SendMessage", "estas muy equivocado en como entiendes Unity".
 

Cita de: lightbug date=1502390782Me da gracia porque si preguntan "q son los delegates? como usarlos en eventos? que es un evento? Componentes?" nadie constesta nada, ahora si preguntas "como envio la posicion y rotacion?" termina en delegates, eventos, componentes ...  Los programadores y su lucha de ego...
   

Nadie dijo nada de delegates, hasta que alguien quiso darse de listo con el tema de los delegates porque queda muy "PRO" ... y al final para poner un ejemplo que mas que quedar pro quedó bastante de "NOOB"
 
En realidad la pregunta era : Como enviar dos variables en un SendMessage ? El que no tiene ni idea, solo por sentido comun y viendo que las dos variables se encuentran dentro de un mismo objeto, contesto "enviando el transform".
 

Cita de: francoe1 date=1502390696Jajajajajajaja  ... el comentario de @Arthure me hizo recordar a un usuario TheCode de hace un tiempo que quería programar un sistema revolucionario en unity.
   

Pues yo volveria a leer el comentario de Arthure porque me parece que te perdiste algo ... utilizo Unity para uso personal a ratos, empiezo un proyecto y cuando cierro unity borro el proyecto. Unity lo utilizo para desconectar del trabajo; donde da a entender que quiera hacer algo grande y revolucionario con Unity, cuando dejo claro que no intento hacer ni algo pequeño ?
 

Cita de: Kvashir date=1502390025venga, vamos a sacarnos todos el rabo a ver quien lo tiene mas grande XD
   

Nooo porfavor !!!!!
 
Con un tio podria hacer una comparacion de a ver quien los tiene mas grandes, entiendase los huevos pero para eso no hay que sacarselos ni tocar ni nada por el estilo.
 
Pero medirse a ver quien tiene el rabo mas grande ?? Sinceramente, prefiero que me de su opinion cualquier tia ... pero tu te imaginas una colla de tios sacandose la polla y ponerse a medirla ? Que pensarias tu si entras en un cuarto y te encuentras con esa imagen ?
 
Ya se que es una frase hecha, que no es literal ... pero hay cosas que quedan un poquillo ... del ambiente digamos
 
 
 
 
 
 

Cita de: francoe1 date=1502384143@Arthure La manera en la que piensas de cómo deben comportarse los componentes no es la correcta, este error surge de utilizar Unity, se trata de ver todo como un "Único", cuando en realidad tratamos de manejar todo de manera arbitraria.
   
   
      Dejemos de lado un poco los eventos y vayamos a otro ejemplo. ¿Programaste alguna vez un juego fuera de Unity, comenzando de cero?, si es así te darás cuenta que la programación basada en componentes es algo chocante, no termina de convencerte y por lo general da más problemas que soluciones, Unity hace que lo "recién llegados" lo vean de manera equivocada...
   

A la pregunta ... ¿Programaste alguna vez un juego fuera de Unity, comenzando de cero? La respuesta es ... (me ha quedado tope concurso de la tele jajajaja) NUNCA he programado un juego en Unity, pero llevo mas años de los que me gustaria a veces programando aplicaciones para empresas (y hay empresas de todo tipo). Lo siento, no se si tendre idea o sere un zoquete pero en cualquier caso mi ignorancia no vendra porque empece a programar cuando descubri Unity con la idea de hacerme millonario con los juegos, por lo tanto no soy un "recien llegado"
 
Cuando hablo de programacion no lo hago pensando en el poco tiempo que llevo utilizando Unity, si no en el mucho tiempo que llevo haciendo programacion orientada a objetos (mayormente C++, C# y java). Cuando quieras te menciono alguna de las caracteristicas de la POO, o te hago un copy / paste para que las palabras no sean mias y asi no de la sensacion de vacilada xDDD
 
Con tan solo una de las caracteristicas fundamentales de la POO ves que el metodo que pusiste no llega ni a chiste, pero de buen rollo (no es algo que diga yo, lo dice el paradigma de la POO que no lo invente yo). A ver si averiguas cual es esa caracteristica
 
Utilizo mucho Unity a nivel personal porque me permite por un lado hacer lo que me gusta mas, que es programar, al mismo tiempo que lo que programo es muy distinto a lo del curro por lo que me permite desconectar sin dejar de programar. Pero aunque lleve relativamente poco tiempo en Unity, te aseguro que no fueron los de Unity los que inventaron los delegados en este caso ... algunos utilizabamos los delegados antes de que existiera Unity, mientras que otros no programaron hasta que aparecio Unity. No preguntare a que grupo perteneces porque tampoco interesa mucho.
 
Un saludo.

Cita de: francoe1 date=1502375905@Arthure Lo comente abajo, que es algo complicado de explicar, cuando alguien está comenzando se le hace muy dificil entender como funcionan los delegados, los eventos, los argumentos, para que y porque se utilizan. Por ejemplo, si vamos a lo teórico, un delegado se parece mucho a un puntero de C, este vendría a ser una referencia a un método cualquiera, es decir no está explícitamente declarado para el compilador. Pero, ¿Quién podría entender estas palabras?, muchos ni siquiera saben que es un compilador... 
   

Pido disculpas con mis maneras ... pero a estas alturas no les sorprenderan a nadie (aunque eso diga muy poquito de mi persona jajaja) aunque ni mucho menos intentaba ser una burla o critica; aunque el hecho de no pretender ser una burla, no significa que no me parezca una chorrada el sistema eh !!
 
Como dije, lo primero que me parece una chorrada es utilizar una clase estatica ... y lo pondre con un ejemplo : en unos juegos deportivos, pongamos por simplificar mucho, el salto a la pata coja donde el ganador es quien de el salto mas alto sin moverse del sitio (nos podemos reir, pero ese deporte un dia llegara a los juegos olimpicos jajajajajajaja).
 
Pues quien realiza el evento (la accion) en este caso seria el deportista y al resto de entidades no les importa como realiza esta accion, simplemente la accion en si. Despues existen dos entidades, quien se encarga de controlar la altura a la que se salto y los espectadores que aplaudiran por el salto.
 
Pues el ejemplo tan chorra anterior, pasado a codigo ... las acciones de saltar, medir altura y aplaudir estaran implementadas en sus propios objetos no en una clase estatica. Del mismo modo que los manejadores de eventos (en este caso el "arbitro" y espectadores) tendran el codigo en sus propios objetos.
 
Pero la muestra mas clara de que es una chorrada el sistema, es que cuando se ejecuta el evento y el objeto player lo maneja tiene que comprobar un atributo para saber si debe ejecutar una accion o no. Eso es la cosa menos limpia, optimizada y expansible que alguien se pueda tirar a la cara por una sencilla razon ... en el ejemplo puesto por @francoe1 el player comprobaba el name del gameobject para saber si tenia que ejecutar un codigo, pero que pasa si se le cambia el atributo name cambia por cualquier razon ? en el mismo ejemplo solo se comprueba si el name coincide con "Box Temp" pero que sucederia si hubieran 100 names distintos (pongamos que un nombre para cada tipo de caja) ? Que sucederia si encima si al destruir una caja te dieran puntos y cada tipo de caja tuviera una puntuacion distinta ?
 

• 
     Si cambiando un atributo interno de un objeto, en este caso el name del objeto caja, el codigo va a dejar de funcionar entoces es un indicador de que no se trata de un codigo expansible.
  


• 
     Si un codigo tiene 100, 1.000 o 10.000 condicionales innecesarios entoces no se trata de un codigo limpio ni optimizado.
  

@lightbug cada cual utilizara las cosas como mejor crea, pero en el caso de los delegates que era lo que me preguntabas ... para mi es una pasada precisamente para tener un codigo mas limpio y expansible (lo de optimizado luego depende de las funciones), puesto que solo llamando a una funcion puedes hacer que un objeto tenga cierto comportamiento segun una circumstancia.
 

public class Jugador : Monobehaviour {
private delegate void ComportamientoJugador ();
private ComportamientoJugador comportamiento;
private void Update () { comportamiento (); }
private void Esperar ();
private void Correr ();
private void Saltar ();
private void Atacar ();
private void Morir ();
}

 
En el codigo que he puesto, la funcion "comportamiento" que se ejecuta en el Update podria adoptar el codigo de cualquiera de las funciones que hacen referencia a los estados segun convenga.
 
Al final no se trata mas que de un sencillo uso de maquinas de estado ... entre eso y el metodo utilizado por clases no serializadas de @francoe1 (la clase Motor y sus derivadas), la unica diferencia es que su codigo esta en clases separadas y en mi caso el codigo esta "dividido" en diferentes funciones dentro de la misma clase ... pero el resultado es el mismo, dentro del Update solo existe una funcion, consiguiendo que sea mucho mas facil de leer.
 
A parte de todo eso, los delegates despues se utilizaran para el manejo de eventos pero como una parte y no por si solos (estudiar event y EventArgs) ... del mismo modo que el tipo float por si solo no sirve para guardar la posicion de un objeto, pero el Vector3 que si se utiliza con esa finalidad esta compuesto por float.

Cita de: francoe1 date=1502307684Claro, siempre que puedo estoy compartiendo, pero en mis momentos libres creó material que luego pueda obtener ganancias, pero estoy muy limitado con el tiempo.
   
   
      En este caso, no se explica claramente lo que está necesitando, pero supongamos que el tiene un objeto que emparenta a otro.
   
   
      (Player):GameObject // Jugador

              (Box Temp):GameObject // Caja temporal que se destruye al pasar por algún lugar.
   
   
      Supongamos que el jugador necesita saber si la caja temporal se ha destruido, de ser así, obtener los valores del componente transform de la caja.
   
   
      Por lo general, este tipo de problemas se plantean de la siguiente forma ¿La caja le avisa al Jugador que se destruyó?, ¿El jugador comprueba que la caja se existe? ... pero todas estas dudas no son más que malas ideas, partamos desde un inicio. ¿Por que el jugador necesita saber si la caja se destruyo?, ¿Y?¿Si otro componente tambien lo requiere? ... siempre estas son las preguntas futuras, las que hacen que el desarrollo de una aplicación se vuelva inestable. Entonces ¿Cómo realizarlo de la manera correcta?, bien, en primer lugar, vamos a tratar de centralizar los eventos, es decir, creamos una clase estática la cual puede llevar el nombre de GameEvents donde registramos todos los eventos del juego (con antelación deberíamos tener el diseño de nuestra aplicación, está más que claro que de lo contrario hay pocas posibilidades de éxito). Veamos un Ejemplo:
   
   

public static class GameEvents
{
public delegate DestroyObjectDelegate(GameObject go);
     public static event DestroyObjectDelegate DestroyObjectEvent = delegate {};
public static void DestoyObject(GameObject go)
    {
         DestroyObjectEvent.Invoke(go);
         //Unity ... 
         MonoBehaviour.DestoyObject(go);
    }
}

   
      De esta manera nosotros podríamos desde cualquier lugar de la aplicación capturar el evento requerido... Ejemplo.
   
   

public class Player : MonoBehaviour
{
private void Start()
    {
   GameEvents.DestroyObjectEvent += OnDestroyObject;
    }

private void OnDestroyObject(GameObject go)
    {
   if(go.name == "Box Temp") Debug.Log("¡Objetivo destruido!");
    }
}

   
      Podríamos utilizar la misma implementación desde cualquier lugar del proyecto, debido a que estamos trabajando basado en eventos.
   
   
      Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
   
   
      1º Aprender a utilizar eventos(event y delegate)
   
   
      2º Aprender a utilizar enumeradores, entender como funcionan internamente (IEnumerator)
   
   
      3º Aprender a utilizar clases Abstractas, Interfaces, Estructuras saber donde y cuando utilizarlas.
   
   
      4º La decisión de utilizar un Componente MonoBehaviour es crítico, tratemos de no hacerlo.
   

No es mi intencion ofender ... pero a mi me parece una chorrada como utilizas los delegados y eventos eh ! Sobretodo teniendo en cuenta que segun algun comentario se da a entender algo parecido a "para esto hay que recorrer un gran camino, estudiar muchos años y cuando crezcais podreis ser como dios" xDDD
 
El problema de querer hacer ver que el uso de los delegados es algo muy avanzado, es que los que somos programadores (no me refiero a Unity) los utilizamos desde hace mucho tiempo, y los que no pretenden ser programadores se las va a sudar ... Como si se quiere decir que es la panacea.
 
Dicho eso, comentare porque encuentro una chorrada ese uso de los delegados ...
 
En primer lugar, una clase estatica para los eventos Como se dice en mi tierra, "oh dios mio !" ... exceptuando mi sobrina que es muy chula ella y diria "ohh my god !" xDDD Para decir que hay que estudiar mucho y entender como y para que se utilizan las cosas, no vamos muy sobrados
 
Comenzando porque no se que pinta ese delegate ahi, pero eso es otra historia que no viene a cuento ... imagino que el codigo queda mas cool con la palabra delegate xDDD
 
Continuando porque un evento (no la captura y lo que se haga con ese evento) sino el evento se ejecute desde una clase estatica ... ademas de ser de chiste de por si, estas obligado a hacer la funcion publica, que ademas es un delegado, y eso para alguien que dice que hay que mantener una aplicacion limpia, optimizada y expansible suena a chiste malo.
 
En mi mundo un evento (accion) lo ejecuta un objeto, y otros objetos capturan estos eventos ... en tu caso coges y llevas tanto la accion como la captura de dicha accion a una clase estatica, dices que asi hay que hacerlo porque evitas utilizas MonoBehaviour y te quedas tan ancho
 
Solo dire que si una vez "capturado" el evento por el Player este debe comprobar el tag, name o cualquier otro atributo del objeto destruido para saber si debe hacer una accion o no ... es que se nota que es un codigo bien hecho, lo que cualquiera llamaria una aplicacion limpia, optimizada y expansible

Cita de: francoe1 date=1502307684En este punto me gusta mucho dar el ejemplo del movimiento de las actores dentro de un juego, por ejemplo, tenemos dos tipos de personajes con movimientos totalmente diferentes, muchos frente a este problema crearán un componente diferentes para cada uno, 2 prefabs, y se empieza a complicar todo, otros recurrirán a la abstracción, mi recomendación, utilizar clases no serializadas para los diferentes comportamientos, es decir.
   
   

public class Player : MonoBehaviour
{
private Motor _motorJumper = new MJumper();
private Motor _motorRunner = new MRunner();
private Motor _current;
private void SetMotor(int mode)
    {
   switch(mode)
   {
      case 0: _current = _motorJumper; break;
      case 1: _current = _motorRunner; break;
   }
    }
private void Update()
    {
   _current.Run(Input.Axis*****);
    }
}
public class Motor 
{
public virtual void Run(Vector3 axis){}
}
public class MJumper : Motor
{
public override void Run(Vector3 axis)
    {
   movimientos.. 
    }
}
public class MRunner : Motor
{
public override void Run(Vector3 axis)
    {
   movimientos.. 
    }
}

   
      Existen muchos ejemplos, en cuanto tenga tiempo voy a terminar una serie de tutoriales que tengo ya en edición, sobre un sistema de armas bastante completo, donde trato de explicar la importancia de cada técnica... 
   

Esto ultimo que se decia te hubiera podido quedar mucho mejor ... pero tambien es un poquito una cagada; porque el uso de la clase Motor, junto a sus derivadas, es muy bueno para hacer un codigo mas limpio y expansible (lo de optimizado vamos a dejarlo en el aire) pero cuando se trata de hacer una maquina de estados.
 
Pero si solo es para mover un personaje, por muy distinto que se muevan ... una clase abstracta, con la funcion abstracta encargada de movimiento para que obligue a implementarla en cada uno de los personajes, y marchando.

Cita de: pioj date=1502178924Es una buena solución, sí. Condensarlos en una string con un delimitador...

Pues para mi es una solucion un tanto ... sin palabras; como aquel que intenta reinventar la rueda. Si se trata de enviar la posicion y rotacion de un gameobject, lo mas sencillo es enviar el propio objeto "transform" que ya tiene almacenados ambos datos.

Buenas,
 
estaba echando un vistazo al asset "Gaia" y me ha surgido una duda ... Cuando utilizas un asset como el mencionado, que tiene un tamaño de 1 giga casi, eso afecta al tamaño del proyecto final obligatoriamente o es posible borrarlos antes de compilar sin problemas ?
 
Muchas gracias y disculpar por el desconocimiento.

@Scripter80, a ver si nos acostumbramos a decir el error que te muestra la consola y no solo copiar los scripts ... tan mal esta el que solo muestra los scripts sin el error, como el que muestra solo el error sin los scripts; mostrando toda la informacion es mas facil (comodo) para el que quiera ayudar. Eso es una recomendacion para cualquiera, no solo para ti.
 
Dicho eso, el error que te debe saltar es porque tienes una variable en el script de la camara que se llama target (quiero entender que se trata del objeto jugador) ... pero cuando el jugador muere destruyes ese objeto, por lo que en el momento que eso sucede y la camara intenta consultar dicho objeto no lo encontrara y habra un error.
 
Para solucionarlo, es tan facil como antes de consultar la variable target del script cameraFollow2DPlatformer compruebes de que existe el objeto.

Hola @leocub58,
 
Yo optaria por la 2ª opcion con los ojos cerrados sin dudarlo ... mas que nada porque tener instanciados los objetos de la ropa e ir activando / desactivando segun vayas equipando en el inventario me parece super cutre, la cosa menos elegante que te puedas echar a la cara. Es como el tipico tutorial de principiante que se veia hace años sobre hacer un shooter y el tema armas estaba realizado con el mismo metodo (solo tenias que fijarte que el que hablaba era un niño de 10 años).
 
El object pooling es un metodo que, como dicen @lightbug, va genial y mejora mucho el rendimiento de un juego pero como con todo, su efectividad se nota si se utiliza para lo que esta diseñado ... nadie dudaria que un bazooka tiene una efectividad excelente como arma mortifera pero no por eso es buena idea utilizarlo para matar moscas
 
Por ejemplo si se trataran de projectiles (que vas a instanciar quizas 10 cada segundo) te mejorara el rendimiento mucho, pero si vas a instanciar una armadura cada cuanto ? Cada 5 o 10 minutos o tal vez un par de veces en toda la partida el object pooling no te va a hacer nada en absoluto, todo lo contrario.
 
Por eso yo optaria por la 2ª opcion ... y pensaria soluciones para evitar los problemas o inconvenientes que te puedan surgir derivados de la eleccion. Una manera sencilla, por ejemplo, es que el canvas del inventario oculte al personaje cuando este abierto (cosa de diseño, esto sucedera el 100% de los casos si se trata de un proyecto para dispositivo movil) y no se realicen las operaciones en el momento de poner una prenda de ropa en su casilla correspondiente sino en el momento de cerrar el inventario. La idea seria la siguiente por pasos :
 

• 
     Abro el inventario, el canvas esta diseñado para que oculte al personaje.
  


• 
     Hago los cambios que desee, equipando / desequipando los objetos.
  


• 
     En el momento de aceptar los cambios, antes de cerrar el inventario, destruyo o instancio los objetos segun convenga para que el personaje se corresponda con la informacion del inventario.
  


• 
     Oculto el inventario.
  

Con eso te evitas tener que instanciar / destruir objetos muchas veces y ademas, como el personaje estara oculto por el inventario no se vera ningun parpadeo en el momento de instanciarse.

Suerteeeeeeeeee !!!!!!!!!

Cita de: LoquenderoMix date=1501616263Espero que lo de 30 euros lo estés diciendo de coña  Pido personal por la razón de que, por ejemplo, no puedo estar por la noche, solo puedo continuar con el desarrollo por la tardes y algunas veces por la mañana. Por eso pido personal, para que den progreso al juego mientras yo no esté.
   

Mi recomendacion, y lo que creo que es mas sensato para tu caso en concreto, seria que tomaras una de las siguientes opciones (de menos a mas drastica) :
 

• 
     Cambia de proyecto, piensa en algo sencillo que puedas hacer tu mismo sin la ayuda de nadie aunque te pueda llevar mas tiempo.
  


• 
     Planteate el buscar a alguien que te transmita seriedad e intenta llegar a un acuerdo economico que os pueda interesar a los dos; olvidate del "se repartiran beneficios cuando se finalice", sencilla y llanamente un precio por hora.
  


• 
     Simplemente abandona la idea de realizar ningun videojuego.
  

La razon de los consejos anteriores es que tal vez @lightbug dijera en coña eso de 30 euros, o tal vez no ... Quien sabe ? Pero eso de "pido personal para que den progreso al juego mientras yo no este" suena todavia mas a chiste que el comentario de los 30 euros.
 
Lo que no puedes pretender, porque mas que chiste es un comentario de mal gusto, es que otras personas trabajen en tu proyecto por el simple motivo de que tu no estas y encima no vayan a cobrar por ello.
 
El primero que tiene que estar a los pies del cañon es el cabeza de proyecto, y aun asi es dificil que los colaboradores no te abandonen ... imaginate si tu intencion es que te hagan el trabajo por tu estar ausente.
 
Con lo que pretendes, mas que desearte suerte se te deberia desear un milagro.

Hola @chessjose,
 
no te aconsejaria hacer eso ... exponer un problema que tienes, y al cabo de un rato volver a escribir diciendo simplemente "Solucionado" sin molestarte en comentar que has hecho para solucionar el error.
 
En primer lugar por respeto al resto de compañeros, puede que detras tuyo venga otro con el mismo problema ... y despues por tu propio interes, puede que vuelvas a pedir ayuda (no seria raro, llevas 2 dias en el foro y has pedido ayuda 2 veces) y viendo que no ayudas en lo poco que podrias luego el resto de compañeros no se molesten en ayudarte.
 
Pero como decia es solo un consejo, despues puedes hacer lo que quieras

Las matematicas no es el fuerte de la gente por lo visto xDDD
 
No se que funciones de la libreria Mathf permiten hacer lo que se quiere conseguir, tampoco tengo ahora en mente las funciones que hay
 
Con el sueño que hay la cabeza no me da para mucho, pero que para conseguir lo que quiere conseguir @El preguntón tampoco se necesita ninguna funcion ... una simple ecuacion, y lo de simple nunca mejor dicho, es suficiente para saber el resultado de la variable B en funcion de lo que valga en cada momento la variable A. La operacion seria la siguiente :
 
B = 360 * A - 180;
 
Poniendo algunos valores a la variable A como ejemplo tendriamos que ...
 
B = 360 * 0 - 180 = -180 (Cuando A vale 0, B valdra -180)
 
B = 360 * 0.5f - 180 = 0 (Cuando A vale 0.5, B valdra 0)
 
B = 360 * 1 - 180 = 180 (Cuando A vale 1, B valdra 180)
 
y cualquier valor que se le ponga a la variable A entre 0 y 1 dara el valor exacto de la variable B sin necesidad de ninguna funcion.

Cita de: J4v1v1g2 date=1501162616No estoy muy seguro se lo preguntare a la traductora, en principio creo que es otra manera correcta de decirlo.
   

pues yo despediria a la traductora eh

Cita de: WalteWalter date=1501047063pasa que aun soy un principiante :v me podrias dar un pequeño ejemplo de script en c# para hacer daño?  lo que me han enseñado hasta ahora no me sirve para lo que busco hacer
   

Hoy en dia todo se soluciona con decir cosas como "pasa que aun soy un principiante" ... y esa parte no es mala, todo lo contrario, todos hemos pasado por esa etapa. Pero esta claro que hay un abismo entre decir "pasa que aun soy principiante, me queda mucho por aprender para conseguir lo que quiero pero me esforzare" o decir "pasa que aun soy principiante, me podrias dar un pequeño script para hacer daño".
 
Es muy diferente estar aprendiendo programacion, a estar buscando videotutoriales que hagan exactamente lo que buscas ... con la primera opcion haras lo que quieras (en tu imaginacion estara los limites), con la segunda opcion haras muy poquito porque al final no sabras adaptar las cosas a tus necesidades y estaras limitado a lo que otras personas quieran hacer por ti.
 
Supongo que era eso a lo que se referia @lightbug con que no te iba a servir de nada ... y la prueba esta en que los boleanos son un tipo de variable que se aprende con lo mas basico de programacion, de aquellas cosas que se deberian tener claras como el agua incluso antes de abrir Unity por primera vez ... si realmente estas aprendiendo programacion.

Cita de: TheBullet date=1500559163@Arthure a veces eres demasiado basto cuando contestas y entras muy a saco, y te lo dice alguien que tiene muy poca delicadeza al hablar, pero lo tuyo es top tío 

Cita de: lightbug date=1500561133... por mas duro que pueda parecer lo que dijo Arthure dejo pequeñas dudas, o no, no importa pero movio un poco las aguas, cual es el posible resultado? mas opiniones de parte de los espectadores (nosotros, lo cual esta pasando ahora mismo) lo que lleva a la inevitable mejora del proyecto en cuestion, sea cual sea el camino que le de el autor.
   

Cuando dejas estancada agua, por mas pura y limpia que estuviera al principio, siempre acabara pudriendose ... yo hago una labor social siendo la mano que agita las aguas
 
@lightbug te recomiendo un proyecto del foro que tambien era muy grande, excesivo ... y estaba muy currado (no me acuerdo el nombre pero todo es cuestion de buscarlo), se trata de un mundo abierto sobre la prehistoria.
 
Se curraron hasta un video promocional de un par de minutos mezclando juego con la vida real tremendisimo para hacer una campaña y conseguir fondos.