Comunidad Game Maker

Quisiera saber como podria hacer un scroll automatico, o sea, que la pantalla vaya avanzando sola. Porque por ejemplo: Tengo un juego de naves que avanzo de abajo hacia arriba. Entonces a medida que avanzo deberían aparecer naves o bases de naves (algo tipo el Star Soldier o Starforce de NES) mi nave puede moverse de arriba hacia abajo y de costado a costado  XD. El problema es que si a mi nave le asigno una view, la nave va a ir para atras y el scroll va a ir para atras con mi nave cosa que el scroll deberia seguir y no frenarse ni retroceder. Como debería hacer para que el scroll continue a pesar de que me mueva para abajo por ejemplo?
Ojala haberme explicado bien  :-[

En algun evento step agrega:
[gml]
view_xview += 2 //Dependiendo de la velocidad que le quieras dar va a ser menor o mayor.
[/gml]

A eso de MaanuRP agregale que la velocidad de la nave en estado normal no debería ser 0 sino la velocidad del movimiento de la view. Ese sería el eje del cual partir a la hora de darle movimiento. Por ejemplo si querés que se mueva con una velocidad de 4 hacia la derecha sería 6 y hacia la izquierda -2 ya que 2+4=6 y 2-4=-2
Luego agregarás límites para que la nave no se salga de la view y listo. Aunq lo que hacen algunos juegos es crear la apariencia de que se mueve la view cuando en realidad la nave está estática y lo que se mueven son los objetos que salen de arriba. Mirá los ejemplos básicos de gm, hay uno de autos, te va a servir para comprender lo q digo
Saludos!

para los juegos de nave se suele usar una pantalla estática pero con el fondo haciendo scroll para dar esa sensación, y los enemigos escuadrones, etc aparecen como si viniesen mientras la nave tuya avanza

Cita de: Texic en Junio 12, 2012, 10:06:05 PM
A eso de MaanuRP agregale que la velocidad de la nave en estado normal no debería ser 0 sino la velocidad del movimiento de la view. Ese sería el eje del cual partir a la hora de darle movimiento. Por ejemplo si querés que se mueva con una velocidad de 4 hacia la derecha sería 6 y hacia la izquierda -2 ya que 2+4=6 y 2-4=-2
Luego agregarás límites para que la nave no se salga de la view y listo. Aunq lo que hacen algunos juegos es crear la apariencia de que se mueve la view cuando en realidad la nave está estática y lo que se mueven son los objetos que salen de arriba. Mirá los ejemplos básicos de gm, hay uno de autos, te va a servir para comprender lo q digo
Saludos!

Eso es cierto, si mueves la nave por hspeed es asi.
Como yo las veces que hice juegos asi las movia por x, no necesitaba hacer esas cuentas.

Si me permites la "discusion" el ejemplo que puede servir mas, es el shooter de Yoyogames, creo que es el que mas iria con este tema (Aunque en realidad no vi el de autos que dices, pero del que hablo yo es exclusivamente de esto).

---

Cita de: SobacoEnLlamas en Junio 12, 2012, 10:28:56 PM
para los juegos de nave se suele usar una pantalla estática pero con el fondo haciendo scroll para dar esa sensación, y los enemigos escuadrones, etc aparecen como si viniesen mientras la nave tuya avanza

¿Quien te dijo que esto es asi? Quizas tu lo hagas asi, y desde ya te digo que esta bastante mal.
Tengo 5 razones por las cual no deberias seguir haciendolo asi:

1 - Al dejar la camara estatica, tendras que crear los objetos a medida que el juego corre, no podras ubicarlos en el editor del room, ya que nunca aparecerian, y si pones para que aparezcan solos, estas usando muchos eventos step al mismo tiempo, que ya es obvio porque esta mal.

2 - Si vas a hacer que las naves disparen, y las naves ya vienen con, no se, digamos -5 de hspeed, sus balas tendran que tener algo de -7 hasta -10 para que se vea bien, y si le pones esa velocidad a las balas normales, quiero ver como te ingenias una bala rapida del boss o de otro mob.

3 - Si nunca mueves la camara, como pretendes llegar al final del room para llegar a un boss o simplemente al fin del room? Si lo haces por la "x" del background, quiero ver que lo hagas sin complicaciones (Bugs, cuentas, pruebas), lo digo por experiencia.

4 - Despues de solucionar todo eso, tendrias que ponerte a pensar como podrias hacer la muerte, ya que si la camara esta siempre en el mismo lugar, no tienes referencia para el grado de avanzado del jugador y lo unico que te quedaria es reiniciar el room entero.

5 - Si despues de todas estas razones, no me quieres creer a mi, revisa el ejemplo Shooter que da Yoyogames, y revisa como lo hacen.

Si despues de todo eso lo quieres seguir haciendo asi, me vas a dar la razon cuando te metas en un proyecto mas complicado y no puedas o te canses de solucionar bugs por cosas que se pueden programar de una mejor manera.

manu... calmate okey?... yo le di un ejemplo de juego de naves amater, no me sé de memoria el grado makero de todos los usuarios del foro, y todo lo que has dicho, se puede tranquilamente hacer sin necesidad de hacer una room dinámica con views, que a ti no te sala no es mi problema y tampoco voy a hacer un ejemplo para que acabes contento y convencido, adios muy buenas

Cita de: SobacoEnLlamas en Junio 13, 2012, 02:04:04 AM
manu... calmate okey?... yo le di un ejemplo de juego de naves amater, no me sé de memoria el grado makero de todos los usuarios del foro, y todo lo que has dicho, se puede tranquilamente hacer sin necesidad de hacer una room dinámica con views, que a ti no te sala no es mi problema y tampoco voy a hacer un ejemplo para que acabes contento y convencido, adios muy buenas

En ningun momento me sobresalte, como le conteste a Texic, te conteste a ti. A ver, que en dos post estemos discutiendo, no nos hace enemigos, eso te tiene que quedar bastante claro para toda tu vida de los foros, en un foro es asi, vas a tener gente que piensa totalmente distinto y saldran discusiones, no por eso son tus enemigos o rivales.

Cuando quieras hacemos una competencia de juegos shooter, y vemos quien lo hace mas rapido, sin bugs, y mejor programado, no tengo problema yo.

Lo que si, deberias practicar un poco mejor tus respuestas. Se supone que respondes el post para ayudar, y tu lo unico que hiciste fue describir casi lo mismo que en el post de la pregunta.
Y otra cosa, a menos que sea cierto, no añadas: "se suele usar". Una cosa es que vos generalmente lo hagas asi, pero como ya te demostre, genera bastantes bugs y complicaciones hacerlo asi, por algo los tutoriales no lo hacen asi, no? Y no digo tutoriales hechos por cualquier persona, sino los de Yoyo.

Si hubo un mal entendido y sentiste que en algun momento te falte el respeto, desde ya te digo que esa no fue la intension, pero de forma escrita es casi imposible saber como tratar a los demas, siempre hay algo que se puede tomar a mal.

Saludos!

Aunque no lo creas Manu, la forma más eficiente aunque mucho más complicada es la forma que menciona Sobaco

1.- Tienes razon, no los puedes ubicar en el room manualmente, pero no se utilizan eventos step, con alarmas basta y sobra.

2.- Lo de las balas es relativo. Simplemente juega con las velocidades al disparar y listo. No es tan complicado como parece.

3.- Nuevamente: Uso de alarmas, o mejor aun, timelines. Ejemplo:
step 1: creo 3 aviones
step 400: 5 aviones mas
step 1500: Unos helicopteros
step 151215615861: Un jefe final.

4.- La mayoria de los juegos de naves tienen 1 o 2 checkpoints durante el recorrido. Un par de variables guardando que checkpoint alcanzaste y almacenando las coordenadas basta y sobra.

5.-Es una idea. Te comento esto porque yo igual cree años atras un shooter con este estilo y mira que funciona bien. No te niego que crear escenarios vistosos y divertidos es complejo de esta manera, pero es muchisimo mas eficiente ya que no tienes que recorrer un room de 15.000 pixeles de largo "precargado" desde antes.  Es cosa de estilos.

Cita de: FrogGer en Junio 13, 2012, 03:01:25 AM
Aunque no lo creas Manu, la forma más eficiente aunque mucho más complicada es la forma que menciona Sobaco

1.- Tienes razon, no los puedes ubicar en el room manualmente, pero no se utilizan eventos step, con alarmas basta y sobra.

2.- Lo de las balas es relativo. Simplemente juega con las velocidades al disparar y listo. No es tan complicado como parece.

3.- Nuevamente: Uso de alarmas, o mejor aun, timelines. Ejemplo:
step 1: creo 3 aviones
step 400: 5 aviones mas
step 1500: Unos helicopteros
step 151215615861: Un jefe final.

4.- La mayoria de los juegos de naves tienen 1 o 2 checkpoints durante el recorrido. Un par de variables guardando que checkpoint alcanzaste y almacenando las coordenadas basta y sobra.

5.-Es una idea. Te comento esto porque yo igual cree años atras un shooter con este estilo y mira que funciona bien. No te niego que crear escenarios vistosos y divertidos es complejo de esta manera, pero es muchisimo mas eficiente ya que no tienes que recorrer un room de 15.000 pixeles de largo "precargado" desde antes.  Es cosa de estilos.

Si agregas tantas cosas para un simple shooter, no me imagino para un juego de plataformas o mas aun, un Online, en el que debes hacer los menos cambios posibles, sino no tendras buena comunicacion.

Recuerda que ademas de eso, van sprites que si se puede se tiene que usar HD, ademas que no estamos creando juegos que la gente deberia revisar los requisitos, y que un shooter no tire los FPS que deberia, es lamentable.

Nunca va a ser mejor agregar tantas cosas, menos para cosas simples.

---

1 - Si lo haces con alarm, tiene que ser a prueba y error con el tiempo, o estimaciones. Me imagino que sabes que eso no es muy profesional que digamos (Obviamente que hay bugs que hay que arreglarlos asi, pero a la hora de programar, cuanto menos prueba y error, mejor).

2 - Lo mismo, si es a prueba y error cualquiera podria programar, las cosas se hacen bien, si lo haces al aire la verdad que es mejor que no lo hagas, para algo somos programadores, para usar la logica, no la suerte.

3 - Sigue siendo lo mismo, como vas a poner un Boss creado en un alarm o un step asi? Puede dar muchisimos bugs, o quede realmente mal, ni siquiera sabes si va a quedar bien en ese lugar, la unica forma de verlo es jugando. Sabes el tiempo que te pierdes haciendo prueba y error? No lo justifica. Ahora puede ser que te sirva, total no tienes limite de tiempo, pero el dia que el proyecto no sea tuyo, sea de trabajo o algo asi, vamos a ver si te es tan facil hacer prueba y error y perder tiempo solo por un capricho de no hacer las cosas como se debe.

4 - Sigues agregando cosas, cuanto menos se agregue, mejor. Ademas que por como lo quiere hacer, deberias agregar condiciones en todas las creaciones de instancias, ya que si quieres partir el room en 2 asi, no lo puedes hacer tan sencillo

5 - Hablamos de solo correr un room al principio, cuando despues vas a poder jugar con las instancias como quieras para que consuman lo que quieras, por ejemplo, que afuera de la view no esten activadas y listo.

Si a eso le llamas eficiencia, no concuerdo contigo, y no creo que a alguien que te vaya a dar un trabajo le guste tu forma de hacer las cosas. Insisto que los programadores tenemos que usar la logica, y no la suerte o la "prueba y error" (Como ya aclare, hay casos, como bugs, que es inevitable, pero hacer todo el juego a prueba a error? Gastas demasiado tiempo)

---

Al margen, SobacoEnLlamas, que des Karma negativo solo por no aceptar criticas es de noob.

Si entras en un foro serio, tienes que aceptar toda critica que te hagan, sea buena o mala. Pero ya me di cuenta la clase de usuario que eres.

Esperemos que con el tiempo puedas tomar la seriedad que tiene este foro, hasta entonces, nos seguiremos llevando asi jajaj.

Saludos y suerte en tus proyectos ^^

CitarSi agregas tantas cosas para un simple shooter, no me imagino para un juego de plataformas o mas aun, un Online, en el que debes hacer los menos cambios posibles, sino no tendras buena comunicacion. 

Ah, es que ya ese es otro tema. Si hablamos de plataformas la cosa cambia y en ese caso no sería recomendable el método anterior. Aunque eso tambien depende de que tipo de juego de plataformas quieres hacer: Si quieres hacer un metroidvania, vale no sirve. Pero si quieres hacer un Canabalt o un Robot unicorn es lo mas recomendable.

CitarNunca va a ser mejor agregar tantas cosas, menos para cosas simples.

Esto ya es un asunto de mentalidad personal. Yo siempre preferiré más optimización aunque eso incluya hacer muchas lineas de código extra. Creo que con los pcs tan potentes que estan saliendo al mercado los desarrolladores han empezado a tener la mala costumbre de hacer casi nula optimizacion de los juegos, lo cual es lamentable. o ya me dices del famoso Crysis, que era un mostruo graficamente pero esta horriblemente optimizado. Ellos mismos se dieron cuenta del error cometido, y su siguiente version del motor grafico lo optimizaron mucho más. Te das cuenta que si es preferible hacer muchas mas cosas, con tal que el producto final sea mejor?

 Respondo tu mensaje que no me fije que lo habias editado:

Citar1 - Si lo haces con alarm, tiene que ser a prueba y error con el tiempo, o estimaciones. Me imagino que sabes que eso no es muy profesional que digamos (Obviamente que hay bugs que hay que arreglarlos asi, pero a la hora de programar, cuanto menos prueba y error, mejor).

Puedes citarme algun libro de ingenieria de software donde diga expresamente que un proyecto debe tener el minimo de prueba y error? Son enfoques diferentes de programar, y en eso también se basa tu habilidad y rapidez como programador. Los proyectos se encierran en tiempos de desarrollo, si uno es capaz de hacer esfuerzo extra en el mismo periodo de tiempo pues perfecto.

Citar2 - Lo mismo, si es a prueba y error cualquiera podria programar, las cosas se hacen bien, si lo haces al aire la verdad que es mejor que no lo hagas, para algo somos programadores, para usar la logica, no la suerte.

Exacto, las cosas se hacen bien. Hacer las cosas bien es aprovechar al maximo el tiempo estipulado para desarrollo del juego, cumplir con las fechas y entregar un producto de calidad. Como programes es decion tuya.

Citar3 - Sigue siendo lo mismo, como vas a poner un Boss creado en un alarm o un step asi? Puede dar muchisimos bugs, o quede realmente mal, ni siquiera sabes si va a quedar bien en ese lugar, la unica forma de verlo es jugando. Sabes el tiempo que te pierdes haciendo prueba y error? No lo justifica. Ahora puede ser que te sirva, total no tienes limite de tiempo, pero el dia que el proyecto no sea tuyo, sea de trabajo o algo asi, vamos a ver si te es tan facil hacer prueba y error y perder tiempo solo por un capricho de no hacer las cosas como se debe.

Creeme, se puede. Has intentado alguna vez programar algo con este método? No es tan dificil como parece. La cantidad de tiempo, bugs y errores que tengas sera proporcional a tu habilidad como programador.

Citar4 - Sigues agregando cosas, cuanto menos se agregue, mejor. Ademas que por como lo quiere hacer, deberias agregar condiciones en todas las creaciones de instancias, ya que si quieres partir el room en 2 asi, no lo puedes hacer tan sencillo

Si, ya te comente que era mas complejo (aunque tampoco tanto). Pero ganas optimizacion y eso es algo que se valora mucho. MUCHO.

Citar5 - Hablamos de solo correr un room al principio, cuando despues vas a poder jugar con las instancias como quieras para que consuman lo que quieras, por ejemplo, que afuera de la view no esten activadas y listo.

No, las instancias creadas en el room aunque esten fuera de la view SI estan activadas y estas están consumiendo recursos del pc.

CitarSi a eso le llamas eficiencia, no concuerdo contigo, y no creo que a alguien que te vaya a dar un trabajo le guste tu forma de hacer las cosas. Insisto que los programadores tenemos que usar la logica, y no la suerte o la "prueba y error" (Como ya aclare, hay casos, como bugs, que es inevitable, pero hacer todo el juego a prueba a error? Gastas demasiado tiempo)

Es eficiencia, pero en recursos de computador (pensé que tenias claro el termino). Ahora, si ocupas mas o menos tiempo depende nuevamente de tu habilidad de programador. Si cumples con los plazos establecidos, cual es el problema de sudar un poco más y entregar un juego aun mejor?

Es cierto lo que dice FrogGer Manu, si importa la optimización, a la hora de hacer un room grande te puede costar muchos fps. Decís que cualquier computadora moderna tendría que tirarlo? Error, si quiero jugarlo en una netbook o algo por el estilo una gran cantidad de objetos tira los fps tremendamente abajo, hace poco que estoy trabajando con un juego y la optimización me costó gran parte del tiempo de desarrollo (por suerte agarré el error al principio). Como se dijo, es cuestión de gustos, si preferís tu comodidad al programar que la comodidad del usuario al jugar es tema tuyo. Pero que se usa mucho el método es cierto, vos estás citando un ejemplo de yoyogames (probablemente de un usuario X), yo estoy citando un ejemplo que viene con GM, hecho por el mismísimo Mark Overmars, no podés estar diciéndo que él programa peor que un usuario de yoyo...

Cita de: FrogGer en Junio 13, 2012, 03:26:48 AM
Esto ya es un asunto de mentalidad personal. Yo siempre preferiré más optimización aunque eso incluya hacer muchas lineas de código extra. Creo que con los pcs tan potentes que estan saliendo al mercado los desarrolladores han empezado a tener la mala costumbre de hacer casi nula optimizacion de los juegos, lo cual es lamentable. o ya me dices del famoso Crysis, que era un mostruo graficamente pero esta horriblemente optimizado. Ellos mismos se dieron cuenta del error cometido, y su siguiente version del motor grafico lo optimizaron mucho más. Te das cuenta que si es preferible hacer muchas mas cosas, con tal que el producto final sea mejor?

Aunque no lo creas, estaba pensando en el Crysis cuando escribia lo anterior :| Jajajajaj que conexion. Concuerdo con vos, que lindos graficos que tiene ese juego ♥ Pero bueno, no viene al caso jajaj

---

Citar
Puedes citarme algun libro de ingenieria de software donde diga expresamente que un proyecto debe tener el minimo de prueba y error? Son enfoques diferentes de programar, y en eso también se basa tu habilidad y rapidez como programador. Los proyectos se encierran en tiempos de desarrollo, si uno es capaz de hacer esfuerzo extra en el mismo periodo de tiempo pues perfecto.

1 - Es 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.

Citar
Exacto, las cosas se hacen bien. Hacer las cosas bien es aprovechar al maximo el tiempo estipulado para desarrollo del juego, cumplir con las fechas y entregar un producto de calidad. Como programes es decion tuya.

2 - Tu 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.

Citar
Creeme, se puede. Has intentado alguna vez programar algo con este método? No es tan dificil como parece. La cantidad de tiempo, bugs y errores que tengas sera proporcional a tu habilidad como programador.

3 - Yo 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.

Citar
Si, ya te comente que era mas complejo (aunque tampoco tanto). Pero ganas optimizacion y eso es algo que se valora mucho. MUCHO.

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

Citar
No, las instancias creadas en el room aunque esten fuera de la view SI estan activadas y estas están consumiendo recursos del pc.

5 - Quizas 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).
Obviamente que no hay que dejar instancias activadas fuera de la view en juegos asi! Puede llegar a consumir muchisimo si es que no estan hechas para eso.

Citar
Esto ya es un asunto de mentalidad personal. Yo siempre preferiré más optimización aunque eso incluya hacer muchas lineas de código extra. Creo que con los pcs tan potentes que estan saliendo al mercado los desarrolladores han empezado a tener la mala costumbre de hacer casi nula optimizacion de los juegos, lo cual es lamentable. o ya me dices del famoso Crysis, que era un mostruo graficamente pero esta horriblemente optimizado. Ellos mismos se dieron cuenta del error cometido, y su siguiente version del motor grafico lo optimizaron mucho más. Te das cuenta que si es preferible hacer muchas mas cosas, con tal que el producto final sea mejor?

Recursos estan los que estas usando en el GM, y los de tu computadora, creo que nombre los dos, no se a que parte te refieres ahi ya que no la citaste.
Vuelvo con el ejemplo que te di, que es mas eficiente si te doy esta cuenta: 2+2?
Hacer "prueba y error" o entenderlo logicamente?
No estamos de acuerdo en algo, tu comparas un juego hecho logicamente y otro hecho a "prueba y error" para mi no se pueden comparar, siempre va a ser inferior el metodo "prueba y error" en cuestion de programacion. Porque insisto, deberiamos usar la logica y no la suerte.
Nunca te paso que arreglaste un bug sin querer y que nunca terminaste de entender porque se arreglo? No te queda un "vacio" o un remordimiento por no poder haberlo arreglado de la forma correcta? Porque a mi si.
Quizas yo hago mucho drama por esto, pero a mi me gusta que las cosas sean exactas y logicas. (Tambien soy asi en el dia a dia, a muchas personas les resulta molesto por el hecho que soy demasiado ordenado y no acepto que me cambien de lugar nada, por ejemplo xD) es dificil que acepte algo hecho "al aire"

---

Citar
Es cierto lo que dice FrogGer Manu, si importa la optimización, a la hora de hacer un room grande te puede costar muchos fps. Decís que cualquier computadora moderna tendría que tirarlo? Error, si quiero jugarlo en una netbook o algo por el estilo una gran cantidad de objetos tira los fps tremendamente abajo, hace poco que estoy trabajando con un juego y la optimización me costó gran parte del tiempo de desarrollo (por suerte agarré el error al principio). Como se dijo, es cuestión de gustos, si preferís tu comodidad al programar que la comodidad del usuario al jugar es tema tuyo. Pero que se usa mucho el método es cierto, vos estás citando un ejemplo de yoyogames (probablemente de un usuario X), yo estoy citando un ejemplo que viene con GM, hecho por el mismísimo Mark Overmars, no podés estar diciéndo que él programa peor que un usuario de yoyo...

Asi que su computadora ejecuta mejor condiciones y steps continuos con mas condiciones que un codigo fluido? Me parece que les hace falta un poco de estudio, o por lo menos programacion en un lenguaje un poco mas avanzado.

Yo trabajo con una netbook, creo que tengo algo de experiencia en lo que es optimizacion.

Y no, hablo de los ejemplos de Yoyo, que son 4 o 5, sinceramente no me acuerdo como se llaman, pero son los "originales", por decirlos de alguna manera. Igualmente fue malo de mi parte usar algo no creado por mi para usarlo de argumento en mi favor.

CitarAsi que su computadora ejecuta mejor condiciones y steps continuos con mas condiciones que un codigo fluido? Me parece que les hace falta un poco de estudio, o por lo menos programacion en un lenguaje un poco mas avanzado.

Em, no, si te fijás, a mayor cantidad de objetos, mayor cantidad de eventos draw, y si se mueven o algo tmb step. En cambio si se crean y destruyen de manera dinámica no tenés tanto procesamiento. Si tenés experiencia en optimización deberías saber que desactivar las instancias no libera completamente al programa de su procesamiento, además de que hay andar desactivándolas y activándolas cuando entran en view y la memoria la siguen ocupando porque podés chequear sus variables x, y con funciones cono instance_deactivate_region
Por favor no seas condescendiente al hablar, es molesto, además de que no conocés nuestro estilo de programación como para tratarnos así, yo estudié programación en el secundario y conozco casi todo aspecto en lo que a ejecución de código en gm se requiere, cuánto código se ejecuta, en qué orden, qué función es más pesada y cuál más liviana, y te digo que se obtienen más fps con objetos dinámicos que activando y desactivando instancias. En vez de seguir la discusión hacé la prueba y listo, usá como prueba un pentium 233 y vas a ver cuál anda mejor. Si no tenés procesá aparte cosas inútiles en el juego para simular una pc lenta

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.