Usa Adobe Flash CS4 o 5 para dibujar y exporta la biblioteca en un .swc que importas en un proyecto de FlashDevelop.
Porgramar en Flash CS... es una locura y FlashDevelop es gratis.

Pues yo no puedo jugar entonces al history mode  :D
Seré el primero, pero no el último!  jeje

Esto también le ha pasado a grandes juegos como Bioshock 2: http://www.videojuegosaccesibles.es/2010/02/vision-de-un-daltonico-en-bioshock-2.html. Que lo arreglaron después con un parche.

O a Modern Warfare 2: http://www.videojuegosaccesibles.es/2009/12/daltonismo-en-modern-warfare-2.html que no se si llegaron a hacer algo. Bueno, y a muchos otros más.

No se cuanta gente coincidirá conmigo en no poder distinguir ese azul de ese violeta, pero para la próxima vez intenta evitarlo con formas distintas, por ejemplo.  ;)

Buenas!

El juego parece muy adictivo, sencilla mecánica que da para mucho.

Pero tiene un importante problema de accesibilidad! los colores!
En el screenshot puedo diferenciar bien las fichas azules de las verdes, pero en el video no las diferencio absolutamente nada. Mi asistente dice que unas son azules y otras rosas y violetas, pero yo las veo totalmente iguales, jeje. ¿Se pueden elegir los colores de las fichas?

La cegera de colores es bastante común en los hombres, llegando casi a un 10%. Hay gente que le afecta a ciertos colores y gente que a otros, pero se puede solucionar fácilmente creando fichas de distintas formas para cada jugador, o con un dibujo dentro claramente visible.

Una de las cosas que hace falta es... paciencia!! 
porque no veas que lío tienen motado los de facebook con las apis, antiguas, nuevas sin terminar, cosas que no funcionan como debieran... si miras por los foros de dev de facebook verás que desesperación de todo el mundo.

Hace muy poco Adobe actualizó su documentación sobre facebook: http://www.adobe.com/devnet/facebook.html
Porque también actualizaron la api gratuita de flex para la nueva api de facebook: http://code.google.com/p/facebook-actionscript-api/

Pero la verdad es que me ha costado mucho conseguir algunas cosas que no sean las típicas, por falta de documentación en facebook sobre sus apis (que horror....). Así que me he alegrado mucho al ver en este hilo que player.io tiene una api propia y con ejemplos!!!  no lo sabía!! tengo que probarla porque parece mejor, o más clara al menos gracias a los ejemplos que se que ve que funcionan bien.

Hay un sitio que además de tener una api propia te hacen hospedaje del juego multijador (pagando según el plan que quieras), no lo he usado pero me parece interesante: http://playerio.com

Y en su web tienen un tutorial sobre lo más básico de programación multijador en tiempo real, está muy bien explicado y puede valer para cualquier lenguaje y plataforma porque son conceptos básicos a tener en cuenta:
http://playerio.com/documentation/tutorials/building-flash-multiplayer-games-tutorial/

Pues entonces genial  :)

Los gráficos y la música molan mucho, pero jugando no me da tiempo a ver lo que viene o si veo algo que quiero coger ya me es casi imposible, así que la sensación que tengo es que es más un vídeo que un video juego, je.

Igual esta es la idea inicial porque esté destinado a un público infantil que puede que no lo controle bien.

pues así es como lo hago yo, jeje. Y por lo que he dicho antes creo que es la mejor manera.

Si hay algo en el juego que dependa del tiempo, por ejemplo una plataforma que desaparece a los 30 segundos, deberías controlarlo con un timer, pero con un timer propio mirando el tiempo real que ha pasado desde que se inició. No vayas a usar un timer de flash poniéndolo que se ejecute 1 vez por segundo y a la 30 lanzas código de logica... mejor cuando en tu gameloop te toque mover los elementos "plataforma" comprueba si ya han pasado 30 segundos desde que apareció, comparando tiempos (horas).

Sobre que en flash "no puedes saltarte frames" aclarar que yo me refiero a que no puedes controlar cuando se pinta, por lo que sí, los frames de la película principal no los puedes controlar, pero los movimientos de los personajes sí los puedes adaptar al tiempo real que pasa entre cada ciclo del game loop y los frames de las animaciones de esos personajes también, saltándote frames de su animación si hace falta.

Además, otra cosa, no tiene sentido hacer más iteraciones del gameloop de las que puedas pintar en pantalla  xD

Todo esto es algo un poco raro que no sucede en otras tecnologías de videojuegos y es porque en flash no se puede controlar cuando se pintas las cosas. Normalmente en otras tecnologías se pasa la logica del gameloop y después se pinta, se pinta una vez por cada vez que se hace un ciclo de gameloop; en flash no puedes controlar cuando se hace y cuando no.

En flash, si tu máquina está saturada y baja a 18 imágenes por segundo, aunque tu timer se ejecute 30 veces por segundo (cosa que es posible que tampoco pase ya que está saturada) ¿de que te sirve si no lo puedes pintar?  xD   de hecho si se estuviera ejecutando el timer 30 veces y pintando 18 estarías intentando hacer más de lo que puede la máquina con lo que podrías estar haciendo se se saturara más y no subiera nunca de las 18 imágenes por segundo.

Bueno, sobre usar el enter frame o un timer hay mil discusiones en internet  xD
Yo estuve leyendo mucho (por ejemplo: http://llops.com/blog/2008/07/27/enterframe-vs-timer-i/) y al final llegué a la conclusión de que era mejor on enter frame

De todas formas cuando la máquina esté saturada tu timer también puede que no se ejecute las veces que debe.
Lo importante, sobre todo, es saber el tiempo que pasa entre un ciclo y otro del gameloop y actualizar posiciones y animaciones en consecuencia.

Crear eventos propios puede estar bien, pero yo lo usaría sólo para activar ciertas variables banderas o cosas así de sencillas, nunca para lanzar lógica de juego. En la lógica de un juego siempre tienes que seguir un mismo orden para que cada game loop termine bien y no pasen cosas raras.

Por ejemplo, si en tu ciclo del gameloop mueves los objetos en este orden: personaje, enemigos, nubes...   nunca podría, por ejemplo, un evento de la nube (un rayo) hacer mover al personaje para atrás. Mejor lanzar el rayo sin listener, al final de ciclo comprobar colisiones y en el siguiente ciclo ya se moverá el personaje (cuando le toque) porque ya está chocando con el rayo. Así mantienes una lógica de juego que no se puede romper, lanzando lógica de juego en listeners puede que la lies mucho.

Bueno, el onEnterFrame es otro de los listener que también hay que usar, por lo menos yo también uso, pero sólo para poner al inicio del juego una llamada para que ejecute el game loop onEnterFrame, y no quitarlo ni cambiarlo durante todo el juego.

Código [Seleccionar] Expand

this.addEventListener(Event.ENTER_FRAME,this.gameLoop);

No te hace falta un manual en concreto para aprender a programar juegos con un game loop y mantener la lógica correcta. Mira cualquier manual sobre programación de juegos que lo haga así (que deberían ser todos  xD ) y simplemente programa así en flash, ovlidándote de que existen los listener.

Sólo deberías usar los listerners para saber cuando se pulsa una tecla o botón del ratón, pero no hacer que directamente lancen código de lógica, simplemente que anoten un estado de "tecla A pulsada" para que en el siguiente ciclo del game loop se procese.

El tema es no lanzar lógica en listeners que puedan activarse en cualquier momento, porque perdimos el hilo del game loop, pudiendo tener graves problemas con la lógica del juego.

Buenas!!

Me alegra verte por aquí!
A ver si nos volvemos a ver en persona, con algo de la asociación. Y ya sabes... si quieres proponer cosas... adelante!

Mola!
Con replay y todo!!  xD