Empezar con Unity

[^MiSaTo^]

En mi caso particular me he encontrado mucha gente con el "fuck apple si tengo que pagar 100 pavos al año", y ahora son 99€ han hecho 99$=99€ no es como antes que iba "por el cambio". Asi que apple nos ha subido la tarifa a los europeos, asi like a boss xD

Me da igual. Si no tienes 99€*AL AÑO para pagar una licencia... entonces no se a qué estás jugando.
No es significativo para mi alguien que dice eso y no creo que sea un caso muy grande. El problema es que la morralla es mucho más dificil de colarse en iOS por las reviews.
Aparte sabes que si quieres programar algo para iOS necesitas un mac. No se si para juegos puedes no compilar con Xcode, ahí me pierdo. Pero en general el desarrollo para iOS está más "restringido" y es más dificil hacer la apli de linterna que te robe datos o cualquier otro juego mierder porque tampoco va a pasar el proceso de aprobación.

Tb, iOS da mucho más beneficio que Android. Al menos en el caso de las apps siempre ha sido así. Incluso teniendo una cuota de mercado muchísimo más pequeña.

[Anarchy]

Aparte sabes que si quieres programar algo para iOS necesitas un mac. No se si para juegos puedes no compilar con Xcode, ahí me pierdo.

Necesitas un mac por narices. Yo ando mirando para pillarme uno porque no me quedan otros cojones...

[TRaFuGa]

Eso es algo que hace falta @nintiendo1, actualmente si yo hago un juego (que sería mierder xD) ocultaría de la store el resto de juegos buenos, lo que se debería hacer es algo similar a lo que tiene steam, pero dejando que quien quiera pueda tener su app/juego sin tener que pasar por eso y sin tener que dejar la app para descarga directa que en android sería posible pero para ios no... yo estaría dispuesto a que mis juegos o aplicaciones no estuvieran en la store porque no cumplen cierta calidad, si eso ayuda a mejorar la calidad de lo que se publica. En Android puedo poner la app para descargar sin problema, y si no tengo calidad suficiente pues ya no lo planteo para ios.

Enviado desde mi SM-N910F mediante Tapatalk

[Eskema]

Me da igual. Si no tienes 99€*AL AÑO para pagar una licencia... entonces no se a qué estás jugando.
No es significativo para mi alguien que dice eso y no creo que sea un caso muy grande. El problema es que la morralla es mucho más dificil de colarse en iOS por las reviews.
Aparte sabes que si quieres programar algo para iOS necesitas un mac. No se si para juegos puedes no compilar con Xcode, ahí me pierdo. Pero en general el desarrollo para iOS está más "restringido" y es más dificil hacer la apli de linterna que te robe datos o cualquier otro juego mierder porque tampoco va a pasar el proceso de aprobación.

Tb, iOS da mucho más beneficio que Android. Al menos en el caso de las apps siempre ha sido así. Incluso teniendo una cuota de mercado muchísimo más pequeña.

Asi es, pero ya te digo que me he encontrado muchos "imbeciles" de esos que no podian pagar 99 al año, y como dices tu, anda y q te den mucho por culete si quieres entrar a un market y no tienes 100leuros al año xD.

Y sí, tanto en juegos como en apps, o tienes un mac o no puedes hacer nada para ios, asi que la barrera de entrada junto a las reviews es mas alta

[^MiSaTo^]

Asi es, pero ya te digo que me he encontrado muchos "imbeciles" de esos que no podian pagar 99 al año, y como dices tu, anda y q te den mucho por culete si quieres entrar a un market y no tienes 100leuros al año xD.

Y sí, tanto en juegos como en apps, o tienes un mac o no puedes hacer nada para ios, asi que la barrera de entrada junto a las reviews es mas alta

Esa gente no es gente seria. Esto es un negocio y como tal a veces toca invertir. Y vamos 100€ al año es nada, de verdad. No hablamos de 100€ al mes (que para un negocio tampoco sería mucho pero si estás empezando sí lo es), no me digas que no pueden ahorrar 10€ al mes o algo así xD

-----Actualizado-----

Necesitas un mac por narices. Yo ando mirando para pillarme uno porque no me quedan otros cojones...

Pilla un Mac Mini pero no el de últimísima generación. Es la opción más barata para desarrollar para iOS. Te lo digo porque cuando monté la empresa hace ya 7 años es como lo hicimos. Aquel Mac Mini del 2008 aún lo sigue usando mi socio Y nos costó 500€ en una fnac por ser el modelo del año anterior (era mediados de 2009) y lo tenían de liquidación.

[OscarBraindeaD]

Hola a todos,
mi razón para abandonar la tienda de apple (de ordenadores, no de iOS) fue que, al menos entre 2011 y 2013, cambiaban cada 2x3 las "reglas" para aceptar los juegos... metieron mil historias... entitlements, sandboxing, iconset de 1024x1024 (tenían más resolución los iconos que mis juegos XD) y demás... para una empresa, no supone mucho jaleo, pero para un aficionado (que además no usaba xcode, sino blitzmax lo que complicaba a cosa) es algo que descorazona y terminas abandonando, al menos recuperé la inversión del coste de la tienda.
El desarrollo de videojuegos es un negocio, no un hobby y, por desgracia, el sitio para lo pequeños con calidad -vamos a decir- justita y sin márketing es posible que se haya acabado.

[^MiSaTo^]

Hola a todos,
mi razón para abandonar la tienda de apple (de ordenadores, no de iOS) fue que, al menos entre 2011 y 2013, cambiaban cada 2x3 las "reglas" para aceptar los juegos... metieron mil historias... entitlements, sandboxing, iconset de 1024x1024 (tenían más resolución los iconos que mis juegos XD) y demás... para una empresa, no supone mucho jaleo, pero para un aficionado (que además no usaba xcode, sino blitzmax lo que complicaba a cosa) es algo que descorazona y terminas abandonando, al menos recuperé la inversión del coste de la tienda.
El desarrollo de videojuegos es un negocio, no un hobby y, por desgracia, el sitio para lo pequeños con calidad -vamos a decir- justita y sin márketing es posible que se haya acabado.

Vuelvo a repetir como ya he dicho varias veces en varios sitios.Siempre ha sido un negocio. Siempre ha sido dificil hacer dinero siendo independiente.
No se quién os contó que había sitio para los pequeños porque nunca lo ha habido. Pero esque ni con las aplicaciones que es un mercado más "fácil" tampoco lo ha habido nunca.

Ya digo que llevo desde el 2008 dedicándome a esto, cuando el SDK de android era el 0.9 y la tienda era muy muy básica. En 2009 di el salto a iOS también y monté empresa dedicándonos a aplicaciones móviles. En aquel momento teníamos bastante trabajo porque no había casi nadie que hiciera esto (era el principio de los markets móviles). Y ya aún así no daba dinero para sobrevivir. Tengo varias aplis que hice como hobby desde entonces y no he ganado casi nada de ninguna.
Lo que me da de comer son cosas para clientes como McDonalds, Vodafone, ECI, etc (bueno ahora sus equivalentes holandeses XD). O por ejemplo la aplicación de ING de twyp que he visto que hay un mogollón de anuncios en España y demás. Vamos una campaña de márketing brutal. Esa la ha hecho un buen amigo mío, de freelance. Y te aseguro que no es rico, ni la ha hecho él sólo (a él le llamaron porque necesitaban un programador de iOS), ni creo que se coman mucho sin invertir lo que ha invertido ING en publicidad (y aún así no se si la rentabilizarán bien). Él tiene aplis también propias que tampoco le dan para sobrevivir si no es haciendo trabajos de freelance para clientes grandes.

[OscarBraindeaD]

Si estoy de acuerdo contigo, lo único que, tonto de mí, tenía una visión más "romántica" del asunto... pero no, es pasta pura y dura!

[^MiSaTo^]

La industria de los videojuegos SIEMPRE ha sido así. Lo que pasa que con los móviles había una ilusión como de que se podían volver a hacer "juegos en un garaje entre 2". Pero era eso, una ilusión. Desde el minuto 1 había metidas empresas grandes como EA y demás. No puedes competir con ellas a no ser que tengas un producto muy muy bueno y un marketing adecuado para que la gente lo conozca.
Siempre hay casos de éxito de indies que les ha ido bien pero son los menos. Y bueno lo que si es verdad es que es más facil publicar algo que antes tanto con Greenlight como con los markets de los móviles. Pero quitando eso todo está como siempre.

Mucha gente habla de burbuja pero sinceramente yo no he visto ninguna. Lo que había era que mucha gente se creía que era facil hacer un juego de movil y triunfar con ello. Incluso sin ser un juego de calidad muy alta. Y nope, de nunca.

[TRaFuGa]

Volviendo al tema del hilo (consejo empezar con Unity xD), tengo alguna duda/pregunta sobre cómo llevar un proyecto (por muy pequeño que sea este).
-¿Cuál es la manera correcta de interconectar scripts? Me refiero a que, ahora mismo por ejemplo, tengo un Player con su script en c# y sus métodos y atributos, uno de estos atributos es la vida (si vive o no), ¿cómo hacer de manera correcta esa gestión de la vida? teniendo que interconectar con la GUI y el resto de objetos del juego para que se pare todo en base a si el personaje está vivo o no (esto lo controlo de dos formas, una es con una colisión con otros objetos y la otra es si queda fuera de pantalla, dentro de los propios métodos del Player).
Mayormente mi problema es este, el tema de código y aprender todas las funciones van poco a poco, haciendo cada vez un proyecto mayor e ir probando las distintas funcionalidades, de momento hay que ir poco a poco con cosas alcanzables.

[Eskema]

Lo mas "logico" seria tener unos delegados en el player, si el player ha perdido vida/energia lo que sea, envias el delegado. La clase guiloquesea se suscribe al delegado, recibe la notificacion del player y actualiza la pantalla con la nueva vida. Asi al player se la trae floja la gui o el resto del juego, el solo sabe que le han quitado vida y lo notifica, cualquier clase que se suscriba a ese delegado recibira el mensaje de vida y hara lo que quiera hacer con él.

ClaseGUI{
Player miplayer;

void Start(){
miplayer.delegadoVida += FuncionUI;
}

void FuncionUI(float energia){
//acabas de recibir un mensaje de que al player le han quitado "energia" y su cantidad, haz lo que sea aqui en la gui para actualizar
}

}

[notbad]

Volviendo al tema del hilo (consejo empezar con Unity xD), tengo alguna duda/pregunta sobre cómo llevar un proyecto (por muy pequeño que sea este).
-¿Cuál es la manera correcta de interconectar scripts? Me refiero a que, ahora mismo por ejemplo, tengo un Player con su script en c# y sus métodos y atributos, uno de estos atributos es la vida (si vive o no), ¿cómo hacer de manera correcta esa gestión de la vida? teniendo que interconectar con la GUI y el resto de objetos del juego para que se pare todo en base a si el personaje está vivo o no (esto lo controlo de dos formas, una es con una colisión con otros objetos y la otra es si queda fuera de pantalla, dentro de los propios métodos del Player).
Mayormente mi problema es este, el tema de código y aprender todas las funciones van poco a poco, haciendo cada vez un proyecto mayor e ir probando las distintas funcionalidades, de momento hay que ir poco a poco con cosas alcanzables.

Esto que preguntas es bastante genérico y personal.

Unity se basa en componentes así que la forma "académica" de trabajar con Unity es que cualquier cosa que quieras añadir a un gameobject y que le ofrezca una caracteristica debería de ir en un componente desacoplado de todos los demás para que pudiera ser usado en otro gameobject sin modificaciones.

Si hablamos por ejemplo de un personaje que se mueve izquierda y derecha y que tiene energía, una solución que se adapta bien a componentes sería tener 2 componentes. Uno que podrías llamar como mucha gente hace "Locomotion" y otro "Health". Locomotion se encargaria de recoger el input y mover al personaje en la dirección correcta así como gestionar colisiones con el entorno si por ejemplo haces raycastings. El componente Health se debería dedicar a gestionar la eneriga del personaje y a soltar algún tipo de mensaje cuando esta por debajo del mínimo para que otro componente se entere y haga cierta cosa como matar al personaje.

Todo lo anterior es muy bonito, desacoplado, etc... pero cuando tienes cosas muy pequeñas al final lo qeu haces es unir todo eso en un componente que se asemeja al comportamiento y lógica de una entidad a la vieja usanza ya que es mucha más sencilla la comunicación. Aunque, como ya habrás adivinado, ese componente no se podrá reusar para ningún otro menester o con una probabilidad mínima.

Edit: Ahora que veo el post de @Eskema que parece que ha posteado al mismo tiempo que yo, decirte que la solución que presenta, es la que se suele usar al final. Esta a medio caballo entre las 2 que he comentado antes y suele ser la más efectiva en cuanto a proceso. De todas formas no se adapta bien a la comunicación entre 1 -> muchos. Para esto lo mejor es o lanzar un mensaje de Broadcast (lento como él solo) o tener un sistema de mensajes propio del estilo a http://wiki.unity3d.com/index.php/Ad...harp_Messenger. Hay varios más por ahí.

Como ejemplo de mensaje de broadcast podría ser "El jugador a muerto". Esto le interesa a muchas entidades en el juego o "El enemigo X a muerto". Este último puede ser importante por ejemplo si tienes un sistema de de grupos de enemigos y no quieres que un grupo tenga menos de X componentes. Tras soltar este tipo de mensaje todos los grupos de juego se autogestiónan y se ceden<->reciben miembros para balancear su número y cumplir el requisito.

Un saludo.

[HexDump]

Jo, como mola, después de casi 10 años y gracias a la bondad del señor Anarchy voy a poder postear con mi nick real . Así que Notbad ha muerto. Larga vida a HexDump .

Un saludo.

[Eskema]

Edit: Ahora que veo el post de @Eskema que parece que ha posteado al mismo tiempo que yo, decirte que la solución que presenta, es la que se suele usar al final. De todas formas no se adapta bien a la comunicación entre 1 -> muchos.

Un saludo.

Normalmente para solucionar el 1 > muchos sueles enviar el delegado al manager y el ya loopeara la lista de enemigos (por ejemplo), vamos que si mi player muere envio el delegado al enemymanager y el avisa a los enemigos de su lista y les dice que hacer.

En otros casos un delegado global al que se suscriben todos, tipo cuando pausas el juego y todo el mundo recibe ese delegado, es un momento 1 > muchos porque todo el juego recibe la pausa....

Aunque como siempre en programacion cada problema requiere una solucion distinta, no hay una solucion perfecta

[HexDump]

Normalmente para solucionar el 1 > muchos sueles enviar el delegado al manager y el ya loopeara la lista de enemigos (por ejemplo), vamos que si mi player muere envio el delegado al enemymanager y el avisa a los enemigos de su lista y les dice que hacer.

En otros casos un delegado global al que se suscriben todos, tipo cuando pausas el juego y todo el mundo recibe ese delegado, es un momento 1 > muchos porque todo el juego recibe la pausa....

Aunque como siempre en programacion cada problema requiere una solucion distinta, no hay una solucion perfecta

El delegado global al final es el manager de mensajes que yo comentaba pero generalizado a cualquier mensaje que se pueda registrar. De todas formas yo uso las 2 formas a la vez para la comunicación 1<->1 y 1->n. Depende realmente de como sea el juego. Si por ejemplo el jugador tiene que llevar el tracking de un enemigo, me suelo suscribir a él directamente ya que paso de engordar un event manager con filtros del tipo "Avisame cuando te llegue un EnemyDead para la instancia X". El filtro lo podría hacer yo en el cliente (el player), pero me gusta tener código genérico y ortogonal que no tenga que ir modificando según que cosas.

Un tema importante, para mí al menos, en ejemplo del delegado que has usado arriba, es que alguien ha de suscribirse a algo específico para reaccionar. Yo en tema de UI y es una opinión personal, prefiero no suscribirme a nada y escuchar a mensajes genéricos que uso en todos los juegos. Tipo, Player_Energy_Changed. Esto me permite meter el UI y registrar la escucha con el manager de eventos que siempre es el mismo y que se inyecta en el UI en su creación haciendo C&P de un juego a otro. Vaya, hago bastante C&P entre proyectos para las cosas normales. Tengo la convicción que si para distintos juegos puedes hacer C&P de sistemas sin tener que tocar nada o muy poco suele ser un diseño sólido.

Un saludo.