Comunidad Game Maker

[gml]switch (foobar) {
    case 1:
        show_message("La variable vale 1.");
        break;
    case 2:
        show_message("La variable vale 2.");
        break;
    case "foo":
        show_message('La variable tiene el valor "foo".');
        break;
}[/gml]
El valor de la expresi?n que le pases al switch (en este caso una variable llamada foobar) se compara con el valor de cada case, y si hay una coincidencia, se ejecuta el c?digo que precede al case hasta el break.
El c?digo anterior es equivalente a este:
[gml]if (variable == 1) {
    show_message("La variable vale 1.");
}
if (variable == 2) {
    show_message("La variable vale 2.");
}
if (variable == "foo") {
    show_message('La variable tiene el valor "foo".');
}[/gml]
El switch tambi?n cuenta con un "case" especial llamado default:
[gml]switch (variable) {
    case 1:
        show_message("La variable vale 1.");
        break;
    case 2:
        show_message("La variable vale 2.");
        break;
    case "foo":
        show_message('La variable tiene el valor "foo".');
        break;
    default:
        show_message("La variable tiene otro valor.");
        break;
}[/gml]
El c?digo de default se ejecuta si ninguno de los anteriores cases se ejecut? (es decir que la variable no vale 1 ni 2 ni "foo").

La ventaja del switch es que s?lo ten?s que escribir la expresi?n a evaluar una vez.

Otra ventaja se puede apreciar considerando el siguiente switch:
[gml]switch (sprite_get_width(other.sprite_index)) {
    case 10:
        foo();
        break;
    case 20:
        bar();
        break;
    default:
        baz();
        break;
}[/gml]
Ese c?digo, usando ifs ser?a as?:
[gml]if (sprite_get_width(other.sprite_index) == 10) {
    foo();
} else if (sprite_get_width(other.sprite_index) == 20) {
    bar();
} else {
    baz();
}[/gml]
Ese c?digo es peor porque:
    a) Es m?s repetitivo.
    b) Es menos legible.
    c) En un switch, la expresi?n solo se eval?a una vez. Usando ifs, si la primera condici?n es falsa, la funci?n sprite_get_width se vuelve a llamar. Por lo tanto el c?digo est? menos optimizado. Una posible soluci?n ser?a:
[gml]var tmp = sprite_get_width(other.sprite_index);
if (tmp = 10) {
    foo();
} else if (tmp = 20) {
    bar();
} else {
    baz();
}[/gml]
Ah? la funci?n solo se llama una vez, pero se consume m?s memoria al guardar el valor devuelto en una variable, y el c?digo sigue siendo m?s lento.

En fin, el punto es que en algunas situalciones, el switch es la mejor opci?n ;).


Y una cosa m?s. Esto es una particularidad de C/C++, y no s? si se encuentra tambi?n en GML, pero me parece que s?, y a?n si no lo est?, me parece importante mencionarlo.
Consideramos el siguiente switch:
[gml]switch (5) {
    case 1:
        foo();  // Esto no se ejecuta.
        break;
    case 5:
        bar();  // Esto se ejecuta.
    case 10:
        baz();  // Esto tambi?n (!!!).
        break;
    case 11:
        game_end();  // Esto no.
        break;
}[/gml]
La expresi?n a evaluar de ese switch es 5. Primero la compara con 1. 5 no es igual a 1, por lo tanto salta al siguiente case. El siguiente case es 5, y 5 es igual a 5, por lo tanto lo ejecuta. Luego, uno pensar?a que el int?rprete se sale del switch y comienza a ejecutar lo que sea que viene luego, pero el int?rprete no se sale del switch hasta no encontrarse con un break, por lo que el case 10 tambi?n se ejecuta por completo.
Es algo a tener en cuenta. En parte porque puede ser ?til, pero m?s que nada porque puede generar grandes bugs dif?ciles de encontrar, o puede ir acumulando bugs peque?os que hacen que el juego poco a poco y solo a veces, comience a funcionar mal. Esos bugs s? que son jodidos, y muy dif?ciles de localizar.
El est?ndar de C++ recomienda (y es una buena pr?ctica hacerlo en GML tambi?n) que cuando se cree un case sin break a prop?sito, se coloque un comentario que lo indique. Algo as?:
[gml]switch (5) {
    case 1:
        foo();
        break;
    case 5:
        bar();
        // Sin break.
    case 10:
        baz();
        break;
    case 11:
        game_end();
        break;
}[/gml]

Y eso es todo. Espero haber sido claro ;).

Hmm. Prob? a poner el jugador como no s?lido.

Cita de: MaanuRP en Agosto 26, 2011, 05:40:34 PM
Buena idea, pero sigue igual :/

?Tsk! :(

Cita de: elviskelley en Agosto 26, 2011, 06:31:29 PM
en el event step de la plataforma.
if place_meeting(x+4,y+16,objPlataforma)
{with(objJugador){x*=-1;}}
if place_meeting(x-4,y+16,objPlataforma)
{with(objJugador){x*=-1;}}

?Lo probaste? Porque creo que eso har?a que el jugador desaparezca misteriosamente.

No puedo ver el editable, as? que estoy hablando a ciegas, pero prob? a poner esto en el evento de colisi?n con la plataforma:
[gml]if (y > other.y) {
    move_outside_solid((other.x < x) * 180, 10);
}[/gml]

La respuesta es "s?" a ambas cosas.

Por cierto, antes se me hab?a pasado: en el primer post del tema pon? el ?cono de la versi?n de GM que us?s.

Deber?as definir las variables en el evento create del parent, poni?ndoles un valor gen?rico:
[gml]vida = 6;
dano = 3;[/gml]
Despu?s, si cre?s un objeto, le asign?s ese parent, y no le pon?s evento create, el objeto hereda el create del parent y por lo tanto tiene la variable "vida" con valor 6 y la variable "dano" con valor 3.
Si quer?s que tenga un valor distinto, us? esto en create:
[gml]event_inherited();  // Esto ejecuta el create del parent.
vida = 5;[/gml]
Ah? tendr?a "dano" con valor 3 pero "vida" con valor 5.

Tambi?n pod?s hacer esto:
[gml]file_text_write_string(foo + chr(13) + chr(10));[/gml]
Dependiendo de la situaci?n, te puede convenir m?s.

En fin.

Cita de: MaanuRP en Agosto 07, 2011, 03:12:48 AM

Cita de: Wadk en Agosto 07, 2011, 03:00:51 AM
Como dice Masterkey

MaanuRP :) jajaj

?Oops! :-[
Ahora lo arreglo :P.

@p34: Qu? bien que te haya servido :). Suerte con tu juego.

Como dice MaanuRP, si al destru?r la pared tambi?n se destruye el objeto, no deber?a haber problema. La pared desaparece por completo y las balas pueden pasar tranquilamente.
Por otro lado, si la pared se destruye, pero el objeto no, pod?s ponerle este c?digo para "destru?rla":
[gml]solid = false;
visible = false;[/gml]

Y este c?digo en el evento de colisi?n de la bala con la pared:
[gml]if (other.solid) {
    // ...
}[/gml]
(Donde dice "// ..." va el c?digo que hay actualmente.)

Tener un objeto s?lido parent de todas las paredes es un muy buen m?todo, deber?as dejar el juego as?.

Si no me equivoco, el parent es un atributo del objeto, no de cada instancia, y por lo tanto no se lo pod?s sacar a cierta instancia sin sacarlo de todas las dem?s. Si eso te sirve, creo que era con object_set_parent o algo as?.
Pero no se me ocurre para qu? querr?as hacer eso. Modificar el parent de un objeto durante el juego no es algo normal, y va contra los principios de la programaci?n orientada a objetos. Mejor explic? qu? es lo que quer?s hacer, y qu? te hace pensar que esa es una buena forma de hacerlo.

Cita de: DarkKRuleR en Agosto 04, 2011, 06:42:15 PMpero SIGO TENIENDO la duda de qu? va antes, si el evento create o el c?digo que pones en el objeto en el editor de rooms!  :o

Este tipo de cosas pod?s comprobarlas vos mismo en menos de cinco minutos ;).

Cita de: brunoxzx en Agosto 02, 2011, 02:44:11 AM

Cita de: Wadk en Agosto 02, 2011, 02:00:30 AM

Cita de: brunoxzx en Agosto 01, 2011, 09:22:17 PM
No, la primera linea estaba encriptada con una clave distinta a la segunda.

?De qu? l?neas me est?s hablando? XD

De las 2 lineas del archivo de texto, cada una estaba encriptada con una clave distina  :o.

Oh, ?as? que el archivo era de texto plano? Yo lo tom? como un archivo binario.

Cita de: MaanuRP en Agosto 02, 2011, 02:28:53 AM

Cita de: Wadk en Agosto 01, 2011, 08:45:12 PM
El valor de todas las variables se guarda en la RAM, entre otras cosas.

Y eso como lo haces? jajaj

Us? un programa que hizo un amigo hace tiempo en C.

Cita de: brunoxzx en Agosto 01, 2011, 09:22:17 PM
No, la primera linea estaba encriptada con una clave distinta a la segunda.

?De qu? l?neas me est?s hablando? XD

El valor de todas las variables se guarda en la RAM, entre otras cosas.

Cita de: brunoxzx en Agosto 01, 2011, 01:30:17 AM
eran 2 claves no una.

?Dos claves? Yo us? una sola. Si lo que hiciste fue encriptarlo dos veces, seguramente creaste una redundancia.

Cita de: brunoxzx en Agosto 01, 2011, 12:15:52 AM

Cita de: Wadk en Julio 31, 2011, 06:33:35 PM
Yo acepto el reto ;).
EDIT: Listo :P. Adjunto el archivo de puntuaci?n.

Para mi que descompilaste el juego  :P, nah la verdad lo dudo pero tengo que admitir que yo no habr?a podido, lo que me lleva a preguntar: ?como lo hiciste? para despu?s justificar que mi m?todo de encriptaci?n era bueno, diciendo: pues el reto no era para dioses en programaci?n.

Captur? la clave explorando la RAM. ;)