Juegos De Guerra De Robots Para Pc
Niki Wienberg
Nuestra coleccin es perfecta tanto para los entusiastas de los bots como para los novatos. Puedes construir a partir de una variedad de materiales, construyendo la mquina perfecta para competir con oponentes. Usa hojas de sierra, motosierras y rifles de alta potencia para destruir a tus enemigos! Nuestros juegos de robots son la solucin definitiva para sus necesidades de juego de droides y bots. Juega con monstruos, perros de metal y una gran cantidad de otras formas de robots. Dirgete a la batalla y lucha con tu propia mquina hoy!
Nuestros juegos de robots son fciles de controlar y divertidos de jugar. No importa lo complicada que sea su creacin, podr controlarla con facilidad. Simplemente use su teclado para conducir, moverse y saltar con su mquina. Lanza armas, dispara y realiza trucos con simples pulsaciones de teclas! En nuestra coleccin, puedes resolver acertijos, construir mquinas asesinas y jugar a la accin de alto octanaje. Empiece a cargar chapa, disee un plan de robot y preprese para el ataque de las mquinas!
Los robots se pueden utilizar literalmente para cualquier cosa, y en los juegos de navegador pueden ser simplemente increbles. Algunos juegos de robots te permiten crear tu propia monstruosidad mecanizada y equiparla con armas mortales. Otros juegos de robots te permiten superar una serie de niveles de plataformas y utilizar poderes especiales de los robots.
Los juegos de robots son juegos que cuentan con robots. Su temtica vara desde juegos de plataformas de desplazamiento lateral hasta juegos .io, pero la mayora de ellos son juegos de accin que presentan construcciones hechas por el hombre que estn destinadas a imitar la vida.
War Robots celebra su dcimo aniversario este abril! Y hasta el da de hoy, continuamos desarrollndolo y brindndole soporte, no solo lanzando nuevas funciones para nuestros jugadores sino tambin mejorndolo tcnicamente.
Para mantener la funcionalidad de este tipo de proyectos y garantizar un mayor desarrollo de alta calidad, no basta con trabajar nicamente en las tareas inmediatas del producto; Tambin es clave mejorar su condicin tcnica, simplificar el desarrollo y automatizar los procesos, incluidos los relacionados con la creacin de nuevos contenidos. Adems, debemos adaptarnos constantemente al mercado cambiante de dispositivos de usuario disponibles.
Volvamos a 2014: el proyecto War Robots fue creado inicialmente por un pequeo equipo, y todas las soluciones tcnicas encajan en el paradigma de rpido desarrollo y entrega de nuevas funciones al mercado. En ese momento, la empresa no contaba con grandes recursos para alojar servidores dedicados, y as, War Robots ingres al mercado con un multijugador en red basado en lgica P2P.
Photon Cloud se utiliz para transferir datos entre clientes: cada comando de jugador, ya sea moverse, disparar o cualquier otro comando, se envi al servidor de Photon Cloud utilizando RPC separados. Como no haba un servidor dedicado, el juego tena un cliente maestro, que era responsable de la confiabilidad del estado del partido para todos los jugadores. Al mismo tiempo, los jugadores restantes procesaron completamente el estado de todo el juego en sus clientes locales.
Como ejemplo, no hubo verificacin de movimiento: el cliente local movi su robot como mejor le pareci, este estado se envi al cliente maestro, y el cliente maestro crey incondicionalmente este estado y simplemente lo reenvi a otros clientes en la coincidencia. Cada cliente mantuvo de forma independiente un registro de la batalla y lo envi al servidor al final del partido, luego el servidor proces los registros de todos los jugadores, otorg una recompensa y envi los resultados del partido a todos los jugadores.
Usamos un servidor de perfiles especial para almacenar informacin sobre los perfiles de los jugadores. Este consista en muchos servidores con una base de datos Cassandra. Cada servidor era un servidor de aplicaciones simple en Tomcat y los clientes interactuaban con l a travs de HTTP.
El enfoque utilizado en el juego tena una serie de desventajas. El equipo, por supuesto, saba de esto, pero debido a la velocidad de desarrollo y entrega del producto final al mercado, hubo que hacer una serie de concesiones.
Entre estas desventajas se encontraba, en primer lugar, la calidad de la conexin del cliente maestro. Si el cliente tena una mala red, entonces todos los jugadores de un partido experimentaban un retraso. Y, si el cliente maestro no se ejecutaba en un telfono inteligente muy potente, entonces, debido a la gran carga que tena, el juego tambin experimentaba un retraso en la transferencia de datos. Entonces, en este caso, adems del cliente maestro, otros jugadores tambin sufrieron.
El segundo inconveniente era que esta arquitectura era propensa a tener problemas con los tramposos. Dado que el estado final fue transferido desde el cliente maestro, este cliente podra cambiar muchos parmetros del partido a su discrecin, por ejemplo, contando el nmero de zonas capturadas en el partido.
En tercer lugar, existe un problema con la funcionalidad de emparejamiento en Photon Cloud: el jugador de mayor edad en la sala de emparejamiento de Photon Cloud se convierte en el cliente principal, y si algo les sucede durante el emparejamiento (por ejemplo, una desconexin), la creacin del grupo se ve afectada negativamente. Dato curioso relacionado: para evitar que el emparejamiento en Photon Cloud se cierre despus de enviar un grupo a una partida, durante algn tiempo incluso configuramos una PC simple en nuestra oficina, y esto siempre admita el emparejamiento, lo que significa que el emparejamiento con Photon Cloud no poda fallar. .
En algn momento, la cantidad de problemas y solicitudes de soporte alcanz una masa crtica, y comenzamos a pensar seriamente en evolucionar la arquitectura tcnica del juego; esta nueva arquitectura se llam Infraestructura 2.0.
La idea principal detrs de esta arquitectura fue la creacin de servidores de juegos dedicados. En ese momento, el equipo del cliente careca de programadores con amplia experiencia en desarrollo de servidores. Sin embargo, la empresa estaba trabajando simultneamente en un proyecto de anlisis de alta carga basado en servidor, al que llamamos AppMetr. El equipo haba creado un producto que procesaba miles de millones de mensajes por da y tena una amplia experiencia en el desarrollo, configuracin y arquitectura correcta de soluciones de servidor. Y as, algunos miembros de ese equipo se sumaron al trabajo de Infraestructura 2.0.
En 2015, en un perodo de tiempo bastante corto, se cre un servidor .NET, incluido en el marco Photon Server SDK que se ejecuta en Windows Server. Decidimos abandonar Photon Cloud, manteniendo solo el marco de red Photon Server SDK en el proyecto del cliente y creamos un servidor maestro para conectar clientes y los servidores correspondientes para el emparejamiento. Parte de la lgica se traslad del cliente a un servidor de juegos dedicado. En particular, se introdujo la validacin bsica de daos, adems de colocar clculos de resultados de partidos en el servidor.
Despus de crear con xito la Infraestructura 2.0, nos dimos cuenta de que necesitbamos seguir avanzando hacia la disociacin de las responsabilidades de los servicios: el resultado de esto fue la creacin de una arquitectura de microservicios. El primer microservicio creado en esta arquitectura fueron los clanes.
A partir de ah, apareci un servicio de comunicacin separado, que era responsable de transferir datos entre microservicios. Se ense al cliente a establecer una conexin con el "hangar" responsable de la metamecnica en el servidor del juego y a realizar solicitudes de API (un punto de entrada nico para interactuar con los servicios) utilizando UDP sobre Photon Cloud. Poco a poco, la cantidad de servicios creci y, como resultado, refactorizamos el microservicio de emparejamiento. Con esto se cre la funcionalidad de noticias, Inbox.
Cuando creamos clanes, estaba claro que los jugadores queran comunicarse entre s en el juego: necesitaban algn tipo de chat. Esto se cre originalmente en base a Photon Chat, pero todo el historial de chat se borr tan pronto como el ltimo cliente se desconect. Por lo tanto, convertimos esta solucin en un microservicio independiente basado en la base de datos de Cassandra.
La nueva arquitectura de microservicios nos permiti gestionar cmodamente una gran cantidad de servicios independientes entre s, lo que signific escalar horizontalmente todo el sistema y evitar tiempos de inactividad.
En nuestro juego, las actualizaciones se produjeron sin necesidad de pausar los servidores. El perfil del servidor era compatible con varias versiones de clientes, y en cuanto a los servidores de juegos, siempre tenemos un grupo de servidores para las versiones antiguas y nuevas del cliente, este grupo cambi gradualmente despus del lanzamiento de una nueva versin en las tiendas de aplicaciones, y Los servidores de juegos desaparecieron con el tiempo de la versin anterior. El esquema general de la infraestructura actual se denomin Infraestructura 4.0 y tena este aspecto:
Adems de cambiar la arquitectura, tambin nos enfrentamos a un dilema sobre dnde deban ubicarse nuestros servidores, ya que se supona que cubriran a jugadores de todo el mundo. Inicialmente, muchos microservicios se ubicaban en Amazon AWS por varias razones, en particular, por la flexibilidad que ofrece este sistema en trminos de escalamiento, ya que esto era muy importante en momentos de aumento del trfico de juegos (como cuando apareca en tiendas y para impulsar la AU). Adems, en aquel entonces era difcil encontrar un buen proveedor de hosting en Asia que proporcionara una buena calidad de red y conexin con el mundo exterior.
El nico inconveniente de Amazon AWS fue su alto costo. Por lo tanto, con el tiempo, muchos de nuestros servidores se trasladaron a nuestro propio hardware: servidores que alquilamos en centros de datos de todo el mundo. Sin embargo, Amazon AWS sigui siendo una parte importante de la arquitectura, ya que permita el desarrollo de cdigo que cambiaba constantemente (en particular, el cdigo de los servicios de Ligas, Clanes, Chats y Noticias) y que no estaba suficientemente cubierto por la estabilidad. pruebas. Pero, en cuanto nos dimos cuenta de que el microservicio era estable, lo trasladamos a nuestras propias instalaciones. Actualmente, todos nuestros microservicios se ejecutan en nuestros servidores de hardware.
d3342ee215