Comunidad Game Maker

Ey, muy bien; ya está todo corregido.

No se borran, solo fue por ese inconveniente con al base de datos.
Puedes volver a preguntar y se te responderá (Si sabemos la respuesta  :-[ ).

Sí, es muy recomendable. Evita escribir código, y permite un mejor control sobre los objetos así como sobre los eventos.
Yo incluso llegué a poner un objeto como padre de todos (Enemigo, paredes, armas, items...) con una variable que indica el tipo de objeto que es.  :P
La característica sobre si es sólido o no se sobreescribe en cada hijo.

Sí se generan 4, pero quién sabe dónde   XD

El problema es que estás poniendo como coordenadas (x o y) la variable "objJugador" que lo que hace es tomar el valor del id de la primera instancia del jugador. Debes hacer referencia a objJugador.x y objJugador.y; así:



instance_create(objJugador.x+90,objJugador.y,obj_Bola_Orbital);
instance_create(objJugador.x-90,objJugador.y,obj_Bola_Orbital);
instance_create(objJugador.x,objJugador.y+90,obj_Bola_Orbital);
instance_create(objJugador.x,objJugador.y-90,obj_Bola_Orbital);
instance_destroy();


Una de las razones es que el creador del ejecutable (nosotros) no está registrado en las bases de datos del AVAST... no hay mucho que hacer.

Mira, lo que recomiendo es que dividas el código en "partes". O sea, si vas a repetir el mismo código de disparar en muchas partes, haz un script con ese código y solo llámalo cuando sea necesario.

Si lo que quieres es que el personaje se detenga al presionar la tecla 'Z', cambia la variable hspeed a 0

    hspeed=0;
    sprite_index = spr_jugador_anda_derecha; //según sea el caso
    scr_disparar(); //El script que contiene el código para disparar


El código para disparar deduzco que sería algo como el siguiente:
scr_disparar()

if (sprite_index = spr_jugador_anda_derecha)
{
  instance_create(x,y,obj_bala);
  sound_play(snd_bang);
  action_sprite_set(spr_dispara_derecha,0,0.4)
}
else
{
  instance_create(x,y,obj_bala);
  sound_play(snd_bang);
  action_sprite_set(spr_dispara_izquierda,0,0.4)
}


Quiero suponer que el GMS tiene la facilidad de obtener una fotografía mediante la cámara ¿no?

Pues de allí tienes que buscar una librería (c++ o android) que puedas añadir a tu aplicación y que sirva para manejar códigos QR.

La verdad estás pidiendo algo que se aleja mucho del principio del GM que es meramente crear vídeo-juegos, por eso tienes que recurrir a recursos externos que te permitan hacer cualquier otra cosa  :-\

Concuerdo con lo que dice clamud, debes posicionar la view en un punto intermedio de ambos jugadores. Deberás estar calculando ese punto intermedio a cada paso.
Una forma sería:

Citar
intermedio=(jugador1.x + jugador2.x) / 2

La variable "intermedio" sería la coordenada x en la cual se posicionaría la vista; supongo que la altura del cuarto será el mismo.
También debes de poner la restricción a ambos jugadores de que no se puedan salir de la vista.

Los valores TRUE y FALSE son valores lógicos.
Verás, una variable puede tener (en principio) 3 tipos de valores:
Numéricos, o sea números  :-[ como puede ser: 1, 2, 3, 4.36, -14.12...
Valor del tipo texto, letras y cadenas de letras: "h", "Hola" "ola ke ase"...
Y valores lógicos (En informática se llaman "booleados") que tiene sólo los valores TRUE y FALSE (Verdadero y False).

Usas el tipo de valor según las necesidades que tengas (y la lógica que uses así la forma en la que te acomodas a la hora de programar).

Si lo que quieres "desactivar" una variable justo después de ejecutar una acción, escribes:

variable=false;

En este caso:

Citarhspeed=xxxx; //salta
variable_salto=false;

Vaya, que bien que regresas Elvis.
Lo creas o no, no fue agradable que te fueras de la comunidad, y menos de una forma así. Pero pues, como siempre, cada uno es libre de lo que quiera (Un berrinche todos hemos querido hacer y hasta hemos hecho). Y no te preocupes, cada quien ha pasado momentos frustrantes (Algunos más y algunos menos) así que se entiende todo.

Bienvenido de nuevo; y aunque no sea de manera oficial, si que esperamos una GIA  XD

También hace falta tomar en cuenta el lado técnico, definitivamente matiascarpello tiene razón a la hora de decir a qué plataforma correrá la aplicación, así como los FPS, resolución de las imágenes, uso de sonidos, procesos en segundo plano y demás. Pero basándose en la arquitectura de una computadora (Que es la base de todo dispositivo como SmartPhone, ipad, tablet, etc) opino lo mismo que Iros:

1) Considerando que en sumatoria son las mismas líneas de código (o más o menos las mismas líneas), conviene usar pocos objetos con mucho código que muchos objetos con poco código. ¿Por qué? En primera, cada objeto se pasa a memoria cuando se está ejecutando; si tiene 50 objetos es menos espacio que 200 objetos. Además, Game Maker procesa los eventos de un objeto a la vez. O sea, que en cada STEP procesa un objeto y cambia a otro, así hasta terminar con todos los objetos. Hacer ese "cambio" de un objeto para procesar 200 es más la carga que hacer sólo 50 "cambios".

2) Pues... considera que el renderizado es el proceso más costoso de una computadora; ya que éste se hace en la tarjeta de vídeo y no se encuentra conectada tan "cercanamente" al procesador como es el caso de la memoria RAM, así que entre menos objetos tenga que renderizar le será mucho mejor para tu juego; estarías sacrificando costo en el procesador pero ahorrando renderizado. El costo de la memoria es "casi" la misma, ya que las imágenes que se están usando se cargan a memoria (cada subimágen).

3) Recuerda que los eventos STEPS, COLLISION y DRAW se ejecutan en cada Frame (cuadro) del juego. Así que entre menos uso hagas de éstos será mejor. Usa el STEP sólo en aquellas condiciones que se tengan que revisar cada cuadro; si la puedes reemplazar con cualquier otro (Evento de teclado, ratón, alarma, etc) te estarás ahorrando procesador. (Sé que muchos odian usar los eventos del teclado por lo inexactos).

Y ya que hablamos de tiempos, usa lo menos posibles las funciones de leer archivos de disco duro; es muy tardado abrir un archivo y pasarlo a la memoria y esto se puede ver reflejado por parte del usuario, ya que comúnmente la aplicación se "pausa" hasta haber leído todo el archivo. Claro, posiblemente este proceso dure 1/4 de segundo o menos, pero nada más te informo.

No has declarado antes (En el evento create) la variable "value"

agrégale otra condición al if para saber si hay alguna plataforma abajo :p

Citar
if(vhspeed>0 && !instance_place(x,y+16,obj_plataform))// El +16 sería la altura de tu personaje, por ejemplo
{
    sprinte_index= spr_cayendo;
}

Forzosamente debes poner un objeto a checar si existe abajo; así que si no usas parents para los pisos y plataformas, deberías empezar a usarlos.

Por cierto ¿Alguien sabe qué le pasó a la guía que había en la comunidad?  ???
Quise buscar las funciones allí pero ya no existe...

Técnicamente quieres que el sprite cambie cuando se esté "desplazando" hacia abajo sin importa el por qué ¿no?

Pues con una condición puedes hacer eso:


if(vhspeed>0) // Si se está desplazando hacia abajo...
{
    sprinte_index= spr_cayendo;
}


Siempre he querido usar así la 39Dll  :'( pero la flojera me gana  XD

Mira, vi tus programas. Lo que sugiero que hagas es que el mismo objeto "Tiempo" que tienes en el cliente, lo pongas en el servidor (sólo el evento create y la alarma, el Draw es innecesario).
Luego, en el objeto Tiempo del cliente, tú tienes esto en el create:

global.tiempo=0

En lugar de inicializarlo en 0, obtienes el valor del tiempo del servidor... no sé cómo se hace  :-[ pero seguramente tú sí jeje (¿Es con eso de external_call()?); el resto queda igual. De esa forma, cuando un nuevo jugador se conecte, el tiempo será el mismo que el del servidor y ya será el cliente el que correrá por su cuenta el tiempo :)