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.
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!)
CitarCitarCuando 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).
CitarCitarTu 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?
CitarCitarComo 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.
CitarCitarPero 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.
CitarCitarExacto, 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
CitarCitarEsto 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.
CitarCitarSi 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.
CitarCitarPero 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.
CitarCitarNono, 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?
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.
CitarCitar
{
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.
A que le llamas considerable? Porque la verdad que yo jamas tuve problemas de FPS con esto.
CitarCitarComo 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).
Como 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?
Osea, 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.
CitarCitarEsta 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.
Estando 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 (No llevo ni un año en esto, pero en el transcurso de tiempo lo he usado MUCHISIMO, y muchas veces tuve bugs que los veia irreparables, pero nunca tuve un problema de optimizacion que no pudiera arreglar. Lo que no quiere decir que en un futuro no los tenga, ni que soy un crack arreglando esto, sino que no me surgieron, y que por eso es mi forma de pensar asi).
CitarCitarAdmito 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 :)).
Te lo merecias, me gustaron mucho los sprites tambien!
Otra 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)
CitarY bueno, Texic ya te respondió lo siguiente. Simplemente le haces un SHIFT a los steps y listo, todo se corre mágicamente.
Aqui el mismo mal entendido que le explique a él.
CitarPara 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.
Creo 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.
CitarModificacion:
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).
Como 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.
CitarAhora, 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.
Si, en eso tambien tienes razon, lleva su debido tiempo armar un room manualmente, ademas que el GM no tiene el mejor editor de niveles que todos. Pero creo que con practica y buena predisposicion, se te hace bastante facil.
Que a la hora de hacer cambios va a ser tedioso, es cierto, pero creo que de eso no hay ninguna forma de esquivarlo.
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
jjaja ... nunca un juego de estos será de la rapidez optimizada que ofrece hacerlo en C/C++ o incluso Bmax, y uno de sus grandes problemas no pasa por el tamaño de sus Sprites, sino por la interacción directa que tiene el lenguaje compilado, ASM con el procesador. Y C/C++ es muy superior en optimización.
Lo otro es un problema de recursos, es decir, yo puedo tener 1000 Sprites he imágenes de Todo tipo, y empaquetadas en un, Zip, y al momento de cargar el nivel, voy al archivo y leo y cargo solo los recursos que ocupa ese nivel, dejando un margen de memoria gráfica de un 50% es suficiente, para no agotar el sistema, es bueno que tengan un programa que cuente esta memoria gráfica, libre cuando cargan el juego. Y tambien se da un aviso de Requerimiento gráfico para el XGame 1gb, y asi los usuarios sabrán que menos de eso el juego no correrá.
GameMaker personalmente es bastante bueno, para desarrollar un concepto de juego, se puede optimizar, con codigo, step, y ciertas lineas estrategicas "if(y < view_yview || y > view_hview) deactivate_instance(true)", sin entrar mas en detalles, pero el problema que yo veo de fondo, y no se si tendrá solución, es la persistencia de recursos, osea, si una instancia llama a un objeto que no existe en la room, aparecera un error que dice que la instancia de ese objeto no esta creada, pues 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,,,, porque en C/C++ todo lo que se declara como objeto, no ocupa memoria si no se abre con new, o se desaloja con delete, inclusive las imagenes, osea, no se si me equivoco, yo estaría diciendo, que la memoria usada, es toda la memoria de imagenes declarada, y se agrega toda la memoria usada por los objetos creados en la room, la suma de ambas, debe ser menor que el total de la memoria de la tarjeta gráfica, sino colapsa, !!!
Hay alguna manera de que toda la memoria declarada en las imágenes, no sea memoria usada para el Game?,, creo que no !!!
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 :)
CitarCitarA 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.
Una cosa es que sea logico, no veo la necesidad de tener un room de 150.000 pixeles, ni mucho menos 1500 instancias (En un juego asi)
CitarCitarComo 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.
Si no se justifica usar un metodo que atrae mas bugs, mayor necesidad de prueba y error en vez de logica, y cosas asi, yo lo veo como que esta mal (Como ya dije, no tan amplio, sino que seria una de las peores ideas para usar)
CitarCitarOsea, 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.
En las oportunidades que tuve de programar un juego asi, nunca se me bajo ni un FPS, por eso te estoy preguntando.
Mi pregunta es que sin cambiar absolutamente nada, solo como se crean las instancias.
CitarCitarComo 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.
Para mi no es lo mismo poder poner la instancia donde yo quiera, estar viendola en tiempo real y poder modificarla a mi gusto. Que tener que ir poniendolo por steps, que hastaque no corra el juego y llegue hasta ese lugar, no se como van a quedar.
CitarComo 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.
Yo no me referia a eso xD
Igualmente creo que nunca lo usaria, creo que no se justifica usar este metodo, tampoco me gusta para hacer distintas cosas en el juego en si.
Pero cada cual con lo suyo.
La habilidad de un programador se refleja en su capacidad de optimizar el código sin cambiar el funcionamiento del mismo. Quizás fue exagerado lo de un room de 150000 pixeles, pero cuál método sirve para el caso y cuál no? Quién sabe, quizás algún día se te de por hacer un shooter extensos como lo son juegos estilo RaidenII y ahí se va a sentir la diferencia de optimización. Igual a lo que apuntamos con FrogGer no es a cambiar tu manera de hacer los shooters sino a cambiar la manera de pensar al programar, la optimización es muy importante, y si nunca la haces, ni para juegos chiquitos, nunca mejorás la técnica. Hace poco vino alguien a preguntar sobre cómo optimizar un código en el que se usaba draw_background_tiled. Si te fijás es sólo una función, pero es totalmente inefectiva ya que la velocidad depende del largo y ancho del room (como el caso de tu shooter). Obviamente nadie te obliga a cambiar la manera de programar, pero estamos acá para repartir nuestros conociemientos y experiencias con los demás. Por mi parte te recomiendo empezar a optimizar todo código que hagas así va a llegar el día que hagas que el crysis corra en un AMD K6... Bueno, tampoco para tanto, pero por ahí viene la mano xD
Cita de: Texic en Junio 14, 2012, 11:42:07 PM
La habilidad de un programador se refleja en su capacidad de optimizar el código sin cambiar el funcionamiento del mismo. Quizás fue exagerado lo de un room de 150000 pixeles, pero cuál método sirve para el caso y cuál no? Quién sabe, quizás algún día se te de por hacer un shooter extensos como lo son juegos estilo RaidenII y ahí se va a sentir la diferencia de optimización. Igual a lo que apuntamos con FrogGer no es a cambiar tu manera de hacer los shooters sino a cambiar la manera de pensar al programar, la optimización es muy importante, y si nunca la haces, ni para juegos chiquitos, nunca mejorás la técnica. Hace poco vino alguien a preguntar sobre cómo optimizar un código en el que se usaba draw_background_tiled. Si te fijás es sólo una función, pero es totalmente inefectiva ya que la velocidad depende del largo y ancho del room (como el caso de tu shooter). Obviamente nadie te obliga a cambiar la manera de programar, pero estamos acá para repartir nuestros conociemientos y experiencias con los demás. Por mi parte te recomiendo empezar a optimizar todo código que hagas así va a llegar el día que hagas que el crysis corra en un AMD K6... Bueno, tampoco para tanto, pero por ahí viene la mano xD
No creo que mi manera de programar sea tan poco optima, sino alguna vez lo hubiera notado.
Siempre busco la manera mas "rapida" para el sistema de hacer las cosas, y hasta ahora me ha ido bien.
Sera porque mi nivel de optimizacion me alcanza para lo que estoy creando, quizas algun dia necesite mas, o quizas este por el buen camino de la optimizacion.
Cuando tenga algun problema con esto, seguramente van a estar ahi, reprochandome todo eso xD Broma, pero van a estar ahi para ayudarme, como siempre, seguramente ^^