Desenvolvendo uma estrutura de jogo de cartas


7

Que tipo de padrões e idéias de design se pode usar para criar uma estrutura de jogo de cartas de propósito geral?

Isso decorre de que eu tentei construir um clone do popular jogo de Steve Jackson "Munchkin". Por causa da natureza desse jogo, acabei tendo que codificar tantas funcionalidades de cartão que o desenvolvimento se tornou caótico e complexo. Eu queria criar algo geral, mas acabei com apenas muitas classes com muitas funções substituídas e alternar instruções para determinar o comportamento.

Eu estava curioso para saber como alguém com mais experiência em design lidaria com essa tarefa de construir uma estrutura de jogo de cartas de propósito geral, ou pelo menos algo que pudesse ser estendido. Ou é melhor que, se eu quiser fazer uma simulação de um jogo de cartas como o Munchkin, estou preso em criar uma estrutura específica.

Eu gostaria de usar c #.

EDITAR

Eu gostaria de esclarecer um pouco do que eu gostaria de alcançar. Eu gostaria de uma estrutura na qual eu possa implementar basicamente fases com funcionalidade personalizada (fase 1: cartões de compra, fase 2: aplicar regras de manutenção, fase 3: cartões de jogo, fase 4: resolução, etc.).

Penso que definir um conjunto de regras seria sábio, o que seria combinado com as cartas e as fases.

Então, as cartas seriam definidas e, suponho, vinculadas às regras, por exemplo, uma regra poderia ser "Durante a fase de manutenção, perca 1 ficha". No entanto, uma carta que o jogador possui pode fornecer "Não perca nenhuma ficha durante a fase de manutenção". Portanto, seria bom poder amarrar isso juntos, mas dentro das entranhas da estrutura.

Suponho que isso também esteja fora do meu alcance.


11
Por favor, esclareça algo para mim: você está procurando algo que permita desenvolver o Munchkin sem dor ou tem a ambição de criar uma estrutura genérica de jogos de cartas que as pessoas também possam usar em outros jogos de cartas? (Além, se você estiver considerando o último, eu aconselharia apenas incidindo sobre o ex neste momento)
doppelgreener

Não estou mais interessada em Munchkin, mas na verdade tenho outro jogo de cartas em mente (algo da minha própria criação) que gostaria de colocar em forma de computador, sem dor. Isso ajuda?
Robb

Respostas:


6

Eu teria usado algum tipo de linguagem de script como LUA ou Python para definir cada comportamento ou cartão especial.

Dessa forma, você pode definir um mecanismo "genérico" e manter as particularidades dos cartões longe do código principal, em alguns scripts pequenos e facilmente editáveis.

A principal vantagem das linguagens de script sobre XML ou outros dados "estáticos" é que as linguagens de script podem "criar" seus próprios comportamentos usando os métodos públicos oferecidos pelo mecanismo.

Exemplo: suponha que seu mecanismo ofereça os métodos "setDommage (target, dmg)" e "setVisualEffect (nameOfFxLuaScript)" etc. etc.

------Card1 -- A simple fireball-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

------Card2 -- A multitype ball (outch it hurts!)-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

// Ice ball
if( player.protectionAgainstIce == false )
{
    setDommage(target, 102);
    setVisualEffect("iceBall.lua");
}

// thunderbolt
while( player.Alive )
{
    setDommage(target, 1005);
    setVisualEffect("thunderBolt.lua");
}

Os dois cartões usam os mesmos métodos de mecanismo , mas não fazem as mesmas coisas. Os comportamentos também podem usar dados coletados do mecanismo (como a lista de jogadores para fazer um loop sobre eles) e para instruções if, etc.

A segunda, mas não a menor vantagem, é que ela não precisa ser compilada. Você pode modificar o script LUA e recarregá-lo diretamente sem recompilar o jogo. É muito bom para testar e iterar até encontrar as boas configurações.

A terceira vantagem é que qualquer pessoa que possa aprender a linguagem de script pode criar novos cartões / comportamentos, desde que você forneça uma lista dos métodos públicos compartilhados pelo mecanismo (e desde que você não codifique as LUAs). E como todos sabem, a comunidade é incrível quando você oferece ferramentas legais;)


Aqui está um wrapper LUA para C #: http://luaforge.net/projects/luainterface/


Você não teria um link para um projeto que possa ser semelhante ao que você descreve? Eu nunca usei linguagens de script antes. Eu esperava apenas definir os cartões em XML, lê-los e basicamente o jogo apenas aplicaria o que o cartão faz.
Robb

XML não é uma má idéia, mas você será muito limitado. O script oferece a capacidade de criar comportamentos personalizados usando os métodos públicos oferecidos pelo mecanismo. Dessa forma, o mecanismo pode permanecer o mais "genérico" possível. Não conheço um exemplo de aplicação a cartões, mas há muitos jogos usando LUA como WoW (addons) ou Aquaria (comportamentos de entidades).
Valkea 19/05

Hmm, estou vendo uma vantagem real de usar uma linguagem de script. Então, no exemplo, você tem danos. Para um jogo de cartas, com várias coisas, seria melhor tentar descobrir todas as ações possíveis ou criar um 'setActionEffect' genérico. Em Munchkin, você pode aplicar um modificador ao seu nível para aumentá-lo. Você também pode fazer o monstro desaparecer. Você pode até ajustar um rolo de matriz. Essa parte do quebra-cabeça é o que me desafia, como modelar algo complexo como esse.
Robb

Não tenho muita certeza de como o script ajudará seu "mecanismo" a se transformar em várias propriedades, como "ProtectionAgainstX" e "CanDoY" etc. que acredito que tornaria cada vez mais difícil adicionar novas cartas e alterar as regras fundamentais do jogo.
Alex Schearer

@ Alex: O objetivo é torná-lo o mais "genérico" possível, para que possa ser usado com um universo completamente diferente sem ter que alterar o código / núcleo do jogo. O "protectionAgainstIce" usado no pseudocódigo foi um mau exemplo usado para demonstrar a instrução "if", mas deve ser algo como isProtectedAgainst ("ice"), que é mais genérico e pode ser reutilizado com materiais diferentes ("fire", " bolas "," laser "etc.). Desta forma, há uma infinidade de possibilidades, desde que os tipos (fogo etc) sejam definidos fora do núcleo do jogo.
Valkea 19/05
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.