Bueno pues al fin me he liado la manta a la cabeza. Tenia ya el juego hecho para probar el tema del juego casual en un paquete con otros tres juegos más, pero al final he decidido hacer el port a AS 3.0 e investigar esto de la monetización flash.

Se que podría ser más complejo y más de aquí y más de allá, pero está claro que hay que buscar la rentabilidad y una de mis milestone en este proyecto era no emplear mucho más tiempo del que había tardado ya.

He ido buscando un mercado casual, público de todas las edades posibles y efectillos de particulas y sonido para hacerlo más atractivo; sin embargo luego te das cuenta de que los grandes portales de juegos flash (léase Armor Games, Kongregate, Newsground) están poblados de "hardcore gamers" reconvertidos, y mi juego con una tendencia hacia una temática/gameplay entre infantil y femenino está en un nicho muy apretado, copado por gente de la talla de Nitrome ante los cuales uno piensa que es mejor que se quede en su casa y olvide "las chorradas esas de intentar hacer algún dinerilo con un juego propio".

Bueno aquí os dejo el enlace del juego en GameJacket para que le echéis un vistazillo si tenéis tiempo:
http://gamejacket.com/gamejacket.asp?gjid=00817

Un saludo.

[en el 2º frame]

No sé cuantos os habréis topado con el típico problema de un preloader y con exportar en el primer frame, pero como creo que es un problema bastante común voy a aportar mi granito de arena (aparte de porque voy a rapiñar ayuda en brevísimo tiempo ;) ).

Seguramente a la hora de hacer un preloader os habréis encontrado con el inconveniente de que la precarga ni siquiera se ve, ya que los símbolos de nuestra librería que tienen la vinculación/linkage a una clase suelen exportarse en el primer frame, y por lo tanto el primer frame no muestra nada más que el fondo de nuestra película hasta que se cargan por completo todos esos símbolos.

Esto es especialmente cierto cuando tenemos una clase principal que gestione la película, cuando eso de modificar las opciones de publicación para exportar en el frame X sirve sólo para que maldigas a alguien porque tu precarga no tira "ni p'alante ni p'atrás". Para esos casos en los que quieres un solo .swf sin un preloader en otro archivo flash, para cuando has buscado 20.000 clases indescifrables para hacer precargas.

Bueno al meollo:
1.   El primer paso es en todo lo que tenga en la vinculación/linkage una clase, desactivar la casilla de exportar en el primer frame. Busca en tu librería todos los símbolos que tengan esa casilla activada.

2.   El segundo es añadir en el primer frame de la película una acción con un código como el siguiente:

Código [Seleccionar] Expand

stop();

loaderInfo.addEventListener(ProgressEvent.PROGRESS, progressListener);
loaderInfo.addEventListener(Event.COMPLETE, completeListener);

function progressListener(e:ProgressEvent):void {
  var loaded:Number = e.bytesLoaded / e.bytesTotal;
  var percent:int = loaded * 100;

  this.loadingText.text = "Loading: " + String(percent) + "%";
  this.loadingBar.scaleX = loaded;
}

function completeListener(e:Event):void {
  loaderInfo.removeEventListener(ProgressEvent.PROGRESS, progressListener);
  loaderInfo.removeEventListener(Event.COMPLETE, completeListener);
  gotoAndStop(3);
}
Donde loadingText es el nombre de la instancia de un textfield dinámico que tú mismo incluyes en el escenario del primer frame; y donde loadingBar es también el nombre de la instancia de un símbolo que contiene un rectángulo.

3.   Añadir en un segundo frame todo símbolo de la biblioteca que tenga vinculada una clase. Los sonidos tienen una particularidad y es que deberás añadirlos uno en cada capa, pero en el 2º frame, deja el flujo de cada uno en evento y no hace falta cambiar nada, ya que no llegarán siquiera a reproducirse por el gotoAndStop(3) de antes.

De esta forma el preloader funcionará correctamente y tus símbolos estarán disponibles como clases sin ningún problema.

4.   Añade un tercer frame e incluye una acción que invoque a la función que cree tu juego (p.e.: crearJuego(); ). Para ello deberás olvidarte de usar directamente un constructor de clase, es decir, que si la clase que contiene el código del juego se llama Piratas, la función Piratas() no debes usarla, en vez de ello quita todo el código del constructor y mételo en una función con un nombre descriptivo.

¿Y esto por qué? Porque sino al ser la clase principal de tu película, se ejecutaría al comienzo de la reproducción de la misma.

5.   Por último revisa tus variables de clase, propiedades o como te guste llamarlas (, ya sabes, esas que se declaran al principio de una clase) que instancien un símbolo de la biblioteca. Mira que no hayas inicializado ninguna en su declaración. Por ejemplo:

Código [Seleccionar] Expand

public class Juego extends MovieClip {
  private var personaje:Heroe=new Heroe();

En vez de eso decláralas pero inicialízalas dentro de la función crearJuego() que te comentaba antes. Es decir las declaras con: private var personaje:Heroe; y luego en la función de inicio: personaje=new Heroe;.

Eso es todo lo que necesitas para tener tu precarga funcionando para que des una buena imagen cuando a aquellos interesados vean tu juego en flashgamelicense.com.

He intentado explicar las cosas lo mejor posible ya que sé que hay gente que se ha metido en AC 3.0 y se consideran mucho más diseñadores que programadores.

Espero que le sirva a alguien. Saludos.

Encantado de haberos conocido.

Una reunión muy fructifera (al menos para mí). Espero que podamos cuajar esto en algo más grande, por nuestra parte sabed que Desea cuenta con todo el apoyo que podamos ofrecerle.

Lo único que he echado en falta es haber dedicado un tiempecillo más a enseñarnos nuestras cosas y haber visto algo de lo conseguido con el taller de modelado.

Por cierto Fenris, voy a cambiar el gameplay de la demo que os mostré para que no se parezca tanto a tu idea (que coincidencia mas chunga, jeje). Espero que cuando lo termine podamos intercambiar lo que llevemos hecho ya que me quedé con las ganas de hincarle el diente a lo que me enseñaste, además de que nos despedimos sin saber en que andaba metido Ionic ni incluso IllogicGames.

Espero que en la próxima haya más tiempo para todo eso. Un saludo

Será muy interesante. Yo también soy de Córdoba, así que espero que nada me impida poder ir.

Un saludo

Secundo lo dicho por Warchief.

En cuanto al numero de nodos te recomiendo q primero establezcas escalas en tus personajes: pequeños(gatos), medianos(hombre), grandes(ogros). Soy partidario de crear un mapa de nodos para cada tamaño ya q en escala un mapa para un duende tiene muchisimos más nodos q un hombre aunq la regla de oro es q un duende puede usar el mapa de un hombre, pero un gigante no. Hacer pasar a un gigante por una puerta normal es muy complicado....

En lo referente al tamaño de cada celda te recomiendo q uses el de el propio personaje con una salvedad; divide la celda en 9 nodos: 1 central más las 8 direcciones posibles. ¿Que para qué sirve esto? Cuando hagas un editor (o el propio modelo q uses de nivel) te darás cuenta que quizá haya paredes u obstaculos delgados o menudos pero intransitables. Eso lo tendría en cuenta.

Esto ultimo depende del realismo q kieras conseguir.

Te recomiendo que la matriz en la que guardes el mapa de nodos no guarda otra información más que la de pasar o no pasar. A lo sumo guardaría en ella el coste de desplazamiento en caso necesario.

Te recomiendo tb q le eches un vistazo a esto:
http://portalxuri.dyndns.org/darkbasico/descargas/descargasdbpro/tutoriales/ameba.zip
Es un tutorial sobre pathfinding muy sencillo que hice.

Yo también soy de Córdoba, aunque como lord_taran me temo que ese proyecto me queda grande. De todas formas es agradable ver gente que se mueva de tu provincia.

Quizá algún día podríamos hacer una "microquedada", creo que sería interesante compartir opiniones o incluso saber más de nuestros respectivos proyectos.

 La tierra está achatada en los polos, en el ecuador se está relativamente más lejos. Menos gravedad hay incluso en grandes altitudes (inapreciable, lo justo para q sus vidas sean mas rápidas para nosotros apenas unos instantes).

En cuanto a la fuerza centrífuga solo he de añadir q no existe. Recuerden q la velocidad q produce la rotacion es tangencial.

 Segun la dualidad onda-particula donde haya luz hay materia. La existencia termina donde acaba la energía... Aunq esto es pasarse obviamente.

En cuanto a un ejemplo como el del principio solamente habria q tenerse en cuenta la friccion (en este caso la del aire) y el tiempo: un coche tarda más en caer q una pelota de golf. Aunq para una simulacion fisica es irrelevantante a no ser q en la caída se simule un fluido.

[programacion basada en objetos]

 Si pero comprenderas q no en todos los lenguajes tipo BASIC se consigue (al caso q nos referimos), sobre todo x la necesidad de estructuras de datos dinamicas y tipos definidos x el usuario q no todos poseen. Es x eso q recalco esa capacidad de blitz ya que su potencial junto con el concepto de entidad permiten q su programacion basada en objetos, sea más auténtica.

Bueno creo q nos hemos desviado del tema principal. X eso Josepho te recomiendo q pruebes ambos y si puedes esperar al modelo 3D, lo ideal es q optes x Blitzmax.

[posibilidad]

 

Esto no tiene por que ser asi, es mas, las dx9 van mucho mas rapidas que las dx7.

Opinión de cada uno aunq comprenderás q ir avanzando un motor desde el directx 8.0 hasta el 9.0c implica una serie de complicaciones q si no se solventan desde primera hora le dan ese aspecto sucio del q hablo y q evidentemente afecta a su rendimiento. Malos habitos de programador q busca el beneficio.

No se donde has visto que b3d tenga POO, me imagino que aqui hablaras del blitzmax.

Como verás he dicho q tienen la posibilidad y aunq el lenguaje es claramente estructurado hay ciertos comandos como self q permiten una emulacion bastante fiel aunq engorrosa. Te dejo un enlace:

http://techlord.blackeve.com/AOBPwB3D/

Los shaders no significan menor rendimiento ya que el tener todos los vertices en la memoria de la tarjeta grafica implica no tener que pasarlos por el agp cada vez que se modifican, no obstante el que tenga shaders no significa que deban de usarse.

En Blitz muchos efectos tipicos de shaders han sido programados a pelo con el lenguaje y han salido maravillas varias tipo el DOT3 q hasta el momento el dbpro solo puede conseguir mediante shaders. Obviamente los shaders son muchisimo más rapidos sin embargo provocan incompatibilidad según la version de pixel y vertex shader q soporte tarjeta en la q se ejecute el programa. La mención al rendimiento es una evocación al embrollo q sin duda tendrán en el código el TGC como tantas veces nos ha demostrado, q en vez de arreglar problemas antiguos nos ofrecen algunos nuevos o pijotadas como los shaders q como tu sabiamente dices... aunq se tengan no significa q deban usarse.

Espero haberme explicado mejor. Perdonadme pero el texto ya era lo suficiente largo como para ampliarlo aun mas.

[editado]
Te respondo Josepho:

Efectivamente eso ha sido cierto. Aunq debo añadir lo de ha sido xq con el tiempo la presion de los usuarios ante ciertas desfachateces ha guiado al TGC de nuevo al buen camino.  Yo he dicho eso mismo en multitud de ocasiones pero he de reconocer q muchas veces dejaba un proyecto x cuestiones como la q siguen:

En dbpro hay un comando q gestiona con una increible facilidad el manejo de sprites animados(entendiendo x sprite un plano 3D usado en HUD o vista ortográfica, usea como una imagen 2D). Yo siempre me kejaba de q en ninguna actualizacion arreglaban este comando tan util y la gente harta (supongo) de mis quejas, las callaba  de una forma simple: haz tu mismo una función q haga lo mismo.... Supongo q el dbpro es tan sencillo q cuando uno de esos comandos q te hacen la vida más facil no funciona, abandonas el proyecto pensando q el dbpro no puede hacer lo q tu kieres y te cabreas xq pagaste x todo el puzzle y ahora te faltan piezas. A mi me ha ocurrido en muchas ocasiones y siempre he encontrado una solución mejor o diferente con el tiempo, o simplemente la ultima actualización mensual me la arregló.

[Bugs]

 He programado ampliamente en Blitz3D y creo q conozco DBPro mejor incluso q la tabla del 1. El tema dualidad Blitz/Darkbasic nos lleva a la tipica discusion estilo ps2/xbox q no nos llevan a nada.

Para resumir daré expondré una serie de conceptos q ya habré repetido unas 1000 veces:

Bugs
Nunca oí hablar a usuarios de B3D hablar nunca acerca de bugs  y cosas así mientras q en dbpro siempre lo hacíamos. Sin embargo, una vez descubierta la comunidad internacional, me he dado cuenta de q el numero sino igual, es realmente cercano.

Rendimiento
El motor de dbpro se basa en el directx 9.0c, sin embargo B3d va sobre la version 7.0. Ni q decir tiene q siendo una versión mas reciente es obvio q el motor es más sucio y voluminoso, x lo tanto es totalmente cierto que blitz tiene un mayor rendimiento q dbpro.

Promesas cumplidas
Si bien en la caja y en la web disponemos de una serie de características, hemos de aclarar q no es oro todo lo q reluce. Hay alguna q otra caracteristica q nos ofrecen q luego resulta no ser cierta como x ejemplo el conversor .X -> .BSP (un programa q supuestamente convierte archivos .x al formato de mapas del Quake, aunqe solo funciona si el modelo ha sido usado mediante modelación CSG). Por supuesto, en este campo Mark Sibly, nunca ha defraudado.

Actualizaciones
Blitz dispone de esporadicas actualizaciones q consiguen hacer al producto mas robusto q su version anterior. Sin embargo en dbpro no sabes si en el siguiente patch dejara de funcionar algun comando o necesitaras intalarte el último directx; sin embargo el lenguaje suele avanzar con nuevos comandos q amplian el campo de posibilidades o nos facilitan el trabajo.

Extensible
Tanto b3d como dbpro son extensibles mediante dll externas, sin embargo debemos inclinarnos x este ultimo ya q las librerias q se crean para el son más numerosas y habitualmente gratuitas.

Facilidad y Capacidad del Lenguaje
Entre ambos sin duda el dbpro es el gran vencedor en este campo. Tiene un sintaxis clara y limpia tan ideal para el q se inicie q con solo leer el texto y unos ligeros conocimientos de ingles parece q uno este leyendo pseudocódigo. Se q eso es irritante para mucha gente, pero no olvidemos q de esta froma es facil recordar la gran cantidad de comandos de q dispone. Las estructuras de datos y tipos definidos x el usuario es tb mucho más clara, sencilla y potente en dbpro, sin embargo b3d tiene la posibilidad de usar una POO q aunq dificil, puede resultar en muchos casos muy necesaria cuando el codgo empieza a crecer en logitud. Creo q la única ventaja q dispone b3d sobre dbpro en este campo es el concepto de entidad q unifica cualquier elemento 3D utilizado.

Accesibilidad y Comunidad
Sin duda la gente de b3d cuenta con una comunidad mucho mas extensa. Sin embargo y aunq parezca lo contrario, la de dbpro es mucho mas colaborativa. El numero de tutoriales disponibles para dbpro es muchisimo mayor, la comunidad de blitz entiende la colaboración en la transmision libre de sus códigos fuente.
Tb hay q tener en cuenta q el dbpro va a ser distribuido en breve x una empresa nacional en castellano www.darkbasic.es cosa q nunca ocurrira con el b3d. He de añadir como antiguo administrador de Darkbasico - www.darkbasico.tk , q sin duda allí se pueden encontrar gran cantidad de tutoriales q yo mismo he traducido y creado.

IDE
Solo me remitire a las ides orignales de ambos lenguajes. La IDE de dbpro es mucho mas potente, sencilla, auxiliar y completa.  Mientras q la de blitz es parca, austera y engorrosa. Sin embargo he de decir q la d dbpro no permite depurar con comodidad y q el manejo de mas de un código fuente perteneciente al mismo proyecto es realmente complicado.

Shaders
Si bien el motor de blitz sorprende, DBPro tiene una serie de capacidades heredadas de la ultima directx de turnos mucho mas espectaculares. La gente de blitz suele añorar las posibilidades graficas de dbpro pero muchos olvidan la compatibilidad de version de pixel y vertex shader q necesita la tarjeta del usuario final. Sin embargo, es verdad q el dbpro tiene mas pijotadas q el blitz aunq es x eso mismo q tiene un menor rendimiento y una incompatibilidad tb mas alta (al menos en lo q shaders se refiere) q se puede ver en cosas como la multitextura.

Quizá podría añadir más verborrea pero solo incuiré un conclusión final:

- DBPro es para el principiante, para el q kiere hacer una superproducción espectacular o para el que tiene poco tiempo. Blitz3D es para el indie, para el q kiere q su juego vaya hasta en un equipo antiguo o para aquel q se va embarcar en un proyecto largo y complicado.

Bueno, creo q me he pasado un poco en la extensión del texto. X ultimo solo añadir, q hoy x hoy, la mejor opción es Blitzmax aunq habrá q esperar al modulo 3D ya q el uso de opengl para eso mismo x ahora es bastante complejo. Este lenguaje es mucho más potente y compatible, ademas de facilmente expandible.

 Y tanto, imagina q lo hice para Darkbasic Pro.

Si has visto alguna vez un codigo de dbpro habras podido observar q es casi pseudocódigo. Aún así no solo tengo hecho el propio codigo, sino q tb cree un tutorial a la postre.

Aqui lo tienes:
http://portalxuri.dyndns.org/darkbasico/de...iales/ameba.zip

Ten en cuenta q este algoritmo no esta para nada optimizado, y aunq encuentra un camino en un mapa de 100x100 en pocos milisegundos no es lo q diriamos una liebre.

Este algoritmo es util para la gente q nunca ha comprendido el tema de la busqueda de caminos, es decir, q está pensado para no asustar. Cuando lo veas podras ver q incluso el num de lineas q lo compone es realmente ridiculo.

Un amigo mío creo una versión optimizada del mismo, esa versión optimizada es increiblemente rápida. Tanto q en muchos casos puede incluso vencer al A*.

Si quieres, una vez q lo asimiles hablamos de las cosas tipicas como la restriccion a 4 direcciones o la esquiva de las esquinas al hacer movimientos en diagonal.

 Vil acabo de registrarme, te aseguro q a partir de ahora me verás más.

marcode y dracks: no hay de que.

Solo he de subrayar 2 cosas:

 1.- Q aunq en la pagina de patrick solo haya publicado 1 articulo, en realidad hay 3 más
 2.- Hay otros algoritmos de pathfinding mucho más sencillos y fáciles de implementar. Como ya ye he dicho yo mismo creé una variante del flood fill q es tan simple q cualquier persona con unos minimos conocimientos de programación puede comprender.