Comunidad Game Maker

Bueno, se esta alargando el asunto.

CitarEs obvio que el metodo de "prueba y error" no es lo mas eficiente. Piensalo asi: Si yo te pregunto 2 + 2, tu lo vas a razonar y me vas a decir que es 4, no vas a empezar a decir: 1, 2, 3, 4 asi hasta que yo te diga que el 4 esta bien, entiendes? Porque perderias tiempo que con un poco de logica lo haces.

No entendí tu comentario, ademas que prueba y error no es un método. El metodo del cual estamos hablando se podria llamar como "generacion en tiempo de ejecucion" aunque no es la misma cosa.

CitarTu dices que hacer el juego a "prueba y error" es utilizar bien el tiempo? Es mas, cuando usas un alarm, sacando excepciones, es mejor usar "room_speed *" por si cambias la velocidad o simplemente para tener una escala. Y ahi ya seria menos prueba de error. Pero pensar alarmas para crear instancias poniendo solo un numero, a menos que no seas para nada detallista, vas a estar muchas veces probando a ver cuando queda bien.

Tu respuesta no concuerda con la conclusión que yo escribí. Volvemos a lo mismo. Vuelve a leer mi respuesta numero 2.

CitarYo no le llamo habilidad a saber en que step poner un Boss, le llamo poco ingenio. Es mas, aseguro que podemos encontrar formas mucho mas logicas y exactas que poner numeros en un timeline, usando este metodo.
No siempre depende de la habilidad del programador, si las cosas no son ni logicas ni exactas, te puede quedar bien por suerte, no por habilidad. Para mi la programacion en PC es pura logica, no hay factores externos que lo puedan modificar (Sacando los bugs del programa que eso es otro tema me parece).
Por darte un ejemplo, a la hora de programar un PIC, hay otros factores que van a hacer que tu programa ande o no, ahi puede que uses toda tu logica y este todo bien, pero hay cosas que no van a tener logica porque son factores externos.

Vuelves a descontextualizar mi respuesta. Dijiste que no era posible hacer un boss de esta forma, yo te respondo que si se puede. Cuando me refiero a la habilidad como programador no lo digo por el boss, sino en la cantidad de pruebas que harás o bugs que encontraras. Obviamente mientras mas domines el lenguaje puedes anticipar muchas mas fallas o reducir el tiempo de programación.

CitarOptmizacion? Cuantas mas condiciones tienes, menos optimo es, cuanto mas fluido es el codigo mejor es. (Hablando de la misma cantidad de funciones).

Aca te equivocas rotundamente. Menor lineas de código no significa mejor optimizacion. Te dare un ejemplo bien basico:

Dime cual de los 2 codigos es mas optimo, y cual tiene mas lineas de codigo. Elije un numero del 1 al 10.
for(i=0; i<10; i++)
{
        if numero == i
               mostrar en pantalla(numero encontrado)
}

O este?

for(i=0; i<10; i++)
{
        if numero == i
        {
               mostrar en pantalla(numero encontrado)
               break;
         }
}

CitarQuizas el room tarde mas en cargar, eso lo admito, pero cuanto? La verdad que no lo se, deberiamos hacer la prueba, pero no creo que sea tanta la diferencia (Dependiendo de las instancias, claro esta).

El tiempo de carga no es tanto problema como el gasto de recursos (ram, CPU, etc). Obviamente crear todas las instancias desde el inicio gastan mas recursos que crearlas progresivamente. No hay vuelta que darle a esto.
   Para terminas, no debes prejuzgar el conocimiento ajeno. Se programar en bastantes lenguajes (por ejemplo C#) y creeme que estudio sobre est tengo bastante, por algo soy Ingeniero informático.

   Insisto, tu principal problema es que estas enfocado en tu solución al asunto, y no logras ver que hay muchas mas formas de programar algo.  Un software que requiera mas prueba y error (que no es un método, es una concecuencia) no significa que sea peor. Significa que esta mas testeado, si lo quieres mirar de esa forma. Si para ti es una perdida de tiempo, pues no lo hagas asi y listo, pero eso no significa que sea peor o una tontería.

CitarVamos a llegar a algo concreto en cuanto a optimizacion? Creo que con un juego asi, y con las maquinas que cada uno debe tener, no se puede generar algo concreto. Por algo yo hable de bugs, exactitud y tiempo de creacion, y no de optimizacion.

Lo que pasa Maanu es que, volviendo al inicio de este debate (que por mi esta bien, aunque dudo que a JEA le guste :)) todo empezo por esto:

Citar¿Quien te dijo que esto es asi? Quizas tu lo hagas asi, y desde ya te digo que esta bastante mal.

El asunto es que no esta mal, es una opcion y la complejidad en programacion se compensa con optimizacion. De ahi el debate mio defendiendo la optimizacion en los juegos.

  Claro, si seguimos asi no terminaremos nunca. Lo ideal es no perder el rumbo de porque se inicio el debate. Creo que ya lo he dejado claro.

Por lo que vi, no entendiste casi ninguna de mis respuestas, y a otras me contestaste lo que quisiste.

Te doy solo un ejemplo para hacerlo rapido, pero la verdad que senti que no me respondiste lo que dije en ninguna de las respuestas (Quizas sentitste lo mismo por mi parte, por lo que pusiste):

Dije: Optmizacion? Cuantas mas condiciones tienes, menos optimo es, cuanto mas fluido es el codigo mejor es. (Hablando de la misma cantidad de funciones).
Dijiste: Aca te equivocas rotundamente. Menor lineas de código no significa mejor optimizacion. Te dare un ejemplo bien basico:

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!

---

Citar
El tiempo de carga no es tanto problema como el gasto de recursos (ram, CPU, etc). Obviamente crear todas las instancias desde el inicio gastan mas recursos que crearlas progresivamente.

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.

Citar
Para terminas, no debes prejuzgar el conocimiento ajeno.

Me gustaria que leas lo que remarque en el comentario anterior, que se ve que no lo leiste.

Citar
Insisto, tu principal problema es que estas enfocado en tu solución al asunto, y no logras ver que hay muchas mas formas de programar algo.

Me parece que en esto tambien te equivocaste, me gustaria que vuelvas a leer el post completo. Fijate que cuando Texic me corrigio, le di la razon y le explique el porque yo lo habia hecho asi, nada mas.
Y me parece que si me dices a mi que prejuzgo el conocimiento, tu estas prejuzgando mi personalidad. Tienes en frente que acepto las correcciones hacia mis soluciones y sigues diciendo eso.

Citar
Un software que requiera mas prueba y error (que no es un método, es una concecuencia) no significa que sea peor. Significa que esta mas testeado, si lo quieres mirar de esa forma. Si para ti es una perdida de tiempo, pues no lo hagas asi y listo, pero eso no significa que sea peor o una tontería.

No le quieres decir metodo a "prueba y error", dile como quieras, a mi me salio expresarlo asi, quizas me equivoque. Aun asi, sigue siendo inexacto e ilogico, y no puedo entender como comparan algo asi con algo pensado y calculado. Y creo que entediste mal cuando le dije "perdida de tiempo", me refiero a que para hacer esto debes estar entrando, jugando, saliendo, y asi sucesivamente hasta que lo que estas modificando quede como te gusta, y se pierde de tiempo.
Te vuelvo a dar el mismo ejemplo de hoy:
2 + 2 = (Lo pienso un poco) y te digo 4
2 + 2 = Te digo 0, espero que me contestes y que me digas que esta mal. Te digo 1, espero, y asi sucesivamente hasta llegar al 4. Cual tiene mas perdida de tiempo?
Si me exprese como si "perdida de tiempo" fuera una tonteria, me exprese mal. Porque como dije, hay bugs que se sacan asi, que no hay otra forma porque la cabeza no nos da la respuesta.

Ademas, una cosa es que lo uses para sacar bugs, otra muy distinta es que lo uses para todo.
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!
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.

---

Citar
El asunto es que no esta mal, es una opcion y la complejidad en programacion se compensa con optimizacion. De ahi el debate mio defendiendo la optimizacion en los juegos.
Claro, si seguimos asi no terminaremos nunca. Lo ideal es no perder el rumbo de porque se inicio el debate. Creo que ya lo he dejado claro.

Nadie hablo de que la complejidad en la programacion es malo, yo hable de que si genera mas bugs va a ser malo. Porque no todos se ponen a arreglar todos sus bugs. Hay juegos hoy en dia que estamos pagando algo de 500ARS y hay bugs que decis: Hasta yo se como arreglarlo, y me parece una verguenza. Por eso creo que hay costumbres que las tenemos que agarrar desde ahora.

Quizas me exprese mal al decir que estaba mal, porque abarca demasiado, como el tema de optimizacion del que hablaste. En cuanto a bugs y exactitud, si que esta mal. Siempre hay que buscar lo que menos bugs de y lo mas exacto posible. En cuanto a optimizacion, deberiamos hacer la prueba con algun computador BASTANTE basico para que nos pueda dar algo concreto, hablando con computadora con i7 (Ojala tuviera eso xD) no creo que podamos llegar a algo verdadero a menos que ustedes hayan hecho pruebas en computadores antiguos (Porque yo no tuve la oportunidad de hacerlo, por eso les digo que no hablaria de temas tan puntuales de optimizacion).

Cita de: MaanuRP en Junio 13, 2012, 05:13:32 AM
Me gustaria remarcar esto, remarcarlo mucho:Como ya dije en un comentario anterior, no se si de este post.
Muchas veces me dicen que parezco enojado o algo por el estilo cuando hablo por chat (En este caso, escribiendo).
Pido disculpas si sono que los trate de alguna manera despectiva, diferente, o no se a que te refieres de como sono, pero les puedo asegurar que es con todo el respeto.
Yo soy de la vieja escuela, cuando entre y vi a los que tenian muchos comentarios, esos me quedaron para siempre como mejores que yo, y a esos hay que respetarlos SIEMPRE jajaj. No menos importante, a los que tienen pocos mensajes o poca participacion, hay que incluirlos bien y no hacerlos menos, siempre y cuando la situacion no lo amerite.

---

Ya habiendo pedido perdon por si se entendio mal, o me exprese mal. Paso a contestarte.

Yo tambien estoy estudiando programacion, en la escuela estoy estudiando: C, C++ y Visual Basic bastante, y otros lenguajes que tenemos algunos datos como para saber, pero nada profundizado. Ademas de otro lenguajes como de programacion de PICs, PLCs, y demas.

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. Eso si puede ser que sean distintos estilos, pero no los comparemos nunca.

Cuando yo pierdo el tiempo en la carga del room, ustedes lo pierden en el medio del juego al irlas creando.
Y comparando que ustedes no tienen las variables de "x" e "y" y las demas cosas que me podrian bajar un poco la optimizacion a mi, ustedes pierden ese tiempo creandolas en la mitad del juego, que nos dejaria parejos (En cuestion de cantidad de cosas, de tiempo habria que ver cuanto es, pero esas cosas que yo ya tengo cargadas, se me restan a la hora de activarlas).
Ademas piensen que no van a crear 1,2,3 navecitas cada minuto. Pueden llegar a crear unas 20 por segundo en alguna parte complicada del juego, y acuerdense que hay muchisimas otras cosas que se van a estar ejecutando, un boss, el jugador, un controlador, mas todos los eventos de las nuevas naves que estan entrando.

Que ni siquiera quieren poner exactitud en la creacion de esas naves, pero ahi vuelvo al mismo tema, no puedo creer que ustedes hagan cosas estimando con un timeline en vez de crearlas exactamente donde irian.

---

Dos cosas que me gustaria preguntar a todos los que nos prendimos en la discusion:

1) Vamos a llegar a algo concreto en cuanto a optimizacion? Creo que con un juego asi, y con las maquinas que cada uno debe tener, no se puede generar algo concreto. Por algo yo hable de bugs, exactitud y tiempo de creacion, y no de optimizacion.
Si se fijan, hasta que FrogGer no nombro este tema, yo jamas hable de optimizacion, solo de bugs y esas cosas que nombre antes, ya que no me creo muy apto para hablar de optimizacion tan concretamente, ya que ni siquiera puedo hacer pruebas reales. Solo puedo hacer opiniones logicas o bastantes obvias. Por eso va esta pregunta. Tampoco creo que ustedes esten en una pentium bien vieja todos los dias como para ir probando que tan lento se hacen las cosas. Si las tienen, y las usan para realizar estas pruebas, estaria genial que se armen un articulo con esas cosas que son bastantes interesantes, y por mas que en juegos asi quizas no influyan, en uno mas grande de verdad sirva!

2) Deberiamos tener un chat o algo para discutir estas cuestiones, ya que J.E.A, que fue el que creo el post, quizas no tiene su respuesta resuelta y no puede comentar por nuestra deliveracion.

A tu segunda pregunta, ya se le respondió de varias maneras, ahora el debate que se abrió después puede serle util a la gente, y si no se puede debatir no sé para qué es el foro. Acá se generó y acá debería quedar, no entiendo por qué habría que moverlo, en el buscador va a saltar igual si alguien busca optimización. Sobre optimización, no necesitás tener una pentium 233, lo dije a manera de exageración, gm es bastante pesado como para comprobarlo en una pc más potente, y si agregás un proceso inutil constante como draw_get_pixel un par de veces por step reducís la capacidad de procesamiento para otras funciones, osea que reducís la velocidad total del cpu en el juego en sí y lográs bajar la velocidad hasta un punto en q se note la diferencia de fps entre cosas que estás probando. (Si es una sola función conviene meterla en un for muchas veces hasta que los fps bajen)
Igualmente hacerlo por step y alarmas no es impreciso, uno puede calcular facilmente en qué momento y lugar aparecen las cosas. Sabiendo que cada código se ejecuta cada 60 steps podés saber exactamente dónde van a estar las naves y fondos cuando crees los enemigos, no hace falta basarse en prueba y error.

Depende como lo hagas.
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.
Porque no estamos hablando del evento step, estamos hablando de "a tal step del juego, crear tal cosa". Eso es lo que me parece que no es preciso, puede pasar cualquier cosa que modifique el lugar del personaje, del boss, de lo que sea y que te buguee eso. No puede estar seguro que a tal step el jugador va a estar en tal lugar.

Por ejemplo, siempre que se llega al boss, como que la pantalla queda "trabada", solo hay lugar para el boss y un poco mas para ti. Entonces con un timeline no podes estar seguro si el jugador esta dentro de ese rango.
Pero si lo haces bien, en el evento step, preguntar la posicion del jugador, preguntar si quedan navecitas por si hay que destruirlas y demas.

---

Con esa forma de ralentizar todo, realmente serviria para hacer pruebas reales? Porque la verdad que hay varios detalles, ademas de estos, que quizas son caprichos o solo de curiosidad, pero que me gustarian saber.
Alguna vez lo usaste para hacer pruebas de este tipo? Como?
Me gusto la idea, pero no se si la podria implementar bien, por eso te pregunto.

Si, sirve perfectamente, lo he hecho mil veces y siempre da resultados fieles que se ven a la hora de makear juegos grandes.
No estamos hablando de timelines, sino de condiciones y alarmas, podés ingeniártelas para que la alarma en la q sale el boss quede en el menor rango de tiempo en el que el jugador destruiría las naves enemigas y empezar a chequear desde ese step cuándo deja de haber naves, igualmente al ser un juego de scroll no se suelen chequear esas cosas porque las naves avanzan hacia la izquierda en vez de quedarse en la pantalla. No es dificil, lo estás planteando como si fuera programar un World of warcraft casi xD
Una vez se me ocurrió la idea de poner en una lista la velocidad de cada función en una unidad creada para el caso, sería más que interesante, pero llevaría mucho trabajo. Quizás lo haga algún día

Ok, no habia revisado si habias actualizado tu respuesta. Eso responde varias cosas.
Primero, no te prejuzgo en tu personalidad, simplemente confirmo lo que tu mismo dijiste:

CitarInsisto 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.

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.

CitarCuando 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!

Tienes razón, lei mal. Aun asi no puedo responderte porque no se a que te refieres con condiciones (if, else ?).

CitarTu 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.

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.

CitarComo 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!

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. 

CitarPero 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.

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.

Para terminar, porque ya me voy a comer:

CitarSiempre hay que buscar lo que menos bugs de y lo mas exacto posible.

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.

Actualizacion:

CitarSi 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.

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.

 

FrogGer, Texic, pido mil disculpas por no responder.
Razon: Estaba terminando de editar mi respuesta y le doy a previsualizar. Y que paso? No se puso porque se me deslogueo, y al apretar "Atras", no se porque, no estaba lo que habia escrito, solo que habia citado.

Aqui ya son las 2AM, por lo que estoy bastante cansado y ahora frustado, porque ese error es algo que estoy pidiendo que se cambie en la seccion de propuestas, y como que me frustro el doble.

Despues vuelvo a hacer la respuesta y la publico!

De nuevo, mil perdones por no poder contestar ahora, pero no los voy a dejar con la discusion a medias, seria de muy mala educacion!

Dont worry, mañana será otro día.

Cita de: MaanuRP en Junio 13, 2012, 02:54:38 AMA ver, que en dos post estemos discutiendo, no nos hace enemigos,

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 ;)

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

Cita de: SobacoEnLlamas en Junio 13, 2012, 12:45:12 PM

Cita de: MaanuRP en Junio 13, 2012, 02:54:38 AMA ver, que en dos post estemos discutiendo, no nos hace enemigos,

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 ;)

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.

CitarOk, no habia revisado si habias actualizado tu respuesta. Eso responde varias cosas.

No hay problema

CitarPrimero, no te prejuzgo en tu personalidad, simplemente confirmo lo que tu mismo dijiste:

CitarInsisto 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.

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.

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

CitarCuando 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!

Tienes razón, lei mal. Aun asi no puedo responderte porque no se a que te refieres con condiciones (if, else ?).

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

CitarTu 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.

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.

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

CitarComo 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!

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. 

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

CitarPero 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.

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.

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).

CitarPara terminar, porque ya me voy a comer:

CitarSiempre hay que buscar lo que menos bugs de y lo mas exacto posible.

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.

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.

CitarActualizacion:

CitarSi 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.

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.

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!

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!)

Agregame al Feisbuk y listo :)

CitarExacto, 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).

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

CitarEsto 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?

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.

CitarSi vas a trabajar con un grupo, vas a tener que programar de cierta manera que concuerde con las otras personas.

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.

CitarPero si hablamos de cosas independientes, si, puedes entregarlo de la manera que tu quieras mientras cumplas las reglas y tiempos.

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

CitarNono, 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.

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.

Citar

CitarExacto, 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).

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

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

Citar

CitarEsto 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?

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.

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

CitarSi vas a trabajar con un grupo, vas a tener que programar de cierta manera que concuerde con las otras personas.

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.

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

CitarPero si hablamos de cosas independientes, si, puedes entregarlo de la manera que tu quieras mientras cumplas las reglas y tiempos.

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

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

CitarNono, 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.

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.

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.

CitarAdmito 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

Hay una función en las timelines llamada shift que hace ese trabajo

Cita de: Texic en Junio 14, 2012, 05:36:56 AM

CitarAdmito 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

Hay una función en las timelines llamada shift que hace ese trabajo

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?