¿Alguien sabe dónde puedo encontrar ejemplos de diagramas de clase para el desarrollo de juegos RP? Algo similar a aquí sería muy útil. No busco cosas que pueda copiar servilmente, sino diferentes ejemplos que muestren varias soluciones a los problemas que descubro mientras trato de anotar mis propias clases.
Respuestas
¿Demasiados anuncios?Conozco a Emmanuel Deloget de GameDev.net pero no estoy seguro de que elegiría usar la jerarquía que tiene allí! Demasiada herencia, no suficiente flexibilidad.
Si estuviera escribiendo un RPG basado en texto (como lo he hecho en el pasado) se vería un poco como esto (aunque no tengo tiempo de hacer un diagrama para ello, tristemente):
- Las criaturas, las habitaciones y los artículos derivados de WorldEntity, con WorldEntity objetos dispuestos en un compuesto estructura, para que los artículos puedan vivir dentro otros artículos, llevados por las criaturas, que existen dentro de las habitaciones. Implementando el patrón de visitantes de WorldEntities podría funcionar bien.
- Las clases CreatureType y ItemType que contienen los datos de "clase" para Criatura y objeto individuales que se refieren a sus casos, que se remontan a su el correspondiente objeto "tipo". (por ejemplo, la base puntos de golpe y estadísticas en los primeros, puntos de golpe actuales y efectos transitorios en este último). Podría implementarlas como listas prototípicas de propiedades que obtienen copiado a las instancias de criatura o artículo cuando se crean. Puedes implementar la propiedad herencia a través de una propiedad "parental" para que una instancia específica de criatura duende puede relacionarse con la "duende guerrero" CreatureType, que contiene un referencia parental al 'duende genérico' CreatureType. Y así sucesivamente.
- Las salidas que son propiedad de su habitación, y son una dirección, 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 de desove para dictar donde la criatura y se crean instancias de artículos (por ejemplo, qué habitación, o en qué coordenadas), cuando se crean y con qué frecuencia, y desde que CreatureTypes y ItemTypes. Puede que tengas algo de lógica aquí para aleatorizar un poco las cosas.
- Hechizos, habilidades, destrezas, etc. todas ellas derivadas de una clase de Acción base o interfaz que especifica los requisitos previos (por ejemplo, la posición actual, los puntos de maná, algunos grado de aprendizaje de una habilidad, etc.). Normal los comandos y acciones pueden ir aquí también ya que a menudo también tienen algún tipo de requisitos (por ejemplo, una orden de "dormir" requiere que no estés ya está durmiendo.)
- Una clase de FutureEvent que es esencialmente una que empujas a una cola de prioridad para ejecutar en el futuro. Puedes usar esto para programar rondas de combate, deletrear tiempos de enfriamiento, ciclos de noche/día, lo que quieras.
- Un hash/mapa/diccionario de nombre->pares de valores para estadísticas de jugadores y artículos. No es seguro de tipo pero apreciará la flexibilidad más tarde. En mi La experiencia en la elaboración de variables de miembros de las estadísticas es trabajable pero inflexible, y teniendo la especialización las clases de "atributos" se convierten en un enrevesado pesadilla al depurar.
- Un tipo de modificador que contiene un nombre de estadística y un valor modificador (por ejemplo, +10, +15%). Estos se añaden a sus criaturas a medida que se utilizan (por ejemplo, a través de un efecto de hechizo, o blandiendo un arma encantada) y ser despojado más tarde por un Evento Futuro cronometrado o algún otro evento como como una orden que se está ejecutando.
- Clases de juegos específicos como PlayerClass o PlayerRace, cada uno de los cuales describe la clase de un jugador (por ejemplo, guerrero, mago, ladrón) o raza (humano, elfo, enano) y establecer los valores iniciales y los límites, listas de disponibilidad de habilidades, poderes especiales, etc.
- Clases básicas de interfaz de jugador que variarán dependiendo de tu tipo de juego real. Podrías tener una clase de representación para un juego gráfico, o en un MUD podrías tener una clase de conexión reflejando la conexión TCP al cliente del jugador. Trata de mantener toda la lógica del juego fuera de esto.
- Una interfaz de programación. La mayoría de tus comandos, hechizos, y la IA de las criaturas puede realizarse más rápidamente con una interfaz de scripts decente y mantiene los tiempos de compilación abajo tambié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.
Tal vez convenga considerar un sistema de entidades componentes en lugar de una jerarquía de herencia tradicional; tienden a ser más flexibles a ciertos tipos de cambio, facilitan mucho el desarrollo de herramientas (por ejemplo, el editor mundial) y presentan oportunidades de paralelismo que de otro modo no serían obvias ni fáciles.
Muchos motores de juegos modernos se están alejando de la "clase monolítica Objeto" (o clase Entidad, lo que sea) y se acercan a un enfoque de "bolsa de componentes".
Hay numerosos libros y artículos por ahí. En general:
- el Gemas de programación de juegos (aparentemente tanto el volumen 5 como el 6 tienen artículos componentes, y creo que el 2 podría haber tenido uno también)
- el Conferencia de desarrolladores de juegos El sitio web a menudo tiene enlaces a presentaciones de años anteriores, y es una mina de oro para este tipo de cosas - incluso se puede comprar los CDs/DVDs de años anteriores a bajo precio (especialmente si usted asiste)
- Los archivos de los artículos de fondo del Gamasutra y el Revista de desarrollo de juegos backissues
Específicamente (algunos dignos de mención, "componente" y "entidad" de Google en varias combinaciones para más):
- Evoluciona tu jerarquía Mick West
- Los sistemas de entidades son el futuro del desarrollo del MMOG También parte 2 y parte 3
- Introducción a la arquitectura del asedio a las mazmorras en la wiki de Gas Powered Games
- Un sistema de objetos de juego basado en datos Scott Bilas (GDC 2002)
- el Iniciativa Nocturna una colección abierta de librerías y herramientas de Insomniac Games (tienen uno de los mayores esfuerzos de herramientas en la industria, por lo que he visto)
Cada uno de estos artículos enlaza con algunos más.
Prueba el kool-aid, puede que te guste. =)
Esta es una interpretación simplificada de lo que estoy usando en mi pícaro ahora mismo (Sólo estoy enumerando los nombres y sus variables):
GameObject
-location (NSPoint)
-isPassable (bool)
-beenSeen (bool)
//Everything that is in the game will have these basic attributes
//beenSeen is used to "remember" things outside the current FOV
Wall : GameObject
//nothing extra variable-wise, but it will have it's own draw function
//and it's own init that would set the isPassable and beenSeen to NO
Floor : GameObject
Door : GameObject
-isLocked (int)
-integrity (int)
-isOpen (bool)
//isLocked is an int, with 0 being unlocked, higher levels would require more skill
//integrity would determine if you could kick the door down or not
GameCharacter : GameObject
-health (int)
-sightRadius (int)
-inventory (NSMutableArray)
-inventoryValue (int)
-inventoryWeight (float)
//everything else is up to you for this, there are many stat systems
//each with their own pros and cons
Player : GameCharacter
-steps (int)
//Forgot this the first time through, this is important
Monster : GameCharacter
//you might put AI specific things here
Skeleton : Monster
Item : GameObject
-value (int)
-weight (float)
//everything else is specific to what the item is
//weapons, potions, ammo, etc
Gold : Item
//example
//value = 1
//weight = 0.1
Container : Item
-contents (NSMutableArray)
-contentsValue (int)
-contentsWeight (float)
-capacity (float)
-isLocked (int)
//capacity would use the weight, but that could get silly
//maybe add size to items as well? it's up to you!
He dejado un poco fuera, pero una vez que tengas los cimientos abajo todo lo demás debería caer en su lugar.
Me di cuenta después del hecho de que puse la integridad usada dos veces, tal vez podrías ponerla en GameObject y tener -1 ser invencible o algo así. Depende de ti.
No te sientes ahí y hagas 9.000 clases . Nunca lo terminarás y sólo te enfadarás cuando cambies una cosa que estropee el resto de todo. Sólo codifica exactamente lo que necesitas, y a medida que añadas características y lo amplíes, verás lo que tendrás que cambiar/implementar, y refactorizar a partir de ahí. Lo más probable es que estés aprendiendo mucho entre estos refactorings, y mirarás atrás en el código antiguo y te preguntarás qué demonios estabas pensando.
¿Qué pasa con los seis votos a favor del tipo que escribió el nombre dos veces? ¿Dónde están las ubicaciones que están siendo almacenadas? Preguntando por los dolores de cabeza más tarde. Si quisieras poner un nombre, obviamente iría bajo "Objeto de Juego", lo mismo para la descripción. No estoy tan adelantado en el mío, de ninguna manera, y personalmente creo que nombrar las cosas desde el principio es un ejemplo perfecto de una de las cosas que NO se deben hacer desde el principio, ya que pasarás demasiado tiempo en ellas, y no hacen nada. Concéntrate en hacer que las cosas funcionen bien primero, luego pasa tu tiempo nombrando cosas y añadiendo descripciones.
Concéntrate en hacer que las cosas funcionen bien primero. No tiene que ser bonito. Puede parecer la parte divertida, pero si nada funciona todos sus nombres son inútiles. Repetí esto porque es muy común tratar de establecer todo desde el principio, y será te quemará. Te vas a encontrar con muchas cosas que no esperabas. Como la gran mayoría de la gente de aquí, probablemente has jugado muchos juegos de rol, y estás familiarizado con ellos. Puede parecer "obvio" y "tiene sentido" que las cosas se planteen de cierta manera desde el principio, pero a medida que te adentras en esta bestia (cueva, mazmorra, castillo, agujero, etc.) encontrarás que a veces la forma en que tiene sentido en tu cabeza desde tu experiencia de juego no tiene NINGÚN sentido desde el punto de vista de la codificación.
Cíñete a ello, no empieces un billón de proyectos, ciñete a ello, puedes hacerlo bastante más tarde. Saldrás de esto con una apreciación mucho mayor para los programadores de juegos.
Trata de no hablar mucho de ello, tampoco. He descubierto que eso me quita toda la motivación algunos días, sólo sentarme a hablar de todo lo que quieres hacer. Finalmente llegas a la computadora, abres el XCode y no tienes ganas de tocarlo. Parece hipócrita de mi parte decir esto después de exponer todo eso, y lo es. A veces no puedes evitarlo.
No se apresure a venir aquí y preguntar tampoco, haga una investigación original, busque en la documentación. No estoy diciendo esto para ser malo, pero todo lo que querrás preguntar se ha hecho antes y alguien probablemente ha hecho un blog sobre ello. Si no estás seguro de si algo funcionará o no, inténtalo de todas formas, aprenderás algo. No se trata de intentar no cometer errores, sino de cometer tantos errores como puedas (dentro de lo razonable).
Lo siento por la novela.
<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>
¿Qué tal algo así?
Aquí hay algunos otros diagramas:
- http://www.russelldare.net/media/2dgame/uml.jpg
- http://dirkkok.files.wordpress.com/2007/12/domainmodel1.jpg?w=505&h=573
- http://members.gamedev.net/emmanuel_deloget/images/text_rpg_rule_system.png
- http://theworldofdan.co.uk/wp-content/uploads/2009/05/classdiagram1.jpg
- http://www.c-sharpcorner.com/UploadFile/mgold/SpaceInvaders06292005005618AM/Images/SpaceInvadersUML.jpg
- http://blog.xlandersoftware.com/wp-content/uploads/2008/08/tankrushuml.png