[gratis]

¡¡Buenas!!

Hace algún tiempo ya os enseñé por aquí nuestro proyecto en kickstarter de The Last Door.
Bueno pues salió bien la campaña de crowdfunding y pudimos hacer el capítulo 1 :)

Ahora quería anunciaros que acabamos de publicar el capítulo 2, y el capítulo 1 pasa a ser totalmente gratis.
Se puede jugar en la web: http://www.thelastdoor.com

Para jugar al capítulo 2 hay que hacer una pequeña donación (de la cantidad que te de la gana) para apoyar el desarrollo del tercero.

Y además tanto el capítulo 1 como el 2 están ahora disponibles en castellano :)

Nos sería de gran ayuda que difundierais el juego, si es que os mola ;)

¡Gracias!

[aventura de horror con estilo pixel art]

Buenas!!

En The Game Kitchen hemos lanzando un proyecto de crowdfunding sobre una aventura de horror con estilo pixel art.

Ya nos quedan solo 9 días de campaña, la cosa va bien, pero necesitamos un buen empujón final para conseguirlo; así que cualquier ayuda a la difusión será muy agradecida  ;)

Aquí el proyecto en Kickstarter: http://www.kickstarter.com/projects/1042570429/the-last-door-episodic-horror-adventure

Os dejo también con algunos vídeos...

Vídeo gampeplay
http://www.youtube.com/watch?v=nEOfjEi45JY

Vídeo de la campaña, subtitulado al Castellano
http://www.youtube.com/watch?v=4bZUgxdCybY

¡Pedida de matrimonio dentro del juego, de nuestro loco compañero Alejo!
http://www.youtube.com/watch?v=T57Md2mlrsI

¡¡Muchas gracias!!

Comparto enlace a un artículo que escribí hace un par de semanas.
Para concienciar un poco más por aquí, que seguro que hay muchos que todavía temen incluir accesibilidad en sus juegos  ;)

http://www.videojuegosaccesibles.es/2012/03/perder-el-miedo-la-accesibilidad.html

Según dice la documentación al darte de alta como vendedor en Android Market los pagos me vendrán de Google Payment ltd, entidad que está registrada en UK. El problema está en que no encuentro por ningún lado su dirección de facturación y su CIF europeo y me harían falta para emitirles una factura cada vez que ellos me hagan un pago.

Con Apple funciona así, y no hay impuestos porque se emite una factura a una entidad de Apple que también es europea. Pero no se que hacer ahora con Android, veo a mucha gente preguntando lo mismo pero ninguna respuesta clara y oficial. Algunos dicen que Google Payment ltd es solo un intermediario y hay que facturar como si le vendieras directamente a los compradores, pero no es nada oficial, y yo no creo que sea así, porque a mí el pago me llegaría al banco de la entidad Google Payment ltd y a esa es a la que le tengo que enviar la factura por la cantidad exacta que me mande.

¿Alguien lleva ya tiempo haciendo esto? ¿Tiene los datos completos de Google Payment ltd?
¿Hay alguna forma de hacerle preguntas a Google sin que sea un foro donde nadie de Google responde de forma oficial?

[ActionScript 3]

Buenas!!!

Estamos preparando el próximo DevSpace, que seguramente será el próximo sábado 29 de mayo. Todavía nos tienen que confirmar el sitio, y además esta vez vamos a estrenar sitio!! Va a ser en un centro cívico que hay al lado del parque de los Principes, en los Remedios. Es fácil llegar, hay autobuses y metro cerca y además sitio para aparcar para quien venga de fuera.

El DevSpace consistirá en mini-exposiciones sobre herramientas, metodologías, leguajes, programas... o lo que sea que uses para desarrollar videojuegos. La idea es que este DevSpace sea muy participativo y se anime el mayor número de gente a hablar. La mini exposición debería ser una descripción muy breve de lo que usas y 3 pros y 3 contras. Sólo unos 5 o 10 minutos hablando. No hace falta prepararse presentación, aunque estaría bien por lo menos enviarnos antes los 3 pros y contras para que nosotros los metiéramos en una presentación básica.

Quien esté interesado en participar que escriba al mail de DeSEA o que lo comunique por este hilo, iremos actualizando este post y uno en la web para que se vayan viendo lo temas ya elegidos.

Pongo algunos ejemplos de temas: Scrum, Fireworks, 3DStudio, XNA, Ogre, C++, GameMaker...

De momento tenemos ya asegurados:

• Programación: ActionScript 3 (por mi-go)
• Programación: OpenAL (por H-K)
• Programación: XNA (por D.V.)
• Gráficos: Flash, para gráficos de juegos (por ionicboy)

Pedazo de artículo sobre un caso de éxito de un juego flash vendido usando Flash Game License:

http://www.gamasutra.com/view/news/27924/InDepth_Behind_Flash_Game_SteamBirds_Revenue_Deals.php

Del artículo también salen dos direcciónes muy interesantes:
Las estadísticas de Flash Game License: http://www.flashgamelicense.com/report_monthly_site_sales.php
Y una API para controlar el uso de tu juego, incluyendo tiempos, fases... : http://swfstats.com/

Buenas!

Estoy pensando la mejor manera de crear un sistema de ranking online propio y tengo dudas con la seguridad...

Pensaba hacer un web service para controlar el ranking online porque es lo que me parece más reutilizable. Primero pensé en hacerlo en PHP, pero viendo el tema de la seguridad, para asegurarme de que sólo lo puede llamar el juego y no otra aplicación y que además los datos que se envían no se puedan leer para poder reenviarlos después, encontré que existe un estándar en seguridad de web services que se llama WS-Security que te da todas esas posibilidades.

En la parte sevidor de PHP tengo que pasar, porque WS-Security sólo lo he visto implementado con una extensión que no es sencilla de instalar y en servidores compartidos no la van a meter... así que tiraré por ASP.NET que sí soporta nativamente WS-Security, aunque hay que hacer algunas cosillas.

El problema lo veo ahora en la parte cliente del juego en AS3. Según he leído flex (porque realmente uso el sdk de flex) no soporta nativamente WS-Security pero hay apaños por ahí para crear una cabezera que te da la autentificación necesaria en WS-Security, pero que sólo sirve para eso y no se puede activar la parte de encriptación de los mensajes.

¿Alguien sabe algo de esto o a implementado un ranking online con seguridad de otra forma?

Gracias!!!

Agradecer a todos los que asistieron al DevSpace #9, estuvo muy bien y fue muy numeroso!  :)

A ver si este año se anima todavía más gente y somo más todavía!

Voy adelantado ya, como conté ayer, que el mes que viene nos vemos por la facultad de informática (ya avisaremos el día y la hora) y que dentro de dos meses Jose ha dicho que seguramente hagan un DevSpace sobre desarrollo para Android.

Quien quiera hacer un DevSpace sobre algo ya sabeis que sólo hay que decirlo!

más movimiento!!   ^_^

Buenas!

Tengo un textfield de tipo input pero no logro hacer que se pueda introducir ciertos caracteres como: á é í ó ú ñ....

He estado buscando por documentación e Internet y no encuentro solución que funcione.
He probado metiendotiéndolos como permitodos en la propiedad restrict, y cambiando el tipo de letra a estándares como Verdana.

¿alguna idea?
gracias!   ;)

Copio la última entrada de mi blog (http://www.videojuegosaccesibles.es/2009/12/gamma-4-concurso-desarrollo-de-juegos.html) porque esto le puede interesar a alguno de por aquí....

El grupo Gama 4 invita a los desarrolladores de videojuegos a participar en una competición de creación juegos controlados sólo por un botón.

Los videojuegos serán expuestos y podrán ser jugados en el recinto de la Game Developers Conference 2010 de San Francisco (GDC 2010). La GDC es uno de los eventos más importantes a nivel mundial sobre desarrollo de videojuegos. Además los juegos seleccionados serán premiados con pases de "acceso completo" a la GDC.

Más detalles y las reglas de participación en: http://www.kokoromi.org/gamma4

[Nivel21]

Aparición de Nivel21 (http://www.nivel21.net) y Divertronic Games (http://www.divertronicgames.com) en GiraldaTV, televisión digital local de Sevilla. Hablamos un poco sobre "Rotor'scope - El secreto de la energia infinita" (http://www.rotorscope-game.com) y sobre los proyectos que estamos desarrollando en el campo de la accesibilidad.

Vídeo: http://www.youtube.com/watch?v=TgXHahwEQJ4

[La Huída]

Buenas!

Claudio Sáez ha creado el juego "La Huída" usando las librerías dx_lib32.
Lo podéis bajar de: http://a11d.net/juegos/LaHuida.rar

Es un juego de rol, no pongo screenshots porque sólo hay texto y formularios. Es un juego pensado para que puedan jugar también los ciegos usando un lector de pantalla. El creador del juego es también ciego.

Lo comento yo por aquí porque supongo que le haría ilusión a EX3 saber de este juego.

http://www.ted.com/talks/pranav_mistry_the_thrilling_potential_of_sixthsense_technology.html

[IV Congreso de la Cibersociedad 2009]

Hola a todos!

Se está celebrando on-line el IV Congreso de la Cibersociedad 2009.

Hay una sección de trabajos sobre videojuegos:
http://www.cibersociedad.net/congres2009/es/coms/llistat/gts/videojuegos-y-ocio-digital/49/

Y el foro para discutir sobre ellos:
http://www.cibersociedad.net/congres2009/es/forums/7/videojuegos-y-ocio-digital/38/

[Advertencia: Cómo hacer y cómo no hacer juegos en flash]

Llevo mucho tiempo queriendo actualizar el documento que hice para adevertir de ciertas cosas, ya lo he hecho añadiendo un apartado al princpio.


   Advertencia: Cómo hacer y cómo no hacer juegos en flash

Este aparatado ha sido añadido en la 2ª edición de este documento para advertir sobre cómo hacer y cómo no hacer un juego flash, ya que este documento comete los mismos fallos de programación que muchos tutoriales que hay en Internet sobre desarrollo de juegos en flash.

He decidido no eliminar este documento a pesar de que en él se explique una forma no correcta de hacer un juego en flash, porque sí que puede resultar una forma más fácil para los que estén aprendiendo programación en general, como primer paso fácil y motivador a seguir aprendiendo. Pero aquellos programadotes experimentados deberían seguir con atención las siguientes razones de porque no es correcto este manual y cómo se debería hacer realmente un juego.

Existe un peligro grande de aprender a programar videojuegos empezando por Flash/Actionscript por varias razones:
-   Es una API claramente para software "orientado a eventos" del usuario, como una página web o software de gestión.
-   El 99% de los libros y manuales que hay sobre ActionScript usa la librería de igual forma, pensando en software orientado a eventos del usuario.

La forma de programar orientado a eventos se centra mucho en esperar las acciones del usuario y a partir de ahí lanzar cierta lógica de ejecución, sin importar demasiado que exista una única "línea lógica de ejecución" ya que muchas de las acciones son totalmente independientes y no influyen entre ellas.

Por esta razón en muchas webs, programas o juegos hechos en flash se observará un uso excesivo de "event listeners" que ejecutan código generando varias líneas lógicas de ejecución haciendo imposible cierto tipo de control sobre el juego.

Para hacer bien un videojuego en flash hay que tener siempre en mente el modo clásico de un motor de un videojuego con un "main game loop". Muchos libros y artículos en Internet tratan este tema, por ejemplo: http://en.wikipedia.org/wiki/Game_programming#The_game_loop
Y evitar, en la medida de lo posible, el uso de los event listeneters.

Además, recomiendo la lectura de estos dos artículos para entender mejor la forma en la que funciona flash:
El sistema de renderizado de Flash Player
http://llops.com/blog/2008/05/24/el-sistema-de-renderizado-de-flash-player/
EnterFrame vs Timer (I)
http://llops.com/blog/2008/07/27/enterframe-vs-timer-i/


Trabajando de esta manera tendremos:
-   Control completo de la lógica del juego en todo momento.
-   Facilidad para cambiar la velocidad del juego en cualquier momento o hacer pausa.
-   Control para asegurarnos de que el juego se ejecutará siempre a la misma velocidad en todos los pcs.

Teniendo en cuenta el modelo clásico de cómo hacer un videojuego, Flash sigue siendo una herramienta muy potente porque posee una API muy completa, fácil y útil para videojuegos y podemos exportar para gran cantidad de plataformas.

[DevSpace #8 + Tecontec Playground "Diseño y prototipos"]

DevSpace #8 + Tecontec Playground "Diseño y prototipos"

Miércoles 9 de Septiembre de 2009. 19:00  Centro Cívico "Las sirenas", La Alameda de Hércules, Sevilla.

Con poco tiempo de margen anunciamos que este Miércoles realizaremos el siguiente Devspace junto con los amigos de la asociación átomos y bits que tienen algunas inquietudes afines a las nuestras. Aprovechamos también la situación para probar día y horario nuevo.

En este caso cerramos un poco el ciclo y volvemos a hablar de Diseño y prototipado rápido de videojuegos, como ya hicimos en el DevSpace#1 hace un año.

Se planteará un coloquio y presentaciones de diversos libros relacionados con el diseño y desarrollo de videojuegos.

El conductor de la sesión será Alejo Acevedo, para presentar algunas ideas de base, pero la intención es que todos participemos. Para ello se invita a los asistentes (aunque no es necesario) a que traigan algunas fichas de juegos de mesa, cartas o similares para usarlos en la realización de los prototipos.

Si quieres asistir es conveniente que te pongas en contacto con nosotros, para que vayamos haciendo una estimación de plazas.  Ya que estamos en colaboración con los encuentros tecontec el acceso es libre.

Más info: http://www.desea.es/index.php/2009/09/07/devspace-8-tecontec-playground/

Buenas!

Cuando hacemos un juego para venderlo a un cliente o portal que nos preocupe mucho el saber si el juego está teniendo fallos una vez publicado, supongo que lo mejor es tener un fichero con un log de errores.

En un juego convencional se guardaría en el pc del usuario y después se le podría pedir permiso para enviarlo a los creadores, pero en flash la única manera que se me ocurre es la de crear por PHP algo para que reciba los errores y los guarde en un fichero en el servidro y llamarlo desde el juego cuando algo vaya mal.

¿Hay alguna solución más sencilla? ¿Soléis hacer esto?

He recuperado de una muerte segura unas antiguas pistolas con las que jugaba con mis primos.
Tendrán.... 15 años por lo menos, y sólo había que cambiarles las pilas y limpiarle los compartimentos donde van las pilas y siguen funcionando!!!

Lo guapo es que son dos parejas, pistola + visera, uno se pone de jugador A en la pistola y en la visera en un botón y el otro se pone de jugador B y es un Quazar casero!! o como se llame!!
Muy guapo!!!  no??  xD
Claro que ahora no me voy a poner a jugar, pero mola tenerlas. Algún día igual las uso   xD



Lo curioso también es que son de SEGA.
Y bueno, el detalle de las vidas....
En la primera foto se ve un 9 al revés, que son las vidas que te quedan, está al revés porque es para que las veas reflejadas en las medio gafas de sol que tiene, como en bola de dragón!!!!

Esto es lo que ves por tu ojo derecho:


mola no??  xD
Además las pistolas tienen dos modos de disparos uno normal y otro que le das y tiene como un tiempo para lanzar un super disparo que le quita 2 o 3 vidas.

He creado un blog sobre accesibilidad en videojuegos:
http://videojuegosaccesibles.blogspot.com/

Estoy al tanto de varias webs en inglés sobre el tema así que puedo ir contando en castellano lo más importante de lo que pase por el mundo y también lo que pase por España más de primera mano.

Creo que es interesante tanto para desarrolladores como para jugadores con diversidad funcional.

Está recién creado, pero podéis ir poniendo enlaces al blog ya   ;)

Saludos!!

Buenas!!

Tengo una duda con las colisiones.

El control básico de colisiones que he visto hasta ahora, tanto en 2D como en 3D, es el de ver si la posición a la que se tiene que mover un objeto está ya ocupada o no por otro objeto y si no lo está entonces se puede mover a esa posición.

Bien, ahora parto de la base de que los movimientos de los objetos se basan en el tiempo que pasa entre un ciclo y otro de nuestro main game loop para que el movimiento sea siempre correcto en el tiempo.
Pero se me plantea el caso (en mi cabeza  :D ) de que, en un estado de saturación de la CPU, haya pasado tanto tiempo que el objeto que tenemos que mover pueda atravesar otro objeto debido a un movimiento que casi podríamos llamar teletrasportación  :D

Me explico con un ejemplo llevado al extremo para que se vea claro:
Tenemos una bola que avanza 1 posición por segundo hacia una pared fina que se encuentra a 5 posiciones de distancia.
En un buen estado de la CPU actulizará la posición de la bola 30 veces por segundo por lo menos, así que cuando llegue a la pared la detectará sin problema (le han sobrado muchas comprobaciones).
Pero si la CPU estuviera muy cargada y cada ciclo del game loop tardara 10 segundos en ejecutarse (es un caso extremo para el ejemplo) la actualización de la posición de la bola sería posicionarla 10 posiciones hacia delante, comprobando antes que hay no chocara con nada, y lo haría!!!   habría atravesado la pared!!!

¿esta comprobación de colisiones que tanto he visto no es correcta??