Comunidad Game Maker

Lee el reglamento de la seccion y arregla el post

As you wish lady. Es velocidad contra estabilidad resumiendo, aunque a grandes razgos. Probá ambos sistemas y tomá tu propia decisión, ya tenés todos los datos sobre el funcionamiento de ambos y un largo debate sobre cuál resulta más conveniente. Lo de los items agarrables ha de haber sido un problema menor, no tienen una trayectoria movil como las balas, simplemente hay que crearlos de un lado del juego y pasar los datos al otro, lo mismo para cuando se destruyan. En ese caso se habla de un envío de datos de única ejecución, para las balas sería ejecución constante y si hay muchas balas en pantalla hay que enviar datos por cada una en cada step o intervalo de tiempo

La version studio creo que queda fuera por el tema de la estabilidad, por ahora es un riesgo usarla, aunque ofrece una velocidad de ejecucion muy superior en los juegos. Entre los que mencionaste el mejor es el game maker 8 por simples razones. Tiene muchas mas funciones y lo mas importante, soporte para canales alpha

Me suena a kaillera xD
La desincronización de un juego así no es muy grave, es más que esperable, no es como en kaillera que los emuladores tienen que estar completamente sincronizados para funcionar. Con respecto al efecto que mencioné, no hablo de la latencia, hablo de datos que quedan en cola, y más datos que quedan en cola, y así infinitamente hasta que la cola es tan grande que lo que haces llega 20 segundos después a los demás. Como bien dijo ferhand, habría que hacer pruebas, pero es imposible probar lo que digo en un ejemplo dedicado, tendría que estar incrustado en un juego con mucho envío de datos, porque sino no saturarían el servidor.
PD: Con tu método sucedería otra cosa que no me gusta, recuerda que la latencia sube y baja constantemente, y la actualización de coordenadas a veces llegaría antes y a veces más tarde, produciría un efecto muy extraño en el movimiento de la bala, parecería una bala con epilepsia xD

No he confundido nada, a lo mejor has malinterpretado la parte en la que mencioné la desincronización y la latencia al mismo tiempo, pero me refería a que un juego en tiempo real no se puede mantener sincronizado con más de 500ms y es muy común obtener esas cifras con la 39dll. Además tené en cuenta que en una conexión p2p con la 39dll no se suelen obtener altas velocidades, de una conexión con una subida de 40kbps te quedarán 5 o 10 y se dividen entre la cantidad de jugadores, si en cada step tenés que enviar más datos de los que puede la conexión entonces se embotellan y se obtiene un asqueroso efecto, mucho peor que la latencia. Los bytes no sobran, todo suma y al final hay que andar rehaciendo códigos por no optimizar el envío de datos. La optimización de fps o la mecánica de sincronía se puede hacer después, primero lo primero, que es ahorrar cada bit como si de oro se tratase

Nono, digo por el ancho de banda que consume enviar muchas cantidades de datos, imaginate la cantidad de balas que pueden llegar a haber en pantalla, sumado al movimiento sprite, etc de los personajes, sumado a cuanto dato haga falta enviar, recibir, y eso para cada jugador conectado, es mucho. Cuando hacés un juego online tenés que optimizar más que nada el envío (y recepción por ende) de datos. Puede llegar a ocurrir deincronización si los fps fluctúan mucho, si, pero mucho peor sería la desincronización si terminás con datos que tardan 1 segundo o medio segundo en llegar al receptor, una catástrofe total, porque por más que trates de sincronizar luego las balas, los datos van a seguir llegando horrendamente tarde y eso no lo podés solucionar con ningún código. Hay ventajas en reajustar la posición de las balas, pero las desventajas las superan ampliamente, no resulta conveniente para nada. No voy a decirte que tengo razón porque creo que la tengo o porque teóricamente debería ser así, lo digo porque he probado ambos métodos y para wan conviene infinitamente lo que dije, cada byte cuenta

Si, si se programa bien funciona de maravilla. Además no hay que ser tan pesimistas con los fps, lo que más falla en un juego online es el envío de datos, los fps son muy secundarios

Mejor hacer que el cálculo de movimiento tenga en cuenta los fps y listo
En wan siempre va a haber desincronización, es mejor vivir con ella que tratar de sacársela de encima enviando más y más datos (cosa que la vuelve más grande) xD

PD: El número de mensajes de Silver_light coincide con mi número de puntos  :P

Es para una bala? Silver, es mejor enviar la dirección, la velocidad y las coordenadas iniciales en el byte y asignarlos al crear, que el cliente saque sus propios cálculos, sino es un mambrollo de datos volando de un lado a otro y jamás te va a funcionar bien en wan

Las grid más o menos, a mi me resultan cómodas para guardarlas y cargarlas, pero no traen demasiadas funciones útiles, la de búsqueda sería la que más destaca. Lo que uso con frecuencia para la 39dll son los stacks, resultan útiles en juegos de movimiento rpg por cuadrícula. Las list son las que más funciones útiles traen

Jaja, no hay problema, pero no tuviste en cuenta un par de aspectos. Para buscar un valor en un array hay que recorrer con un for, que es mucho más lento que ds_list_find_index. O para ordenar los valores de un array de forma ascendente, en un array es un dolor de cabeza, para las ds_list hay una función muy simple y eficiente. Para quitar un valor en un array lo mismo, tenés que andar recorriendo con un for de vuelta y moviendo todo de lugar, en la ds_list es una sola función. La diferencia principal radica en que las funciones internas que ejecuta la ds_list están previamente compiladas, y los scripts o códigos que vos crees con tus arrays son interpretados, la diferencia de velocidad es abismal

Ferhand, las listas son mucho más eficientes en muchos sentidos
Pero sí, básicamente necesitás ponerle un identificador a cada instancia cuando se crea y al asignar buscás con with(object) y comprobás que el identificador sea igual al que te enviaron

No es más facil así?
[gml]while argument0>360 {argument0-=360}
while argument0<0 {argument0+=360}[/gml]
Digo por la optimización, no es lo mismo sumar que dividir, hacer floor y multiplicar

Genial por los premios extra, me parecieron excelentes para motivar no sólo a los creadores sino también a los jugadores. Esto sí que no me lo esperaba, muchas felicidades a Wegame, y esperemos que aparezca pronto, antes de que otro reclame su premio XD

Se puede crear la ilusión de que se sigue en el mismo room cuando se pasa a uno nuevo, en los juegos de pókemon de gbc, gb y gba lo hacen, claro, en una cuadrícula de 32x32 es más facil, pero la teoría se puede aplicar sobre cualquier tipo de juego, simplemente tenés que hacer desde el final de un nivel se vea exactamente lo mismo que en el comienzo del siguiente y viceversa, entonces cuando hagas el cambio de room elegí cuidadosamente la posición en la que ponés al personaje (tendría que ser persistente para conservar su sprite, subimágen, chequeo de teclas, etc) y listo
Saludos!