Hace unos artículos os contaba como conseguí a dos valiosos participantes del equipo: un compositor para la música y los efectos de sonido, y un level designer que se debería ocupar de exactamente eso y me quedó explicar mi aventura para conseguir un diseñador 2D.
Esto como ya dije, no fue para nada tan sencillo, si bien los anteriores los encontré en NewGrounds, los diseñadores del tipo que yo buscaba,es decir: diseño 2D estilo pixel, no abundaban por esos lares.
Por ello tome la decisión de buscar de forma muy manual y valorando el portfolio de cada candidato que pudiese encontrar en Deviantart.
Este estilo de búsqueda de candidatos puede que fuera un poco arcaico, pero lo que yo buscaba era a la vez algo muy concreto. Que decir sobre el filtrado por categorías de la web, sin duda muy bien implementado, lo cual me ayudó mucho a sesgar los resultados.
Sorpresivamente buscar filtrando por pixel art fue un fracaso, así que lo siguiente era buscar por shoot'em up y shmup dio menos resultados, pero mucho mas concretos, era el momento de espamear a los artistas.
Todo espameo da sus frutos, esto es así, verdad de la buena... y los dio, varios artistas se interesaron en participar, otros no lo veían tan claro, pero si vi algo que tenía en común fue la cautela y el gusto por el dinero, y es que el gremio de los dibujantes/artistas del pixel así como diseñadores, tienen muy bien aprendida la lección de que en este mundo nada es grátis.
Con esto, a todos les ofrecí las mismas condiciones, no voy a negar que la muchos las rechazaron, pero de los pocos que no había uno que tenía un estilo quizás desviado del pixel art que buscaba en un principio, pero dominaba el diseño de naves espaciales como nadie y evidentemente este terminó por ser el elegido.
Así es como finalizó mi búsqueda del diseñador ideal, si bien ya me indicó que no disfrutaba de mucho tiempo libre para dedicarlo a mis diseños a mi no me molestó pues la intención a parte de crear un juego era aprender y aprender requiere tiempo.
Con este artículo quiero que se vea que sí, es realmente arduo y difícil encontrar colaboradores y más que estén a la altura, pero si realmente pones tu empeño en ello, los frutos no tardan en llegar y más en un mundo tan globalizado como el actual, donde miles pueden ser lo que buscas e incluso como me pasó a mi: ninguno era español.
jueves, 28 de marzo de 2013
Sistemas de puntuaciones
Si hay algo importante en los shoot'em ups, sin duda es su sistema de puntuaciones y rankings en los que ir viendo nuestra mejora.
Desde los primeros exponentes del género, las puntuaciones han sido un pilar básico, siempre que terminabas una partida ya fuese acabando la fase o muriendo, podías acceder directamente la puntuación conseguida, esto se hacía aun más evidente si jugabas en una máquina recreativa.
En aquellos primeros tiempos, los sistemas de puntuación se basaban en cálculos sencillos, apenas reduciéndose a la asignación de un valor por muerte a cada tipo de enemigo. Pero conforme ha ido avanzando el género y los tiempos, sus sistemas de puntuación han ido avanzando y volviéndose más y más complejos, basándose en por ejemplo combos de ataques, armas, intervalos de tiempo entre muertes, y un largo eccetera.
A continuación y como segunda parte de mi investigación sobre el género detallaré los sistemas de puntuación actuales más comunes:
- Chaining o encadenado: tipo de sistema de puntuación usado por excelencia en los juegos de la desarrolladora Cave. Su sistema se basa en el encadenado de acciones en un orden específico y/o una inmediata sucesión sin dejar apenas intervalos de tiempo entre estas acciones, ya sea derrotar enemigos o recoger items durante la partida. Cuantas más acciones se encadenen, más crecerá el bonus de puntuación y por tanto las puntuaciones obtenidas serán mayores.
- Medalig o su basta traducción: medallero; este sistema es reconocido por su implementación de los juegos de la desarrolladora Raizing. Este sistema de puntuaciones usa la idea de recolección de items a modo de medallas que si bien al principio aportan poca puntuación, cuantas más se recogen más aumenta su valor, lo que hace que nuestra puntuación aumente exponencialmente.
- Proximity Bonus o bonus de proximidad: como su propio nombre indica, este sistema bonifica con puntuación extra el hecho de acabar con los enemigos desde lo más cerca posible de los mismos. Si bien la lógica en este tipo de juegos nos recomienda mantener las distancias, con este sistema se nos impulsa a lo contrario y esto tiene un riesgo y un valor añadido, pues se premiará también la memoria del usuario, ya que si sabe cuanto cuesta acabar con cada tipo de enemigo, más riesgo de proximidad podrá tomar y por tanto mayores puntuaciones obtendrá.
- Kill Bonus o bonus de muertes: quizás el mas sencillo y más acorde con el género, sin complicaciones, mata! mata todo lo que se mueva, nútrete del caos en pantalla, acumula enemigos y acaba con ellos uno tras otro, oleada tras oleada. Conseguir combos de muertes y limpiar la pantalla te hará conseguir bonificaciones de puntuaciones cada vez más altas.
- Resource Management o gestión de recursos: un sistema relativamente reciente en comparación con el resto y algo más complejo. La idea principal como su propio nombre indica es saber gestionar las armas y/o items de los que disponemos, pues cada uno de ellos otorga diferentes bonificaciones con su uso y tienen un tiempo de uso determinado, por ello debemos gestionar su uso durante cada partida para explotar su bonus al máximo.
- Milking/Leeching sin una traducción clara y tampoco siendo por esencia un sistema de puntuación, su base es exprimir la puntuación que se puede obtener de cada enemigo. Esto és, si un enemigo se regera por partes o cada cierto tiempo, la idea sería dejar que lo hiciera y así sumar una y otra vez más y mas puntos. Esto requiere de la paciencia del jugador, y además muchas desarrolladoras aplican un tiempo máximo de vida de los enemigos víctimas potenciales de estás prácticas.
- End Bonus o bono por finalización: estas bonificaciones de puntuación se aplica al acabar cada nivel o incluso el juego. Se basa en varios criterios, como la cantidad de vidas restantes o la cantidad y calidad de armas especiales no usadas. Esto proporciona al usuario un afán de superar los niveles con el menor número de recursos usados ajustándose a estos criterios de bonificación para conseguir puntuaciones más altas.
Como se puede ver, existe una amplia variedad de sistemas de puntuación en los shoot'em ups actuales, a cada cual más rebuscado, pero los cuales aportan mayor diversión a cada partida y siempre un reto, como es típico en este tipo de juegos.
Conocer y saber explotar cada uno de ellos nos llevará a la consecución de mayores puntuaciones, un reto, sin duda.
Desde los primeros exponentes del género, las puntuaciones han sido un pilar básico, siempre que terminabas una partida ya fuese acabando la fase o muriendo, podías acceder directamente la puntuación conseguida, esto se hacía aun más evidente si jugabas en una máquina recreativa.
En aquellos primeros tiempos, los sistemas de puntuación se basaban en cálculos sencillos, apenas reduciéndose a la asignación de un valor por muerte a cada tipo de enemigo. Pero conforme ha ido avanzando el género y los tiempos, sus sistemas de puntuación han ido avanzando y volviéndose más y más complejos, basándose en por ejemplo combos de ataques, armas, intervalos de tiempo entre muertes, y un largo eccetera.
A continuación y como segunda parte de mi investigación sobre el género detallaré los sistemas de puntuación actuales más comunes:
- Chaining o encadenado: tipo de sistema de puntuación usado por excelencia en los juegos de la desarrolladora Cave. Su sistema se basa en el encadenado de acciones en un orden específico y/o una inmediata sucesión sin dejar apenas intervalos de tiempo entre estas acciones, ya sea derrotar enemigos o recoger items durante la partida. Cuantas más acciones se encadenen, más crecerá el bonus de puntuación y por tanto las puntuaciones obtenidas serán mayores.
- Medalig o su basta traducción: medallero; este sistema es reconocido por su implementación de los juegos de la desarrolladora Raizing. Este sistema de puntuaciones usa la idea de recolección de items a modo de medallas que si bien al principio aportan poca puntuación, cuantas más se recogen más aumenta su valor, lo que hace que nuestra puntuación aumente exponencialmente.
- Proximity Bonus o bonus de proximidad: como su propio nombre indica, este sistema bonifica con puntuación extra el hecho de acabar con los enemigos desde lo más cerca posible de los mismos. Si bien la lógica en este tipo de juegos nos recomienda mantener las distancias, con este sistema se nos impulsa a lo contrario y esto tiene un riesgo y un valor añadido, pues se premiará también la memoria del usuario, ya que si sabe cuanto cuesta acabar con cada tipo de enemigo, más riesgo de proximidad podrá tomar y por tanto mayores puntuaciones obtendrá.
- Kill Bonus o bonus de muertes: quizás el mas sencillo y más acorde con el género, sin complicaciones, mata! mata todo lo que se mueva, nútrete del caos en pantalla, acumula enemigos y acaba con ellos uno tras otro, oleada tras oleada. Conseguir combos de muertes y limpiar la pantalla te hará conseguir bonificaciones de puntuaciones cada vez más altas.
- Resource Management o gestión de recursos: un sistema relativamente reciente en comparación con el resto y algo más complejo. La idea principal como su propio nombre indica es saber gestionar las armas y/o items de los que disponemos, pues cada uno de ellos otorga diferentes bonificaciones con su uso y tienen un tiempo de uso determinado, por ello debemos gestionar su uso durante cada partida para explotar su bonus al máximo.
- Milking/Leeching sin una traducción clara y tampoco siendo por esencia un sistema de puntuación, su base es exprimir la puntuación que se puede obtener de cada enemigo. Esto és, si un enemigo se regera por partes o cada cierto tiempo, la idea sería dejar que lo hiciera y así sumar una y otra vez más y mas puntos. Esto requiere de la paciencia del jugador, y además muchas desarrolladoras aplican un tiempo máximo de vida de los enemigos víctimas potenciales de estás prácticas.
- End Bonus o bono por finalización: estas bonificaciones de puntuación se aplica al acabar cada nivel o incluso el juego. Se basa en varios criterios, como la cantidad de vidas restantes o la cantidad y calidad de armas especiales no usadas. Esto proporciona al usuario un afán de superar los niveles con el menor número de recursos usados ajustándose a estos criterios de bonificación para conseguir puntuaciones más altas.
Como se puede ver, existe una amplia variedad de sistemas de puntuación en los shoot'em ups actuales, a cada cual más rebuscado, pero los cuales aportan mayor diversión a cada partida y siempre un reto, como es típico en este tipo de juegos.
Conocer y saber explotar cada uno de ellos nos llevará a la consecución de mayores puntuaciones, un reto, sin duda.
jueves, 21 de marzo de 2013
Investigando sobre el género
Hechos los primeros test, y ya formando estos un pequeño juego que se podía jugar e incluso empezaba a divertir, pensé en profundizar en el género de los shoot em up's para decidir que camino iba a tomar mi juego, si iba a ser difícil, accesible, como se iba a jugar y responder a muchas más de estas cuestiones.
Para esto nada mejor que San Google (si, ese que algunos usamos muchos y otros demasiado poco).
Como siempre en los resultados había de todo, pero hubo una entrada: esta, la cual tenía todas las respuestas a las preguntas que me pudieran surgir y holgadas explicaciones sobre todos los aspectos del género.
A continuación voy a recopilar los aspectos más destacables del post y compartiendo la opinión de su autor, pilares básicos del género:
Convenciones del género, es decir, que tiene que tener un juego para ser considerado un verdadero shmup:
Para esto nada mejor que San Google (si, ese que algunos usamos muchos y otros demasiado poco).
Como siempre en los resultados había de todo, pero hubo una entrada: esta, la cual tenía todas las respuestas a las preguntas que me pudieran surgir y holgadas explicaciones sobre todos los aspectos del género.
A continuación voy a recopilar los aspectos más destacables del post y compartiendo la opinión de su autor, pilares básicos del género:
Convenciones del género, es decir, que tiene que tener un juego para ser considerado un verdadero shmup:
- Armas de proyectiles, es decir armas de fuego. Si bien se comenta que algunos juegos también incluyen armas tipo melee estas son sin duda relegadas a un aspecto secundario y opcional.
- Movimiento en 2D, algo evidente, solo en momentos puntuales como cinemáticas y transiciones existe un "movimiento en 3D", el desarrollo pues será siempre en 2D independientemente de hacia donde se traslade el fondo o mundo del juego.
- Escenarios con desplazamiento automático, otro punto clave, un shmup siempre va acompañado de su desplazamiento en una, y en algunos caso 2 direcciones, que te empujan a seguir avanzando y al mismo tiempo al seguir acabando con nuevas hordas de enemigos.
- 1 Toque para morir, o dicho de otra forma, el jugador solo tiene una vida. Esto tiene sus matizes pues si en algunos juegos es literal y con solo una bala enemiga mueres, en otros dispones de armaduras o barras de vida que hacen la vida un poco más facil. Este aspecto define mucho la dificultad del género.
- Puntuaciones, aspecto más abstracto pero uno de los más importantes. La puntuaciones y el como son manejados los sistemas de puntuación son uno de los secretos para que un juego de este género vicie, te mantenga pegado a la pantalla intentando mejorar una y otra vez.
- PowerUps: estos son conocidos como mejoras temporales (o no) del armamento del jugador, proporcionando desde mayor potencia de fuego a invencibilidad temporal. Esto es además uno de las aspectos más atrayentes de los shoot'em up's, puesto que su vistosidad y sensación de poder y superación atraen al usuario a mejorar al máximo su juego.
- Hitbox, cuya traducción directa sería "caja de golpes" y no dista mucho de su sentido. Este concepto se ha vendido desarrollando a través de los años y consiste en que el personaje del jugador solo tien una parte/área de su dibujado como "consistente" y la única que puede ser afectada por los golpes o disparos de los enemigos. En este caso no obstante, yo no lo tomaría como una convención, sino como una corriente.
- Desaceleración, (ojo nada que ver con la crisis...), esto si bien se podría entender como una pausa en el juego, no lo es de forma exacta, debería entenderse como una desaceleración del tiempo de juego. Esto muchas veces es confundido con un bug o fallo de programación que en cambio suele ser implementado con el proposito de dar al usuario la opción de pararse a pensar en una situación comprometida en el juego.
- Rango, refiriéndose casi exclusivamente al sistema de ajuste de dificultad del juego, teniendo en mente un aumento de dificultad que se veo solo mitigado con la experiencia (de aquí lo de "rango") del usuario.
miércoles, 20 de marzo de 2013
Primeros test: Rutinas y colisiones
En el artículo anterior sobre los test, conseguí hacer que los enemigos aparecieran en pantalla y dispararan sin demasiada dificultad, así como añadí algunos detalles que si bien no añadían utilidad, si añadían vistosidad.
Llega el momento de ponerse serios y para ello primero empecé por implementar las rutinas de los enemigos.
Para esto utilizaría como se comentó anteriormente la librería Tween Engine la cual definiendo las coordenadas de origen y destino me permitiría definir facilmente sus rutinas pues esta librería permite además definir secuencias de rutinas por lo que se puede mover cuantas veces se quiera cada enemigo de cual forma se quiera.
Los resultados, aunque básicos, apuntaban a maneras:
Y ya que nos poníamos serios con las rutinas, vamos a más y empezaremos a implementar las colisiones con Box2D
Si no conocéis Box2D, os diré que es un motor de colisiones pensado especialmente para los cuerpos en 2 dimensiones, capaz de representar desde círculos y otras figuras simples a polígonos complejos sin dejarnos en ello el rendimiento del juego.
Normalmente y para ajustar lo mejor posible las colisiones se deberían realizar polígonos adecuados a cada nave, pero para empezar a testear las colisiones usaremos rectángulos sencillos y círculos.
Para implementar los cuerpos de Box2D lo más sencillo era, partiendo de lo que ya había, colocar los cuerpos en lugar los sprites actuales y luego copiar la posición de los cuerpos a los sprites para representarlos. Con esto se conseguirá mover los cuerpos junto con los sprites de una forma muy sencilla y efectiva.
El siguiente paso es definir los grupos de colisión a los que pertenece cada nave/disparo, para ello definimos los grupos:
En mi test, al contactar dos objetos (a excepción del jugador) los objetos se borran, aqui video:
Y hasta aquí los test de rutinas y colisiones.
Llega el momento de ponerse serios y para ello primero empecé por implementar las rutinas de los enemigos.
Para esto utilizaría como se comentó anteriormente la librería Tween Engine la cual definiendo las coordenadas de origen y destino me permitiría definir facilmente sus rutinas pues esta librería permite además definir secuencias de rutinas por lo que se puede mover cuantas veces se quiera cada enemigo de cual forma se quiera.
Los resultados, aunque básicos, apuntaban a maneras:
Y ya que nos poníamos serios con las rutinas, vamos a más y empezaremos a implementar las colisiones con Box2D
Si no conocéis Box2D, os diré que es un motor de colisiones pensado especialmente para los cuerpos en 2 dimensiones, capaz de representar desde círculos y otras figuras simples a polígonos complejos sin dejarnos en ello el rendimiento del juego.
Normalmente y para ajustar lo mejor posible las colisiones se deberían realizar polígonos adecuados a cada nave, pero para empezar a testear las colisiones usaremos rectángulos sencillos y círculos.
Para implementar los cuerpos de Box2D lo más sencillo era, partiendo de lo que ya había, colocar los cuerpos en lugar los sprites actuales y luego copiar la posición de los cuerpos a los sprites para representarlos. Con esto se conseguirá mover los cuerpos junto con los sprites de una forma muy sencilla y efectiva.
El siguiente paso es definir los grupos de colisión a los que pertenece cada nave/disparo, para ello definimos los grupos:
- Nave enemiga
- Meteorito
- Disparo enemigo
- Disparo jugador
- Nave jugador
En mi test, al contactar dos objetos (a excepción del jugador) los objetos se borran, aqui video:
Y hasta aquí los test de rutinas y colisiones.
miércoles, 13 de marzo de 2013
Resultados de la búsqueda!
Y por fin, la búsqueda y espameo para encontrar un equipo y hacer realidad el juego en todos sus aspectos empezó a dar resultado.
Tal y como comenté en mi segundo artículo, para hacer realidad el juego iba a necesitar algo de ayuda, si bien yo podía cubrir la parte técnica sin muchas dificultades, iba a necesitar varios colaboradores para la parte más artística.
Después de espamear en Deviantart y foros especializados en diseñadores como PixelJoint o WayofPixel y otras páginas para todo tipo de artistas los resultados muy a mi sorpresa empezaron a llegar sin hacerse mucho de esperar.
El primero en aparecer fue el compositor, puesto que todo shoot'em up que se precie goza de una elaborada banda sonora y unos buenos efectos de sonido o FX para los entendidos. Este artista me sorprendió gratamente pues a parte de aceptar mis condiciones sin demasiadas preguntas, me ofreció echar un vistazo a su variado portafolio en Souncloud (un buen sitio para buscar compositores por cierto), el cual era realmente variado.
Después de unas buenas primeras impresiones decidí que realizara una pequeña prueba para ver si se podía adaptar al estilo concreto que buscaba, es decir una música estilo old school, y como nó me volvió a sorprender y en solo 24h me preparó una pequeña prueba que hizo que le agregara al equipo de forma inmediata pues era exactamente lo que buscaba.
Llegados a este punto, ya tenía mi primer compañero en el grupo y seguía buscando con avidez un diseñador para el juego, pero cual fue mi sorpresa una mañana al revisar los mensajes de todas las webs y foros en las que pasé la semana buscando cuando, en una de ellas, un usuario me contactó directamente... para ofrecerse como level designer, hecho que me sorprendió de nuevo y me alegró a la vez, pues era una persona con experiencia en este campo y podría hacer del juego algo más divertido y equilibrado.
Sin apenas dudarlo decidí interesarme por el y su trabajo, me explico de sus experiencias y su forma de trabajar y decidí ofrecerle ocuparse del diseño de niveles y asistirme sobre el gameplay del juego, sin duda presentía que iba a ser de gran ayuda.
Ahora ya tenía compositor y diseñador de niveles/gameplay... el diseñador (gráfico) sería ya otro cantar...
Tal y como comenté en mi segundo artículo, para hacer realidad el juego iba a necesitar algo de ayuda, si bien yo podía cubrir la parte técnica sin muchas dificultades, iba a necesitar varios colaboradores para la parte más artística.
Después de espamear en Deviantart y foros especializados en diseñadores como PixelJoint o WayofPixel y otras páginas para todo tipo de artistas los resultados muy a mi sorpresa empezaron a llegar sin hacerse mucho de esperar.
El primero en aparecer fue el compositor, puesto que todo shoot'em up que se precie goza de una elaborada banda sonora y unos buenos efectos de sonido o FX para los entendidos. Este artista me sorprendió gratamente pues a parte de aceptar mis condiciones sin demasiadas preguntas, me ofreció echar un vistazo a su variado portafolio en Souncloud (un buen sitio para buscar compositores por cierto), el cual era realmente variado.
Después de unas buenas primeras impresiones decidí que realizara una pequeña prueba para ver si se podía adaptar al estilo concreto que buscaba, es decir una música estilo old school, y como nó me volvió a sorprender y en solo 24h me preparó una pequeña prueba que hizo que le agregara al equipo de forma inmediata pues era exactamente lo que buscaba.
Llegados a este punto, ya tenía mi primer compañero en el grupo y seguía buscando con avidez un diseñador para el juego, pero cual fue mi sorpresa una mañana al revisar los mensajes de todas las webs y foros en las que pasé la semana buscando cuando, en una de ellas, un usuario me contactó directamente... para ofrecerse como level designer, hecho que me sorprendió de nuevo y me alegró a la vez, pues era una persona con experiencia en este campo y podría hacer del juego algo más divertido y equilibrado.
Sin apenas dudarlo decidí interesarme por el y su trabajo, me explico de sus experiencias y su forma de trabajar y decidí ofrecerle ocuparse del diseño de niveles y asistirme sobre el gameplay del juego, sin duda presentía que iba a ser de gran ayuda.
Ahora ya tenía compositor y diseñador de niveles/gameplay... el diseñador (gráfico) sería ya otro cantar...
martes, 12 de marzo de 2013
Primeros test: Varios
Como cuando se crea todo juego, es usual fijarse en los grandes del género, o incluso en los grandes de tu plataforma objetivo y esa es una de las primeras cosas que hice.
Me fije en varios detalles que tenían como el uso de sombras o el desplazamiento del fondo/cámara según la posición del jugador. Detalles que me resultan atractivos y dotan de mayor impacto visual al juego.
Primero me propuse mover el fondo en referencia a la nave del jugador, no fue demasiado difícil, pues podía mover el fondo en el mismo momento que la nave del jugador y para conseguir el efecto deseado solo tenía que invertir el movimiento y reducirlo para limitar la cantidad de pixeles que se iba a poder desplazar el fondo.
Después decidí aplicar las sombras, al principio me planteé proyectarlas de forma dinámica a partir de las texturas, pero por cuestiones de rendimiento era poco recomendable.
Decidí entonces buscar una librería de iluminación para proyectar las sombras, de nuevo mala decisión, logré proyectar las sombras pero el rendimiento cayó en picado.
¿Que podía hacer? se me ocurrió optar por una solución rudimentaria pero que resultó ser muy efectiva y no afectar de forma negativa al rendimiento del juego como las anteriores.
La solución fue crear texturas solo para las sombras y colocarlas en referencia a sus objetos, así pues cada sprite tendría su sombra asociada y después solo tendría que dibujar ambas.
Finalmente solo tenía que solucionar el posicionamiento de las sombras pues si las dejaba así los propios objetos cubrirían su sobra y esta por tanto no se vería. Para solventar este problema decidí tomar como segundo punto de referencia y un punto común de la pantalla para todas las sombras y así crear la ilusión de un punto de luz en pantalla, con estas dos referencias el problema de las sombras estaba solucionado...
Siguiente artículo, material pesado: rutinas y física de colisiones!
Me fije en varios detalles que tenían como el uso de sombras o el desplazamiento del fondo/cámara según la posición del jugador. Detalles que me resultan atractivos y dotan de mayor impacto visual al juego.
Primero me propuse mover el fondo en referencia a la nave del jugador, no fue demasiado difícil, pues podía mover el fondo en el mismo momento que la nave del jugador y para conseguir el efecto deseado solo tenía que invertir el movimiento y reducirlo para limitar la cantidad de pixeles que se iba a poder desplazar el fondo.
Después decidí aplicar las sombras, al principio me planteé proyectarlas de forma dinámica a partir de las texturas, pero por cuestiones de rendimiento era poco recomendable.
Decidí entonces buscar una librería de iluminación para proyectar las sombras, de nuevo mala decisión, logré proyectar las sombras pero el rendimiento cayó en picado.
¿Que podía hacer? se me ocurrió optar por una solución rudimentaria pero que resultó ser muy efectiva y no afectar de forma negativa al rendimiento del juego como las anteriores.
La solución fue crear texturas solo para las sombras y colocarlas en referencia a sus objetos, así pues cada sprite tendría su sombra asociada y después solo tendría que dibujar ambas.
Finalmente solo tenía que solucionar el posicionamiento de las sombras pues si las dejaba así los propios objetos cubrirían su sobra y esta por tanto no se vería. Para solventar este problema decidí tomar como segundo punto de referencia y un punto común de la pantalla para todas las sombras y así crear la ilusión de un punto de luz en pantalla, con estas dos referencias el problema de las sombras estaba solucionado...
Siguiente artículo, material pesado: rutinas y física de colisiones!
lunes, 11 de marzo de 2013
Primeros test: Enemigos
En el anterior artículo nos terminamos de definir el comportamiento básico de la nave controlada por el jugador. Ahora tocaba definir los enemigos y su comportamiento básico.
Para llevar a cabo esto podemos aprovechar los ciclos de disparo de la nave del jugador, esto nos resolverá facilmente el disparo de los enemigos.
Ahora la parte más complicada: colocar algunos enemigos en pantalla, moverlos y que a su vez disparen.
Por partes:
- Colocar los enemigos en pantalla podríamos reducirlo en un principio a añadirlos en tiempos fijos tal y como se hacía con los disparos de la nave del jugador, esto más tarde plantearía otros problemas, pero para realizar unas pruebas es más que suficiente.
La resolución sería:
Para solventar este aspecto de la forma más elegante posible elegí usar la librería Tween Engine que manejaba sobradamente una gran gama de animaciones y su implementación es clara y sencilla, con lo que obtenía:
Con todo esto se obtuvo esto:
Como se puede observar, se producía un caos considerable, pero era una prueba valida de mis intenciones e implementación.
También existe una pequeña animación del fondo y el uso de sombras, cosas que no he comentado, pero se explicará con detalle en siguientes artículos.
Para llevar a cabo esto podemos aprovechar los ciclos de disparo de la nave del jugador, esto nos resolverá facilmente el disparo de los enemigos.
Ahora la parte más complicada: colocar algunos enemigos en pantalla, moverlos y que a su vez disparen.
Por partes:
- Colocar los enemigos en pantalla podríamos reducirlo en un principio a añadirlos en tiempos fijos tal y como se hacía con los disparos de la nave del jugador, esto más tarde plantearía otros problemas, pero para realizar unas pruebas es más que suficiente.
La resolución sería:
Cada T tiempo -> añade enemigo -> hasta que existan I enemigos en pantalla- Moverlos: quizás la parte más peliaguda, pues aunque se decidiera mover las naves a posiciones aleatorias de la pantalla deberíamos hacer las animaciones para representar dichos movimientos.
Para solventar este aspecto de la forma más elegante posible elegí usar la librería Tween Engine que manejaba sobradamente una gran gama de animaciones y su implementación es clara y sencilla, con lo que obtenía:
Animar cada T tiempo -> enemigo a coordenadas X e Y- Hacer que disparen: como ya se ha comentado antes, el funcionamiento era similar a la de la nave jugador, con la diferencia que las coordenadas de disparo son las del enemigo y cada enemigo tiene por separado su rutina de disparo.
Con todo esto se obtuvo esto:
Como se puede observar, se producía un caos considerable, pero era una prueba valida de mis intenciones e implementación.
También existe una pequeña animación del fondo y el uso de sombras, cosas que no he comentado, pero se explicará con detalle en siguientes artículos.
domingo, 10 de marzo de 2013
Primeros test: La nave del jugador
La búsqueda de un equipo para desarrollar un videojuego, es algo difícil, requiere tiempo y muchas ganas, si bien como he comentado anteriormente ahora me tocaba esperar, y mientras, como no podía ser de otra forma me dediqué a crear pequeños test e investigar las distintas mecánicas que se esconden detrás de los shoot'em up verticales y 2D.
Para ello, teniendo montado el entorno de desarrollo y habiendo hecho varias pruebas con el, me dispuse a buscar algunos diseños para realizar los primeros test.
Y para encontrar unos buenos sprites nada mejor que googlear un rato con las palabras clave "shmup sprites" y con ello me topé con este fantástico pack de sprites que me venía muy bien para mi cometido.
Ahora tocaba empezar a desarrollar de verdad.
Lo primero que quise hacer es colocar la nave en pantalla, hacerla disparar y poner algunos sprites que representaran los enemigos, moverlos aleatoriamente y ponerles la misma forma de disparo que a la nave del jugador.
Mover la nave del jugador era simplemente hacer que siguiera el ratón, ya que en los móviles sería seguir el dedo. No me costó demasiado siguiendo la documentación de libgdx para los inputs de usuario.
El siguiente paso era hacer disparar a la nave del usuario, pense en hacer que disparara automáticamente mientras el usuario estuviera tocando la pantalla, lo que facilitaba el juego en dispositivos móviles. Así que con este planteamiento llegaba a la simplicidad de la sentencia:
Con todo esto el gameplay básico de la nave estaba completo, era hora de pasar a implementar los enemigos básicos y su comportamiento...
Para ello, teniendo montado el entorno de desarrollo y habiendo hecho varias pruebas con el, me dispuse a buscar algunos diseños para realizar los primeros test.
Y para encontrar unos buenos sprites nada mejor que googlear un rato con las palabras clave "shmup sprites" y con ello me topé con este fantástico pack de sprites que me venía muy bien para mi cometido.
Ahora tocaba empezar a desarrollar de verdad.
Lo primero que quise hacer es colocar la nave en pantalla, hacerla disparar y poner algunos sprites que representaran los enemigos, moverlos aleatoriamente y ponerles la misma forma de disparo que a la nave del jugador.
Mover la nave del jugador era simplemente hacer que siguiera el ratón, ya que en los móviles sería seguir el dedo. No me costó demasiado siguiendo la documentación de libgdx para los inputs de usuario.
El siguiente paso era hacer disparar a la nave del usuario, pense en hacer que disparara automáticamente mientras el usuario estuviera tocando la pantalla, lo que facilitaba el juego en dispositivos móviles. Así que con este planteamiento llegaba a la simplicidad de la sentencia:
Si el usuario está tocando la pantalla -> disparaEsto dio en su origen una inundación de disparos en pantalla, pues disparaba tan rápido como refrescos sucedían en pantalla (el juego estaba corriendo a 60 fps) lo que hacía de ello una locura y planteaba el siguiente problema: ¿como hacer que dispare a intérvalos fijos y calculados una cantidad razonable de disparos. Para conseguir esto debería usar el tiempo del loop de juego y guardar su tiempo a intervalos regulares para compararlos con su actual, entonces llegaba a la sentencia:
Si tiempo guardado es mayor o igual a tiempo de loop -> autoriza disparo y guarda de nuevo el tiempoEsto combinado con la sentencia anterior conseguía lo que yo necesitaba, disparos regulares y con una cantidad que podía controlar y resultaba razonable.
Con todo esto el gameplay básico de la nave estaba completo, era hora de pasar a implementar los enemigos básicos y su comportamiento...
Empieza la aventura
Y menuda aventura...!
- Sabes que quieres hacer un shoot'em up: siempre lo has deseado,
- Sabes para que lo quieres hacer: plataformas móviles, ya que conoces como se programan un disponen de una gran variedad de frameworks para el desarrollo de videojuegos.
- Sabes como lo quieras hacer: un gameplay rápido, muchos enemigos, todavía más balas, buena música, un gran diseño y preguntar siempre a los pros.
¿Y ahora qué? pues ahora empieza lo bueno, manos a la obra!
Al principio esto es como una receta de cocina, tienes tus ingredientes:
- Motor/framework de videojuegos: libgdx
- Motor de físicas: box2D
- Entorno de desarrollo: Eclipse IDE
Y luego tienes a los participantes en su creación:
- Participantes en su creación: programador (yo), compositor y diseñador.
Digamos que los ingredientes técnicos son los más sencillos de encontrar, solo tienes que ver las opciones de las que dispones para las plataformas has elegido y luego comparar, probar y finalmente elegir con cual te quedas.
Dar con los participantes es algo más complicado, hablemos de ello y de paso dejaré algunos enlaces interesantes.
Buscar compositor ha sido sencillo, muy a mi sorpresa. Realmente me tropecé por causalidad con el foro de Newgrounds, primero vi que tenía una sección dedicada justamente a lo que necesitaba (bendito Google y tu excelsa manera de manejar palabras clave), la búsqueda de participantes en el desarrollo de un proyecto audiovisual, y después de darme de alta con dicho propósito vi su maravilloso project manager en el cual puedes manejar muchos de los aspectos relacionados con un proyecto de este tipo.
Si, Newgrounds es un foro que se dedica a la creación de juegos flash, pero eso solo es la parte técnica, la parte creativa (diseñador y compositor) es independiente de esa parte, así que publiqué un post explicando lo que buscaba y cual era mi meta (la creación de un shmup).
Hecho esto tocaba ir con muchas ganas a Deviantart y buscar de una forma más agresiva a un diseñador que cumpliera con los requisitos que buscaba.
Esto requiere paciencia y enviar muchos (muchos!) mensajes a muchos (muchísimos) usuarios que tienen el/los estilos que buscas para tu videojuego. En mi caso las palabras claves eran "shmup" o "shoot'em up" con lo que conseguí cientos de dibujos/artworks/diseños sobre este genero y lo siguiente fue abrir pestañas como loco y enviar mensajes como un demente ( xDD), lo siguiente era esperar a ver que pasaba...
Mientras esperaba busqué en otros foros/webs como Dribbble (fuente de inspiración para muchos proyectos) o PixelJoint (donde publiqué un post buscando diseñador), aunque la verdad son sitios orientados mucho a profesionales que normalmente exigen pargo por adelantado y yo buscaba más bien a gente amateur o indie que buscase embarcarse en una aventura.
Y bueno así es como empieza la aventura de mi primer juego indie, los resultados de la búsqueda/investigación, no se harían mucho de esperar...
- Sabes que quieres hacer un shoot'em up: siempre lo has deseado,
- Sabes para que lo quieres hacer: plataformas móviles, ya que conoces como se programan un disponen de una gran variedad de frameworks para el desarrollo de videojuegos.
- Sabes como lo quieras hacer: un gameplay rápido, muchos enemigos, todavía más balas, buena música, un gran diseño y preguntar siempre a los pros.
¿Y ahora qué? pues ahora empieza lo bueno, manos a la obra!
Al principio esto es como una receta de cocina, tienes tus ingredientes:
- Motor/framework de videojuegos: libgdx
- Motor de físicas: box2D
- Entorno de desarrollo: Eclipse IDE
Y luego tienes a los participantes en su creación:
- Participantes en su creación: programador (yo), compositor y diseñador.
Digamos que los ingredientes técnicos son los más sencillos de encontrar, solo tienes que ver las opciones de las que dispones para las plataformas has elegido y luego comparar, probar y finalmente elegir con cual te quedas.
Dar con los participantes es algo más complicado, hablemos de ello y de paso dejaré algunos enlaces interesantes.
Buscar compositor ha sido sencillo, muy a mi sorpresa. Realmente me tropecé por causalidad con el foro de Newgrounds, primero vi que tenía una sección dedicada justamente a lo que necesitaba (bendito Google y tu excelsa manera de manejar palabras clave), la búsqueda de participantes en el desarrollo de un proyecto audiovisual, y después de darme de alta con dicho propósito vi su maravilloso project manager en el cual puedes manejar muchos de los aspectos relacionados con un proyecto de este tipo.
Si, Newgrounds es un foro que se dedica a la creación de juegos flash, pero eso solo es la parte técnica, la parte creativa (diseñador y compositor) es independiente de esa parte, así que publiqué un post explicando lo que buscaba y cual era mi meta (la creación de un shmup).
Hecho esto tocaba ir con muchas ganas a Deviantart y buscar de una forma más agresiva a un diseñador que cumpliera con los requisitos que buscaba.
Esto requiere paciencia y enviar muchos (muchos!) mensajes a muchos (muchísimos) usuarios que tienen el/los estilos que buscas para tu videojuego. En mi caso las palabras claves eran "shmup" o "shoot'em up" con lo que conseguí cientos de dibujos/artworks/diseños sobre este genero y lo siguiente fue abrir pestañas como loco y enviar mensajes como un demente ( xDD), lo siguiente era esperar a ver que pasaba...
Mientras esperaba busqué en otros foros/webs como Dribbble (fuente de inspiración para muchos proyectos) o PixelJoint (donde publiqué un post buscando diseñador), aunque la verdad son sitios orientados mucho a profesionales que normalmente exigen pargo por adelantado y yo buscaba más bien a gente amateur o indie que buscase embarcarse en una aventura.
Y bueno así es como empieza la aventura de mi primer juego indie, los resultados de la búsqueda/investigación, no se harían mucho de esperar...
¡Hola!
Bueno ante todo me presentaré: mi nombre es Jorge Garrido, aunque depende de donde me encuentres puedes conocerme por varios nick's como: FireZenk o dark-kei.
Soy programador, de básicamente todo lo que me encapricha, es decir de todo lo que me causa curiosidad.
Programo desde hace unos 8 años mas o menos, descontando el tiempo que aprendí lenguajes de marcas como HTML que es como empezó mi curiosidad pero no se puede considerar un lenguaje de programación como tal.
Declaro mi amor por Java, el primer lenguaje serio que aprendí de verdad, con el cual conocí todos los aspectos de la programación profesional y además me hice amante de la programación orientada a objetos. A partir de este punto aprendí otros muchos ya que en esencia todos son parecidos dentro de la programación imperativa, como por ejemplo C, C++ o C# así como PHP y JavaScript, seguidos de otros muchos y acompañados de sus variados frameworks y librerías, pero eso ya es otra história.
La intencionalidad de este blog es mostrar el avance de una de las curiosidades que me viene desde que apenas podía hablar, los videojuegos y en concreto su creación.
Desde pequeño y empezando por la NES mi curiosidad hacia ese mundo ha ido creciendo exponencialmente y siempre he deseado crear mi propio videojuego, uno que divirtiera y no solo a mi, sino a gente que también compartiera mis gustos.
Este año por fin me encuentro con el poder necesario como para desarrollar mi primer videojuego serio, habiendo antes dedicado un tiempo para la investigación y desarrollo de pequeños juegos y test.
Vayamos al grano, en este blog voy a ir explicando como desarrollo de mi primer gran videojuego: un shoot'em up vertical para plataformas móviles y la nueva consola de sobremesa (y primera) indie Ouya.
En los primeros artículos, os podré al día ya que el videojuego lleva aproximadamente una semana de desarrollo en el tiempo en el que estoy escribiendo este artículo.
Sin más que añadir, espero que disfrutéis de este blog tanto como yo disfrutaré desarrollando este videojuego.
Soy programador, de básicamente todo lo que me encapricha, es decir de todo lo que me causa curiosidad.
Programo desde hace unos 8 años mas o menos, descontando el tiempo que aprendí lenguajes de marcas como HTML que es como empezó mi curiosidad pero no se puede considerar un lenguaje de programación como tal.
Declaro mi amor por Java, el primer lenguaje serio que aprendí de verdad, con el cual conocí todos los aspectos de la programación profesional y además me hice amante de la programación orientada a objetos. A partir de este punto aprendí otros muchos ya que en esencia todos son parecidos dentro de la programación imperativa, como por ejemplo C, C++ o C# así como PHP y JavaScript, seguidos de otros muchos y acompañados de sus variados frameworks y librerías, pero eso ya es otra história.
La intencionalidad de este blog es mostrar el avance de una de las curiosidades que me viene desde que apenas podía hablar, los videojuegos y en concreto su creación.
Desde pequeño y empezando por la NES mi curiosidad hacia ese mundo ha ido creciendo exponencialmente y siempre he deseado crear mi propio videojuego, uno que divirtiera y no solo a mi, sino a gente que también compartiera mis gustos.
Este año por fin me encuentro con el poder necesario como para desarrollar mi primer videojuego serio, habiendo antes dedicado un tiempo para la investigación y desarrollo de pequeños juegos y test.
Vayamos al grano, en este blog voy a ir explicando como desarrollo de mi primer gran videojuego: un shoot'em up vertical para plataformas móviles y la nueva consola de sobremesa (y primera) indie Ouya.
En los primeros artículos, os podré al día ya que el videojuego lleva aproximadamente una semana de desarrollo en el tiempo en el que estoy escribiendo este artículo.
Sin más que añadir, espero que disfrutéis de este blog tanto como yo disfrutaré desarrollando este videojuego.
Suscribirse a:
Entradas (Atom)