Arquitecturas MMOG

1,121 views
993 views

Published on

Una ligera introducción a las arquitecturas software para MMOG más comunes.

Aunque le faltan algunos retoques (la actualizaré en breve) creo que está presentable

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,121
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Arquitecturas MMOG

  1. 1. Virtual reallity software architecture Massive Multiplayer Online Games Miguel Ángel Pastor Olivar http://miguelinlas3.blogspot.com http://twitter.com/miguelinlas3
  2. 2. Categorías de juegos <ul><li>Single Games: jugadores individuales
  3. 3. Online Games: múltiples jugadores
  4. 4. Massive Multiplayer Online Games (MMOG) </li><ul><li>Role
  5. 5. First person shooter
  6. 6. Real time strategy
  7. 7. Sports, racing
  8. 8. Social game </li></ul></ul>
  9. 9. MMOG:Reparto del mercado
  10. 10. MMGO:Suscripciones activas
  11. 11. MMGO: Total suscripciones
  12. 12. MMOG Características principales
  13. 13. Características <ul><li>Mundo virtual personalizable
  14. 14. Acciones repercuten en el mundo de otros jugadores
  15. 15. Mundo virtual y personajes persistentes a lo largo del tiempo
  16. 16. Gran número de usuarios concurrentes
  17. 17. Necesidad de autenticación para jugar </li></ul>
  18. 18. Características <ul><li>Comunicaciones seguras: evitar cheating
  19. 19. Velocidad de juego
  20. 20. Rendimiento
  21. 21. Fácil escalabilidad
  22. 22. Distribución múltiples procesadores </li></ul>
  23. 23. Arquitectura Cliente - Servidor
  24. 24. Enfoque tradicional <ul><li>Servidor central y varios clientes
  25. 25. Arquitectura multicapa </li></ul>Encrypt Server Message Tier Message Tier Client Encrypt Network Network
  26. 26. Capa de aplicación <ul><li>Patrón publisher-suscriber </li></ul>Cliente 1 Cliente 2 Cliente N Cliente 3 Suscribe Suscribe Suscribe Modificar VW Interested Server
  27. 27. Arquitectura servidor En/Decrypt WorldDB World Governor Groups AI Controller Authentication Governor UserDB Network Component World Component User Component Messenger Network
  28. 28. Escalabilidad: multiservidor <ul><li>Cientos de miles jugadores simutáneos </li></ul>
  29. 29. Ventajas <ul><li>Control centralizado
  30. 30. Nivel alto de seguridad de información
  31. 31. Estructura relativamente simple
  32. 32. Facilidad de diseño de juegos
  33. 33. Modo sencillo de escalabilidad </li></ul>
  34. 34. Desventajas <ul><li>Alto coste de instalación
  35. 35. Mantenimiento costoso
  36. 36. Grandes necesidades de ancho de banda
  37. 37. Escasa flexibilidad
  38. 38. Desaprovechamiento de recursos caros </li></ul>
  39. 39. Arquitectura Distribuida Peer to Peer
  40. 40. Requisitos:Distribución <ul><li>Arquitectura completamente distribuida
  41. 41. Particionado del mundo virtual
  42. 42. Gestión de datos
  43. 43. Algoritmos de coordinación </li></ul>
  44. 44. Requisitos:Consistencia <ul><li>Mundo virtual consistente entre jugadores
  45. 45. Esencial: alteraciones del mundo virtual
  46. 46. Importante el orden de eventos </li></ul>
  47. 47. Requisitos:Auto-organización <ul><li>24 x 7 x 365
  48. 48. Sin embargo, los usuarios se desconectan
  49. 49. Necesidad de reorganizar pérdidas
  50. 50. Adaptación autónoma por parte del juego </li></ul>
  51. 51. Requisitos:Persistencia <ul><li>MMOG persisten durante años
  52. 52. Necesario detectar cambios entre logins
  53. 53. Mundo virtual continua evolucionando
  54. 54. Necesidad información histórica mundo virtual </li></ul>
  55. 55. Requisitos:Disponibilidad <ul><li>Alta disponibilidad
  56. 56. Tolerancia a fallos
  57. 57. Multidispositivo </li></ul>
  58. 58. Requisitos:Interactividad <ul><li>Generalmente interactividad intensa
  59. 59. Garantizar la jugabilidad
  60. 60. Minimizar tiempos de respuesta (dependiente) </li></ul>
  61. 61. Requisitos:Escalabilidad <ul><li>Número elevado de jugadores
  62. 62. Característica principal sistemas P2P
  63. 63. Ejemplo problemática: ancho de banda </li></ul>
  64. 64. Requisitos:Seguridad <ul><li>Cheating
  65. 65. Virtual crime: lenguaje ofensivo, fraude
  66. 66. Dependiente del juego
  67. 67. Algunas soluciones: voting,logging system </li></ul>
  68. 68. Requisitos:Eficiencia <ul><li>Elevado consumo de recursos </li><ul><li>CPU
  69. 69. Memoria
  70. 70. Ancho de banda </li></ul><li>Minimización recursos peers
  71. 71. No puede ser influenciada por el desarrollador </li></ul>
  72. 72. Requisitos:Mantenibilidad <ul><li>Constante en el tiempo
  73. 73. Prevención del cheating
  74. 74. Sencillo en arquitecturas cliente-servidor </li></ul>
  75. 75. Aproximación P2P Overlay
  76. 76. Aproximaciones <ul><li>DUT: Topología no estructurada no centralizada
  77. 77. DHT : Topología estructurada no centralizada ( Pastry )
  78. 78. Scribe : multicast (nivel app) sobre Pastry
  79. 79. Colyseus : localidad y previsibles patrones de acceso a datos </li></ul>
  80. 80. Aproximaciones <ul><li>Híbrido: DHT + DUT
  81. 81. Reparto de recursos sobre DHT
  82. 82. Asignación de eventos
  83. 83. Evento modificación: broadcast
  84. 84. Problemática: unicidad del manejo de eventos </li></ul>
  85. 85. Arquitectura Pastry Interface Pastry Application Game Interface Cooperation Management Neighbour discover ARPL Algorithm Manage module Agent Module Resource Mgmt Security module Game Logic Rendering UI Systems Script Mod Network Data Mgmt Physics
  86. 86. Node joining <ul><li>Autenticación
  87. 87. Descarga de información de usuario
  88. 88. Búsqueda del manager local
  89. 89. Registro de información del resto de managers
  90. 90. APRL: asignación de eventos </li></ul>
  91. 91. Neighbour Discovery <ul><li>Busqueda de managers vecinos
  92. 92. Intercambio de información de agentes
  93. 93. Si conjunto vacío se registran agentes locales en vecino
  94. 94. Reemplazados ante una nueva unión </li></ul>
  95. 95. Cross Domain and Failure <ul><li>Cruce de fronteras
  96. 96. Notificación de vecinos: antiguos y nuevos
  97. 97. Deberán ejecutar el algoritmo ARPL
  98. 98. Ante un fallo; el resto de agentes serán notificados </li></ul>
  99. 99. Conclusiones
  100. 100. Conclusiones y retos <ul><li>Mercado interesante: tendencia creciente
  101. 101. Cliente-Servidor: mantenimiento y recursos
  102. 102. Arquitecturas distribuidas: mundo real?
  103. 103. Complejidad elevada: soluciones híbridas
  104. 104. Nuevas tendencias: enfoque cloud </li></ul>

×