Ayuda > Preguntas y respuestas

Como hacer un scroll automatico tipo de algunos juegos de naves

<< < (6/8) > >>

MaanuRP:
Empiezo por la respuesta de: SobacoEnLlamas. Que es mas corta, solo por eso ^^

--- Cita de: SobacoEnLlamas en Junio 13, 2012, 11:45:12 am ---
--- Cita de: MaanuRP en Junio 13, 2012, 01:54:38 am --- A ver, que en dos post estemos discutiendo, no nos hace enemigos,

--- Fin de la cita ---
Me dio esa sensación que estabas mezclando conceptos que no tienen nada que ver, disculpa mi mal entendido, yo no mezclo nada ok? ;) solo pensé que tú ya estabas picado de otro lado y eso me fastidió mucho, pero si no es así, todo bien ;)

--- Fin de la cita ---
Para nada! Vuelvo a decir algo que dije varias veces, no es la primera vez que me dicen que sueno agresivo, enojado, o algo similiar escribiendo. Pero si estariamos hablando te darias cuenta que es todo lo contrario!
Obviamente que no es lindo discutir, pero me gusta esto de poder compartir ideas con gente que realmente sabe, y que me pude aportar muchos datos.
Creo que ya lo dije muchas veces, pero no hay nada mejor que aceptar los errores, pido perdon si alguno se sintio ofendido o atacado por mi, esa NUNCA fue la intencion!


Ahora si, FrogGer.


--- Citar ---Ok, no habia revisado si habias actualizado tu respuesta. Eso responde varias cosas.
--- Fin de la cita ---
No hay problema


--- Citar --- Primero, no te prejuzgo en tu personalidad, simplemente confirmo lo que tu mismo dijiste:

--- Citar ---Insisto en que no puedo creer que digan que es mejor hacer prueba y error que hacer las cosas logicamente. Eso es algo que nunca voy a poder entender, para mi lo que no es logico, no merece ni ser evaluado, soy demasiado del lado izquierdo del cerebro jajajaj.
--- Fin de la cita ---
  Lado izquierdo del cerebro, personas mas lógicas que emocionales, prefieren la estabilidad y tienen resistencia al cambio. Son personas les cuesta ver puntos distintos de opinion y se mantienen casi siempre en la suya. Si, a mi tambien me enseñaron un poco se psicologia y si, tambien soy lado izquierdo del cerebro. Solo me limite a resumir lo que conozco.
--- Fin de la cita ---

Sacando excepciones, todos los que nos dedicamos al maravilloso mundo de la programacion tendemos muchisimo mas al lado izquierdo.
Y por esos datos que diste, nos damos cuenta de como reacciones frente a muchas situaciones, como una discusion.
Pero no alargo mas esta contestacion porque es desviar el tema y seria malo!
(Lo que no quiere decir que no lo podamos hablar, me encantaria seguir hablando de otros temas, por mp, msn, chat, lo que quieran, me gustan las conversaciones en las que se intercambias ideas y opiniones, siempre y cuando sean bien hechas y con todo respeto!)
 

--- Citar ---
--- Citar --- Cuando hable de cantidad de lineas de codigo? Hable de condiciones, de lo fluido del codigo (Que seria basicamente lo mismo) y de la cantidad de funciones, no de lineas!
--- Fin de la cita ---
Tienes razón, lei mal. Aun asi no puedo responderte porque no se a que te refieres con condiciones (if, else ?).
--- Fin de la cita ---
Exacto, te lo podria comparar con la programacion en PIC, en el que al agregar condiciones (ifs, por ejemplo) estas gastanto un "step" de trabajo, y tambien un lugar de memoria.
Hoy mismo tuve un problema con eso, en la escuela estoy en un proyecto de diseño de una IA en C++ de robot de futbol, y al tener que ser todo solo por ifs, daba muchisimo retardo en los movimientos. (Muchisimo relativamente, obviamente que alguien que no entienda mucho, es dificil que se de cuenta).


--- Citar ---
--- Citar ---Tu prefieres que un juego baje de FPS a que tarde mas en cargar al principio? Yo prefiero esperar 1 minuto mas en la pantalla de cargado, pero que mi juego responda con los FPS que debe.
Si creo tantas instancias seguidas que el juego se vaya trabando por la cantidad de repeticiones del instance_create y no por como son las instancias. No te va a quedar otra que crearlas desde antes y esperar un poco mas en la pantalla de carga.
--- Fin de la cita ---
Por el contrario, prefiero más FPS. El asunto es que con el metodo tradicional (el tuyo) bajan considerablemente mas los FPS. Imaginate una escena gigante, con 15000 pixeles de largo, con 150 enemigos ya cargados en el room, ocupando cada uno de ellos ram, video y cpu por el solo hecho de estar ya inicializados. Ahora compara con el otro metodo: una pantalla de 400 pixeles de ancho, con no mas de 15 enemigos creados e inicializados a la vez... de verdad crees que tu forma tendrá mas FPS?
  Ahora bien: Tus lineas de codigo seran por ejemplo 100, las mias seran 1000, pero que es mas pesado: Procesamiento de lineas de codigo o carga de objetos graficos en memoria? Y son 1000 lineas de solo inicializacion, nada de fors o bucles infinitos. recuerda que en mi metodo solo habran 15 objetos al mismo tiempo y no 150.
--- Fin de la cita ---

Esto me gustaria hacer una prueba. Ya que yo pierdo tiempo a la hora de crear el room, pero se supone que eso lo gano en optimizacion, ya que al desactivar todas las instancias (Por mas que no se libere toda la memoria, solo minimas cosas quedan guardadas, lo que tambien me da mas velocidad para hacer que sus eventos "resurjan) es casi lo mismo que no tenerlas. Seamos realistas, si la funcion de desactivar no funcionaria para optimizacion, para que se creo?


--- Citar ---
--- Citar ---Como arreglas bugs de colisiones y esas cosas si no tienes del todo claro el tema? Vas y haces prueba y error obviamente! Pero no lo solucionas asi, vas pensando que pasa y porque pasa para arreglarlo. Y eso esta perfecto!
--- Fin de la cita ---
  Porque no lo he de tener claro? Si tecnicamente es lo mismo poner manualmente los objetos en el room a crearlos en secuencia. Imaginate esos pianos antiguos que les ponias una secuencia de pasos y ellos te tocaban la melodia, ya estaba diseñada la cancion, solo que se escribia por partes y con anticipacion. 
--- Fin de la cita ---
Aca tuvimos un mal entendido! No me referia a vos cuando decia "si no tienes del todo claro el tema", me referia a cual persona que vaya a programar.
Ademas que esto era solo un ejemplo, la conclusion estaba en el siguiente.
Ya que este ejemplo te daba la razon, en estos casos no te queda otra que hacer prueba y error a menos que seas todo un crack y sepas como se va a comportar cada cosa en cada colision.


--- Citar ---
--- Citar ---Pero otra muy distintas es decir: Bueno, MAS O MENOS a x steps va a aparecer el boss, lo pongo ahi y veo que pasa, de ultima lo corro un poco mas y listo. Que me parece muy poco profesional. Y por mas que ahora estemos haciendo esto por hobby, no debemos agarrar malas costumbres.
--- Fin de la cita ---
   Es que volvemos a lo mismo otra vez, si es mas complejo el codigo, si se requiere mas prueba y error, si se requiere mas tiempo gastado, si se pierde mas tiempo puliendo el juego, pero se gana en optimizacion de recursos, esa es su ventaja y su compensacion. Porque recalco una y otra vez esto, porque es una justificación de porque programar así, porque es una opcion valida y no una tonteria como le dijiste a Sobaco.
--- Fin de la cita ---
Que un codigo sea mas complijo no quiere decir que va a ser mas optimo.
Ademas que al complejizar todo, estas mas propenso a bugs.
Estas seguro que dije que era una tonteria? Porque la verdad que yo no me acuerdo, si fue asi, pido que me lo citen para recordarlo porque sinceramente no me acuerdo!
Como dije anteriormente, quizas me exprese mal al decir que estaba mal, ya que eso es muy amplio, cuando yo solo me queria referir a bugs y esas cosas (Que ya no me acuerdo cuales mas nombre, para ser franco).


--- Citar --- Para terminar, porque ya me voy a comer:

--- Citar ---Siempre hay que buscar lo que menos bugs de y lo mas exacto posible.
--- Fin de la cita ---
No, siempre hay que entregar algo que NO tenga bugs y sea lo mas exacto posible. El camino que uses para llegar es decision tuya.
--- Fin de la cita ---
En esto tambien nos desentendimos. Cuando dije: "lo que menos bugs de", me referia al metodo o a la manera de programar.
Obviamente que si hablamos de un proyecto a entregar tenemos que dar algo que no tenga bugs.
No siempre es asi, no siempre te dejan usar el metodo que tu uses, lo digo porque ya tuve experiencias. Si vas a trabajar con un grupo, vas a tener que programar de cierta manera que concuerde con las otras personas. Por ejemplo, si a ti te dan la parte de diseño de la interfaz, a tu compañero de comunicacion. Entre esos dos diseños la comunicacion debe ser perfecta, por lo que cosas como variables y demas, deben quedar en comun.
Pero si hablamos de cosas independientes, si, puedes entregarlo de la manera que tu quieras mientras cumplas las reglas y tiempos.


--- Citar --- Actualizacion:

--- Citar ---Si en el create del jugador le pones un timeline que cree navecitas, quizas no te importa mucho si es exacto o no, pero cosas como el Boss, que muchas veces tiene que estar en un lugar exacto para que su IA funcione como tu quieres, no puedes darte el lujo de probar si eso de bug o no. Seria mucho mejor ponerlo cuando lo necesitas y en la posicion que lo necesitas. No por un timeline.
--- Fin de la cita ---
  Creo que ya voy entendiendo porque es tan dificil que comprendas este metodo. No todo se crea y se ordena con timelines o alarmas, o sea, yo no programo algo asi:

step 1: Jefe, muevete hacia arriba
step 5: Jefe, detente.
step 15: Jefe, dispara una bola de energia
step 20: Bola de energia, muevete hacia el prota.

Para nada, los objetos ya estan programados de la misma manera que tu harias el tuyo. El jefe tiene sus eventos, alarmas y comportamiento ya deficnido anteriormente por ti. La unica diferencia es que en vez de colocarlo comodamente en el room desde antes, esperando 10 minutos a que la nave llegue donde el para que empiece a moverse, yo mediante una timeline lo creo en un step indicado y listo. Luego el se mueve y comporta de manera propia. Las timelines solo crean objetos, nada mas. No manejan comportamiento.
   Ya entiendo porque te parecia tan ineficiente.
--- Fin de la cita ---

Nono, esto ya lo habia entendido. A lo que yo me refiero con que es inexacto, es que hay demasiadas cosas que interactuan en un juego para que los enemigos se creen asi.
Por ejemplo, como vas a poder crear un minimapa si creas las instancias de la nada? A menos que las crees fuera de la view, y ahi estariamos haciendo mas o menos lo mismo que yo.

PD: Pido disculpas por la tardanza de la respuesta! Ya explique porque fue, espero que me sepan entender!

FrogGer:

--- Citar ---(Lo que no quiere decir que no lo podamos hablar, me encantaria seguir hablando de otros temas, por mp, msn, chat, lo que quieran, me gustan las conversaciones en las que se intercambias ideas y opiniones, siempre y cuando sean bien hechas y con todo respeto!)
--- Fin de la cita ---
Agregame al Feisbuk y listo :)


--- Citar ---Exacto, te lo podria comparar con la programacion en PIC, en el que al agregar condiciones (ifs, por ejemplo) estas gastanto un "step" de trabajo, y tambien un lugar de memoria.
Hoy mismo tuve un problema con eso, en la escuela estoy en un proyecto de diseño de una IA en C++ de robot de futbol, y al tener que ser todo solo por ifs, daba muchisimo retardo en los movimientos. (Muchisimo relativamente, obviamente que alguien que no entienda mucho, es dificil que se de cuenta).
--- Fin de la cita ---
  Lo que sucede es que aqui entramos al tema de complejidad en los algoritmos. Tienes razón, una sentencia o condicion gasta cpu (memoria no lo creo, porque solo es una evaluacion) pero tiene solo un gasto de 1. Al contrario de instanciar un objeto, ya que este reserva memoria ram, gasta video y ademas cpu. Porque es mas optimo 1000 condiciones o 200 instancias creadas? te respondo en la siguiente respuesta.

Te dejo un link para que revises el tema de complejidad en los algoritmos. No se si te lo han pasado aun (es muy aburrida xD)
http://www.lab.dit.upm.es/~lprg/material/apuntes/o/index.html


--- Citar ---Esto me gustaria hacer una prueba. Ya que yo pierdo tiempo a la hora de crear el room, pero se supone que eso lo gano en optimizacion, ya que al desactivar todas las instancias (Por mas que no se libere toda la memoria, solo minimas cosas quedan guardadas, lo que tambien me da mas velocidad para hacer que sus eventos "resurjan) es casi lo mismo que no tenerlas. Seamos realistas, si la funcion de desactivar no funcionaria para optimizacion, para que se creo?
--- Fin de la cita ---
Ok, pero 2 cosas:

1.- Cuando creas instancias reservas memoria, video, etc. todo lo que te he comentado antes. Si las desactivas siguen usando su porcion reservada, solo que sus eventos no se ejecutan, por lo tanto lo unico que te ahorras al desactivar una instancia es CPU.
2.- Una instancia desactivada no puede activarse sola. Tendras que tener un objeto con un step continuo (ya el evento step es doloroso) que vigile TODAS las instancias y si alguna entra en la view debe activarla. Eso no es algo liviano de mover, vulevo al ejemplo de las 150 naves ya creadas en el room, se deben evaluar por cada step del juego 150 objetos al mismo tiempo. Eso me parece sumamente costoso. En mi metodo, como las voy creando y estan van desapareciendo del juego progresivamente, siempre habran pocas instancias al mismo tiempo (15-20) que es mucho mas liviano en terminos generales, independiente de que estas gasten un poquitin mas de cpu al ser inicializadas. Ese cpu que yo gasto en crearlas tu lo gastan en la "vigilancia" continua que debes de hacer para activar y desactivar instancias.

 
--- Citar ---Si vas a trabajar con un grupo, vas a tener que programar de cierta manera que concuerde con las otras personas.
--- Fin de la cita ---
Eso ya es otra cosa, obviamente uno debe moldearse a como trabaje tu equipo, 100% de acuerdo. Pero... y si tu equipo trabaja de mi forma? o de otra diferente a las 2 que discutimos aca? Aca ya es apartarse del tema porque influyen muchas variables ajenas.


--- Citar ---Pero si hablamos de cosas independientes, si, puedes entregarlo de la manera que tu quieras mientras cumplas las reglas y tiempos.
--- Fin de la cita ---

  Tu mismo lo dices, si lo estas haciendo solo es una opción valida.


--- Citar ---Nono, esto ya lo habia entendido. A lo que yo me refiero con que es inexacto, es que hay demasiadas cosas que interactuan en un juego para que los enemigos se creen asi.
Por ejemplo, como vas a poder crear un minimapa si creas las instancias de la nada? A menos que las crees fuera de la view, y ahi estariamos haciendo mas o menos lo mismo que yo.
--- Fin de la cita ---
Claro que las cosas las creas fuera de la view, o sino se veria horrible la generacion espontanea de enemigos XD Ahora tu preguntas por los minimapas, yo no he visto ningun juego de naves que tenga un minimapa. Quizas no entiendo bien este punto asi que no puedo responderte mas hasta que me lo aclares.

 Por ultimo, te dejo un editable de ejemplo que hice muuuuuuuchos años atras (por alla por el 2005) del metodo que te digo. Comprenderas que es muy mejorable y es un caos de programacion, pero en ese tiempo no tenia los conocimientos de hoy. Imaginate que esta hasta en drag and drop XD Pero bueno, es una forma de mostrar que la cosa no es tan compleja como parece. Solo fijate en los timelines que agrege y entenderas la forma de usar este metodo.
  El editable lo modifique un poco porque era un juego online, asi que tiene muchas cosas demas para conexion  y eso.


MaanuRP:

--- Citar ---
--- Citar ---Exacto, te lo podria comparar con la programacion en PIC, en el que al agregar condiciones (ifs, por ejemplo) estas gastanto un "step" de trabajo, y tambien un lugar de memoria.
Hoy mismo tuve un problema con eso, en la escuela estoy en un proyecto de diseño de una IA en C++ de robot de futbol, y al tener que ser todo solo por ifs, daba muchisimo retardo en los movimientos. (Muchisimo relativamente, obviamente que alguien que no entienda mucho, es dificil que se de cuenta).
--- Fin de la cita ---
  Lo que sucede es que aqui entramos al tema de complejidad en los algoritmos. Tienes razón, una sentencia o condicion gasta cpu (memoria no lo creo, porque solo es una evaluacion) pero tiene solo un gasto de 1. Al contrario de instanciar un objeto, ya que este reserva memoria ram, gasta video y ademas cpu. Porque es mas optimo 1000 condiciones o 200 instancias creadas? te respondo en la siguiente respuesta.

Te dejo un link para que revises el tema de complejidad en los algoritmos. No se si te lo han pasado aun (es muy aburrida xD)
http://www.lab.dit.upm.es/~lprg/material/apuntes/o/index.html
--- Fin de la cita ---

Ahora mismo lo voy a leer, por lo menos de a poco xD


--- Citar ---
--- Citar ---Esto me gustaria hacer una prueba. Ya que yo pierdo tiempo a la hora de crear el room, pero se supone que eso lo gano en optimizacion, ya que al desactivar todas las instancias (Por mas que no se libere toda la memoria, solo minimas cosas quedan guardadas, lo que tambien me da mas velocidad para hacer que sus eventos "resurjan) es casi lo mismo que no tenerlas. Seamos realistas, si la funcion de desactivar no funcionaria para optimizacion, para que se creo?
--- Fin de la cita ---
Ok, pero 2 cosas:

1.- Cuando creas instancias reservas memoria, video, etc. todo lo que te he comentado antes. Si las desactivas siguen usando su porcion reservada, solo que sus eventos no se ejecutan, por lo tanto lo unico que te ahorras al desactivar una instancia es CPU.
2.- Una instancia desactivada no puede activarse sola. Tendras que tener un objeto con un step continuo (ya el evento step es doloroso) que vigile TODAS las instancias y si alguna entra en la view debe activarla. Eso no es algo liviano de mover, vulevo al ejemplo de las 150 naves ya creadas en el room, se deben evaluar por cada step del juego 150 objetos al mismo tiempo. Eso me parece sumamente costoso. En mi metodo, como las voy creando y estan van desapareciendo del juego progresivamente, siempre habran pocas instancias al mismo tiempo (15-20) que es mucho mas liviano en terminos generales, independiente de que estas gasten un poquitin mas de cpu al ser inicializadas. Ese cpu que yo gasto en crearlas tu lo gastan en la "vigilancia" continua que debes de hacer para activar y desactivar instancias.
--- Fin de la cita ---

La forma de que las instancias de fuera de la view se desactiven es la siguiente:

[gml]
{
instance_activate_all();
instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true);
}

Para no tener que estar revisando instancia por instancia, activa todo, pero para que no gasten recursos, al instante desactiva las que estan fuera, con solo revisar su x e y es suficiente.

Insisto en que esta en el manual, por lo que no debe ser por capricho.

Lo que queda guardado de estas son en donde estan creadas, solo gastaria memoria, y cuanta? Quizas en infima y no justifica no hacerlo, quizas es demasiada y si justifica no hacerlo de este metodo.
Como ya te dije, me gustaria hacer pruebas sobre esto, ya que para hablar de optimizacion, no estoy de lo mas seguro de mis conocimientos ya que nunca pude hacer pruebas concretas, por eso nunca quise meter en discusion esto.


--- Citar ---
--- Citar ---Si vas a trabajar con un grupo, vas a tener que programar de cierta manera que concuerde con las otras personas.
--- Fin de la cita ---
Eso ya es otra cosa, obviamente uno debe moldearse a como trabaje tu equipo, 100% de acuerdo. Pero... y si tu equipo trabaja de mi forma? o de otra diferente a las 2 que discutimos aca? Aca ya es apartarse del tema porque influyen muchas variables ajenas.
--- Fin de la cita ---
Esta bien, pero como tu dijiste que el proyecto lo entregabas como vos querias, y te queria hacer acordar que no siempre vamos a tener la suerte (o la no suerte, depende de quien sea) de trabajar solo y poder hacer las cosas como nos gusta.


--- Citar ---
--- Citar ---Pero si hablamos de cosas independientes, si, puedes entregarlo de la manera que tu quieras mientras cumplas las reglas y tiempos.
--- Fin de la cita ---

  Tu mismo lo dices, si lo estas haciendo solo es una opción valida.
--- Fin de la cita ---
A esto venia lo de prueba y error. Recuerdas que te hable de la IA de robots de futbol? Nosotros lo estamos haciendo casi puramente a prueba y error, tardaria un rato en explicarte porque, y no creo que sea importante. Pero te puedo asegurar que el tiempo que perdemos es importantisimo y muy grande, solo por no poder pensar logicamente las cosas y hacer todo como nos guste exactamente al mismo tiempo y luego probarlo.


--- Citar ---
--- Citar ---Nono, esto ya lo habia entendido. A lo que yo me refiero con que es inexacto, es que hay demasiadas cosas que interactuan en un juego para que los enemigos se creen asi.
Por ejemplo, como vas a poder crear un minimapa si creas las instancias de la nada? A menos que las crees fuera de la view, y ahi estariamos haciendo mas o menos lo mismo que yo.
--- Fin de la cita ---
Claro que las cosas las creas fuera de la view, o sino se veria horrible la generacion espontanea de enemigos XD Ahora tu preguntas por los minimapas, yo no he visto ningun juego de naves que tenga un minimapa. Quizas no entiendo bien este punto asi que no puedo responderte mas hasta que me lo aclares.

 Por ultimo, te dejo un editable de ejemplo que hice muuuuuuuchos años atras (por alla por el 2005) del metodo que te digo. Comprenderas que es muy mejorable y es un caos de programacion, pero en ese tiempo no tenia los conocimientos de hoy. Imaginate que esta hasta en drag and drop XD Pero bueno, es una forma de mostrar que la cosa no es tan compleja como parece. Solo fijate en los timelines que agrege y entenderas la forma de usar este metodo.
  El editable lo modifique un poco porque era un juego online, asi que tiene muchas cosas demas para conexion  y eso.
--- Fin de la cita ---

Admito que te quedo muy bien, y que me gusta como te las arreglaste para esto, felicitaciones por ese trabajo.
Pero te pusiste a pensar que si quieres hacer alguna modificacion minima en el room, o algo asi vas a tener que cambiar CADA step y CADA funcion?
Seria un total desastre y, ademas de llevarte muchisimo tiempo, quizas ni siquiera quede bien.

Texic:

--- Citar ---Admito que te quedo muy bien, y que me gusta como te las arreglaste para esto, felicitaciones por ese trabajo.
Pero te pusiste a pensar que si quieres hacer alguna modificacion minima en el room, o algo asi vas a tener que cambiar CADA step y CADA funcion?
Seria un total desastre y, ademas de llevarte muchisimo tiempo, quizas ni siquiera quede bien
--- Fin de la cita ---
Hay una función en las timelines llamada shift que hace ese trabajo

MaanuRP:

--- Cita de: Texic en Junio 14, 2012, 04:36:56 am ---
--- Citar ---Admito que te quedo muy bien, y que me gusta como te las arreglaste para esto, felicitaciones por ese trabajo.
Pero te pusiste a pensar que si quieres hacer alguna modificacion minima en el room, o algo asi vas a tener que cambiar CADA step y CADA funcion?
Seria un total desastre y, ademas de llevarte muchisimo tiempo, quizas ni siquiera quede bien
--- Fin de la cita ---
Hay una función en las timelines llamada shift que hace ese trabajo

--- Fin de la cita ---

Ahi modificarias solo los steps y cada vez lo estas dejando menos exacto. Cuando nombre cambios en el room, me referia a por ejemplo, un cambio de tamaño. Deberias crear una variable global de referencia, pero que igualmente vas a tener que ir cambiando todos los argumentos.

Asi se entendio mejor?

Navegación

[0] Índice de Mensajes

[#] Página Siguiente

[*] Página Anterior

Ir a la versión completa