2009-07-31 26 views
26

¿Alguien sabe dónde puedo encontrar ejemplos de diagramas de clases para el desarrollo de juegos RP? Algo similar a here sería bastante útil. No busco cosas que pueda copiar servilmente, sino solo por diferentes ejemplos que diagraman varias soluciones a los problemas que estoy descubriendo a medida que intento y escribo mis propias clases.Ejemplos del diagrama de clases para RPG (Juego de roles)

+7

Me encanta el que ha vinculado. Juro que la mayoría de nosotros los programadores, especialmente los que tienen trabajos de día ordinarios, solo debemos hacer juegos de rol para la experiencia catártica de escribir funciones como 'bool isLivingDead()'. – Gavin

+3

if (creature.isLivingDead() && hero.isSlayer()) hero.slay (creature); –

Respuesta

48

Sé Emmanuel Deloget de GameDev.net pero no estoy seguro de que elegiría usar el jerarca ¡Y él llegó allí! Demasiada herencia, no suficiente flexibilidad.

Si yo estaba escribiendo un juego de rol basado en texto (como lo he hecho en el pasado) se vería un poco como este (aunque no tengo tiempo para elaborar un diagrama para que, por desgracia):

  • criaturas, salones y artículos derivados de WorldEntity, con WorldEntity objetos dispuestos en una estructura compuesta , por lo que los artículos pueden vivir dentro de otros artículos, realizados por las criaturas, que existen dentro de las habitaciones. Implementar el patrón de visitante para WorldEntities podría funcionar bien.
  • CreatureType y itemtype clases que contienen los datos de la 'clase' para criatura individual y el artículo casos, que se refieren de nuevo a su objeto correspondiente de 'tipo'. (por ejemplo, base puntos de vida y estadísticas en el primero, puntos de vida actuales y efectos transitorios en este último). Podría implementar esto como listas prototípicas de propiedades que obtienen copiadas en instancias de criaturas o elementos cuando se crean . Puede implementar la propiedad herencia a través de una propiedad 'principal' para que una instancia específica de la criatura goblin se relacione con 'Guerrero guerrero duendecillo', que contiene una referencia parental al 'genérico goblin' CreatureType. Y así.
  • Salidas que son propiedad de su Habitación, y son de una manera, y que detallan la dirección de viaje , varias condiciones de paso, etc.
  • Áreas, que contienen grupos de habitaciones conectadas por alguna organización lógica.
  • Una clase freza para dictar donde se crean criatura y del artículo casos (por ejemplo. Que habitación, o en qué coordenadas), cuando se crean y con qué frecuencia, y desde que CreatureTypes y ItemTypes. Puede tener alguna lógica aquí para aleatorizar un poco las cosas.
  • hechizos, habilidades, capacidades, etc. todas derivadas de una clase de acción de base o interfaz que especifica requisitos previos (posición por ejemplo. Actual, puntos de mana, algunos grado de aprendizaje de una habilidad, etc). Normales comandos y acciones pueden ir también en este caso ya que a menudo tienen algún tipo de requisitos demasiado (por ejemplo. Comando de un 'sueño' requiere que usted no es ya dormir.)
  • Una clase FutureEvent que es esencialmente un retrollamada que inserta en una cola de prioridad para ejecutar en el futuro. Puede utilizarlos para programar rondas de combate, tiempos de enfriamiento de hechizos, ciclos de noche/día, lo que quiera.
  • Un hash/mapa/diccionario de pares nombre-> valor para estadísticas de jugador y artículo. No es seguro para el tipo pero apreciará la flexibilidad más adelante. En mi experiencia haciendo estadísticas las variables miembro es viable pero inflexible, y tener especializar clases de 'atributos' se convierte en una enrevesada pesadilla al depurar.
  • Un tipo de modificador que contiene un nombre de estadística y un valor de modificador (por ejemplo, +10, + 15%). Estos se añaden a sus criaturas ya que se utilizan (por ejemplo. A través de un efecto de hechizo, o manejando un arma encantada) y se les quitaron después por un FutureEvent tiempo o algún otro evento, tales como un comando que se ejecuta.
  • clases específicas del juego, tales como PlayerClass o PlayerRace, cada uno de los cuales describen la clase de un jugador (por ejemplo. Guerrero, mago, ladrón) o raza (humanos, elfos, enana) y configurar los valores de estadísticas de partida y límites, listas de disponibilidad de habilidades, poderes especiales, etc.
  • Clases de interfaz de jugador básico que variarán según el tipo de juego real. Puede tener clases de representación para un juego gráfico, o en un MUD, puede tener una clase de conexión que refleje la conexión TCP con el cliente del jugador. Trata de mantener toda la lógica del juego fuera de estos.
  • Una interfaz de scripting. La mayoría de tus comandos, hechizos, e IA de criatura se pueden realizar más rápidamente con una interfaz de scripting decente y también mantiene los tiempos de compilación . También permite una gran depuración en el juego y capacidades de diagnóstico.

Esa sería la estructura básica de alto nivel que usaría.

+0

Esa es la segunda respuesta fantástica que has proporcionado para mis preguntas relacionadas con el juego. Gracias – Steerpike

+0

Si tuviera que usar una arquitectura MVC para este juego. ¿Cómo se vería la separación del modelo, vista y controlador para esta estructura de clase? – BrightIntelDusk

+0

@IntegrityFirst: No usaría MVC, así que es una pregunta que debería responder usted mismo. Pero el manejo de E/S (incluidos los gráficos) depende completamente de la plataforma para la que se está haciendo el juego. – Kylotan

5
<tongue_in_cheek_mode_because_it_is_friday> 

sólo para empezar:

  ----------------     -------------- 
      | Creature |     | Item  | 
      |--------------|     |------------| 
      | Name   |     | Name  | 
      | Hp   |     | Value  | 
      | Abilities |--------------------| Weight  | 
      |--------------|     -------------- 
      | Attack  | 
      ---------------- 
       ^
       | 
     ---------------------- 
     |     | 
---------------- ---------------- 
| Hero  | | Monster  | 
|--------------| |--------------| 
| Level  | |    | 
|--------------| |--------------| 
| KillMonster | | AttackAndDie | 
| GrabTreasure | | DropTreasure | 
---------------- ---------------- 

</tongue_in_cheek_mode_because_it_is_friday> 
+0

Parece sorprendentemente familiar para mi propio diseño Tengo que admitir :) – Steerpike

+1

Lol, depende totalmente del sistema que desea implementar. Puede ser simple, pero como de costumbre, los sistemas de rpg son extremadamente complejos. Pero, de nuevo, el juego no está terminado hasta que encuentres el hackmaster + 12 ;-). –

+2

Creo que mi principal problema es que no estoy seguro de qué se supone que 'gazebo' hereda ... – Steerpike

4
+1

3 principales y 3 GameEngineDatas? Creo que algunas refactorizaciones están en orden. –

+0

Ah, sí, por supuesto ... Publiqué estas imágenes solo para obtener la esencia de cómo empezar a construir un UML –

3

Mira JADE's Javadoc para una buena visión general de un juego complejo :)

+0

. He trabajado en juegos grandes, profesionales, AAA con una estructura de clases más simple. – kyoryu

+1

¿Te importa compartirlo? :) – changelog

11

Es posible que desee considerar un sistema de entidad componente en lugar de una jerarquía de herencia tradicional; tienden a ser más flexibles a ciertos tipos de cambios, a crear herramientas (p.editor mundial) el desarrollo es mucho más fácil y presenta oportunidades para la paralelización que, de otro modo, no sería obvia o fácil.

Muchos motores de juegos modernos se están alejando del "objeto de clase monolítico" (o clase de entidad, lo que sea) y hacia un enfoque de "bolsa de componentes".

Hay numerosos libros y artículos alrededor. En general:

concreto (algunos noteworth los Y, Google "componente" y "entidad" en varias combinaciones para más):

Cada uno de estos artículos enlaces a algunos más.

Prueba el kool-aid, te puede gustar. =)

+0

Gracias, nunca antes había escuchado sobre el diseño impulsado por componentes, pero parece interesante. –

+0

@nemo: gracias por la nota, estaba funcionando hace dos días. = (He insertado su nuevo enlace de blog, pero parece que no tiene la presentación, y una nota de que todavía puede acceder a la presentación usando el caché de google. – leander

+0

Recientemente arreglé mi sitio. Http: // scottbilas .com/juegos/dungeon-asedio – scobi

4

A very different approach por Steve Yegge.

+0

Sí, el concepto de clave/valor es como otra versión de la 10ma Regla de Greenspun: casi todos los sistemas terminan en algún lado. Sugiero usarlo para las propiedades de los personajes y los elementos, incluido el modelo de herencia que Steve y otros hablan. – Kylotan

1

Sea valiente, su juego no debe ser un clon de hack and slash sinsentido. Tus actores deberían ser capaces de cambiar de bando, tomar su propia iniciativa alistar a otros actores, etc. De lo contrario, ¿cuál es el punto?

+-----------------------------+ 
    V        | 
[Actor] ------- [Allegiance] ----+ 
- risk comfort - weight 
- temerity   
+1

Eso está mucho más adelante. No importa lo que hagas, todavía vas a necesitar un sistema como los de arriba para clasificar a todos estos actores y la IA requerida. – Sneakyness

Cuestiones relacionadas