Llevo tiempo con ganas de usar divgo y ver las diferencias que tiene con los otros diviike,incluso me baje unos videotutoriales que me encontre en youtube para empezar con lo basico.
El problema que tengo es que mi ordenador se come un buen trozo de la interfaz de divgo, y no veo parte de la izquierda y derecha de la interfaz,ademas de que no se puede aumentar a un buen tamaño las letras del editor de codigo.
Ya me comentastes algunas cosas para cambiar la resolucion pero no cambio nada y siguio igual,entonces se me ha ocurrido algo.
Podrias simplificar la interfaz para que solo aparezcan los botones que te llevaran a cada editor,por ejemplo...
Tendriamos el boton del editor de fpg que al pulsarlo te llevaria a otra ventana con el editor.De esta forma lo podria maximizar y poner toda la pantalla con este editor y tendrias mas espacio para añadirle mas opciones si tu lo ves adecuado.esto seria igual para el resto de editores,editor de codigo,fnt etc..
O si no quieres crear otra ventana,podrias hacerlo en la misma,por ejemplo...Si pulsas el boton para el editor de codigo se borraria toda la interfaz y apareceria el edito de codigo que tambien ocuparia toda la ventana y habria otro boton para ir para atras.
Seria algo parecido a lo que trae gamemaker,tiene botones para que se habra cada editor por separado y es muy comodo,miralo por ti mismo.
No se si a ti se te ocurre otra cosa o a oscarG.
Hola hokuto40,
¿Qué resolución de pantalla tienes? En principio la interfaz de Div GO es responsive y se adapta a la resolución de dispositivos móviles. También está la opción de crear un tema nuevo para bajas resoluciones, esto se hace por css, agregándolo en la carpeta temas. Cualquiera podría crear su propio tema y compartirlo.
El tema de abrir ventanas del navegador cada vez que clicas una opción no es muy sutil, seria abrir modales dentro de la misma ventana y apartarlas como en Div2.
Hace tiempo que quiero cambiar la interfaz, sobre todo para la futura versión 2.0.
Un saludo.
Resolucion 800x600 y con las letras aumentadas,lo necesito por problemas de vision en un ojo.
He mirado a una resolucion a 1024x768 y se ve todo pero muy pequeño y ademas mi monitor a esa resolucion no se ve bien.A la izquierda aparecen los procesos que vas programando en el editor,seria adecuado que ese trozo se pudiera ocultar para tener mas espacio para el editor de codigo.
No tengo ni idea de css,te pongo una imagen para que lo veas mas claro.
(http://forum.bennugd.org/index.php?action=dlattach;topic=4779.0;attach=4197)
Estas con la versión ejecutable, aquí te adjunto el archivo settings.json con una configuración que creo te puede ir bien.
Sustituyelo por el que tienes en la carpeta donde se encuentra el ejecutable y a ver que tal te va ahora.
He probado el archivo y sigue igual,faltan muchas cosas que no salen en la interfaz,he probado la version web y reduciendo el zoom al 70 % se ve todo pero muy pequeño,pero a mi no me interesa la version web,yo uso la version ejecutable.
Es muy raro esto porque no me ha pasado con ningun programa,creo que lo mejor sera que cada editor este en pestañas separadas.
Una pregunta,¿puedo usar el fpg y el fnt editor de gemix con divgo? , de esta forma puedo estar trasteando un poco con divgo hasta que me des una solucion.
Te vuelvo a poner la imagen actualizada para que veas que sigue igual.
(http://forum.bennugd.org/index.php?action=dlattach;topic=4779.0;attach=4200)
QuoteUna pregunta,¿puedo usar el fpg y el fnt editor de gemix con divgo? , de esta forma puedo estar trasteando un poco con divgo hasta que me des una solucion.
Div GO es compatible con los formatos fpg, fnt y map de Div2 (8bits), Fenix (16bits) y BennuGD (32bits). Mi propósito era que fuera compatible con todos los formatos Divlikes, pero no pudo ser. Por lo que usando los editores de Gemix no te funcionaria la carga de esos ficheros en Div GO.
Aunque yo te recomendaría mejor que uses formatos estándares para gráficos (png, bmp o gif), fuentes (ttf o otf) y música (mp3 o ogg).
Ok,entonces puedo usar los editores de bennugd porque usar el formato png me daria bastantes problemas para realizar animaciones,pero ya te dire mas adelante alguna sugerencia para funciones que se encarguen de manejar la animacion.
Pero me he encontrado con otro problema,no se ve los botones de abrir y guardar el prg y eso me impide hacer cualquier cosa,en fin....de momento no puedo hacer nada.
Voy a seguir dandote sugerencias.
He visto que solo tienes la funcion key() si no me equivoco,aqui es fundamental que introduzcas otras dos.
keyPressed() //cuando pulsas la tecla solo una vez
keyReleassed() //cuando sueltas la tecla
Lo apunto, pero será más estilo Div, por ejemplo: key_on() key_out()
Los nombres que te doy es solo por poner algo,tu puedes poner el nombre que te de la gana que para eso es tu engine,yo encantado de que introduzcas las sugerencias. ;)
Pues vamos a por mas,estas sugerencias que doy son tambien validas para bennugd y pixtudio.
He mirado las funciones de aleatoriedad y por lo que veo solo tienes rand(),estaria muy bien que añadieras esta.
rand_chooise(1,2,3,4,5,6,7,8,9)
Esta funcion es para colocar muchos valores y que elija aleatoriamente uno de ellos cada vez,seguramente me diras que se puede hacer con un array pero esto es mas comodo y sencillo y creo que estaria bien.
Por cierto,he mirado para cambiar el color del grafico y se usa esta funcion.
color_in_map(fichero, grafico,color)
No seria mejor crear una variable interna para los procesos,seria mas corto y mejor.
tint = red
Tendriamos esta varible y las constantes para los colores,la funcion esta bien pero creo que esto es mejor.
Seguimos con mas sugerencias. ;D
He mirado las funciones para manejar el tiempo y tienes timer[] que no se si se pondra añadir mas de 9 y tienes time() que no se muy bien que uso tiene.Yo añado otra sacada de contruct 2.
wait(tiempo) //tiempo en segundos o lo que tu quieras
Esta funcion sirve para esperar un tiempo antes de que pase algo y se pueden colocar todas las que quieras sin limite,pero te pongo un ejemplo para que sea mas claro.
if(colisiona con bomba)
activar bomba
wait(3)
explota bomba
wait(3)
mostrar texto de juego finalizado
end
Aqui hay una colision y se activa la bomba y luego se usa wait() para esperar
los segundos colocados antes de que pase lo siguiente,esto no para el juego ,es como si fuera un contador interno.
Te comento otra sugerencia.
friction = 5
Esta variable seria una variable interna del proceso y serviria para ir frenando poco a poco el movimiento de cualquier objeto,si el numero de la variable es mas alto mas rapido se parara.Podria servir para ir frenando una nave poco a poco o para disminuir la velocidad de un personaje en un juego de plataformas .
Hola amakast,no se si estas viendo las sugerencias pero yo voy a seguir por que si no se me olvidan.
He mirado alguna funcion que me sirva para crear barras de vida y aunque he encontrado algo,le faltan parametros y hay que usarlas con define region y ya son muchas cosas.
Lo mejor es crear una funcion como la que trae gamelibzero de erkozone ,que es la que yo utilizo para la barra de vida.Esta funcion es screenDrawGraphic(),pero te pongo una version un poco mas completa.
drawGraphic(grafico,x,y,,angle,punto de centrado,sizeX,sizeY,alpha)
punto de centrado = left,right,center//constantes para usar
La mayoria de parametros estan claros,pero el punto de centrado es para colocar su punto y que la barra vaya desapareciendo como en cualquier juego.Yo utiliza el parametro sizeX para ir reduciendo la barra.
Esta funcion se puede utilizar para crear un grafico y lo bueno es que se utiliza en dentro de un proceso,por lo que se puede tener el grafico del proceso y el grafico de esta funcion que hace de vida o de lo que quiera.Yo lo he utilizado en mi juego de naves y hace de barra de vida de los jefes.
Ahora te comento otra sugerencia,el fade() esta muy chulo y no es dificil de usar pero hay que crearlo y luego comprobarlo y luego volver a hacerlo para que aparezca la pantalla,muchas cosas para algo tan simple.
Por eso se me ha ocurrido que podrias hacerlo todo de golpe con una sola funcion.
fade_especial(tiempo,tipo,color)
tipo = para distintos tipos de fundido
Solo habria que poner esta funcion y se encargaria de hacerlo todo automaticamente,haria el fundido y luego automaticamente volveria a mostrar la pantalla.Tenemos el tiempo,el color y el tipo de fundido,por si te apetece en un futuro meter otros tipos de fundido.
Quote from: hokuto40 on April 12, 2019, 03:43:44 PM
He mirado las funciones de aleatoriedad y por lo que veo solo tienes rand(),estaria muy bien que añadieras esta.
rand_chooise(1,2,3,4,5,6,7,8,9)
Esta funcion es para colocar muchos valores y que elija aleatoriamente uno de ellos cada vez,seguramente me diras que se puede hacer con un array pero esto es mas comodo y sencillo y creo que estaria bien.
Por cierto,he mirado para cambiar el color del grafico y se usa esta funcion.
color_in_map(fichero, grafico,color)
No seria mejor crear una variable interna para los procesos,seria mas corto y mejor.
tint = red
Tendriamos esta varible y las constantes para los colores,la funcion esta bien pero creo que esto es mejor.
Hola hokuto40,
Existe qsort(), que puedes ordenar aleatoriamente un struct y añadirle los valores que tu quieras. Por cierto, qsort() fallo en alguna versión remota y estará corregida en la 1.20.
Sobre la variable tint... existen las variables tone, blur, grayscale, sepia, saturate, invert, brightness... lo he intentado y créeme, si pudiera cambiar el color del gráfico con un color indicado desde una variable, ya existiría. :P
Quote from: hokuto40 on April 13, 2019, 09:42:00 AM
Seguimos con mas sugerencias. ;D
He mirado las funciones para manejar el tiempo y tienes timer[] que no se si se pondra añadir mas de 9 y tienes time() que no se muy bien que uso tiene.Yo añado otra sacada de contruct 2.
wait(tiempo) //tiempo en segundos o lo que tu quieras
Esta funcion sirve para esperar un tiempo antes de que pase algo y se pueden colocar todas las que quieras sin limite,pero te pongo un ejemplo para que sea mas claro.
if(colisiona con bomba)
activar bomba
wait(3)
explota bomba
wait(3)
mostrar texto de juego finalizado
end
Aqui hay una colision y se activa la bomba y luego se usa wait() para esperar
los segundos colocados antes de que pase lo siguiente,esto no para el juego ,es como si fuera un contador interno.
Te comento otra sugerencia.
friction = 5
Esta variable seria una variable interna del proceso y serviria para ir frenando poco a poco el movimiento de cualquier objeto,si el numero de la variable es mas alto mas rapido se parara.Podria servir para ir frenando una nave poco a poco o para disminuir la velocidad de un personaje en un juego de plataformas.
wait() sería lo mismo que usar frame():
if(colisiona con bomba)
activar bomba
frame(300);
explota bomba
frame(300);
mostrar texto de juego finalizado
endLo de la variable friction no me ha quedado muy claro.
Quote from: hokuto40 on April 14, 2019, 09:17:09 AM
Hola amakast,no se si estas viendo las sugerencias pero yo voy a seguir por que si no se me olvidan.
He mirado alguna funcion que me sirva para crear barras de vida y aunque he encontrado algo,le faltan parametros y hay que usarlas con define region y ya son muchas cosas.
Lo mejor es crear una funcion como la que trae gamelibzero de erkozone ,que es la que yo utilizo para la barra de vida.Esta funcion es screenDrawGraphic(),pero te pongo una version un poco mas completa.
drawGraphic(grafico,x,y,,angle,punto de centrado,sizeX,sizeY,alpha)
punto de centrado = left,right,center//constantes para usar
La mayoria de parametros estan claros,pero el punto de centrado es para colocar su punto y que la barra vaya desapareciendo como en cualquier juego.Yo utiliza el parametro sizeX para ir reduciendo la barra.
Esta funcion se puede utilizar para crear un grafico y lo bueno es que se utiliza en dentro de un proceso,por lo que se puede tener el grafico del proceso y el grafico de esta funcion que hace de vida o de lo que quiera.Yo lo he utilizado en mi juego de naves y hace de barra de vida de los jefes.
Ahora te comento otra sugerencia,el fade() esta muy chulo y no es dificil de usar pero hay que crearlo y luego comprobarlo y luego volver a hacerlo para que aparezca la pantalla,muchas cosas para algo tan simple.
Por eso se me ha ocurrido que podrias hacerlo todo de golpe con una sola funcion.
fade_especial(tiempo,tipo,color)
tipo = para distintos tipos de fundido
Solo habria que poner esta funcion y se encargaria de hacerlo todo automaticamente,haria el fundido y luego automaticamente volveria a mostrar la pantalla.Tenemos el tiempo,el color y el tipo de fundido,por si te apetece en un futuro meter otros tipos de fundido.
Existe en Div GO la función texture_in_map(), aquí un ejemplo para una barra de vida: https://www.divgo.net/c-8285dfe9
Sobre las fade, Div GO soporta también fade con un gráfico de entrada y salida: fade_in() y fade_out(); en el listado de funciones esta con ejemplos. :)
Lo del tipo o estilo de fundido me lo apunto, como una futura variable global que afecte a las fade_on() y fade_off().
Un saludo.
Hola amakast.
Lo de friction es como la friccion,es una fuerza invisible que se le aplica al objeto para que se vaya frenando poco a poco y no de golpe.Ejemplo lo tienes en el mario,que no se para de golpe.
Lo de la barra de vida pues esta muy bien texture_in_map() pero he visto mucho calculo hay y ademas hay que crear un proceso aparte.
Yo me refiero a esto.
process nave()
private vida = 100;
begin
graph = 1;
x = 100;
y = 100;
drawGraphic(grafico=2,x,y,,angle,punto de centrado,sizeX=vida,sizeY,alpha)
drawGraphic(grafico=2,x,y,,angle,punto de centrado,sizeX=vida,sizeY,alpha)
loop
vida--;
frame;
end
end
Con esto podemos tener muchos graficos en un solo proceso y es mucho mas sencillo de usar que el tuyo.
Lo del wait() pues poner frame(300) no ralentiza el juego o lo para hasta que termina.No es mejor tener una funcion propia para esto como si fuera un contador interno que tu activas cuando quieres.
Seguimos con mas sugerencias.
Cuando un enemigo te ataca se suele usar la tecnica del parpadeo y mientras estas parpadeando tu personaje es invensible por un corto periodo de tiempo y no se le puede quitar toda la vida de golpe.
Pero esto es un poco complicado de hacer en el lenguaje div,por eso propongo una serie de funciones que te ayuden en esto.
parpadeo(tiempo)
al_finalizar_parpadeo()
esta_parpadeando()
El parpadeo durara el tiempo establecido en la funcion y luego dejara de parpadear,la funcion esta_parpadeando() es para comprobar si esta parpadeando y decirle que no te pueden quitar vida en ese estado.
La funcion al_finalizar_parpadeo() es para decirle que pueden quitarte vida otra vez,esto es solo un ejemplo,se puede usar para muchas cosas.
if(colisiona con enemigo)
te quita vida
parpadear(3 segundos)
end
if(esta_parpadeando())
invensible
end
if(al_finalizar_parpadeo())
deja de ser invensible
end
Otra sugerencia.
Me gustaria el poder aumentar o disminuir la mascara de colision y tambien el poder visualizar la mascara,para verla cuando ejecuto el juego.
tamaño_mascara = 100 normal,menos de 100 disminuir y mas de 100 aumentar
visualizar_mascara = true o false //con esto pueder ver el tamaño puesto
Que yo sepa la mascara en el lenguaje div ocupa todo el sprite,y pienso que seria util hacer esto.En un juego de naves es crucial,si no tendria que crear otro objeto que hiciera de mascara.
Quote from: hokuto40 on April 15, 2019, 09:20:19 AM
Hola amakast.
Lo de friction es como la friccion,es una fuerza invisible que se le aplica al objeto para que se vaya frenando poco a poco y no de golpe.Ejemplo lo tienes en el mario,que no se para de golpe.
Lo de la barra de vida pues esta muy bien texture_in_map() pero he visto mucho calculo hay y ademas hay que crear un proceso aparte.
Yo me refiero a esto.
process nave()
private vida = 100;
begin
graph = 1;
x = 100;
y = 100;
drawGraphic(grafico=2,x,y,,angle,punto de centrado,sizeX=vida,sizeY,alpha)
drawGraphic(grafico=2,x,y,,angle,punto de centrado,sizeX=vida,sizeY,alpha)
loop
vida--;
frame;
end
end
Con esto podemos tener muchos graficos en un solo proceso y es mucho mas sencillo de usar que el tuyo.
Lo del wait() pues poner frame(300) no ralentiza el juego o lo para hasta que termina.No es mejor tener una funcion propia para esto como si fuera un contador interno que tu activas cuando quieres.
Lo de drawGraphic() se parece bastante al xdraw() de DivGO: xdraw(
fichero,
gráfico,
x,
y,
size,
angle,
alpha,
región)
Frame() no ralentiza el juego, es necesario que todos los procesos lo tengan para que estos dibujen en pantalla y no se mueran. Hay varios ejemplos que usa frame() para generar un parpadeo de imágenes, por ejemplo.
Quote from: hokuto40 on April 15, 2019, 09:36:42 AM
Otra sugerencia.
Me gustaria el poder aumentar o disminuir la mascara de colision y tambien el poder visualizar la mascara,para verla cuando ejecuto el juego.
tamaño_mascara = 100 normal,menos de 100 disminuir y mas de 100 aumentar
visualizar_mascara = true o false //con esto pueder ver el tamaño puesto
Que yo sepa la mascara en el lenguaje div ocupa todo el sprite,y pienso que seria util hacer esto.En un juego de naves es crucial,si no tendria que crear otro objeto que hiciera de mascara.
Existen 3 funciones para colisionar procesos:
collision() > pixel perfect (no necesitas mascaras con esta función)
collision_box() > no es pixel perfect, colisiona con todo el tamaño del gráfico y es más optimo que collision()
collision_circle() > tamaño del gráfico en circulo, sin esquinas y es más optimo que collision()
Un saludo. :)
Puede que xdraw() me sirva para lo que quiero,pero de momento no puedo hacer pruebas por el problema que ya sabes.
En cuanta a las colisiones pues no me sirve,porque si yo quiero reducir el campo de colision de mi nave,para que sea un circulo pequeño en el centro donde sea la colision,habria que crear algo para poder reducir ese campo o mascara.
Pero si no se puede pues habra que conformarse con crear otro proceso con un grafico pequeño.
Mas sugerencias.
Si se quiere conseguir una buena animacion no queda mas remedio que trabajar con arrays,pero esto hace que se llene de muchos numeros y si hay muchas animaciones puede ser una locura.
Se me ha ocurrido el crear una funcion para esto.
animacion(fichero,grafico inicial,grafico final,velocidad)
Aqui tenemos la funcion con el fichero,el grafico donde quieres que comience,el grafico donde finaliza y la velocidad de animacion.
Claro esta que para hacer bien esto habria que meter cada animacion en su fpg correspondiente,es decir...Si tienes el personaje parado con sus animacion ira en un fpg y si tienes el personaje con movimiento en otro fpg.
Otra sugerencia,pero esta es una flipada mia que puede no ser muy sensata pero te la digo igualmente.
Esta claro que no vas a crear un editor de escenarios para colocar mis objetos y crear un buen escenario,entonces lo tengo que crear yo y no tengo ni idea de como se hace.
Se me ha ocurrido unas funcionalidades que faciliten esta tarea.
crear_editor(proceso,guardar,camara)
activar_editor = true o false
rejilla(tamaño de cuadricula,tamaño de cuadricula)
La variable "activar_editor" es para decirle al programa que funcione como editor,la funcion rejilla(32,32) es para decirle el tamaño de cada cuadricula de la pantalla donde colocaremos los objetos,ya sea el suelo o la pared o un enemigo.
Esta rejilla sirve para que no se pongan encima un objeto de otro,y la funcion crea_editor(proceso,guardar,camara) tiene el proceso que vamos a utilizar para ir colocandolo en el nivel,luego pondremos en guardar a true para que guarde el contenido creado cuando cierres la aplicacion y el parametro camara = true es para activar la camara.
La camara estara configurada para mover con los cursores de teclado y el objeto lo moveremos con el raton y si dejamos pulsado el boton izquierdo se ira colocando continuamente mientras nos desplazamos con el raton.
Si queremos crear mas objetos y seleccionarlos utilizaremos otra variable para que se activa el boton de seleccion que sera la rueda del raton.
seleccion_objeto = true
Por lo que si tenemos muchos objetos se podran seleccionar con la rueda del raton y quedaria de esta forma.
crear_editor(proceso=type objeto,guardar=true,camara=true)
crear_editor(proceso=type objeto2,guardar=true,camara=true)
crear_editor(proceso=type objeto3,guardar=true,camara=true)
activar_editor = true
rejilla(32,32)
seleccion_objeto = true
Cuando queramos volver al modo normal para jugar a nuestro nivel creado pues desactivamos el modo editor.
activar_editor = false
Se que esto es una flipada mia pero hay esta por si sirve para dar alguna idea y facilitar el diseño del editor casero.
Sigamos con esto.
Ahora una coleccion de funciones y variables para el movimiento.
Hspeed;
Vspeed;
advancePoint(x,y,velocidad,tipo,rotacion);
advanceSinCos(tipo,velocidad,angulo);
Hspeed y Vspeed es para darle al objeto un movimiento en vertical y horizontal,esto es util para cosas simples pero se puede utilizar para juegos de plataformas y cuando te hable de las sugerencias sobre plataformas estas seran muy utiles para esto.
advancePoint(x,y,velocidad,tipo,rotacion) esta te la explique pero te la explico otra vez,el objeto se desplaza a la posicion x e y, y con su velocidad,el tipo seria si quieres que sea un desplazamiento en linea recto o circular y la rotacion es para decirle si quieres que el sprite rote segun la direccion que tenga o no.
advanceSinCos(tipo,velocidad,angulo),esta funcion es como si utilizas las funciones sin() y cos() juntas,con esta dos funciones se consiguen unos movimientos interesantes pero hay que meter mucho codigo y calculos y es un rollo.El tipo es para decirle si quieres que el movimiento sea en vertical,horizontal o en circulo,luego la velocidad y el angulo es para decirle el tamaño del recorrido,como recorrer un circulo pequeño o grande.
Otra de movimiento sacada de la gamelibzero de javascripts de erkozone.
var p = new path();
p.add(100,100);
p.add(200, 100);
p.add(300, 100);
p.add(400, 100);
p.add(924, 100);
p.add(924, 500);
p.add(100, 500);
p.setPoint(0);
p.setVelocity(5);
p.rotation = true;
p.smooth = 0.1;
p.move(tipo de movimento)
Este es un comportamiento de movimiento automatico donde primiero le pones las distintas coordenadas que tiene que recorrer y luego tienes para decirle en que punto empieza,su velocidad,si el sprite rota o no segun su direccion,la suavidad del movimeiento.
Y por ultimo temos la funcion move para decirle que empiece a moverse con una constante predefinida.
FORWARD
REVERSE
FORWARD_LOOP
REVERSE_LOOP
Ejemplo,p.move(FORWARD),si quieres saber mas preguntale a erkozone.
Vamos con mi sugerencia favorita.
Los divlike no tienen ningun sistema para el manejo de los niveles y por lo que veo todo el mundo suele usar el switch() para manejar todos los objetos y crear multiples niveles,pero cuando se trata de un juego muy grande se complica bastante el tema.
Ademas de que se te puede quedar por hay algun procesos vivo y ya ves los problemas que te puede causar.
Yo propongo crear un proceso especial para esto,con algunas funciones que te ayuden en el manejo de los niveles.
process_scene nivel1()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel2);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
process_scene nivel2()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel3);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
Tenemos el proceso especial process_scene() que es para el manejo de niveles,este tiene todas la propiedades del proceso normal y ademas sirve para el manejo del nivel.
Es decir,esto es un contenedor donde meter todos los objetos del nivel y cuando pasamos de nivel con la funcion pasar_nivel(id) se elimina automaticamente todos los objetos que hay en el para que al pasar al siguiente nivel este todo limpio y solo con los objetos del nivel 2.
Ademas tambien eliminara automaticamente los textos y los recursos que haya en la memoria.La funcion reiniciar_nivel() hace lo mismo que pasar_nivel(id) pero en vez de pasar al nivel siguiente volvera a mostrar el nivel donde esta con todo limpito para mostrar lo del nivel actual.
Pongo un videotutorial de gamemaker donde se explica como se manejan los niveles en este engine y con esto podras entender mejor mi sugerencia.
https://www.youtube.com/watch?v=BaTGBtdKLBU
Hay que ver entero el video sino no sirve. :)
Seguimos con mas sugerencias y tranquilo que mañana ya te digo las ultimas. ;D
Ahora vamos con una coleccion de variables y funciones para el plataformeo,en los divlike no hay nada para ayudarte ha realizar un juego de plataformas,por eso propongo introducir alguna ayudita.
gravity = 0 a 100 o mas
gravity_direction = 270//en angulos
solid = true o false
place_free(x,y)
move_contact_solid(direccion,velocidad)
Gravity es para poner una gravedad al juego y gravity_direction es para decirle el angulo que afecta la fuerza de la gravedad,solid es para decirle que un objeto sea solido,esto seria sobre todo para el suelo,paredes,techo y con esto no se podra atravesar ni por arriba,abajo y los lados.
Place_free(x,y) es para comprobar cada pixel si no hay ningun objeto solido y move_contact_solid(direccion,velocidad) es para solucionar los errores que tiene el sprite al colisionar con el suelo y que quede pegado a el y no se quede por encima o enterrado un poco,la direccion seria la de gravity_direction y la velocidad la de la gravedad.
Tal vez no me he explicado bien o sea complicado de entender,por eso dejo un tutorial de gamemaker donde se explica detalladamente como hacer un pequeño juego de plataformas usando todo esto que he dicho y mas cosas.
https://www.youtube.com/watch?v=iTH3Z9ta69g
Hay que verlo entero,es muy interesante y da muchas ideas. 8)
Vamos con las dos ultimas sugerencias,por ahora.
rebote(fuerza=0 a 10,direccion=angulos,velocidad);
Esta funsion sirve para hacer que un objeto rebote al colisionar con otro ya sea solido o no.
La direccion seria en angulo,la velocidad no hace falta explicarlo y la fuerza seria el impulso que tendria la pelota,ejemplo.
Si pongo 10 en fuerza que es el maximo,la pelota rebotaria por toda la pantalla(izquierda,derecha,arriba,abajo),esto seria ideal para un juego de arkanoid.
Si pongo la fuerza a 5,la pelota rebotaria por los lados y abajo pero no llegaria arriba,solo llegaria a la mitad porque no tiene suficiente impulso,esto seria ideal para un juego como el pang.
Y ahora el ultimo.
mover_hacia_objeto(objeto,velocidad,distancia,solido);
Esta es una funcion de inteligencia articial o algo parecido,sirve para que un objeto te persiga y pueda esquivar.
El parametro objeto es para colocar el objeto que quieres que persiga(type jugador),la velocida no hace falta explicarla,la distancia seria la que hay que tener para que empiece a persiguirte,ejemplo.
Si pones 100 en distancia el objeto empezara a perseguirte cuando su distancia sea igual o menor que 100,si es mayor no te persigue.
El ultimo parametro solid es para decirle si quieres que se pare al colisionar con un objeto solido o si quieres que lo rodee o busque una salida o lo esquive para seguir persiguiendote,True se para,false esquiva.
Voy a poner otro sugerencia,esta la iba a dejar solo en el foro de gemix pero creo que es mejor compartirlo en todos los sitios por igual.
El mapa de durezas ya dio todo lo que tenia que dar por eso hay que buscar una alternativa y la mejor para mi es el editor mapeditor,hay que hacer compatible divgo con este editor para crear tus niveles y aplicar una forma de usarlo como pilasengine.
Dejo aqui el enlace al editor de niveles.
https://www.mapeditor.org/
Aqui dejo un enlace a la parte del manual de pilasengine donde explica como hace uso de este editor de una forma muy original.Hay que leerlo entero,no vale saltarse nada. :P
http://manual.pilas-engine.com.ar/mapas_y_plataformas/
Ahora si que es la ultima,creo. ;D
Quote from: hokuto40 on April 16, 2019, 07:18:17 PM
Vamos con mi sugerencia favorita.
Los divlike no tienen ningun sistema para el manejo de los niveles y por lo que veo todo el mundo suele usar el switch() para manejar todos los objetos y crear multiples niveles,pero cuando se trata de un juego muy grande se complica bastante el tema.
Ademas de que se te puede quedar por hay algun procesos vivo y ya ves los problemas que te puede causar.
Yo propongo crear un proceso especial para esto,con algunas funciones que te ayuden en el manejo de los niveles.
process_scene nivel1()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel2);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
process_scene nivel2()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel3);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
Tenemos el proceso especial process_scene() que es para el manejo de niveles,este tiene todas la propiedades del proceso normal y ademas sirve para el manejo del nivel.
Es decir,esto es un contenedor donde meter todos los objetos del nivel y cuando pasamos de nivel con la funcion pasar_nivel(id) se elimina automaticamente todos los objetos que hay en el para que al pasar al siguiente nivel este todo limpio y solo con los objetos del nivel 2.
Ademas tambien eliminara automaticamente los textos y los recursos que haya en la memoria.La funcion reiniciar_nivel() hace lo mismo que pasar_nivel(id) pero en vez de pasar al nivel siguiente volvera a mostrar el nivel donde esta con todo limpito para mostrar lo del nivel actual.
Pongo un videotutorial de gamemaker donde se explica como se manejan los niveles en este engine y con esto podras entender mejor mi sugerencia.
https://www.youtube.com/watch?v=BaTGBtdKLBU (https://www.youtube.com/watch?v=BaTGBtdKLBU)
Hay que ver entero el video sino no sirve. :)
Hola hokuto40,
Revisándome tus sugerencias, está es la que puedes hacer como indicas con los procesos normales, lo del switch() lo usa quien quiere, cada cual desarrolla su juego de la forma que le parezca más útil. Pero lo que veo en tu ejemplo se puede hacer sin problemas con los procesos o funciones actuales.
Cuando pueda, en un rato, te subo un ejemplo a ver como lo ves. :)
Un saludo.
Aquí tienes un ejemplo simulando lo que habías puesto para saltar de nivel: https://www.divgo.net/c-584df9b2
Hola amakast y gracias por este ejemplo. :D
Esta sugerencia es sobre todo para gente nueva que quiera utilizar divgo y se encuentre este problema,ya que los engines que hay hoy en dia te hacen esto automaticamente y te olvidas de limpiar recursos y ademas creo que para proyectos grandes este metodo es fundamental,porque hacerlo manualmente se te puede complicar bastante a la larga.
Comentando el ejemplo ,hay un par de cosas que no me quedan claras,la primera es que veo procesos sin un bucle y sin el frame,esto es posible,yo pensaba que esto no se podia hacer.
Otra cosa que veo es en el proceso pasar de nivel,estas llamando en dentro un proceso que se llama nivel() y no lo veo por ninguna parte,ademas que le pasas como parametro el nombre del proceso nivel() y yo no sabia que fuera posible llamar a otro proceso como parametro de otro proceso,me acabo de perder un poco. :-\
Quote from: hokuto40 on May 11, 2019, 09:15:34 AM
Hola amakast y gracias por este ejemplo. :D
Esta sugerencia es sobre todo para gente nueva que quiera utilizar divgo y se encuentre este problema,ya que los engines que hay hoy en dia te hacen esto automaticamente y te olvidas de limpiar recursos y ademas creo que para proyectos grandes este metodo es fundamental,porque hacerlo manualmente se te puede complicar bastante a la larga.
Comentando el ejemplo ,hay un par de cosas que no me quedan claras,la primera es que veo procesos sin un bucle y sin el frame,esto es posible,yo pensaba que esto no se podia hacer.
Otra cosa que veo es en el proceso pasar de nivel,estas llamando en dentro un proceso que se llama nivel() y no lo veo por ninguna parte,ademas que le pasas como parametro el nombre del proceso nivel() y yo no sabia que fuera posible llamar a otro proceso como parametro de otro proceso,me acabo de perder un poco. :-\
De nada hokuto40.
Sobre los dos puntos:
1. Esto se debería de poder en cualquier Divlike, sin bucle solo pasa una vez (cuando el proceso es llamado) y sin frame no espera a que se dibuje nada en pantalla. El proceso hará las llamadas y gestiones que deba hacer y morirá.
2. nivel() es una variable privada del proceso pasar_nivel que recibe el nombre del proceso por parámetro, por lo que luego puedes hacer la llamada desde la variable, esto no se si lo soporta otros divlikes, aquí una explicación de lo que es, lo soporta muchos lenguajes por lo que no es tan raro: https://es.wikipedia.org/wiki/Expresi%C3%B3n_lambda
Un saludo.
Gracias por la explicacion. ;)
Dime!,hay alguna sugerencia que puedas introducir en divgo.
Quote from: hokuto40 on April 15, 2019, 03:33:02 PM
Mas sugerencias.
Si se quiere conseguir una buena animacion no queda mas remedio que trabajar con arrays,pero esto hace que se llene de muchos numeros y si hay muchas animaciones puede ser una locura.
Se me ha ocurrido el crear una funcion para esto.
animacion(fichero,grafico inicial,grafico final,velocidad)
Aqui tenemos la funcion con el fichero,el grafico donde quieres que comience,el grafico donde finaliza y la velocidad de animacion.
Claro esta que para hacer bien esto habria que meter cada animacion en su fpg correspondiente,es decir...Si tienes el personaje parado con sus animacion ira en un fpg y si tienes el personaje con movimiento en otro fpg.
Pues en lugar de pedirle a AmakaSt que la haga ¿Por qué no la implementas tú con las herramientas que hay? Es fácil crear un proceso como el que mencionas que se responsabilice de cambiar el gráfico del proceso padre.
Mi única sugerencia es que haya una variable local en dicho proceso padre, para que al crear un proceso "animacion", compruebe si hay algún proceso y eliminarlo, antes de asignarse a sí mismo a dicha variable, y de esta forma tener siempre un único proceso que controle la animación.
Quote from: hokuto40 on April 15, 2019, 03:53:34 PM
Otra sugerencia,pero esta es una flipada mia que puede no ser muy sensata pero te la digo igualmente.
Esta claro que no vas a crear un editor de escenarios para colocar mis objetos y crear un buen escenario,entonces lo tengo que crear yo y no tengo ni idea de como se hace.
Se me ha ocurrido unas funcionalidades que faciliten esta tarea.
crear_editor(proceso,guardar,camara)
activar_editor = true o false
rejilla(tamaño de cuadricula,tamaño de cuadricula)
La variable "activar_editor" es para decirle al programa que funcione como editor,la funcion rejilla(32,32) es para decirle el tamaño de cada cuadricula de la pantalla donde colocaremos los objetos,ya sea el suelo o la pared o un enemigo.
Esta rejilla sirve para que no se pongan encima un objeto de otro,y la funcion crea_editor(proceso,guardar,camara) tiene el proceso que vamos a utilizar para ir colocandolo en el nivel,luego pondremos en guardar a true para que guarde el contenido creado cuando cierres la aplicacion y el parametro camara = true es para activar la camara.
La camara estara configurada para mover con los cursores de teclado y el objeto lo moveremos con el raton y si dejamos pulsado el boton izquierdo se ira colocando continuamente mientras nos desplazamos con el raton.
Si queremos crear mas objetos y seleccionarlos utilizaremos otra variable para que se activa el boton de seleccion que sera la rueda del raton.
seleccion_objeto = true
Por lo que si tenemos muchos objetos se podran seleccionar con la rueda del raton y quedaria de esta forma.
crear_editor(proceso=type objeto,guardar=true,camara=true)
crear_editor(proceso=type objeto2,guardar=true,camara=true)
crear_editor(proceso=type objeto3,guardar=true,camara=true)
activar_editor = true
rejilla(32,32)
seleccion_objeto = true
Cuando queramos volver al modo normal para jugar a nuestro nivel creado pues desactivamos el modo editor.
activar_editor = false
Se que esto es una flipada mia pero hay esta por si sirve para dar alguna idea y facilitar el diseño del editor casero.
¡Y tan flipada! ¿No prefieres una función llamada "create_game" que haga todo el juego por ti? :D
Aquí te toca crearte tu propia herramienta: o te creas un array en memoria y lo vas llenando de números, o usas un programa externo, ya sea el tiled o uno propio, y luego lees el fichero generado para ir poniendo los elementos que quieras.
Ya sé que esto es algo básico, pero hay mil formas de hacerlo, y no todas sirven para todos los tipos de juegos.
Creo que estás confundiendo un lenguaje de programación de videojuegos, con un entorno de desarrollo de videojuegos. Conviene que te olvides de GameMaker, porque ni DivGo, ni DIV, ni Fenix, ni Gemix, ni BennuGD ni PixTudio tienen nada que ver, y empieces a pensar como un programador de verdad :D
Y no, no te estoy echando la bronca, todos hemos pasado por lo mismo, y todos necesitamos este toque de atención. Sólo quiero que pienses, antes de pedir, si lo puedes hacer tú, y cuánto tardarías en hacerlo ;)
Quote from: hokuto40 on April 16, 2019, 10:01:51 AM
Sigamos con esto.
Ahora una coleccion de funciones y variables para el movimiento.
Hspeed;
Vspeed;
advancePoint(x,y,velocidad,tipo,rotacion);
advanceSinCos(tipo,velocidad,angulo);
Hspeed y Vspeed es para darle al objeto un movimiento en vertical y horizontal,esto es util para cosas simples pero se puede utilizar para juegos de plataformas y cuando te hable de las sugerencias sobre plataformas estas seran muy utiles para esto.
advancePoint(x,y,velocidad,tipo,rotacion) esta te la explique pero te la explico otra vez,el objeto se desplaza a la posicion x e y, y con su velocidad,el tipo seria si quieres que sea un desplazamiento en linea recto o circular y la rotacion es para decirle si quieres que el sprite rote segun la direccion que tenga o no.
advanceSinCos(tipo,velocidad,angulo),esta funcion es como si utilizas las funciones sin() y cos() juntas,con esta dos funciones se consiguen unos movimientos interesantes pero hay que meter mucho codigo y calculos y es un rollo.El tipo es para decirle si quieres que el movimiento sea en vertical,horizontal o en circulo,luego la velocidad y el angulo es para decirle el tamaño del recorrido,como recorrer un circulo pequeño o grande.
A ver, lo mismo en DivGo no existen porque hace tiempo que no lo toco, pero voy a suponer que sí porque son funciones básicas del primer DIV: busca GetAngle, o fGetAngle, y piensa cómo puedes usar XAdvance en tu beneficio. Tanto para perseguir a un enemigo, como para seguir una ruta.
Lo de los movimiento sinusoidales y circulares, sí, es un rollo de implementar, pero si sabes trigonometría, sólo necesitas DOS lineas:
x += 1;
dato += 1000;
y += pos_vert + 10*sin(dato);
Donde pos_vert es la posición del centro de la sinusoide, y dato es un valor que se autoincrementa en cada frame, para darnos valores equivalentes a ángulos entre 0º y 360º, que al usarlo dentro de la función sin nos devuelve valores entre -1 y 1, por eso lo multiplicamos por 10, para que el proceso se mueva arriba y abajo un máximo de 20 pixels.
Quote from: hokuto40 on April 16, 2019, 07:18:17 PM
Vamos con mi sugerencia favorita.
Los divlike no tienen ningun sistema para el manejo de los niveles y por lo que veo todo el mundo suele usar el switch() para manejar todos los objetos y crear multiples niveles,pero cuando se trata de un juego muy grande se complica bastante el tema.
Ademas de que se te puede quedar por hay algun procesos vivo y ya ves los problemas que te puede causar.
Yo propongo crear un proceso especial para esto,con algunas funciones que te ayuden en el manejo de los niveles.
process_scene nivel1()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel2);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
process_scene nivel2()
begin
graph = 1;//grafico del fondo
x = 300; y = 200;
jugador();
enemigo();
enemigo2();
balablabla();
loop
if(ya no hay enemigos en pantalla)
pasar_nivel(type nivel3);//funcion para pasar de nivel
end
if(el jugador muere)
reiniciar_nivel();//funcion para reiniciar nivel
end
frame;
end
end
Tenemos el proceso especial process_scene() que es para el manejo de niveles,este tiene todas la propiedades del proceso normal y ademas sirve para el manejo del nivel.
Es decir,esto es un contenedor donde meter todos los objetos del nivel y cuando pasamos de nivel con la funcion pasar_nivel(id) se elimina automaticamente todos los objetos que hay en el para que al pasar al siguiente nivel este todo limpio y solo con los objetos del nivel 2.
Ademas tambien eliminara automaticamente los textos y los recursos que haya en la memoria.La funcion reiniciar_nivel() hace lo mismo que pasar_nivel(id) pero en vez de pasar al nivel siguiente volvera a mostrar el nivel donde esta con todo limpito para mostrar lo del nivel actual.
Pongo un videotutorial de gamemaker donde se explica como se manejan los niveles en este engine y con esto podras entender mejor mi sugerencia.
https://www.youtube.com/watch?v=BaTGBtdKLBU
Hay que ver entero el video sino no sirve. :)
Como ya te ha dicho AmakaSt, cada uno implementa sus propias rutinas para los niveles.
Puedes usar un switch o no, pero creo que tener un "play_level", creado por tí, que se encargue de cargar los recursos y guardar sus ID en listas, y crear los procesos de juego, y al terminar, los libere y mate respectivamente, es la mejor solución.
Aparte, hay funciones y métodos para obtener y descargar todos los recursos, como el delete_text(all_text), Get_id(type xxx)...
Adelantándome a los siguientes tres mensajes, te recomiendo que examines el código de un juego de DIV llamado "Castle of Dr Malvado", que te dará muchas pistas sobre gravedad y rebotes. Si puedes encontrar el "manual avanzado de programación de DIV", en él se explica el código con más claridad.
Y mover hacia objeto ya te lo he dicho: GetAngle, y XAdvance.
Hola drumpi,esto son solo sugerencias para dar ideas no es algo que haya que coger como esta y introducirlo tal cual,son solo eso,ideas por si sirve.
Pero entiendo lo que dices,sin embargo creo que tu forma de ver las cosas esta obsoleta,si lo que quieres es que solo unos pocos utilicen el lenguaje div,simplemente hay que dejarlo como esta,pero si quieres que mucha gente se interese por este lenguaje no queda mas remedio que cambiar y añadir algunas cosas para que sea mas atractivo.
Si cualquiera llega aqui para aprender a crear juegos y tu le dices que se tiene que montar su propio sistema de animaciones,niveles,editor de niveles,y basicamente crear todo desde cero pues entonces esa persona pensara que es mejor aprender c++ o java y montarse su propio engine y acabara antes.
Si cada vez que quiero crear un juego tengo que crear desde cero todo el motor del juego,es reinventar la rueda continuamente y desde luego a esto no se le puede llamar engine de juegos porque no trae las herramientas necesarias para facilitarme el desarrollo de juegos.
En definitiva,que cualquiera que entre aqui y vea lo que hay se ira directamente a unity,godot,ureal etc..
Pero esto no es una critica,eso solo como esta el tema hoy en dia,y el desarrollo de juegos sigue evolucionando y cada vez las herramientas son mas sencillas y completas.
Pero hay que pensar que los desarrolladores de juegos no van a usar un lenguaje div como esta hoy en dia y los programadores tampoco lo van a usar,unos usaran un motor grafico y los otros usaran un framework para sui lenguaje de preferencia.
Entonces donde queda el lenguaje div,pues hoy en dia en tierra de nadie,por eso me parece buena idea que el lenguaje div sea un hibrido entre motor grafico y framework,si no,seguira igual.
Drumpi, menos mal que has aclarado que no era echar broncas... ahora me quedo mas tranquilo!!! xD (???)
hokuto40, lo que drumpi dice en cuanto a que eso es un lenguaje de programacion, me temo que tiene razon, esto es un lenguaje de programacion, no porque existan otros integrados donde todo se hace con clicks nadie lo va a usar... por ejemplo, porque exista lenguajes como Visual Basic .NET (por decir alguna pavada) donde haces casi todo con clicks, no significa que yo deje de programar en C, o que lo prefiera a C... esto es un lenguaje orientado a programar... fantastico seria un IDE grafico donde no se tenga que programar o solo programar lo basico, pero eso es algo encima del motor... y no todo el mundo lo prefiere...
comparar los divlike con unity, unreal, godot, etc... es un poco injusto, detras de esos hay una compañia o algun tipo de apoyo detras, aca somos solo unos pocos compartiendo nuestros trabajos...
igual creo que con tus sugerencias has ayudado a enriquecer el proyecto de AmakaSt...
Quote from: SplinterGU on June 06, 2019, 02:36:39 AM
Drumpi, menos mal que has aclarado que no era echar broncas... ahora me quedo mas tranquilo!!! xD (???)
hokuto40, lo que drumpi dice en cuanto a que eso es un lenguaje de programacion, me temo que tiene razon, esto es un lenguaje de programacion, no porque existan otros integrados donde todo se hace con clicks nadie lo va a usar... por ejemplo, porque exista lenguajes como Visual Basic .NET (por decir alguna pavada) donde haces casi todo con clicks, no significa que yo deje de programar en C, o que lo prefiera a C... esto es un lenguaje orientado a programar... fantastico seria un IDE grafico donde no se tenga que programar o solo programar lo basico, pero eso es algo encima del motor... y no todo el mundo lo prefiere...
comparar los divlike con unity, unreal, godot, etc... es un poco injusto, detras de esos hay una compañia o algun tipo de apoyo detras, aca somos solo unos pocos compartiendo nuestros trabajos...
igual creo que con tus sugerencias has ayudado a enriquecer el proyecto de AmakaSt...
Hola SplinteGU.
Se perfectamente que el lenguaje div es un lenguaje de programacion y que no tiene nada que ver con entornos de desarrollo y jamas compararia este fantastico lenguaje con entornos como unity o unreal donde hay cientos de trabajadores detras.
Sin embargo creo que no es incompatible con este lenguaje el hecho de que se le puedan introducir algunas funcionalidades para facilitarte el desarrollo de los juegos,porque yo veo que trae algunas funciones como advance(),get_angle(),start_scroll(),signal() etc...
Y gracias a estas funciones me resulta mas sencillo hacer algunas cosas y no veo a nadie quejarse de estas funciones o otras que ya trae el lenguaje,ademas de que el lenguaje trae un sistema de procesos que ayuda a la creacion del juego y nadie se queja de esto.
Por eso no veo mala idea el introducir mas cosas relacionadas con los juegos y que el lenguaje sea mas atractivo para mas gente.
Hay tenemos phaser,que es un framework donde todo se hace programando y sin embargo ya trae una seria de funcionalidades para facilitarte el desarrollo del juego y trae un sistema de animaciones y niveles integrado,algo que por aqui parece una locura.
Por cierto drumpi,este tema de sugerencias lo cree porque amaka me invito a crearlo,si no,no lo hubiera hecho.Y aqui solo hay un porcentaje pequeño de sugerencias,desde luego tengo muchas mas pero de momento me las guardo para mi.
Y ya por ultimo y acabo,no os tomeis a mal mis comentarios,solo lo hago por si sirve de ayuda para mejorar este lenguaje,no hay ninguna critica a este lenguaje,todo lo contario,estoy muy agradecido por la creacion de este lenguaje.Pero hay que acordarse para quien fue creado div game studio--""para gente sin conocimentos de programacion"",creo que habria que recuperar esa filosofia. :)
me parece muy bien... y no quita todo lo que has veniendo recomendando... lo mio solo fue un comentario sobre 2 cosas concretas... el resto no opino como Drumpi, me parece fantastico sigas aportando sugerencias...
¿En serio parecía enfadado? :P No era mi intención, lo siento.
Antes que nada, yo me alegro de ver sugerencias, y animo a hacerlas. Es sólo que a muchos novatos les pasa (como me pasó a mi) de empezar a hacer sugerencias sin conocer el lenguaje o el objetivo del mismo, y terminan casi pidiendo que les hagan el juego :D :D :D
Pero es que he leído cosas a lo largo del hilo (aunque todo sea dicho, lo he hecho a super-velocidad, entre compilación y compilación del código) que no te lo hace ni Unity.
Por ejemplo, el sistema de "niveles", aunque Unity tiene algo llamado así... no sé si lo has utilizado, pero me parece un sistema horroroso, porque el paso de parámetros es complicadísimo para el novato, y provoca una cantidad de copy-paste entre niveles bestial... Copy-paste es el principal responsable del 70% de los bugs en los códigos, no te quiero ni contar en un entorno más orientado al desarrollo mediante ratón.
Es cierto que un scroll tileado sería imprescindible en BennuGD, y se lo comenté hace años a Splinter... y a Slainté en época de Fenix, y en ambos casos me remitieron al código fuente para que lo implementara yo, e incluso lo estuve mirando, pero claro, por falta de tiempo y conocimientos, ahí se quedó.
Por eso implementé mi propio motor en Fenix y lo trasladé a Bennu, que me daba mucha más flexibilidad que un código encerrado en una DLL (animar los tiles, darles propiedades diferentes, cambiar el FPG para cada capa...)... y el código lo publiqué para que se usara, y el editor de mapas de tiles para usarlo.
Pero otras cosas como "¿por qué no se implementa una función para...?", la mitad de las que he leído, se pueden hacer por código, y con apenas 20 líneas. Por ejemplo, segur un camino de X puntos: ya digo, un bucle, fGetAngle y XAdvance. Imagina que se implementa ¿Cómo? ¿Y si quiero que haga un giro suave? ¿Debe alterar el angle del proceso? ¿Debería ejecutar una animación? ¿Y si quiero una animación diferente en cada tramo? ¿O si quiero que avance girando sobre sí mismo? ¿Y si otro proceso lo empuja fuera? Son demasiadas cosas que puedes hacer de forma diferente.
Vale, quizás se pueda implementar la más básica para los novatos, y que los expertos usen la suya propia, pero no sé, me parece que hacer eso forma parte del aprendizaje.
Al final, cada uno termina por desarrollar sus propios trozos de código, y los va copiando de proyecto en proyecto, e incluso lo comparte con los demás para que no tengan que reescribirlo (no sé la de veces que habré pegado el código de input de texto por teclado :D ).
Por cierto, SplinterGu ¿En qué no estás de acuerdo conmigo? Me gustaría saber :)
PD: De hecho, sólo he comentado las partes que me parecían más obvias que no se iban a implementar. Del resto no he dicho nada porque, aunque si bien son fáciles de hacer mediante código DivLike, podría ser interesante para los desarrolladores de los lenguajes evaluar el implementarlo o no. Al fin y al cabo, son ellos los que deciden qué entra y qué no, y yo sólo soy un simple usuario del mismo :P
Hola drumpi,entiendo lo que dices pero llevo probando los distintos divlike desde hace unos 2 años.
Aunque tambien es cierto que no estoy todo el rato con los divlike,hay veces que utilizo un divlike,otras gamemaker,otras construct 2, otras muchos otros que he ido probando.No te digo todos porque estaria hasta mañana escribiendo.
La mayoria de sugerencias que he hecho las se programar pero lo he hecho pensando en las personas sin conocimientos de programacion.Veras,el lenguaje div o todos los divlike estan en una situacion que ya saben todos y por eso pienso necesario un cambio en el lenguaje.
Intentar hacerlo mas asequible para las personas que empiezan.Si tu quieres hacerlo todo desde cero pues me parece perfecto,pero tu ya tienes experiencia,algo que una persona que empieza no y si se encuentran con tanta dificultad se iran para otro lado.
Lo mejor es ofrecerles una ayudita al principio de su aprendizaje para motivarlos,y con el tiempo cuando tengan soltura ellos mismos sin forzarlos crearan sus propias funciones.
Sigo pensando que no es incompatible las dos cosas,tener un lenguaje que te permite programar de dos formas,una mas clasica y avanzada y otra mas moderna y sencilla.
Lo mejor es mirar las cosas que funcionan en los engines mas utilizados y tratar de trasladarlas con el tiempo al lenguaje div,hay muchos engines donde mirar con codigo abierto.Godot,pilasengine,phaser,gdevelop etc..
Creo que esto animara a mucha gente a utilizar el lenguaje div,porque ahora mismo ni tu lo estas utilizando,supongo que sera por algo,y no me digas que no tienes tiempo,cuando algo te gusta sacas tiempo de donde sea.
Y si,he probado unity y tampoco me gusta su sistema de niveles por eso es mejor mirar phaser,pilasengine,gamemaker etc...
Por cierto,el tema del editor de niveles,lo suyo seria hacer compatible el lenguaje div con tiled map editor,que ademas trae una funcionalidad para pintar con una capa de color los objetos que tu quieras que sean colisionable.
Bueno, yo llevo con los DIV-like desde el 2002, cuando aprendí a programar en C, usando aquel "vetusto" DIV2, por lo que sé lo difícil que es la curva de aprendizaje :D
Y más teniendo en cuenta que me he enfrentado a la "curva de aprendizaje" de un nuevo lenguaje ya unas cuantas veces, pues si me pongo a enumerar los que me han enseñado y los que he tenido que aprender, te puede dar algo, pero te resumo en que he visto cosas desde ensamblador a Xamarin, así que por variedad no será :D
Pero sí que entiendo el problema, y estoy de acuerdo contigo, que hay cosas que hay que mejorar, pero hay otras que no porque falta personal o porque no entiendes cómo funciona realmente.
Por ejemplo, dices que Tiled pinta con un color los objetos colisionables. Muy bien ¿Y cómo sabe Bennu que es un objeto colisionable? Eso no es más que un atributo en memoria. ¿Significa eso que Bennu debería controlar las colisiones con ese tile? Vale, y si colisiona ¿qué hace? ¿Impide al gráfico avanzar? ¿Y si quiero que el gráfico lo atraviese porque los disparos del prota sí atraviesan los campos de fuerza para activar el botón que hay detrás?
Como digo, no voy a entrar en qué debería estar o no en Bennugd, en DivGo o en X, porque eso es decisión del desarrollador/es, pero que tienes que tener muy claro qué es un entorno de creación de videojuegos, como es Unity o Construct, y qué un lenguaje orientado a videojuegos, como los Div-like, XNA Framework, o el combo C+SDL. Son dos filosofías diferentes.
Ahora, si quieres saber por qué no programo ya en Bennu, mis razones no tienen nada que ver con que me haya dejado de gustar: llego a casa de trabajar sobre las ocho de la tarde, y apenas tengo dos horas antes de cenar y acostarme, y eso incluye las tareas de casa, ducharme, etc.
Si a eso le sumas que me he tirado como 8 horas y media, como mínimo, programando en C#, VB6, XML, SQL o lo que me echen encima, como tu comprenderás, lo último que me apetece al llegar a casa es ponerme a programar. Me he visto obligado a cambiar mi hobby por el modelado 3D en Blender, para no pasarme el poco tiempo libre que tengo enganchado a la consola, y hacer algo creativo para que no me estalle la cabeza con tantas ideas como tengo sin hacer.
Hola Amakast,voy con una nueva sugerencia.
Actualmente estoy diseñando un pequeño juego en otro divlike pero estoy teniendo bastantes problemas con el mapa de durezas y posiblemente acabe haciendo el juego en otro engine o simplemente no lo haga.
Se me ha dicho que la mayoria de mis sugerencia no son muy compatibles con un lenguaje de programacion y son mas bien para engines,entonces te voy a enseñar un lenguaje que tira por tierra ese pensamiento.
Esta sugerencia es tanto para divgo como para bennugd2,hace poco me encontre con un lenguaje basado en basic,este lenguaje esta desactualizado y la ultima version es del 2005 pero como me gusta probar cosas nuevas estuve estudiandolo.
El lenguaje es finlandes,por lo que la documentacion es toda en ese idioma,pero me he encontrado una version con una documentacion en ingles menos completa que la version en finlandes pero que no esta nada mal.
El lenguaje no tiene programacion orientada a objetos pero esta muy bien diseñado y trae una buena cantidad de funciones para ayudarte en el desarrollo de los juegos,y aqui biene lo bueno.
Tiene una serie de funciones para manejar la animaciones de una forma automatica y un sistema de colisiones con mapas super sencilla y tambien automatica,simplemente con una funcion ya lo tienes ,y muchas mas ayudas.
Te recomiendo que estudies las 20 lecciones que trae la version finlandes,son 20 ejemplos con poco codigo que te enseña muchas cosas de este lenguaje,la version en ingles no lo trae.
Cuando ejecutes el programa,hazlo con permiso de administrador,por que si no,no deja compilar.Los ejecutables que crea el programa dan un falso virus con avast,solo para que no te asustes.
Por cierto,el programa trae un editor de niveles super simple que te genera un archivo que simplemente lo cargas y le añades la funcion de colision y ya tienes un escenario para recorrerlo con un personaje y no hay nada mas que programar.
Posiblemente no interese como la mayoria de mis sugerencias pero aqui lo dejo para amakast y splintergu.
Version finlandes.
https://www.coolbasic.com/
Version ingles,aqui te vas a descargas y abajo esta coolbasic
https://ingenieropic.wordpress.com/descarga-de-programas/
Hola hokuto40,
No entiendo nada de Finlandés, he entrado en el Manual de Usuario y no he entendido nada.
Yo no me quejo de las sugerencias, pienso que van bien y puede salir algo bueno que me de una idea para una nueva función. Luego hay algunas que no sabría o imaginaría como implementarlas en DivGO al lenguaje, por ejemplo la sugerencia de las funciones crear_editor() y rejilla(), ¿el juego se pausaría y sacaría un editor estilo Mario Maker?. Para depende que juegos no sería un editor valido y eso tiene mucho curro, también lo puedes programar con DivGO o BennuGD por tu cuenta para un juego tuyo en particular.
Lo de la función para manejar animaciones, no sé bien a que te refieres, pero no es algo muy complicado de hacer en un Divlike, aquí te dejo un ejemplo: https://www.divgo.net/c-49e1b7e2
Un saludo.
Gracias por el ejemplo,pero tampoco hacia falta.
Si te fijas tambien te puse un enlace a una version con documentacion en ingles,la version en finlandes era solo para mirar las 20 lecciones que trae y te deja ver un poco lo que trae el lenguaje,aunque si te digo la verdad es mejor coger ideas de frameworks o engines que estan funcionando muy bien hoy en dia.
Despues de un tiempo haciendote sugerencias y viendo que no entran dentro de tus ideas pues no se que mas decirte,lo unico que se me ocurre es que hagas lo que te dijo oscarg,crear un tema donde pongas la hoja de ruta que vas a tomar con divgo porque no se exactamente que es lo vas a hacer con el lenguaje,cual es su futuro y cual es tu idea de lo que debe traer y no.