Te sobra un punto y coma en la línea de Process Inicializar()

Hola druk.

Acabo de mirar ahora los contenidos del pack ese de Fénix, y he podido ver que todo lo que se usa en ese capítulo de la guía está en la carpeta /bin dentro de la que se crea al instalarlo. Te recomiendo que los uses directamente tal y como dice en la guía, porque si usas el resto de cosas que vienen en el pack, quizás te compliques demasiado la vida.

También aprovecho para animarte otra vez y para decirte que estás empezando a una edad muy buena ;). Empezando tan pronto tienes fácil llegar a ser bueno en esto; solo necesitarás paciencia y un poco de esfuerzo.

La opción del socket XML yo la descartaría, salvo que necesites una comunicación en tiempo real. Lo digo porque necesitarás un servicio de hosting que te permita hacerlo (con los típicos servidores compartidos no se puede), porque es más complicado y porque el tema de la seguridad con sockets y flash es un infierno que yo intentaría evitar xD.

Con lo de "web service" no sé exactamente a qué te refieres, así que ahí no estoy seguro de qué decirte.

El uso de URLLoader es el más básico, pero puede que funcione. Esta la vas a tener funcionando enseguida de forma bastante sencilla, pero si los datos que quieres transmitir son complicados quizás acabe siendo contraproducente. En el "helper" de la api de ululand (una clase en actionscript que te lo da todo hecho) usamos este método para realizar las llamadas al servidor.


Por otro lado, te comento otra opción que quizás te interese: Hay una serie de librerías que se instalan en el servidor y que permiten la comunicación entre el cliente en flash y el servidor de datos binarios serializados. Esto te permitiría comunicar el juego directamente con las clases en el servidor.
En ululand usamos inicialmente esta opción (AMFPHP concretamente) y no nos fué nada mal. Sin embargo, al final lo hemos cambiado por una solución creada por nosotros; más que nada por aprovechar algunas funciones de symfony que nos vinieron muy bien.

Está guay. Mola que salgan este tipo de iniciativas... Está muy activo el tema de los juegos en navegador.

Hola druk. Encantado de dar la bienvenida a (aún) más gente que hace juegos en flash ;).

Te animo a que sigas con ello y a que preguntes por aquí cualquier duda que tengas. También aprovecho para decirte que estoy escribiendo una pequeña guía para gente que empieza desde cero a programar juegos en ActionScript. Creo que puede quedar bien (la voy a hacer con el mismo estilo que la de "Quiero Ser Como Will (Wright)") y seguro va a ser útil para mucha gente (ya me han insistido unos cuantos xD)

Impresionante  ;)

¡Otro voto para ActionScript! (Yo si tuviera que empezar, ahora no tendría ninguna duda... ¡Juegos flash seguro!)

Das asco ya tirso, pero de forma elegante.

Gracias. Sabes que eso me gusta.

3- tenga la opción de micropago por SMS y me dé la ventolá (compra impulsiva, vamos)

Yo creo que la clave es lo de la "compra impulsiva", y ahí es donde yo veo que va a fallar el sistema de nonoba. Te obligan a meter los datos de pago (tarjeta de crédito, o lo que sea) cada vez que quieres comprar algo... Nuestro planteamiento sería diferente: Los jugadores comprarían "ulucréditos" (a través del sistema de pago que elijan) y después los podrían gastar en los juegos, sin necesidad de meter su nº de tarjeta de crédito cada vez. Además, al tener los créditos ya comprados en el momento, creo que sería menos difícil convencer a los usuarios de que paguen x ulucréditos por seguir jugando.

Para los que no la conozcan, nonoba es un portal de juegos flash tipo Kongregate, pero con funciones más avanzadas y, creo que, bastante mejor planteado. De hecho, seguramente sea el portal que más se parece a ululand (¡aunque ni siquiera ellos tienen una sección de verdad para los desarrolladores!).

Pues bien, acabo de ver que han sacado una API de pagos, que permite introducir de forma sencilla una pasarela de pago dentro de los juegos, para que los desarrolladores puedan cobrar por lo que quieran (aunque nonoba se queda el 30%). Nosotros tenemos una idea que permitiría hacer lo mismo, aunque planteada de forma diferente (y, creemos, más cómoda para los usuarios).

La cuestión es... ¿qué os parece? Imagino que como desarrolladores lo veréis positivo, pero ¿creéis que los usuarios lo aceptarán? ¿Estarán dispuestos a pagar para comprar más niveles o extras?

A nosotros nos parece que puede ser muy interesante, pero todavía no hemos desarrollado nada en este sentido porque no sabemos si llegaría a ser aprovechado por los desarrolladores o si los jugadores estarían dispuestos a pagar.

[El código de la lógica del juego no debería estar dentro del archivo .fla]

Para hacer juegos, Flash te da más facilidades. Punto. Eso sí, si quieres ser legal, para usar Flash hay que pagar la licencia, mientras que existen compiladores de Flex gratuitos.

Ahora bien, tengo la sensación de que hay mucha confusión en este tema... Mucha gente piensa que si utilizas Flash tienes que programar dentro de la herramienta Flash, basarte en la línea de tiempos u otras muchas cosas.

Ejemplos en los que noto que hay confusión:

"Los programadores suelen preferir Flex porque en Flash se sienten perdidos.", "Para mi flex permite un codigo mas limpio, ordenado, impoluto, ..." o "Parece que cuando hay muchos programadores es mejor Flex..."

Esto se debe claramente a que mucha gente no sabe cómo montarse su "entorno de trabajo" para Flash, y piensan que es obligatorio programar dentro de la herramienta Flash. Tened en cuenta que el lenguaje de programación es exactamente el mismo (ActionScript 3.0) y, por tanto, se puede programar con herramientas externas (Flash Develop, Eclipse) y se puede estructurar el código exactamente igual, lo compiles con Flash o con Flex.
Por esto mismo, si hay muchos programadores y el código se está organizando bien, es posible utilizar herramientas de control de versiones sin ningún problema. El código de la lógica del juego no debería estar dentro del archivo .fla.

Por otro lado, la herramienta Flash sí que te facilita un montón de tareas habituales en el desarrollo de un juego (gráficos, animaciones, menús, etc...)

Por resumir un poco, os explico como trabajo yo normalmente para programar juegos para Flash:

- FlashDevelop: Lo utilizo para programar toda la lógica del juego. El código lo organizo de la forma habitual en AS 3.0 (paquetes, clases, etc...). En general creo una clase principal que es la que controla la parte jugable del juego (sin menús o interfaz).
- Flash: En flash creo o cargo todos los menús, gráficos, animaciones, sonidos y demás. El código de los menús sí que lo pongo dentro del archivo .fla. Y también va en el .fla el código que se ocupa de cargar, pausar y descargar la parte jugable (lo que tengo programado en el FlashDevelop).

Sí, mola mucho xD

Me lo creo. Y seguramente no será la única "grande" (no solo de España) que empezará a hacer "juegos casuales on-line". Llevo tiempo pensando que es cuestión de tiempo, y al final acabarán llegando a este mercado también, solo que con un poco de retraso porque al ser mayores les cuesta más adaptarse a las modas (ya sabéis eso de los elefantes con poca movilidad, pero que cuando llegan...).

Ya sé que va a quedar muy en plan spam, pero en ululand.com probablemente ofrezcamos esa posibilidad. Si no te lo digo de fijo es porque todavía no estamos muy seguros de cómo integrar las puntuaciones que vengan "de fuera" con las que se generen a través de los usuarios registrados dentro del portal.

estoy de acuerdo con mi-go

E-go-cén-tri-co :P

Te voy a perdonar el off-topic porque, sí, es muy bueno xDD

¡Ya era hora! xD

Na, te digo lo mismo que ya te comenté ayer. El juego está bien, tiene un buen acabado y entretiene. Sinceramente creo que puede funcionar bien.

El único problema es que al principio tardas un poco en pillarle la mecánica, y la gente que juega a juegos flash da muy pocas oportunidades a un juego xD. Espero que no tengáis ese problema y que la gente se enganche, juegue un montón y haga un montón de clics en los anuncios (xD).