Comunidad Game Maker

Cita de: ocarina en Marzo 19, 2014, 04:34:59 PM
he visto en varias preguntas que este amigo penun... hace comentarios muy sarcásticos o ofensivos para los usuarios!!! creo que con un simple "es asi" basta!!! no TENES xq estar corrigiendo a nadie!!!

Esto es una comunidad para ayudarnos todos a todos no para andar discutiendo!!!

Sarcásticos puede ser, pero ofensivos, nunca. Si algún comentario mío ha sido ofensivo para contigo o cualquier otro usuario, no dudes en reportarlo a los moderadores.

No sé por qué el rechazo a la palabra discutir. Por la naturaleza del foro, no es de extrañarse que pueda haber discusiones. Las he visto antes en el foro, en los foros de YoYo y en muchos otros foros. Una cosa es discutir por discutir, y si lo he hecho en este foro habrán sido un par de veces, pero siempre dando argumentos y nunca faltando al respeto.

De lo que recuerdo del reglamento, puede haber discusiones siempre y cuando se mantengan dentro del respeto y las reglas del foro. No pretendo ser monedita de oro para caerle bien a todo mundo, pero mi ánimo no fue exponer al makero xXchopliXx, simplemente aclaré que el post se refería a otro asunto, pero si le falté en algo, mis disculpas sinceras para el makero xXchopliXx.

Cita de: xXchopliXx en Marzo 19, 2014, 10:24:32 AM
Te refieres a colisión con el jugador o con el suelo?

Se refiere a colisiones con enemigos, lo dice claramente.

Cita de: xXchopliXx en Marzo 19, 2014, 10:24:32 AM
No hace falta para nada añadir ningún codigo de limpieza,ya que cuando creas el ejecutable del juego,todos los archivos se comprimen dentro del ejecutable.Es decir,esta todo cargado desde el principio y no te creas que ocupa mucho...

Pero no está preopcupado por el espacio en disco, sino más bien por el uso de RAM.

Cita de: roolandoo en Marzo 19, 2014, 10:00:48 AM
¿Sería recomendable poner TODOS los eventos de colisión en el objeto JUGADOR ó no ponerle ninguno y ponerlos uno a uno en cada uno de los enemigos?

No estoy seguro de dónde, me parece recordar que se recomienda poner los eventos de colisión en el objeto del cual haya menos instancias en la habitación, esto sería el jugador, pero yo no lo haría así. Poner todas las colisiones en un solo objeto se me hace muy desordenado/confuso, personalmente optaría por poner cada colisión con el jugador en el objeto enemigo. Si acaso hubiera diferencia en el desempeño, creo que sería algo que el usuario no notaría a la hora de jugar.

Cita de: roolandoo en Marzo 19, 2014, 10:00:48 AM
Hay que tener en cuenta que en cada fase podría tener varias (2 o 3) instancias de un mismo enemigo, además de varios enemigos diferentes.

Es muy relativo el número de enemigos y el tipo. El desempeño depende mucho de cuánto código en STEP lleve cada enemigo y qué tan optimizado esté ese código, pero 10, 20 o 30 enemigos por habitación no creo que causen problemas.

Cita de: roolandoo en Marzo 19, 2014, 10:00:48 AM
¿Convendría ejecutar algún código de limpieza de memoria o algo parecido para no ir acumulando basura a lo largo del juego?
¿Cómo se haría ésto?

A lo mejor te interesa la dll "cleanmem" que libera el exceso de memoria del juego. he leído buenas referencias de ella aunque no la he usado aun.
http://gmc.yoyogames.com/index.php?showtopic=438215

Según entiendo, al cambiar de habitación, las instancias no persistentes se destruyen automaticamente, aunq ue de todas maneras he visto que muchos makeros aconsejan destruír instancias en el evento [ROOM END].

Sobre las colisiones, quizás lo mejor es hacer un objeto padre y hacer que todos los enemigos sean sus hijos, de esta manera sólo necesitarías un evento de colisión para manejar cualquier colisión con cualquier enemigo.

Es posible, pero... ¿tú crees que si mucha gente juega tu juego, google (o la compañía que sea) no esta pendiente del ancho de banda que consume? ¿Crees que te permitan consumir un ancho de banda pequeño o grande por un servicio gratuito?

Aun así, como sé que ninguna advertencia servirá   :D

https://www.scirra.com/tutorials/419/upload-your-game-to-google-drive

Citar
osea, box2d viene a ser las physics?

Sí

Box2D está desactivado por defecto, sólo se habilita si el usuario lo especifica. Además es imposible usar Box2D en un entorno 3D

CitarMe choca que en GM8 todo iba a la perfección y ahora esto... algo del 3D que no sé de GMStudio? tanto ha cambiado?

Debido a que cada vez hay más diferencias y nuevas funciones, YoYo recomienda no importar  proyectos de versiones anteriores: por lo que si tienes un juego en GM8.x, lo mejor es terminarlo en el 8 o comenzarlo desde 0 en el GM:S.

De lo que he leído (no me llama el 3D de GM), se recomienda dibujar primero todos los objetos opacos y al final los objetos con transparencias. Otros recomiendan usar la función  draw_set_alpha_test(true) al inicio del juego.

Cita de: GioSama en Marzo 15, 2014, 11:03:40 PM
si yo creo un juego por ejemplo de goku, mario etc.... los de google play me lo pueden borrar por el derecho de autor??

La respuesta corta es sí. Y no tiene nada que ver que lucres o no, ni con que incluyas publicidad o no. Lo puedes consultar con un abogado.

El único caso en que legítimamente puedes usar material con copyright sería que el autor o quien ostente los derechos te de permiso por escrito para poder usarlos. O que explícitamente  se anuncie que dicho material puede ser usado por alguien más (como en el caso de las licencias creative commons). Cualquier otra manera es ILEGAL. Por más que pongas "todos los derechos pertenecen a xxx".

Ha habido casos en que compañias como nintendo y otras han ordenado el cese de fan games. Ahora, parece que hay muchos fan games que no tienen problemas ni son demandados, eso no quiere decir que no sean ilegales. Muchos opinan que mientras no lucres, el riesgo de que le pase algo a tu juego o te demanden es bajo. A mi se me hace que el riesgo siempre existe.

Cita de: LowHertzs en Marzo 16, 2014, 02:16:59 AM
si uso los .inis para no hacerlo con variables, por qué tengo que mezclarlas?

No es estrictamente necesario mezclarlas, pero por ejemplo, comparar valores en un IF es más fácil si esos valores se almacenan en variables. Si no almacenas el valor de una clave de un ini en una variable, el IF se volvería muy enredoso (largo), pero nada impide que así se haga.

Y si usas draw_background(back,x,y) con x relativo a la posición de view_xview?

Entonces probablemente sí debas agregar los temas al proyecto.

Una de las diferencias más importantes que hay que tener en cuenta al comenzar a usar GM:S es la manera en que funciona el sistema de archivos

http://docs.yoyogames.com/source/dadiospice/002_reference/file%20handling/file%20system%20limits.html

Cita de: DarkKRuleR en Marzo 15, 2014, 09:24:04 PM
No tengo marcado el usar las nuevas, pero no me reconoce sound_add. Tengo que cargar las músicas al proyecto? O sería muy lento? Porque no veo otra solución

El nuevo sistema viene activado por defecto. El viejo sistema por ende está desabilitado, por eso no reconoce sound add

Haciendo que la bala avance tanto en la coordenada horizontal x como en la vertical y

http://www.comunidadgm.org/manual_GM/Moviendose.htm

Es porque el GM:S usa un nuevo sistema de sonido, las funciones de sonido ya no son las del GM. ¨Pero si quieres seguir usando las mismas funciones viejas símplemente elijes usar el viejo sistema de audio en las settings

ini_read_real(section,key,default) Lee el valor real de la llave indicada con key de la sección indicada como section.  Cuando no existe la llave o la sección se devuelve el valor especificado por default.

El valor de la lectura se lo asignas a una variable en GM y luego pruebas si esa variable es 1 o no

ini_close();//cierra el archivo .ini
El cierre del ini se debe hacer solamente después de haber terminado las operaciones necesarias, es decir, después de que hayas leído o escrito en él.


El problema es que de momento no tienes idea de cómo está estructurado un archivo INI.

Un archivo INI tiene una o más secciones. Cómo especificas una sección, así
[NIVELES]           //Sección de nombre NIVELES

Una sección consiste de una serie de claves (keys) y valores
nivel1=0       //La clave nivel1 tiene un valor de 0

Al usar inis, no manejas directamente variables de GM, lees o escribes en los valores de las claves. Deberías seguir el tutorial de "saving" que viene incluído con el GM:S, ahí explican cómo trabajar con inis.

Cita de: Ruben3D en Marzo 13, 2014, 09:06:16 PM
Tambien he probado una alarm que sume a una variable +1 y que dependa del delta_time el salto de la alarma, le digo que por cada 60steps/delta_time, asi funciona perfecta al tiempo de un delta time, pero si le digo a la room que sea de 30steps, empieza a ir bien, pero pasado un minuto hay un desfase bestial con el tiempo real del delta_time que va cuadrado al reloj de windows, si game maker es asi de impreciso, es muy facil hacer juego para dispositivos potentes, pero muy malo para harware antiguo

Sólo como sugerencia, deberías reconsiderar el uso de delta time. Game Maker no está pensado para funcionar (de manera óptima ) usando delta timing. Como lo veo yo, usar delta time acarrea más contras de los pros que ofrece.

Las alarmas ya no van a funcionar de manera exacta. El tiempo delta trabaja con valores no enteros, las alarmas no soportan eso.

Cada variable relacionada con velocidad o tiempo tiene que estar expresada en relacion al tiempo delta

Las colisiones pueden "buguearse"

Ya no se pueden usar variables como gravity, vspeed, hspeed, direction, image_speed, todo habría que ajustarlo al tiempo delta, incluído la manera como mueves las views o fondos.

Los paths ya no se pueden usar como antes, se tiene que modificar su comportamiento para adaptarlo al tiempo delta

Problemas con las lineas de tiempo, puede que haya acciones que no se ejecuten o que se ejecuten en momentos que no deberían.

El teclado y el ratón se leen a intervalos de tiempo irregulares, y se leen menos veces por segundo, esto les resta respuesta y hasta podría afectar la jugabilidad.

Entre otros. Muchos usuarios prefieren usar frame skipping en lugar de delta time.