2009-05-06 11 views
7

Estoy tratando de utilizar una tecnología de alto nivel para un juego que estoy retocando como un proyecto personal. Es un juego de aventuras por turnos que probablemente esté más cerca de Archon en términos de lo que estoy tratando de hacer.Manejo de efectos de combate en el desarrollo de juegos

Lo que estoy teniendo problemas es conceptualizar la mejor manera de desarrollar un sistema de combate que pueda implementar simplemente al principio, pero que permitirá que la expansión y la complejidad se agreguen en el futuro.

Específicamente, tengo problemas para tratar de descubrir cómo manejar los efectos especiales de combate, es decir, los bonus o los bonus que un actor, un elemento o un entorno pueden aplicar o eliminar.

  • Tengo el actor maneja todos los efectos que están en juego a favor o en contra de ellos si el juego verifica cada arma, armadura, actor y ubicación cada vez que intenta hacer una tirada decisiva.
  • ¿Los efectos se manejan en objetos individuales o hay un objeto 'efecto' o un poco de ambos?

Puede que no me haya explicado nada bien aquí, y estoy más que feliz de tratar de ampliar la pregunta si mi solicitud es demasiado amplia y aireada. Pero mi pensamiento inicial es que las personas más inteligentes que yo han dedicado el tiempo y el esfuerzo para descifrar cosas como esta y, francamente, no quiero manchar la conversación con el callejón sin salida de mi propia estupidez demasiado pronto.

El idioma en cuestión es javascript, aunque en este punto no me imagino que haga una gran diferencia.

Respuesta

7

Lo que llamas "efectos especiales" solía llamarse "modificadores" pero hoy en día se usa el término popular en MMO como "buffs". Manejar estos es tan fácil o tan difícil como lo desees, dado que puedes elegir la versatilidad que deseas otorgar en cada etapa.

Fundamentalmente, cada aspecto del sistema generalmente almacena una lista de los modificadores que se le aplican y usted puede consultarlos bajo demanda.Normalmente solo hay un puñado de modificadores que se aplican a cualquier jugador en un momento dado, así que no hay problema: tome las estadísticas del jugador y los modificadores impartidos por habilidades/hechizos/lo que sea, agregue cualquier modificador impartido por el equipo usado, luego agregue cualquier cosa impartida por el arma en cuestión. Si se presenta una interfaz estándar aquí (por ejemplo, sumModifiersTo (attributeID)) que utilizan los actores, los artículos, las ubicaciones, etc., implementar esto puede ser rápido y fácil.

Normalmente, los objetos de 'efecto' estarían contenidos dentro de la entidad a la que pertenecen: los actores tienen una lista de efectos, y los artículos que usan o usan tienen su propia lista de efectos. Cuando los efectos están explícitamente activados y/o tienen un límite de tiempo, depende de usted dónde desea almacenarlos, por ej. si tiene pociones mágicas u otros consumibles, sus efectos deberán adjuntarse al Actor en lugar del elemento (presumiblemente destruido).

No se sienta tentado a intentar que los efectos modifiquen los atributos del actor en el lugar, ya que rápidamente descubrirá que es fácil que los atributos se "desvíen" si no asegura que todas las adiciones y eliminaciones se realicen siguiendo el protocolo correcto También hace que sea mucho más difícil pasar por alto ciertos modificadores más adelante. p.ej. Imagina un escudo mágico que solo protege contra otras magias: puedes pasar algún tipo de predicado a tu modificador sumando una función que ignora ciertos tipos de efectos para hacer esto.

+0

Gracias por la fantástica respuesta. Tiene perfecto sentido (aunque me perdiste un poco en el último párrafo con respecto a los atributos en el lugar y 'deriva'). – Steerpike

+0

Imagine: - En wearItem() aplica los efectos asociados con un elemento a las estadísticas de un personaje, ej. actor.strength + = item.sumEffects (STRENGTH) - En removeItem() se eliminan dichos efectos, por ej. actor.strength - = item.sumEffects (STRENGTH) Este tipo de cosas funciona bien hasta que agregue otras formas para "eliminar" elementos, por ejemplo. por consumo, daño, ser teletransportados, confiscados por GM en un juego en línea, etc. Debe recordar quitar los efectos en cada posible escenario que agregue, y puede obtener errores sutiles de esa manera, por lo que es más seguro calcular los valores en demanda. – Kylotan

+0

Disculpa por el formato que hay: simula que los guiones antes de 'in wearItem' y 'in removeitem' son viñetas y 'Este tipo de cosas' comienza un nuevo párrafo. – Kylotan

2

Eche un vistazo al libro, Head First Design Patterns, de Elisabeth Freeman. Específicamente, lea sobre los patrones Decorator y Factory y el método de programación para interfaces, no para implementaciones. Encontré ese libro enormemente efectivo para ilustrar algunos de los conceptos complejos que pueden llevarlo a esto.

Espero que esto ayude a apuntar en la dirección correcta.

+0

Eché un vistazo a algunas implementaciones del patrón de decorador en javascript y eso parece muy prometedor. Acabo de conseguir trabajo para pedir el libro que sugirió también. Gracias :) – Steerpike

0

A primera vista diría que los combatientes individuales (jugador y NPC) tienen un papel en determinar cuáles son sus características de combate (es decir, valor de armadura, número de golpe, rango de daño, etc.) dados todos los modificadores que aplicar a ese combatiente. Entonces el sistema de combate no trata de descubrir si la clase del personaje le da o no un bono de armadura, si un arma mágica pesa sobre el golpe, etc.

Pero yo esperaría que el sistema de combate en sí estar fuera de los combatientes individuales. Que tomaría información sobre un atacante y un tipo de ataque deseado y un objetivo o conjunto de objetivos y lo resolvería.

Para mí, ese tipo de modelo refleja la forma en que realizamos el combate en juegos de rol de lápiz y papel. El DM le pidió a cada jugador los detalles de su personaje y luego ejecutó el combate usando esa información como entradas. Que funcione en el mundo real sugiere que es un sistema bastante flexible.

Cuestiones relacionadas