Comunidad Game Maker

Lo mejor es hacer pruebas y comprobar uno mismo si hay diferencia o no (Las pruebas podrían variar de usuario a usuario, porque cada proyecto es diferente y cada usuario tiene equipos distintos). Yo hice algunas pruebas y sí hay diferencia, pero no tanta (no como YoYo la anuncia)

http://www.comunidadgm.org/preguntas-y-respuestas/merece-la-pena-comprar-ahora-un-compilador/msg108801/#msg108801

Las pruebas fueron hechas en windows, desconozco cómo se comporte el YYC en android u otras plataformas.

¿En qué evento usas el código que pegaste? Nunca he usado esos efectos, pero ¿por qué estás usando una condición basada en un número aleatorio?

Cita de: Yoo en Febrero 17, 2015, 08:24:04 PM
Pero aki ya esta true como seria?

Si ya es true, el ciclo siempre se va a ejecutar, así de simple. Así como te puedes encontrar ejemplos de scripts buenos, te puedes encontrar con scripts "malos", que no tienen la manera más recomendable de hacer algo. No estoy diciendo que ese ciclo no funcione en el contexto que se usa, lo que digo es que en la mayoría de cursos de programación se hace hincapié en no usar ese tipo de condiciones, y al contrario, usar una condición que asegure la finalización del ciclo en algún momento.

Cita de: Yoo en Febrero 17, 2015, 08:24:04 PM
pero si la script esta en el evento step se repetiria de nuevo todo hasta la parte de tres(3|) donde comprobará si variable2 sigue siendo cero, y al resultar cierto lo de abajo osea la parte cinco(5|) ya no se realizaria, asi seria o como?

Si el script está en STEP y si variable2 es igual a 0, el script llegará hasta la línea 4, una y otra vez. El script ejecutará la línea 5 sólo cuando variable2 se cambie a un número distinto a 0.

Está correcto
if (desvanecer) equivale a if (desvanecer == true) 

if (!desvanecer) equivale a  if (desvanecer == false)

Personalmente prefiero el método corto, se me hace más pulcro, pero ambos funcionan.

Y si el comportamiento no nos convence, también uno mismo puede crear su propia función draw_text personalizada que admita el texto a desplegar y el color para el texto, todo en la misma linea/función. Eso es lo bueno de los scripts

Pueden ser muchas cosas, sólo tú sabes qué cosas hace cada objeto en tu juego. ¿Alguno o varios objetos hacen algo especial, fuera de lo común? Quizás uno o varios objetos están repitiendo un proceso en STEP continuamente, cuando debería ocurrir sólo una vez. Puedes ir probando/descartando objetos uno por uno hasta dar con el culpable

http://www.comunidadgm.org/preguntas-y-respuestas/191qu233-afecta-para-que-los-juegos-sean-lentos/

Revisa qué cantidad de RAM y CPU usa el juego al comienzo y compáralo con la RAM y CPU que usa cuando se pone lento. Usa draw o la función show_debug_message junto con instance_count() para comprobar que el número de instancias activas no aumenta drásticamente.

Abres una habitación, te vas a la pestaña settings y ahí haces click en el botón Creation Code. Se abre un editor de código y ahí colocas la posición inicial de la rana en esa habitación. Lo que dijo Clamud es importante, usar un objeto puerta distinto por cada habitación es muy poco recomendable

En celulares de especificaciones bajas 60 fps podría afectar el rendimiento, 30 fps se sigue usando hoy día, incluso en juegos de la última generación de consolas.

http://atomix.vg/2014/12/11/dying-light-correra-a-30-fps-en-ps4-pero-podria-cambiar/
http://www.levelup.com/noticias/290461/The-Evil-Within-correra-a-30-fps-incluso-en-PC
http://www.muycomputer.com/2014/10/19/far-cry-4-1080p-30-fps
http://www.meristation.com.mx/xbox-one/noticias/forza-horizon-2-correra-a-30-fps-y-1080p-en-xbox-one/1982583/1983099

También funciona si en el evento "Creation Code" de la habitación room1 defines la posición x e y de la rana

No sé qué signifique, pero creo haber leído que no era malo, no hay riesgo de que se corrompa el proyecto o pierdas información. Antes también veía ese mensaje, pero con las actualizaciones ya no me aparece desde hace meses.

Difícil saber cómo afecta a los usuarios esta medida. Puede que mantengan al equipo de desarrolladores original, puede que hagan cambios. Puede que GMS mejore, o puede que empeore, o que se mantenga igual. Quién sabe qué planes tengan los nuevos dueños, pero me resulta curioso que la operación de compra es buscando que PlayTech tenga presencia en el sector de juegos casuales.

En  'Status & Review' hay que activar la opción que dice

"Do you want to make this app and all its live features available to the general public?"

Guía (en inglés)
http://www.ning.com/ning3help/enable-social-sign-in-with-facebook/

CREATE[gml]
t_max = room_speed * 120     //Dos minutos
t_player = 0
tiempos[0] = 0; tiempos[1] = 0;  etc etc //según la cantidad de niveles del juego
habitacion = 0
puntuacion = 0[/gml]

STEP[gml]
t_player += 1[/gml]

CUANDO SE TERMINE UN NIVEL[gml]
var tiempo = t_max - floor(t_player/room_speed)
if (tiempo >= 0)
{
     tiempos[habitacion] = tiempo
     puntuacion += tiempo
}[/gml]
La variable habitacion se debe aumentar en 1 cuando el nivel actual se haya terminado y se vaya a cambiar a la siguiente habitación. Yo usaría el botón "Creation Code" de cada room para aumentarla(excepto el primero). Cuando el juego termine, cada elemento del arreglo tiempos tendrá el tiempo restante de cada nivel, y se usaría el arreglo para imprimir la tabla. Puede faltar algo, pero es una idea básica de ejemplo.

Creo que no hay virtual keys redondas, porque el código para definirlas siempre esta basado en dos esquinas, y no hay otro. Se puede colocar un sprite redondo en la zona de tecla virtual, pero para GMS, el área activa seguirá siendo un rectángulo.

Si el dibujo original de la espada tiene la misma orientación que el dibujo original del jugador, Y si la espada siempre va a tener la misma dirección del jugador, no es necesario hacer una comprobación, solamente

STEP espada
[gml]image_xscale = obj_player.image_xscale[/gml] Si la espada no está orientada como el jugador, sino al revés, sólamente se agrega un signo "-" menos a obj_player.image_xscale

Si de todas maneras, se quiere hacer una comprobación de la dirección del sprite del jugador, en cualquier objeto (no sólo en la espada)

STEP del objeto[gml]
var dir_sprite_player =  sign(obj_player.image_xscale)

if (dir_sprite_player > 0)
{
      //jugador mira a la derecha
}
else
{
      //jugador mira a la izquierda
}[/gml]

Cita de: Alejandro4231 en Febrero 16, 2015, 03:56:48 AM
y otra duda es si tambien tengo que hacer un sprite de la espada a parte como la del disparo

Tienes dos opciones
a) Hacer un objeto aparte y asignarle un sprite con la animación de la espada
b) Hacer un sprite de tu jugador atacando con la espada (al momento de atacar, se cambiaría el sprite "normal" del jugador por el de atacar. Al finalizar el ataque, se cambiaría el sprite nuevamente al "normal". Esto no necesita una espada aparte.

Dependiendo del método que prefieras, es el código a usar. Esto es más o menos lo que se debe hacer si se elige a):

[spoiler]Para "disparar" la espada, tienes que crear un objeto espada y agregarle el sprite de la espada atacando (ya sea un sprite de una sola imagen o una animación. Suponiendo que al presionar la tecla "X" atacas con la espada (en el objeto jugador)...
[gml]
if (keyboard_check_pressed(ord('X') )
     espadazo = 1

if (!keyboard_check(ord('X') )
     espadazo = 0

if (espadazo)
{
     if !instance_exists(obj_espada)
          instance_create(x + 20*image_xscale , y, obj_espada)   //Esto crea al objeto espada
}[/gml]

El objeto espada se debe borrar, de lo contrario va a seguir en la escena todo el tiempo. Suponiendo que es un sprite animado.
EVENTO ANIMATION END del objeto espada
[gml]instance_destroy()[/gml]


[/spoiler]