preguntas de un principiante segunda parte

Started by hokuto40, June 06, 2017, 08:28:53 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Drumpi

Lo de que parpadee un gráfico mientras es invencible depende de cómo hayas implementado la parte de gráficos en el proceso del personaje:

- Mi primera recomendación al respecto es que todas las asignaciones a graph (y a file, si usa más de un fichero de gráficos) estén localizadas en una sección del proceso concreta (yo suelo ponerlas casi al final, justo antes del frame). Así obligas a que todo el aspecto gráfico sea independiente del resto del código.
- La mejor manera de hacerlo es crear diferentes estados, cada uno con su propia animación, que se seleccionen en función de lo que haga el personaje, así puedes tener una acción como andar con dos posibles animaciones, o incluso encadenar animaciones de forma random para el idle. Unity hace algo parecido, pero a diferencia de tener una serie de cajas, aquí tienes código, y puedes alterar el comportamiento en casos específicos.
- Intenta que el gráfico de la animación no depenta del gráfico anterior. Usa un contador y un array con valores, porque de lo contrario, si por ejemplo, para parpadear, pones el gráfico a 0, y estabas haciendo algo como:
if (cont==4)
    graph++;
    if (graph == 15) graph=11; end
    cont=0:
else
    cont++;
end[/cont]
pues vas a tener problemas :D

Dicho lo cual ¿Cómo implementas un parpadeo? Siguiendo estos consejos puedes hacer algo tan sencillo como:
[code]if (invencible && cont>5)
    graph=0;
    if (cont>10) cont=0; end
end
cont++;

Esto lo pones DESPUÉS de la asignación de gráfico y debería funcionar, poniendo el gráfico a 0 cuando cont>5, y dejando el que estaba cuando no.

Pero, como sé que la mayoría de la gente no tiene en cuenta eso, puedes guardar el gráfico anterior en una variable temporal y ponerlo a cero
O hacer todas las asignaciones de gráficos a otra variable (llámala GRAPH2), para que, justo antes del FRAME se haga alg del tipo:
if (invencible && cont>5)
    graph=0;
else
    graph=graph2;
end
cont++;


O, se me ocurre, que uses el último código que he puesto para cambiar el valor de la variable local predefinida ALPHA de 0 a ¿255?. Ojo, que haciendo eso seguirán funcionando las colisiones.

Ya digo, todo depende de cómo lo hayas implementado y cómo lo quieras hacer. Hay muchas formas, sólo dedícale tiempo a pensarlo.


Respecto a un lenguaje gráfico... Personalmente no soy muy amigo de ellos. Si estoy programando, estoy programando, y si estoy moviendo bloques pues estoy moviendo bloques.
Últimamente me he tenido que pelear bastante con Visual Studio, y no hay nada más incómodo que su interfaz para poner botones: pon el botón, vete a propiedades, haz scroll buscando el nombre, cambia el nombre, haz scroll buscando el texto, cambia el texto, haz scroll buscando el orden de selección, cambia su orden... y cada vez es mueve la mano al ratón, mueve la mano al teclado, mueve la mano al ratón, mueve la mano al teclado... ¡Pierdo mucha velocidad! Tardo menos haciéndolo por código, y eso que hablo de setear tres variables, ni te cuento si tengo que reajustar los valores de 8 botones porque he metido otro en medio.
Y en Unity también me las he tenido. Escribo código en el método START y Unity pasa de mi olímpicamente. Una hora después me acuerdo que en el inspector gráfico he seteado esos valores manualmente y sobreescriben los que he puesto en el código. Las prioridades entre el editor gráfico y el de código me dan pesadillas.
No sé, si estoy usando teclado, prefiero no tener que tocar el ratón, y si tengo que usar el ratón, prefiero usar el teclado para los atajos con la mano izquierda, y punto.

Pero es mi opinión, claro. Si necesito hacer algo visual con Bennu, me programo una utilidad y me pongo con ello: el editor de tiles, el proyecto Montezuma, el "cambiacolor"... y aun tengo pendiente una interfaz gráfica para Venturer.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

l1nk3rn3l

#31
Quote from: SplinterGU on June 30, 2017, 08:51:22 PM
habia leido un mensaje de l1nk3rn3l y ya no lo veo...

por otro lado, vi Blocky de google, y podria ser bastante simple meter BennuGD como lenguaje, aunque asi rapido no veo el concepto de objeto/entidad/personaje/proceso que si veo en scratch...


Si borre el mensaje .. Maestro..   ;D

Bueno , Blocky es facil porque es sobre JS y no sobre Flash que ya no es soportado en navegadores..
pesa como 150k o menos
https://developers.google.com/blockly/

la idea que se habia planteado..

que el editor IDE corriendo sobre nwjs (multiplataforma) tenga dos opciones
+se pueda escoger al inicio que tipo de proyecto bennu deseas (al estilo de unreal con blueprints)
1. proyecto prg programacion normal
2. programacion grafica con blocky o similares

en el caso de programacion gráfica se podria usar un planteamiento dirigido a objetos

1. como construct lo hace
https://editor.construct.net/

Es pasar los datos de los objetos escalados, angulo y demas a bennu ...  usando esta libreria para el layout de dibujo
http://fabricjs.com/demos/ 
para el editor de texto
https://ace.c9.io/
y blocky para el codigo GUI

2. hablando de la parte (grafica) la segunda alternativa seria hacer algo simple
el proceso main en blocky estaria en un tab, y los procesos en otro tab


asi como scratch ambas alternativas dejarian escoger las funciones que queremos
pasar a blocky (dibujo, sonido, red , etc)

la primera alternativa es mas bonita pero seria mas demorada para los involucrados
la segunda seria mas facil ya que blocky permite pasar codigo directamente a bennu
segun vi en los ejemplos (pasa a c++, js, etc) adecuarlo a bennu seria facil

combinando todo esto con nwjs
https://nwjs.io/downloads/

tendriamos editor para (mac, linux ,windows)


y una sugerencia .... dejar  el codigo ppal en C como esta
pero el de producción tenerlo en javascript(js) , de eso nos estamos encargando de portarlo (ya casi).
trabajar todo en Js, es mas fácil portarlo y trabajar en otras plataformas

me refiero  a usar c/c++ en:
+ compilación y dependencia de equipos en el caso de MAC e IOS requieres tener mac
   (phonegap y ludei te permiten compilar gratis, desde su pagina nada de instalaciones como el intel xdk)
+ red online y monetizacion es un dolor de cabeza en cada plataforma
+ control de hardware (acelerometro, giroscopio,etc)
+ makefiles y demas en cada S.O. ademas de dependencia de librerias en linux.
+ entre otras

el santo grial de las plataformas, hardware y monetizacion se llama Cordova(es una libreria de JS)
es lo que usa construct para facilitar la distribucion de los juegos a android/ios

Algunos diran pero Javascript no es lento?  si estamos hablando de hace unos años si..
pero si pasamos bennu a webassembly no... es casi lo mismo..


Pienso que agregarle plugins de parte del usuario final seria mas facil desde JS

SplinterGU

yo lo veo simplemente como un editor, que genere codigo bennugd, luego llame a bennud para compilar y ejecutar
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

l1nk3rn3l


hokuto40

#34
Gracias por vuestras respuestas,me alegro que lo que he comentado alla generado tanto interes,Por cierto echadle un vistazo a pilas bloques,utiliza el mismo lenguaje y creo que esta usando nwjs,tambien echadle un vistazo a stencyl que es un motor completo y utiliza el mismo lenguaje,me gusta mucho stencyl pero si es cierto que no lo he utilizado mucho por que es muy lento al compilar.

Respondiendo a drumpi,yo estoy de acuerdo contigo,hay veces que muchas cosas se hacen mas rapido con el lenguaje escrito,pero yo lo comentaba como segundo lenguaje para que cada persona elija el que mas le guste o mas comodo se sienta y con eso mucha gente se acercaria a bennugd.

Yo he hablado de bennugd a mucha gente y siempre me dicen lo mismo,si bennugd tuviera un lenguaje visual pues seria otra cosa y dejaria contruct.

Tambien queria comentar que yo empece con gamemaker con su lenguaje visual y luego usaba codigo y lenguaje visual,hasta que di el salto al codigo.Gracias al lenguaje visual de gamemaker y de contruct he podido entender muchas cosa que con el codigo no entendia y ahora que con esa esperiencia puedo hacerlo en el codigo.

La verdad es lo visual ayuda mucha a entender muchas cosas y luego das el salto al codigo mucho mejor.Hay una cosa que me gusta mucho del nuevo gamemaker y es que puedes convertir el codigo visual a codigo escrito y eso es una manera escelente para aprender,por cierto tambien hay uno que se llama pencilcode que esta creado por google y es tambien de bloques y te deja elegir programar en visual o en codigo y lo mas chulo es que te da la opcion de traducir el codigo a visual y viceversa,eso para aprender es la bomba.

Lo ultimo decir que lo bueno de lo visual es que ya viene con los parametros impresos y eso es una ayuda fantastica y no hay que estar todo el rato con la wiki y tampoco hay errores de sintaxis,ademas como ya he dicho si utilizas lo visual y luego lo traduces a codigo es lo mejor para aprender,y luego ir pasando poco a poco al codigo de manera definitiva.Que opinais sobre esto que comento.Espero vuestras respuestas.

Bueno me despido y antes de que se me olvide decir a drumpi que me dijistes que te recordara lo del codigo del menu del juego de naves,para ver como estaba echo y ver lo de descargar recursos.Hasta pronto :) :D

Drumpi

Vas a tener que ser un poco más específico, orque tengo en la cabeza demasiados códigos para acordarme de algo que te dije hace un par de semanas. Y recuérdamelo en fin de semana, porque es más fácil que tenga tiempo para ponerme con Bennu ^^U
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Ulthar Kaufman

Hola gente, ya tengo vacaciones y estoy poniéndome al día en el foro.

Lo de programación visual lo he tenido que usar alguna vez con el MIT APPInventor para hacer alguna app de forma urgente. Mola porque es muy sencillo y en 30 min tienes algo que con android studio me costaría dos semanas (java y yo no nos llevamos bien), pero cuando intentas hacer algo más avanzado lo que antes eran ventajas se convierten en serias limitaciones, no puedes moverte cómodamente por códigos largos, no puedes buscar, no puedes cambiar código fácilmente...

Creo que casi todos usamos Notepad++ para programar, creo que es un editor extraordinario y tal vez se podría intentar personalizarlo más y adaptarlo a Bennu. Tengo que ponerme al día con los bennupacks, pixstudio y demás y ver cómo han evolucionado.

Saludos a todos!

hokuto40

Hola,queria decirte drumpi que lo del codigo esta en la pagina 2 de este mismo tema y es un archivo con el menu de inicio,pusistes un archivo con extension .inc y no se que hacer con eso y tambien medijistes que lo habias sacado de space52.
Por cierto drumpi no puedo decirte nada en fin de semana porque no tengo internet en casa,yo me conecto desde una biblioteca.

Con respecto a ulthar te doy toda la razon, al principio es facil hacer cosas con lo visual pero cuando intentas hacer algo avanzado se complica mucho la cosa,pero creo que para una persona que empieza es perfecto porque al `principio es sencillo y te anima a continuar y cuando ya te manejas bien con lo visual pues te pasas al codigo sin traumas.

Ademas que hay gente que prefiere lo visual,ya es cuestion de gustos,ademas al principio te ayuda mucho porque no ha errores de sintaxis y los parametros ya estan puestos visualmente y solo tienes que completar.

Y con respecto a lo del notepad++,es un buen editor pero hay que personalizarlo mas y hacerlo mas completo.
Yo personalmente me gusta mas eclipse.

Bueno lo ultimo que queria comentar es que sigo con mi juego de naves,aunque no se muy bien como avanzar,os voy a pasar un video de youtube que enseña la clase de juego que quiero hacer y agradeceria que le hecharais un vistazo y me deis algunos consejos para hacer este tipo de juego
https://www.youtube.com/watch?v=LhzlUter3j0

Ulthar Kaufman

Los scrolls de naves son lo mejor para empezar y entender los conceptos básicos, creo que casi todos hemos hecho alguno. Cualquier duda que tengas aquí estamos.

¿Cómo piensas hacer los gráficos? Te lo digo porque yo cuando hice el mío usé una herramienta japonesa que se llamaba DOGA, es una especie de prefav de objetos 3D y es muy fácil ensamblar piezas y hacer naves, luego haces una captura desde la perspectiva que quieras y ya tienes una nave 3D resultona en muy poco tiempo y sin meterse con autocads o blenders.

Hace muchos años de eso pero hace poco vi que seguía vivo. La versión 1 es gratuita.

hokuto40

Hola kaufman,la verdad es que el juego que estoy intentando hacer quiero que se parezca como el del video que se llama blue wish resurrection plus y lo curioso es que los graficos estan diseñados con la herramienta doga que tu mencionas, la he ojeado pero al estar en japones no me aclaro,si conoces algun tutorial que este en español dime donde puedo conseguirlo.

Te agradeceria que me dieras algunos consejos y si tienes algun juego de nave que sea simple de codigo te agradeceria que me lo dejaras para ver el codigo y orientarme un poco,aunque ya te digo que si el codigo es muy largo yo me pierdo,soy bastante nuevo con bennugd y todavia voy dandome golpes.

Con lo que no me aclaro bien todavia es con la descarga de recursos.Bueno me despido y Hasta pronto

Drumpi

Mi primer consejo es que te busques un juego más fácil de hacer :D
Aunque un "bullet hell" es simplemente un juego de navecitas con el doble de disparos, son muchos procesos a controlar en tu primer juego. Yo empezaría con otros del mismo género más sencillos, y según adquieras experiencia, ir añadiendo más procesos.
Pero vamos, si insistes en ello, La Momia Que Fuma es un experto en el tema y te podrá aconsejar mejor que yo :D

El fichero .inc que te puse es el código que controla el flujo del juego (el que hace que se ejecute el nivel y te dice qué hacer al acabarlo), y el proceso que jecuta el nivel. Le he puesto extensión .inc como le podría haber puesto .txt o .prg, lo puedes abrir con cualquier editor de código.
Lo llamo .inc porque Bennu tiene una "función" llamada "include" que te permite coger otro fichero y "pegar" el código que contiene en esa posición. Es como el "using" de C#/VB, el import o include de otros lenguajes )lo siento, tengo ahora mismo un batiburrillo de lenguajes en la cabeza que no me aclaro ^^U). Así separo el código en trozos y es más fácil de leer, programar e incluso reutilizar en otros proyectos.

La idea es que te lo leas y preguntes lo que no entiendas, pero tiene muchos comentarios, y los nombres de los procesos y funciones creo que son autoexplicativos. Tómate tu tiempo porque sé que es dificil leer código ajeno, y más en un lenguaje que es nuevo para ti.

De paso, en el Play_level puedes ver cómo se cargan y descargan los recursos, aunque ahí he usado algo de programación de nivel intermedio al crearme mi propio tipo de datos (prota_data, considéralo como una struct).

En fin, ve poco a poco, no quieras correr. Al principio te va a tocar leer muchísimo y escribir poco código y muy simple, pero por ahí se empieza.

Por cierto, fíjate cómo será que la gran mayoría de programadores que conozco piensan que Eclipse es de los peores editores de código que existen: es lento, pesado, y falla demasiado cuando te sales del entorno Java. Podría decir incluso lo mismo de Visual Studio, pero actualmente me está viniendo muy bien para hacer debug en el trabajo, y no me quejo (eso sí, allí gastamos unas máquinas gordas tipo servidor, así que el rendimiento no es un problema... la mayoría del tiempo :D).
Pero eso va en gustos, como los lenguajes :D
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

hokuto40

Hola drumpi gracias por tus respuestas como siempre eres muy amable,me lo tomare con calma aunque la pasiencia no es mi fuerte,con respecto a eclipse,me equivoque quise decir liclipse que es el que uso para trabajar con python que es el unico lenguaje con el que medio me defiendo.

Y bueno solo decir que hago una llamada a la momia para que me de unos consejos para hacer juegos de naves,o que me pase algun codigo cortito para coger ideas con recpecto a los juegos de naves.Hasta pronto :D