Test de mi gameEngine en processing.

[erkosone]

Con motivo de poder terminar decentemente el juego que he empezado me dispongo a retomar el proyecto SZENER y dar un paso adelante con el creando así una nueva versión mas facil y flexible de usar.

Acepto sugerencias, practicamente es un editor de fisica de niveles, donde podremos cargar una imagen a modo de lienzo de fondo y sobre la que podremos trazar poligonos para crear zonas colisionables, por ahora haré una mejor versión de la uqe ya tengo del programa, pero me gustaria saber si alguien realmente le ve utilidad a añadirle algo mas.

[OskarG]

Bueno,no he mirado como lo tienes diseñado,pero te explico como yo hago por encima los scrolls ...
1-Lo ideal es que el engine de base tenga un motor tiles,pero gemix y otros derivados no lo lleva por defecto.
2.Hacerlo tal cual como son ,es una salvajada,demasiados procesos en ejecucion .
3.Cargar mapas tan largos como el escenario no me parece tampoco nada optimo.
?¿?Entonces como lo hago??¿?
Muy simple,sigo el tutorial de la revista div para crear un scroll infinito de esta manera..
1.El motor es multidireccional,es decir,tanto por arriba como por abajo.
2.Si el juego es de 320x240...creo un mapa de 320+16x240+16...a medida que avanzo le hago un map_block_copy.Este sistema es el mas optimo que hay.
3.Como el tuyo ya incluye fisicas,el mapa de colision se va pintando en tiempo real con la misma tecnica que se explica arriba ,creo que se entiende sin entrar en detalles y creo que seria lo mas acertado.
4.Simplemente habria que crear un editor de tiles especifico para tu engine,facil de hacer.Cada numero es un tile,un trozo de grafico que hay que copiar con el map_block_copy si es un numero de colision.se copia en el mapa de colisiones...
NO es nada lioso este metodo y consume nada de recursos,pues solo tienes en ejecucion el mapa de scroll de 320+16,240+16 y cuando avanza x pixeles haces los map_block copy correspondientes.
5.los tiles,colisiones se puede guardar mediante tablas,numeros...o bien mediante colores en un mapa y despues leerlos y segun color se dibuja y se pega una linea recta,una linea horizontal,una linea con inclinacion etc y como tiene fisicas tu engine,en un plis plas se hace.
Es lo que hago yo y funciona bien
----------------------------
Una cuestion que veo en los ejemplos de los engines con fisicas por defecto,no hace bien las colisiones,por ejemplo.un sprite que tiene una cabezota enorme ,pero los pies no toca la plataforma y flota,solucion,poder definir en cada frame,una caja de colision variable de tamaño x,y.

[Hokuto7]

Aqui hay dos soluciones segun yo lo veo y desde luego hay que olvidar como se hace en el lenguaje div que parece que estas construyendo una casa con tus propias manos.

La primera seria arreglar los bug del programa eszener y poder desplazarte a lo largo del mapa,porque yo sigo sin poder hacerlo.Luego habria que cambiar el metodo de cargar un mapa gigantesco porque eso gasta recursos que da gusto y cambiarlo por un editor de tiles,es decir,cargariamos sprites suelos y creariamos nuestros mapas con esos sprites y sus distintas capas.

El otro metodo seria utilizar el programa mapeditor y crear tu escenario y hacerlo igual que pilas engine donde si le pones a un objeto que es solido delante de su nombre automaticamente tendria el cuerpo de fisica y luego se carga el archivo que genere en tu libreria.

Editor.
https://www.mapeditor.org/
Metodo de pilas engine.
http://manual.pilas-engine.com.ar/mapas_y_plataformas/

Te voy a pasar un videotutorial de como se hace un mapa de tiles con contruct 2 y veras lo facil que es y esto te demostrara todo el tiempo que has perdido haciendo tus niveles como lo llevas haciendo toda tu vida.


El video dura unos 13 minutos pero merece la pena verlo entero y si puedes probar contruct 2 y hacerlo tu mismo,mejor que mejor.Hay version gratuita de contruct 2,es un poco limitada pero para ver lo que se puede hacer con el es mas que suficiente,si no pruebas las cosas no sabras como esta el tema.

[erkosone]

Hola geste, gracias por los consejos, llevo tiempo dandole vueltas a la cabeza sobre este tema..
Haber.. vamos por partes, por que aquí hay mucha cosa que no se cuenta al publico y que parece oro y es caca de la vaca XD..

Sobre el tema de los mapas de tiles, son una buena idea "a priory" pero en realidad no lo son, quizá son una buena forma de realizar escenarios pequeños y sin demasiada complicación, pero vamos a analizar esto detenidamente..

Sobre el papel, el estilo del tile map o 'tiled' es buena idea, ya que te permite dibujar muy comodamente un escenario, para la fase de diseño la verdad es que estamos completamente de acuerdo, es muy buena solución para alquien que no quiere hacer algo demasiado rebuscado y que sea en su mayor parte repetitivo, así que es una buena solución en general lo de poder dibujar una escena con un tileset.

Pero ya hablando de recursos.. la cosa cambia bastante.. y digo bastante por lo siguiente..

Lo que el publico en general no conoce o sabe es que un tileset se carga al completo en memoria, osea, todas esas pequeñas partes se almacenan en memoria para luego poder ser utilizadas ingame, enotonces siendo esto así, ahora pensando en lo que comentaba OscarG.. si tu cargas en memoria todo el mapa del nivel.. y vas haciendo map puts al lienzo que se ve en pantalla.. realmente que ganas?

Absolutamente nada, es mas, pierdes mucho, por que necesitas crear un control de posición y desplazamiento de la escena y además necesitas estar controlando y haciendo los puts() graficos al mapa.
En mi opinión, este sistema es el peor de todos, a no ser que no carges nada en memoria, y vayas cargando a razon de lo que va apareciendo en pantalla, y también vayas descargando recursos de memoria ram a razón de lo que deja de verse..
Esto es bastante costoso y tiene muchas limitaciones simplemente por la velocidad de carga y el uso continuado de disco o memoria no volatil.

Creo que no es una solución, pero me gustaria que me lo rebatierais haciendome ver en que me estoy equivocando, ya que no quiero tener la razon, simplemente quiero discutir sobre este tema tan interesante.


Por otro lado tenemos lo que dice hokuto, un motor de tiles, que si que es mejor que la solución de OscarG, pero también tiene sus contras..


La solución del mapa de tiles me gusta mas por que ahorras bastante recursos de memoria ram, pero realmente tiene un motor detras que anda pintando y borrando tiles.. y al final te encuentras con ciertos problemas cuando realizas juegos realmente grandes..


Por ejemplo.. un enemigo, un tile concreto, o un simple evento.. para hacer un juego LOCAL no hay problema.. borras de pantalla no que no se ve.. y listo.. pero.. y digo pero por que hay un gran pero..
Si tienes un enemigo en la parte superior del nivel.. que esta moviendose en una zona que tu no ves.. como comprueba colisiones y eventos con los demas objetos del juego?

Pues he aquí el gran problema real.. si no hay escenario completamente creado no se puede hacer.. sin mas..


Y es aquí donde las capacidades de openGL/Vulkan brillan y nos ofrecen soluciones muy poco costosas y atractivas tanto en fase de diseño como en fase de gameplay, hablo de las "wrapTexture".


La cosa actualmente está en que tu creas un viewport del tamaño de la pantalla, y tienes una textura bien grande, si, bien grande, y lo que hacen estos engines modernos es simplemente cargar el archivo de imagen como una textura para un 'shape' o mascara, osea.. un simple poligono.. y mediante un algoritmo de carga este gran poligono se "TROCEA" en poligonos mas pequeños y se les aplica una parte de la texutura grande original, con lo cual internamente ya tenemos el sistema que comentaba OscarG pero siendo controlado directamente por Vulkan u OpenGL y no por nosotros en plan espartano jeje..

Mi conclusion, es que algo como TILED es muy buena solución para "pintar" la escena, pero a la hora de renderizarla todo esto que estamos hablando ya lo hacen los grandes drivers graficos, otra cosa será como lo hace Gemix o lenguajes así, que no tengo ni la mas remota idea, yo creo que en gemix todo es una textura sin mas que se aplica a un rectangulo sin crear subpoligonos ni nada.. no lo se hee.. esto lo tendría que decir mejor CicTec.. pero vamos..

Que tu cargas el archivo .png en memoria y directamente al cargarse como una "textura" en vez de como una "imagen" ya se poligoniza solo y se aplica de la forma que decis de forma automatica, luego solo tienes que pintarlo desplazado en x o y internamente accediendo a los offset de la textura y ya esta.. tienes una imagen pequeña que parece un scroll como los de gemix mediante una imagen mas grande..

Un ejemplo de como lo hago yo es así:

Source Code (Java) [ Download ] [ Hide ]

Source Code (Java) [ Download ] [ Show ]

• class scroll {
•     int st = 0;
•     PImage gr;
•     PShape s = null;
•     float size = 100;
•     float sizeX = 100;
•     float sizeY = 100;
•     float x = 0;
•     float y = 0;
•     float angle = 0;
•     PVector offset = new PVector(0, 0);
•     PVector tiling = new PVector(1, 1);
•     boolean xmirror = false;
•     boolean ymirror = false;
•     //......................................
•     scroll(PImage gr) {
•         this.gr = gr;
•     }
•     //......................................
•     void render() {
•  
•         // configure transformation matrix..
•         blitter.pushMatrix();
•         blitter.shapeMode(CENTER);
•         blitter.textureWrap(REPEAT);
•  
•         // create a pshape..
•         s = createShape();
•         s.setTexture(gr);
•         s.disableStyle();
•         s.beginShape();
•         s.vertex(0, 0,                     offset.x*tiling.x, offset.y*tiling.y);
•         s.vertex(gr.width, 0,              (gr.width+offset.x)*tiling.x, 0+(offset.y)*tiling.y);
•         s.vertex(gr.width, gr.height,      (gr.width+offset.x)*tiling.x, (gr.height+offset.y)*tiling.y);
•         s.vertex(0, gr.height,             offset.x*tiling.x, (gr.height+offset.y)*tiling.y);
•         s.endShape(CLOSE);
•  
•         // apply pshape fx translate, rotate and scale..
•         blitter.translate(x, y);
•         blitter.rotate(radians(-angle));
•         if(size==100){
•             blitter.scale( xmirror ? -sizeX/100.0 : sizeX/100.0, ymirror ? -sizeY/100.0 : sizeY/100.0);
•         }else{
•             blitter.scale( xmirror ? -size/100.0 : size/100.0, ymirror ? -size/100.0 : size/100.0);
•         }
•         blitter.shape(s);
•         blitter.popMatrix();
•     }
•     //......................................
•     //......................................
•     //......................................
• }

En este simple ejemplo tienes que creas un layer de scroll con un simple:

Source Code (Java) [ Download ] [ Hide ]

Source Code (Java) [ Download ] [ Show ]

• idScroll = new scroll(myTexture);

y para moverlo haces esto:

Source Code (Java) [ Download ] [ Hide ]

Source Code (Java) [ Download ] [ Show ]

• idScroll.offsetX++;

Y con esta birria de codigo ya tienes un scroll grandioso completamente controlado por Vulkan o OpenGL sin tener que hacer nada en absoluto.

Eso si, el que yo estoy diciendo ha de cargar entera la textura de la escena, mas ram gasta si, pero ahorras mucha CPU y carga de disco.
Que opinais sobre todo esto?

[OskarG]

Yo me refiero que si hago un juego,los mapas que voy poniendo ya los pienso que sean tileables,por ejemplo tipo mario,entonces tengo los tiles en un fpg diferente de cada fase,con lo cual,no gasto na de recursos ..salvo que empieces a dibujar un escenario sin hacerlo por tiles,entonces no sirve de nada este metodo,pues si o si,debes cargan el fondo de golpe.
1.Sobre los puts no veo complicacion ni coste alguno,por ejemplo si tengo una escena de 320x240.. e indicando que los tiles son de 16x16 imaginamos que hago un juego de naves de scroll vertical ..cada 16 pixeles que se mueva la nave debo hacer 15 map_block_copy de un grafico de 20x15 pixeles al scroll x numero de planos que quiero poner..........................esto en gemix lo hace muy fino.
2.No tengo que calcular nada...solo debo leer unas tablas o grafico de colores ...segun el color le asigno el tile al mapa de fondo o le asigno el tipo de dureza..para hacerlo en plan chapuza y sin complicarse...creo otro mapa de 320x240 que le hago otros 15 map_block_copy...pero en esta ocasion pensamos un poco 320:16=20 pixeles entonces un simple pixel es un tile de durezas....entonces el mapa de durezas queda reducido a 20x15 pixeles.una chorrada vamos.... aunque tambien se puede hacer hasta sin tiles de durezas,solo con numeros,cada numero indica que clase de tile es,rampa ,pared,tile para pintar en el mapa de scroll...
Esto lo tenia hace siglos implemetado en div2 y funcionaba en todas las direcciones de forma fluida..
lo logico y lo comprensible es que ya por defecto el propio engine lo lleve .
Cuando tenga ganas monto el ejemplo en divgo o div y lo ideal para rematar seria hacerlo de esta manera....http://www.sploder.com/free-arcade-game-maker.php cosa que no lo veo complicado,solo que si yo por ejemlo me mato en hacer esto,es complicado que lo comparta pues las horas que lleva detras para hacerlo son muchas y ahora estoy liado con el dibujo que es mi vicio.

erkos.png

[Hokuto7]

Se me ha ocurrido algo sencillo.

Lo primero es arreglar los bugs de szener que te he comentado anteriormente,es decir,solucionar el problema de los vectores que hay muchas veces que el sprite no los detecta y solventar el desplazamiento sobre el escenario que a mi no me funciona.

Y ahora lo que se me ha ocurrido,te acuerdas del editor brackets.Pues este editor te permite cargar archivos de imagen y una vez cargado los visualiza y ademas aparece una cruz que al moverla con el raton te dice las coordenadas x e y.

Entonces deberias añadir un boton a tu aplicacion para que cuando lo pulses el raton se convierta en una cruz que al desplazarlo por el mapa cargado te visualize las coordenadas x e y en donde este posicionado el raton.

Con esto puedo elegir los lugares donde voy a colocar mis enemigos y apuntar esas coordenadas para luego colocarlas en el codigo.

[CicTec]

Un sistema scroll basado en mapa de dureza ocupa bastante mas RAM y cuando mas es grande el MAP, mas es la RAM requerida, pero mayor es la velocidad de redimiento, mas faciles son los calculos de colisiones, etc...
De contra un sistema de scroll basado en tiles, ocupa bastante menos RAM, y cuando mas grande es el MAP, menos es la RAM requerida respecto al sistema de dureza, todavia va peorando siempre mas el rendimiento debito al mayor numero de tiles por renderizar, especialmente se la resolucion es mas alta y tambien los calculos necesarios para las colisiones con el MAP y los objetos es mas compleja.

Cual sistema usar depende dal contexto del juego que se necesita.

[erkosone]

@Oscarg: Ese editor esta gracioso, lo he mirado y para hacer cosas rapidas sin complicarte nada la vida esta muy bien, pero la verdad es que se queda un poco corto? no lo se, de todos modos muy buen ejemplo de editor, gracias por compartirlo.
@Hokuto: pues si tio, ahora ya con varios años mas de experiencia en programas de escritorio voy a reescribir el programa, la verdad es que no es tanto codigo y creo que en unas horas puedo tenerlo listo y funcionando, voy a hacerle esto que dices, incluso algo mas, poder añadir items en posiciones del mapa, creo que va a ser util para el diseño sencillo de niveles.
@CicTec: Completamente de acuerdo en esto tio, aveces sacrificar un poco de ram a cambio de un buen rendimiento de CPU es buena idea, otras veces es tanta la ram necesaria que hay que hacer trampas, pero vaya.. hoy en dia esto no es un problema real, hace unos años si podia darte dolor de cabeza, pero hoy en dia todo está pensado para hacerse en resoluciones altas, por eso tanta ram instalada.

Estamos hablando de tiles y de scrolls y todavia pensamos en resoluciones arcade de los 90´s como la 320x200 o similar, pero hay que aceptar que hoy se trabaja con 4k y un simple fondo de pantalla para un juego ya es del tamaño 3840x2160!

Así que tener un scroll de 15.000 pixel de ancho no es nada disparatado, es algo bastante normal.

Este es un tema la mar de interesante, voy a ponerme a trabajar con scener y a reparar lo que tiene mal y veremos lo que sale de todo esto jeje..
Gracias por comentar, son temas realmente interesantes.

[Hokuto7]

Se me ha ocurrido algo para simplificar el tema de la colocacion de objetos,aunque no se si es posible o te parece sensato.

Por ejemplo,tendriamos un boton en szener que al pulsarlo apareceria un cuadrado con un color base y podriamos colocar estos cuadrados con el raton donde queramos y la cantidad que queramos.

A este cuadrado se le puede poner un numero o un nombre o simplemente generaria un numero y luego tendriamos una variable interna en el proceso que se llamaria objeto_szener,a esta variable le ponemos el numero generado por ese cuadrado que hemos colocado en el editor y ya tendriamos el proceso colocado en el escenario.

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• class enemigo extends sprite{
•   int estado = 0;
•  
•   void frame(){
•     switch(estado){
•       case 0:
•         setGraph(img[2]);
•         objeto_szener = 1;//con esto ya no haria falta poner la X y la Y
•         x = 320;
•         y = 64;
•         priority = 0;
•         createBody(TYPE_BOX);
•         setSensor(true);
•         estado = 10;
•         break;
•       case 10:
•         break;
•        
•     }
•  
•   }
•  
• }
•  

[erkosone]

Me parece una idea genial Hokuto, de hecho ya tengo pensado hacerlo pero directamente cargando sprites jeje..
Va a quedar algo decente..

Estoy reescribiendo el codigo de SZENER por completo utilizando la nueva gameLibZero que está años luz de la versión que usé en su dia para hacer este programa, parece mentira como avanza la libreria en un año...
En cuanto esté listo y usable lo cuelgo