Comunidad Game Maker

Hola comunidad

Bueno, tras años con GameMaker, he decidido pegar el salto y empezar a hacer algo con multijugador en linea. Y ue pensado en hacer un juego del estilo .io para android, usando un servidor en Python 3. Por ahora eso no es problema, el problema reside en que como manejo el IA.. es decir, ya sea un IA global como podrian ser los triangulitos en diep.io o cualquier enemigo que no pertenezca a ningun jugador. Y además, si quiero que el equipo del cliente sea capaz de crear soldados, que hago.. creo todos los soldados en todos los clientes y que ellos se encarguen de procesarlos? Pero que pasa si en un cliente el soldado hace algo que en los otros no hace? Y ademas, si hago que el cliente sea quien procese el IA... que pasa si el cliente se desconecta, ya que el IA se "apagaria", y deberia poder controlarlo otro miembro de si equipo. Como podeis observar esto es algo nuevo para mi, no solo en GM, cualquier ayuda seria muy agradecida.

Gracias

Mmmm, para el caso de enemigos u objetos NPC (que se juegan solos) basados en IA me parece, nunca lo he intentado, que teóricamente, la mejor manera de gestionarlos es en el servidor, pero, esto aplicaría para casos en los que el servidor es también una aplicación de Game maker.

Ojalá se entienda XD
Y si no, es por que no soy bueno para el networking

En un principio, el servidor podría ser quien gestiona la IA y manda las actualizaciones a los clientes. Si uncliente se desconecta no pasa nada, ahora si el servidor se muere, logicamente todos los jugadores dejarán de poder jugar. Lo usual, basicamente.
La fornma en que se deberia estructirar es 1 sevidor y n clientes. No el usual cliente/servidor que a la vez que juega administra, dentro del mismo proceso, al servidor. deberían estructuralmente ser procesos distintos dentro de la misma maquina si se quiere, o en otra aparte.
eso si, el servidor tiene que tener una conexion buena para administrar los datos entrantes, esto en cuando a capacidad de carga y descarga que tenga la red de internet. Y por otro lado, un procesador que se banque , justamente el procesamiento de los datos... que claro, es tambien lo usual, basicamente.
La idea de transmitir datos es dejarlo en la minima expresion, me acuerdo cuando trabajaba con una user de acá con la 39DLL, ésta traia funciones para enviar determinados tipos de datos, cuya abstraccion era proxima a C, y los tipos de datos a manipular eran tan pequeños que llegaban a 8bit, de los cuales si se operaban de forma optima podias usarlo como un 8 bits sin signo, lo cual le da más margen para representar datos.
nosotros lo que haciamos era, usar uno de 16bits sin signo y al menos en GM8 las instancias tenian la forma aproximada de: 100513, obviavamos el 100 inicial, metiamos la id dentro de los 2bytes y dentro de eso poniamos unos cuantos numeros extras que indicaban el socket de donde provenia el mensaje, y una accion extra, codificada claro, para indicar si tenia que destruirse, moverse, o algo por el estilo.
Y bueno un montonaaaaazo de optimizaciones extra como que el servidor era quien mapeaba el nivel, hacia una lista con los objetos que se podian llegar a destruir y los mapeaba. Luego los movia/destruia segun llegaba la orden o se procesaba. Para ls elementos que se movian solos, por ejemplo plataformas moviles, eso lo administraban los clientes. En el peor de los casos, si alguno se llegaba a desincornizar lo que haciamos era un promedio entre las posiciones de todos estos elementos y los actualizabamos, lo cual a veces hacia que se pegara un lagazo cada q se conectaba alguien, pero era lo que habia xD

Un monton de cosas pueden pasar dependiendo de lo que requiera tu juego, qué cosas hacen falta sincronizar y que otras no, o lo minimo.
Pero siempre tratando de enviar al server o a los clientes, una cantidad de datos que sea optimo y rapido.Para no generar ese cuello de botella. Y aqui es donde entra la cuestión de usar UDP, además.