Rebotes: Construct 2: HTML5

Scirra Construct 2. v178.
-----------------------------
El ejemplo para ver el rendimiento de distintos engines. Ahora en html5.

Puedes hacer el mismo ejemplo en Flash con MMF2? para comparar

aunque creo que Flash sera más rapido

Están todos aquí: https://mmfzone.123.st/t1437-comparando-lenguajes-engines
----
También este pasará allí ...

Si, recuerdo aquel post

Pero lo que quiero decir es usando el mismo sprite (tamaño y forma) y velocidad por si influye esto en el rendimiento. (imagino que no mucho si el tamaño y velocidad es parecido pero...)

Mismo ejemplo en flash subido a petición de Zonacas.
La velocidad del sprite ... es aproximadamente ... la misma.
Lo que hace variar el rendimiento es el numero de objetos en la escena ... mmm ... espero ...
De todos modos, como vale mas una imagen que ....
--------
Flash: (dropbox)

Flash: (sevidor propio)

--------
Nota: Lo que sí afecta al rendimiento es la "carga" que tenga el navegador.
En este caso, hacer reset a los otros ejemplos de esta misma página.
--------
Lo subo a dos servidores distintos, para ver como afecta al rendimiento.

Conclusión: Tras realizar varias pruebas ...
1. La variación de estos dos servidores, para este caso, es poca.
2. Con Chrome va mucho mejor que con Firefox. Tanto en html5 como en flash. (Al menos en mi caso)
3. En Flash va muchisimo mejor que en html5.
4. La velocidad (lo he probado) de la bola sí que influye en el rendimiento (y mucho).

Vale, ahora ya me quedo más tranquilo

Gracias por el ejemplo

Actualizado.
Nueva programación para el html5. No cambia prácticamente nada en el rendimiento.
Los ejemplos puestos a cero en el inicio.

Scirra Construct 2. v84.
----------------------------
El ejemplo para ver el rendimiento de distintos engines. Ahora en html5 con WebGL.

html5 (WebGL):

Notas: Probarlo con Chrome, que tiene soporte para WebGL
Desconozco por qué sale desplazado el marco al usar iframe.

1800 objetos varia entre 48-50 fps

a partir de ahí caen por debajo de los 50

Hasta los 2300 mantengo los 60fps; a partir de ahí empieza a perder velocidad

Después de bastante tiempo he decidido rehacer este ejemplo a ver si ha habido progresos.
Y ya lo creo que los ha habido.
v.178 en el post principal.

La mejora es muy grande, la verdad es que los chicos de Scirra están haciendo un excelente trabajo.
Además del rendimiento, que ha mejorado mucho desde entonces, han añadido muchísimas herramientas para trabajar, como tileset, el multi, sombras dinámicas, un textbox para poner todo tipo de letras etc... y otras para exportar de varias formas, cada vez más sencillo y efectivo, un 10 para ellos, de momento me tienen ganado


Un saludo

Si, pero sigue haciendo cosas raras, sin ir mas lejos, en el ejemplo si lo subes mucho de objetos, verás que parece que hay objetos que salen por abajo (zona que se ve), aunque no disminuya el contador de objetos.

El editor de animaciones es como mínimo un tanto peculiar.
Y su fuerte es el html5, el resto está en función de esto, que en principio representa un handicap.
Y me he encontrado con otros problemas que deben resolverse de forma poco natural, de momento.
En fin, no todo es jauja. Pero a poco que se lo propongan, podrían ser los mejores en este tipo de herramientas, pero aún les falta.

La gestión de variables, los múltiples "action points", la asignación múltiple de comportamientos, la posibilidad de sub-eventos (condiciones y acciones), el soporte para un "else" y unas cuentas cosas más lo hacen más que interesante y los chicos de Clickteam lo saben. A ver si espabilan, que son un montón para hacer cosas y en Construct sólo hay dos programadores.

De momento, mientras los de Clickteam, no acaben de solucionar los múltiples problemas con el HTML5 (ahora mismo no va con Chrome, por ejemplo), no solucionen el problema con su versión free, no armonicen lo que hacen sus distintos exportadores con respecto a las físicas y unas cuantas cosas más, nos dedicaremos a ver lo que hacen los demás.

Confío en que le estén metiendo caña al MMF3 (con programación totalmente nueva) porque se está viendo un abandono paulatino de todo lo que tiene que ver con MMF2/CF2.5.

El editor de animaciones no es peculiar, es malísimo
Es cierto que tiene aún bastantes bugs, alguna vez he hecho algo que no iba bien, le he dado mil vueltas, y ha resultado ser algún bug solucionado en nuevas versiones, pero hasta que no actualizan y dicen lo que han arreglado te vuelves loco
También con este programa te limitas a juegos de navegador, ya que es para juegos html5, con todo lo que conlleva, no puedes hacer juegos demasiado grandes, pues el rendimiento del juego no depende de tu ordenador, si no del navegador, es otro de sus " fallos " .

Pero como has dicho tiene cosas muy interesantes, y lo actualizan casi semanalmente, normal por otra parte, es un programa joven todavía, pero tengo muchas esperanzas puestas en Scirra, creo que están haciendo un trabajo formidable.

También creo que el equipo de Clickteam debería fijarse en alguna de las cosas de Construct 2 para su futuro MMF3 , si aprovechan lo bueno que ya tienen, más cositas que se les ocurran y lo que puedan sacar bueno de la competencia, creo que tendrán un producto sin competencia, pero bueno, toca esperar, a nosotros los usuarios cuanta más competencia mejor, más mejoran todos

Un saludo.

A mi modo de ver una herramienta RAD para desarrollo de juegos debería cumplir con ciertos requisitos:

1. Código compilado (Monkey, Unity).
2. Contemplar un sistema visual (eventos) y código, tanto integrados como independientes (GameMaker).
3. Compilar a un código intermedio que luego será "traducido" al código nativo de las distintas plataformas. (Monkey, Unity (este de forma parcial)). Un mismo código para todas las plataformas, esta es la divisa.
4. Fácil de aprender (juegos casuales) y profesional (mayor dominio).

El MMF3, por lo visto va por ese camino. Pero debido a la nefasta política comercial de Clickteam, no sabemos casi nada. (Algo incomprensible. Todos sabemos como será el futuro Unity 5, por ejemplo).Tan sólo que será compilado, que no será compatible con versiones anteriores, que las extensiones hechas por la casa, valdrán para las distintas plataformas y poco más. Sobre si contemplará código o no, realmente no se sabe.

Game Develop, ya es "Open Source", lo cual puede darle un impulso importante.

Monkey, Haxe y otros por el estilo, no son para todo el mundo y tienen un futuro prometedor pero incierto. Y no son herramientas RAD.

GameMaker es algo inferior a otras muchas herramientas, pero tiene la ventaja de contar con la programación a base de código, que lo hace muy flexible. Y ahora está llevando una política de precios, que a mi modo de ver es totalmente errónea.

En fin, por no alargar esto demasiado, que al final tenemos el siempre complejo Unity, que de momento no está exento de inconvenientes, como por ejemplo su excesiva dependencia de su motor 3D para desarrollos en 2D. En todo caso, es una apuesta segura.

Confiemos en que saquen pronto el MMF3 y mientras tanto sigamos con lo que tenemos, que para divertirse haciendo "cosillas", no he visto nada mejor. Eso sí, que se pongan las pilas y solucionen de una santa vez, lo que no va bien e incluyan lo que le falta.

Ah! se me olvidaba. Para auténticos masoquistas, sigo pensando que Visual C++ sigue siendo la referencia, aunque ya hay muchos que opinan lo contrario y es un debate en el que no voy a entrar.

Construct 2 ? Si, es un pelin mas amigable y tiene cosas que me gustan mucho. Pero invertir tiempo en dominar un programa cuyo fin es la publicación Web, pues como que no.

Para lo que si vale, es para hacer prototipos rápidos. Pero para esto también nos sirve muy bien el MMF.

Y es cierto que la publicación web depende del navegador que uses, pero es tu máquina quién procesa el trabajo, razón por la que se recomienda programar de modo que en lo posible a todos les vaya por igual.

Buen razonamiento pupas, aunque no coincido en todo con tu opinión.
Esta claro que alguien con mas conocimiento pueda sacarle más provecho a un programa, eso ocurre con cualquier software, pero no me parece bien que si un programa está hecho para hacer juegos sin escribir código, tengas que aprender a escribir código para sacarle el máximo rendimiento. Eso es lo que ocurre con Game Maker, y es la razón por la cual descarte ese programa desde el principio. Desde mi punto de vista sería un error adoptar esa medida por parte de Clickteam, creo que estos programas están creados para la gente que o bien no tienen aptitudes para aprender a programar, o no tienen tiempo de ello o simplemente hacen esto por hobbie, como cualquier pasatiempos, y creo que este tipo de personas son los que realmente hacen que estos proyectos sigan adelante.
Pienso que hay muchísima gente con un talento muy grande, con muy buenas ideas, y gracias a estos programas con una linea de aprendizaje tan liviana, pueden llevar a cabo verdaderas joyitas, que si tuviesen que aprender código quizá buscarían otra opción. Así que pienso que eso sería un error, a mi por ejemplo ya me perderían para siempre, y te lo dice alguien que estudió Basic, Cobol y C++ (este lo dejé a medias, ya sabes, era joven y loco ) , que no me supondría un problema demasiado grande, pero sinceramente, no me apetece, con la mitad de tiempo aprendes a manejar otro programa sin código, que aunque con menos posibilidades, no resulta tan tedioso, y al fin y al cabo, esto es un hobbye.
También creo que si alguien quiere hacer algo grande, un juego mas currado y mas profesional, aprenderá código, y no creo que use ni mmf ni construct 2, se irá a unity como poco, o programará a pelo, por tanto pienso que no es el mismo tipo de cliente los de clickteam-scirra que los de unity-cualquier lenguaje de programación, y esto no olvidemos que es un negocio.

En cuanto a lo de Construct 2 tienes razón, el fin es la publicación web, o juegos de android y tal, pero bueno, esa es mi intención desde el principio, así que no es un handicap para mí.

Todo esto según mi criterio, ya sabes, estos son mis principios, si no le gustan tengo otros



Un saludo

Vale, pero no me has entendido en lo del código.

Supón, que tienes el Construct, que tanto te gusta (y aquí no entro, siempre he defendido que cada uno debe usar la herramienta con la que más cómodo se encuentre) y que puedes hacer todo lo que estás haciendo tal y como está diseñado el programa.

Supón ahora, que además le añades la posibilidad (si quieres), de emplear código. Bien sea una simple rutina o bien emplear únicamente código. Esto le aporta una enorme flexibilidad.

En el caso del MMF, es una forma de evitar tener que depender de que alguien haga tal o cual extensión. Lo programas tu y tema resuelto. Además, con la aportación de código, se pueden hacer librerías que podrás reutilizar en cualquier proyecto.

El caso, es que no estés obligado a usar código.

En Unity, no es necesario usar código. Puedes usar máquinas de estado, algo parecido a nuestros eventos, aunque se implementa de forma distinta. Podría muy bien prescindir de código y seguiría siendo un buen programa. Pero perdería gran parte de su potencial. Y el código que se usa en Unity es más a modo de scripts, que se integran en y con el propio IDE o IU (como quieras llamarlo).

Créeme, la posibilidad de código sólo aporta ventajas. Eso sí, como digo, que no sea indispensable.
En el caso del GameMaker es indispensable porque su programación visual, seamos claros, es una auténtica patata. (Que nadie se moleste, es una opinión).

Ponle al Construct o al MMF, la posibilidad de poner código (a semejanza de como lo hace el GameMaker) y sería un producto difícil de batir.

Alguien lo hará y será un caballo ganador y si no... al tiempo !

No te discuto que implementar código es una ventaja, está claro que escribiendo código a pelo o scripts tienes infinitas posibilidades, y siempre tendrá un mayor potencial, Game Maker supongo que será mejor programa que Construct o CF2.5 si sabes manejarte con su lenguaje GML (aunque a mi siga sin gustarme aunque supiese ) .
Lo que yo creo es, supongamos que Clickteam saca MMF3, parecido al de ahora con la posibilidad de trabajar por código, y por ejemplo, en la programación visual hay un fallo con el comportamiento bouncing ball, me da que en vez de corregirlo, sacarían un script que lo añades y se soluciona, y de igual manera, habrían scripts que mejorarían los comportamientos básicos y muchas cosas que se haga por el editor de eventos ( algo lógico ), llegaría un momento en que si quieres algo decente no tendrías más remedio que usar una serie de scripts, pues es normal que mejore la programación por eventos, y es mucho más fácil corregir errores así que actualizando el programa, no sé, es la sensación que me da.

Si es como tu dices, que es un añadido y puedes sacar todo el potencial sin programar, sería estupendo, yo no me opongo a nada, pero creo que llegaría al punto de Game Maker, pero bueno, si me equivoco sería estupendo

Y aunque me sienta mas cómodo trabajando con Construct 2, sigo pensando que CF2.5 es mejor programa, más pulido, aunque no me guste su política de ventas y demás, tienen un producto que creo le podían sacar más rendimiento y rentabilidad, pero bueno, eso son solo opiniones mañaneras

Y por último, si Clickteam decide dar la posibilidad de trabajar por código, espero que sea con lenguajes digamos "universales" como Unity, que no haga la locura de sacar un lenguaje propio como Game Maker, ya que puestos a aprender un lenguaje, mejor uno que te sirva para varias cosas y no para un software en concreto.

Un saludo

Coincido. Inventar un lenguaje propio o matriz sería bastante complicado.
Y como programar a pelo y texto nunca fue lo mío, me daría igual que puedan darle la posibilidad de hacerlo. Solo que no se convierta en necesario.