Comunidad Game Maker

Hace tiempo que no me pasaba por la comunidad, quise entrar para ver que juegos nuevos e interesantes habian salido, y me pillo con esto en el primer post... no puedo estar más contento.
  Recuerdo haber jugado una demo tiempo atrás, pero ya jugando el juego pulido solo me queda felicitarte. Se nota que le has puesto cariño al hacerlo.
  Estuve jugando el primer mundo y saque las primeras gemas hasta la misión de encontrar la que está oculta. No la pillé y salté al mundo de hielo. El juego es adictivo, está bien pensado y el humor con que cuenta es entretenido. Dan ganas de terminarlo.
  Me trae muchos recuerdos a un juego llamado Treasure Adventure Game, con sus diferencias claro. Lo has jugado? Si no te lo recomiendo, tiene el mismo espiritu que el tuyo, aunque el otro es mas Metroidvania y el tuyo mas Mario 64-Banjo Kazzooie.
  No he encontrado bugs, sin embargo en mi notebook tiene un pequeño parpadeo de sprites, y por ejemplo cuanod te lanzas al agua, en la superficie se ven unos cuadrados parpadeantes. No es molesto, pero sería bueno tenerlo en cuenta.
  Que mas? Me haré un tiempo para terminarlo, que el juego se lo merece.


Saludos

 Tienes equivocado el codigo para invertir gravedad, o por lo menos yo lo uso de diferente forma:

Si quieres que la gravedad sea hacia abajo, debes indicar:

gravity_direccion = 270  //Hacia abajo
gravity = 1                   //Velocidad de gravedad

Si es hacia arriba:

gravity_direccion = 90  //Hacia arriba
gravity = 1                   //Velocidad de gravedad

  Prueba con eso.

 Hola 12nes

De la manera que lo has programado es un poco más difícil de realizar, ya que las variables no están conectadas, o sea, no se pueden recorrer. Lo ideal hubiera sido un vector (array, arreglo) ya que así es fácil analizar una por una, pero vamos  mejor a la solución :)

Lo único que se me ocurre, es que, al tocar el objeto, se ejecute una serie de consultas a las variables. La cantidad de lineas depende de la cantidad de variables que hayas creado.

if var_1 = 0
{
        var_1 = 2
        exit
}
if var_2 = 0
{
        var_2 = 2
        exit
}
if var_3 = 0
{
        var_3 = 2
        exit
}

Y eso sería, no lo he probado pero debería funcionar.

 Por lo mismo esbxp, GML no es tan rapido como C++ u otro lenguaje más avanzado, por lo que con un  poco se puede saturar un pc. De ahi la importancia de la optimización.

Citarpues bien, lo mismo debiera ser para los Sprites y Background, puesto ya esta creado, no estoy seguro si el Sprite, o Bacground, desaloja esa memoria, cuando acaba la room, y no lo usare en la siguiente Room, y esto si es un problema

No lo hace, pero existen las funciones sprite_delete y background_delete para liberar la memoria ocupada por estos :)

CitarA que le llamas considerable? Porque la verdad que yo jamas tuve problemas de FPS con esto

Considerable en relacion a la cantidad de información procesada. Si tienes un room  de 1500 de largo, no se nota la sobrecarga, pero vamonos a los extremos. Tu conoces las pruebas de stress? esas que se hacen para probar la optimizacion de CPUs, Sistemas operativos, Rams, Bases de datos, etc? Se basan en llevar al limite lo que se prueba, procesando cantidades gigantes de datos. Créeme, te lo doy por seguro, si tienes 1 room de 150.000 pixeles de largo y 1500 instancias en el cuarto se notará el bajón si o si. 

CitarComo dijimos que estamos hablando de un juego shooter, tu dices que tu forma de hacerlo es mucho mas optima que la mia. De verdad se justifica en un juego de estas caracteristicas?

Posiblemente no, eso ya te lo había dicho. Pero tampoco esta malo, como le dijiste a Sobaco, y ese fue el punto inicial de este debate.

CitarOsea, tu puedes hacer un juego de "la forma tradicional" que baje considerablemente los FPS, y que al pasarlo a tu modo ya no tenga ese problema?
No te lo quiero pedir como prueba, sino que me encantaria ver eso, porque ademas es algo realmente interesante que sucediera.

Suponiendo que estamos hablando de un shooter de naves del estilo del ejemplo que te adjunte, si. Si tienes uno que sea lento enviamelo.

CitarEstando solo nadie te puede decir nada, y es bueno que conozcamos mas metodos, aunque yo siempre prefiero el que menos bugs puede crear, ya que si surje algun problema de optimizacion, quizas se pueda arreglar mas facil que uno de bugs

Estoy de acuerdo. Depende del proyecto y complejidad de este es que decides que método tomas.

CitarOtra cosa, en tu carrera diste GM? O como fue esto del proyecto? (Si no te importa contar, si es un problema o no te gusta contar, no hay problema xD)

Era un curso (no recuerdo el nombre) semestral donde se enseñaba y evaluaba los rpincipios de las conexiones en red. Como trabajo semestral el profe nos pidió (como buenos informaticos jaja) un juego diseñado en cualquier lenguaje que se jugara en red. Hubieron juegos en java, Visual Basic, Python, Flash y como no, aportando por aca con GML :) Fue una muy buena asignatura (Nostalgia Mode ON)

CitarCreo que deberia haber un equilibrio, entre no hacer el Crysis que era muy complicado de levantar con buenos FPS, y hacer una programacion tan complicada que al minimo bug que te salga, no lo puedas arreglar, o ni siquiera puedas trabajar tranquilo.

100% de acuerdo.

CitarComo puedes estar tan seguro que nunca te surgira cambiar el tamaño del room? O cambiar un sprite? O algo asi, juegas demasiado con las cosas numericas, cuando lo mejor, me parece a mi, es usar funciones genericas, para que cualquier cambio no te afecte.

A ver, miralo de esta manera. Ambos metodos tiene casi la misma complejidad cuando se quieren modificar. Ya te di las razones si cambias el room a lo largo, si lo haces a lo alto (height) tendras los mismos problemas mios si lo haces en el tuyo.
Tu mientras tienes que mover manualmente los objetos que quieras reacomodar, yo simplemente cambio las coordenadas en instance_create. De sprites nada, ya que son objetos propios identicos a los que tienes tu.
 
  Como puedo decirte que despues de todo no es tan díficil la creacion y modificacion de este método? Con una respuesta tuya :)

CitarPero creo que con practica y buena predisposicion, se te hace bastante facil.

  Bueno, me voy a dormir. Mañana seguimos :P

Citar{
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.

Conocía ese trocito de codigo, pero si bien en 2 lineas activas y desactivas instancias, interiormente si igual es un gasto considerable de procesamiento al estar evaluando cada instancia individualmente.

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

Claro, se que el tema era otro y salio esto de la optimización, pero es que yo lo agregé por ser una consecuencia positiva de usar el método. es más, es la única justificación posible para usar este método (no te voy a negar que el otro es más cómodo y rápido).

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

De acuerdo, pero como estaba solo lo quise hacer así. Conozco ambos métodos en caso de hacer equipo.

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.

Gracias, el esfuerzo valió la pena (obtuve un 85/100 como nota :)).
  Y bueno, Texic ya te respondió lo siguiente. Simplemente le haces un SHIFT a los steps y listo, todo se corre mágicamente. 

  Para terminar, si es más engorroso programar un juego de esta manera, es más, para ejemplos de juegos cortos ni vale la pena hacer ese esfuerzo extra porque lo que ganas es bastante poco. Pero en la universidad me taladraron el cerebro con el tema de dar prioridad a la optimizacion de recursos, y bueno, siempre mi norte es apuntar en ese estilo. Aunque cueste más trabajo.

Modificacion:

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

No hay cambio de tamaño en este método, la pantalla siempre tiene la misma forma. Todo se basa en los timelines, mientras mas acciones y pasos le des más largo y variado seran los ataques enemigos. Por ejemplo:

1.-Si crees que la primera etapa te quedo muy corta y sencilla, agregas mas enemigos aumentando el timeline.
2.- Si crees que te quedo muy larga, eliges el rango de steps que quieres borrar y listo.
3.- Si crees que en la mitad del recorrido faltan cosas, haces un shift, corres todos los steps el tiempo que quieras (piensa que lo que haces es demorar lo que corres, por lo tanto, tienes espacio para colocar más cosas).

Ahora, lo mismo te pregunto a ti: En tu metodo cuando quieres agregar algo en la mitad debes correr objetos, tiles, etc de manera manual e individualmente, porque GM no tiene selección grupal de objetos. Yo lo considero aun mas engorroso.

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.

Jajajaja, ni idea lo que es un bsf, pero igual  XD

 Me gusto mucho el juego, no se como sería la version anterior pero esta tiene un toque de estrategia muy bueno. Me gusta la IA, responde bien y con fluidez.
  No logré pasármelo, llegue hasta el nivel 10 y mas o menos unos 14000 puntos, y perdí.
  Buen trabajo, a ver si muestras algo del juego de estrategia que estas creando. Seria interesante :)

Saludos

CitarHola a todos,
Seria posible añadir visual basic en game maker 8,
me refiero por ejemplo si quiero poner un textbox del vb al GM8

Si se puede, Texic ya colocó unos links para descargar las DLLs para que game Maker pueda usar controles de Visual Basic (textBoxs, botones, Listas emergentes, etc).

Citarsi pero si tengo una aplicacion creada con VB y quiero que GM8 obtenga solo el textbox del Vb
que hago???

Aca el problema es que no se te entiende bien lo que pides. Tienes una aplicacion creada en Visual basic y quieres traspasar la información escrita en un textBox a un juego de GM?  En ese caso es mas complicado, ya que Game maker no recibe parametros de inicio, por lo tanto el uso de archivos de texto podria ser una opcion (algo poco practica pero solucion al fin).
    Que es realmente lo que quieres entregar como parámetro al juego? puedes poner un ejemplo? tal vez asi te demos alguna forma mejor de hacerlo.

Dont worry, mañana será otro 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.

 

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.

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.

 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?