[TCG] Terceira iteração

Projetos
#1

Para o pessoal que tá me ajudando com o TCG, vou listar aqui as mudanças (com relação ao último playtest) que pretendo testar nessa iteração. Vou tentar apresentar as mudanças como soluções para os problemas que encontramos nas partidas. A única exceção é a minha proposta de sistema de atributos no final do post.

E SIM, EU ESCREVO MUITO. EU SEI.

[hr]

[ul][li]
Problema: Evade desbalanceado.
Solução: Usar uma manobra evasiva deve conter sempre um risco, embora esse risco possa ser reduzido. O Coelho sugeriu aplicar o fator de Evade multiplicativamente nos tamanho das cartas topdeckadas na manobra, Por exemplo, se um jogador tem Evade 2, e está sob um ataque de magnitude 5 (um ataque relativamente fraco) ele precisa topdeckar uma carte de tamanho 3 (pois 3 vezes o 2 do Evade dá 6, que é maior que 5). Assim, fazemos a evasão quase sempre ter um risco associado e ainda assim ter alguma chance de alcançar ataques de magnitude 20 (o que pelo visto no playtest é perfeitamente possível).
[/li][/ul]

[hr]

[ul][li]
Problema: Excesso de stalemates.
Solução: Analisando melhor o conceito dos decks básicos, observamos que o jogo contém três tipos de bônus principais: dano, defesa e evade. Notem como existem 2 bônus defensivos para apenas um ofensivo. Acredito eu ser a essa a principal causa do excesso de stalemates. É preciso trocar um deles por algo diferente. Escolhi tirar o bônus de evade (e não a mecânica em si) e colocar outro que fizesse algo que não fosse ofensivo nem defensivo, e sim expansivo. Comecei chamando ele de Speed, mas acho que vou mudar para Intelligence. Maiores explicações podem ser encontradas na proposta que fiz no final desse post.
[/li][/ul]

[hr]

[ul][li]
Problema: Alta complexidade combinatória na decisão de manobras.
Solução: Percebi que um bom tempo da partida era gasto calculando todas as possibilidades das combinações de manobras na hora do combate: sempre é preciso pensar em todas as 6 diferentes possíveis combinações. Não sei o quanto isso vai tirar da diversão do jogo, mas quero experimentar o seguinte: jogadores estão continuamente usando uma certa manobra, e podem mudar essa manobra uma vez por turno. Assim quem ataca pode mudar mas tem que ficar com a manobra que escolheu até seu próximo turno (possivelmente deixando-o mais vulnerável). Isso também visa diminuir a excesso de controle que a defesa tinha no combate.
[/li][/ul]

[hr]

[ul][li]
Problema: Muitos dados (contadores de tempo)
Solução: Basicamente, para cada setor são preciso no mínimo 2 dados. Logo uma nave com 4 setores precisa de 8 dados, pelo menos. Primeiramente pensei em reduzir todos os setores para apenas um único (grande, obviamente), o que me pareceu bem triste para o jogo =(. Para não ter um gargalo muito grande nesse setorzão, o jogador teria um certo número de “centrais de comando” para cada tipo de cooldown. Por exemplo, a nave X tem 2 dados para cooldown de build-up, 1 para cooldown de units e 1 para cooldown de comandos. Achei complicado ainda assim, e simplifiquei para “a nave X tem N dados”. Cada dado poderia ser usado em qualquer timer, e se não houver o suficiente, a carta não pode ser usada. Pensando agora, acho que dá pra usar esse método e manter os vários setores. Vamos testar ambos.
[/li][/ul]

[hr]

Além dos problemas, eu (junto com umas ideias que troquei com o Coelho) pensei em um esquema interessante para lidar com so diversos bônus que as naves podem ter.

[hr]

[ul][li]
Proposta: Sistema de atributos
Descrição: Toda nave tem três atributos: Material, Energy e Intelligence (nome provisórios). Eles por si só não fazem nada. Mas eles podem satisfazer condições nas diversas cartas. Pensei em focar isso no Módulos. Eles teriam algo do tipo “Cada 5 pontos de Energy dão Shield +1”, ou “Cada 6 pontos de Intelligence dão Evade +1” (notem como Evade não é mais um bônus primário, supostamente eliminando o problema descrito acima). Dessa forma, os Módulo REALMENTE formariam uma “build” para o deck. E as demais cartas focariam mais em contribuir para os bônus primários (Material, Energy e Intelligence), assumindo relevência em mais tipos de decks do que se elas dessem apenas um bônus muito específico.
[/li][/ul]

É isso aí. Opinem, discutam e dêem ideias de cartas. Vou abrir um outro tópico para postar protótipos de cartas.

#2

Boar analisar o jogo um pouco antes de pensar em cards… não existem garantias de que simplesmente fazendo cards aleatórios e testando, e repetindo isso, a gente chega numa coisa balanceada. Até por que se o jogo estiver bom, a gente vai acabar andando em círculos ao invés de achar um balanceamento.

So, boar ver algumas core mechanics do jogo que eu percebi no playtest de quinta:

Core #1 = dano por setor é capado, devido a size constraints e ao fato de que size está relacionado ao poder de uma carta. (este por sua vez é assim pois size está relacionado a HP)

Core #2 = dependendo se você é Melee/Ranged/Assault, você tem vários setores pequenos, ou poucos setores grandes

Issue #1 --> potencial de dano de vários setores tem que ser aditivo.
Issue #2 --> tem que ser impossível nulificar o potencial de dano total de uma nave em pelo menos alguns dados momentos do jogo (suficiente para um jogador perder).

Essas issues sugerem uma correspondencia (espaço*tempo) ~ (potencial de dano total).
nota também que não é só simplesmente fazer (custo de espaço = dano / custo de tempo) para cada card, porque pelo Core #2, tem gente que pode baixar a mão logo de cara, e manter vários clocks em paralelo, efetivamente dividindo o custo de tempo das cartas por um fator de (número de setores usados ao mesmo tempo).

Proponho diferenciar cartas de combate de tipos diferentes, e limitar o uso delas pelo tipo da sua nave. Ainda podem no futuro existir cartas de combate “genéricas”, mas essas não para combate, e sim para implementar mecânicas que queremos que existam em todos os tipos (pense a mecanica de color fix do MTG)

Core #3 = Módulos ocupam espaço constante, geram recursos essenciais, estão ativos desde o começo do jogo
Issue #3 --> Efeitos dos módulos não pode ser fortes pois estão ativos desde o começo do jogo. Módulos virtually não podem ser desativados (senão você morre), logo são mais um debuff de espaço no setor do que outra coisa.

Pela conclusão das issues #1 e #2, módulos reduzem seu potencial de dano máximo, portanto precisam ter efeitos fortes o suficiente para contrabalancear essa redução.
Pela issue #3, eles não podem ter efeitos fortes.

Ou seja, a core mechanic dos módulos leva a uma contradição dentro deste jogo. Precisamos ou scrapear o sistema de módulos, ou reescrever ele completamente.

Core #4 = cards no grave == dano levado
Core #5 = um número apenas para ataque e defesa
Issue #4 --> suponha que eu ocupei todo o meu espaço, mas meu potencial de dano está baixo para atacar (mas suficiente para me defender). Supondo issues #1 e #2 addressed, é possível me recuperar: eu só preciso livrar espaço e usar mais temponeste espaço livrado. Porém, livrar espaço => levar dano + perder poder por bastante tempo == levar dano + perder defesa por bastante tempo.

Ou seja, vale mais a pena tentar manter o uso ineficiente de espaço, e forçar stalemate… e é importante minimisar ao máximo situações onde forçar stalemate é mais atrativo do que tentar ganhar o jogo.

Eu acho que essas issues são sérias o suficiente pra não valer a pena pular já no desenvolvimento de cartas teste. Para começar, os módulos sequer fazem sentido deste jeito, e ainda não fazemos a mínima idéia de como evitar stalemates nesse jogo.

Tentar resolver essas issues com card design transporta as issues para o jogador na hora que ele está jogando/deckbuilding, adicionando mais ainda na complexidade do jogo, já complexo demais.

#3

CYBERLUUUTAAAAAAAA

Concordo que analisar o jogo é importante (e como pode ser visto no meu post acima, eu tentei fazer isso). Mas deixar de fazer cards para teste deixa a gente muito longe da realidade. Eu gosto muito de teoria, mas sei que chega um ponto em que ela não é mais o suficiente. E bom, também tem o fato que eu não tenho tanta experiência em teoria de TCG como vc, então eu prefiro sujar as mãos e aprender por experiência até chegar ao ponto em que consiga fazer game design mais naturalmente. Nesse sentido eu achei o seu post muito bom e agradeço os palpites =P.

Até onde eu sei, também não existem garantias de que não fazendo isso chegaremos a algo balanceado. Se for assim, a questão se torna uma decisão arbitrária de metodologia, e eu prefiro testar pois assim tenho fedback.

Também não estou exatamente fazendo cards aleatórios, mas tampouco sei que padrão estou usando XD. E não sei se é só uma questão de palavras, mas o objetivo por enquanto é ter um jogo divertido, e não balanceado. Ser balanceado é um jeito de assegurar a diversão, mas nunca é bom confundir os meios com o fim.

Explique-se.

Concordo.

Você se refere ao Shield e ao Evade estarem muito fortes?
Se sim, eu espero melhorar isso com as mudanças que estamos para testar.

[quote=“brocoli, post:2, topic:291”]Essas issues sugerem uma correspondencia (espaço*tempo) ~ (potencial de dano total).
nota também que não é só simplesmente fazer (custo de espaço = dano / custo de tempo) para cada card, porque pelo Core #2, tem gente que pode baixar a mão logo de cara, e manter vários clocks em paralelo, efetivamente dividindo o custo de tempo das cartas por um fator de (número de setores usados ao mesmo tempo).[/quote]

Pretendo resolver o problema em negrito usando (1) custo de ocupação e (2) número de timers menores desassociando eles dos setores.

Se “limitar o uso” significa que elas só podem ser jogadas se a nave do jogador for do tipo adequado, então sim, isso estava em meus planos.

Color fix são aqueles terrenos que “ajustam” a cor da mana?
Como você sugere (mais detalhadamente) fazer isso no TCG?

[quote=“brocoli, post:2, topic:291”]Core #3 = Módulos ocupam espaço constante, geram recursos essenciais, estão ativos desde o começo do jogo
Issue #3 --> Efeitos dos módulos não pode ser fortes pois estão ativos desde o começo do jogo. Módulos virtually não podem ser desativados (senão você morre), logo são mais um debuff de espaço no setor do que outra coisa.

Pela conclusão das issues #1 e #2, módulos reduzem seu potencial de dano máximo, portanto precisam ter efeitos fortes o suficiente para contrabalancear essa redução.
Pela issue #3, eles não podem ter efeitos fortes.

Ou seja, a core mechanic dos módulos leva a uma contradição dentro deste jogo. Precisamos ou scrapear o sistema de módulos, ou reescrever ele completamente.[/quote]

Originalmente a ideia dos módulos foi meio arbitrária mesmo, inspirada numa sugestão do Jeff. Mas agora com o sistema de atributos eu acredito que eles devem funcionar, pois:

(1) Eles são fortes, uma vez que determinam um potencial importante para sua nave ao longo da partida. Logo devem compensar o espaço que ocupam.
(2) Apesar de fortes, o fato deles estarem ativos desde o começo do jogo não produz nenhuma vantagem imediata. Vai depender do desenrolar do jogo o quanto eles de fato ajudarão o jogador.

Ou seja, eles compõem uma “build” para sua nave/deck, e não um conjunto de efeitos overpowered somados juntos.

[quote=“brocoli, post:2, topic:291”]Core #4 = cards no grave == dano levado
Core #5 = um número apenas para ataque e defesa
Issue #4 --> suponha que eu ocupei todo o meu espaço, mas meu potencial de dano está baixo para atacar (mas suficiente para me defender). Supondo issues #1 e #2 addressed, é possível me recuperar: eu só preciso livrar espaço e usar mais temponeste espaço livrado. Porém, livrar espaço => levar dano + perder poder por bastante tempo == levar dano + perder defesa por bastante tempo.

Ou seja, vale mais a pena tentar manter o uso ineficiente de espaço, e forçar stalemate… e é importante minimisar ao máximo situações onde forçar stalemate é mais atrativo do que tentar ganhar o jogo.[/quote]

Apesar de o dano do combate ser resolvido usando apenas o valor de “poder” das unidades, a defesa mesmo fica por conta do tamanho das unidades. Quanto maiores as unidades, mais difícil é causar dano nesse setor. Ou seja, tamanho não é apenas um custo das unidades, é também a resistência delas. Logo o Core #5 que você usou na sua argumentação não é completamente verdadeiro. Não obstante, realmente não sei como lidar com a situação hipotética que você falou, a não ser criando cartas que te tirem dessa situação (tipo um fling que libera espaço + causa dano baseado no tamanho da unidade sacrificada). Vou pensar a respeito.

Issue #1 ==> Atendida.
Issue #2 ==> Espero arrumar com as mudanças
Issue #3 ==> Acredito que esteja resolvida com o sistema de atributos
Issue #4 ==> Não sei se era realmente uma issue pois você não mencionou o papel do tamanho na defesa. Mas concordo que parece mais séria essa.

E bom, para resolver issues é preciso fazer propostas. Para saber se as propostas funcionam é preciso testá-las. Para testá-las é preciso de cartas. Logo, como resolver as issues sem fazer cartas de teste?

Eu acabei de “fazer uma(s) mínima(s) ideia(s)” de como resolver os stalemates no meu post acima. E na verdade, no playtest com os novos membros, nenhuma partida chegou em stalemate, embora tenham sido claramente desbalanceadas.

Então, brocoli. Fiquei com a impressão de que você ou não leu, ou só passou por cima do meu post =(. Eu propûs várias mudanças (que não envolviam cartas especificamente) para resolver as issues que fui capaz de perceber e você nem sequer mencionou elas. Estou falando para fazermos cartas agora que já fiz mudanças visando resolver as issues. E como falei algumas linhas acima, como saber se eu realmente consegui resolver as issues sem ter cartas para testar?

Fora isso, tem a questão da motivação. Pensar em cartas é muito divertido. Acho que essa parte do processo tem que estar constantemente presente. Seja para mim, seja para você, seja para o Coelho, seja para os novos membros se manterem interessados (eles também gostaram de bolar cartas). No pior dos casos, o TCG falha como jogo, mas a experiência fica. A diversão fica. As pessoas ficam. Acho que isso é muito mais importante do que ninguém me aguentar por eu implicar demais com a perfeição do jogo.

#4

sorry a demora ^^V
anw

Sobre design de cartas
no problems com isso, a questão é que se o jogo contém contradições de mecânica, as mecânicas precisam ser consertadas. Ignorar isso no melhor dos casos faz as cartas designed serem inúteis, no pior dos casos leva a design de cartas que superficialmente ajeitam o jogo, mas ao mesmo tempo transformam o defeito de mecânica numa coisa que não dá pra se livrar depois.

Basicamente, esse eh o ponto que determina a metodologia, não é arbitrario at all.

mas se vc se diverte fazendo cards, then go ahead XD, eu me divirto mais pensando na mecânica e nas regras.

Ah, e todo jogo competitivo tem que ser balanceado por questões de fairness e retenção de players. Mas balanceado != não deve conter estratégias que parecem OP à 1a vista. More on that further down.

Balanceamento, e como introduzir elementos emocionantes num universo balanceado

Basicamente, combatendo poder raw forte (estatísticas) com fraquezas de defesa exploitável (qualitativas).
Por exemplo, nesse jogo uma dinâmica que eu queria mto ver era a seguinte :

  • Assault tem números altos de setores, garantindo que Algum dano VAI passar, e cada ponto que passa causa problemas no longo termo por causa de boarding. Além disso, eles podem se esconder atrás do escudo dos montes de setores, e não levam mto dano se eles perderem um setor (porque eles são pequenos).

Isso é uma core mechanic de Assault, então faz sentido eles terem que rely nesse tipo de tática. Ou seja, reliance em várias cartas em campo ao mesmo tempo. Faz sentido então introduzir a seguinte fraqueza conceitual:

  • Assaults são lacking em defesa “instant”.

Então eles são mais ou menos vulneráveis a efeitos instantâneos, por exemplo, de disable AoE. A idéia é que eles precisam das cartas na mesa, e portanto não têm cartas na mão tanto quanto o oponente. A pool de cartas defensivas de reação deles pode ser reduzida, ou eles não podem se dar ao luxo de deixar um setor fora de cooldown nunca.

Isso foi só um exemplo, o jogo tem que ter vários tipos de mecânicas assim; e eu acho que esse tipo de mecânica precisa guiar o processo de criação de cartas. Percebe também que cartas genéricas (i.e. que servem pros 3 main tipos de naves/manobras) destróem completamente esse tipo de dinâmica.

Pensa o seguinte: se tivesse uma unidade sequer no Starcraft 1 que fosse igual entre as raças, ou até mesmo parecida o suficiente, então o jogo não teria o balance tão emocionante que ele teve durante anos e anos.

About: módulos

Eu falei de uma contradição de mecânica na idéia de módulos no post anterior. A solução pra isso que você propôs foi…

Ou seja, eles compõem uma "build" para sua nave/deck, e não um conjunto de efeitos overpowered somados juntos.
Então, concordamos que módulos nunca _jamais_ podem ter nenhum tipo de estatística somável anexada a eles, certo?

O objetivo deles é mudar as regras do jogo, de preferencia de alguma forma que trás vantagem para você, que está preparado com cards no deck que combinam com isso. Se não for assim, eu acho que eles atrapalham o jogo demais.
Pense assim: não é que evade estava OP no nosso playtest. E sim que evade nunca deveria aparecer como bônus estático em nada (gastando basicamente só um espaço contínuo da nave). Also, pensa na solução que a gente pensou na hora: “nerfar o valor do evade”. Por mim foi um caso de design de mecânica ruim levando a gente a desbalancear uma outra mecânica unrelated por meio de cards (e assim piorando a qualidade do jogo).

Se for esse o caso, aí eu acho que módulos podem contribuir pro jogo. E mesmo assim, só se você puder (melhor: dever) ter exatamente um módulo no jogo, porque mudanças de gameplay vêm em 2 tipos: as que simplificam o jogo e deixam ele imbalanceável (porque a complexidade do jogo normalmente já é a menor que a gente conseguir fazer ficar, logo remover elementos de complexidade piora o jogo), e as que complicam o jogo e deixam ele mais interessante, mas mais difícil.

What’s left

Eu ainda acho que é meio perigoso dive in em criar cartas já. Tem o problema do sistema

| dano == d*space
| m >= space

onde d e m são constantes. Depois de pensar numa idéia pra resolver isso, dá pra pensar em módulos, e em cards pro jogo.
DESDE QUE não existam EVER de jeito nenhum cards que servem pros 3 tipos de nave
really, enquanto ainda existir isso, o jogo vai estar quebrado, e portanto a gente não estará testando o jogo.

#5

[quote=“brocoli, post:4, topic:291”]Sobre design de cartas
no problems com isso, a questão é que se o jogo contém contradições de mecânica, as mecânicas precisam ser consertadas. Ignorar isso no melhor dos casos faz as cartas designed serem inúteis, no pior dos casos leva a design de cartas que superficialmente ajeitam o jogo, mas ao mesmo tempo transformam o defeito de mecânica numa coisa que não dá pra se livrar depois.

Basicamente, esse eh o ponto que determina a metodologia, não é arbitrario at all.[/quote]

Eu não disse que trabalhar nas mecânicas tem menos prioridade. Eu disse justamente que eu trabalhei nas mecânicas, e você pareceu não perceber isso ou simplesmente tratou como se o que eu tivesse feito não fosse relevante ou efetivo o suficiente. Mas nesse caso, você deveria ter criticado minhas propostas, e não o fato de eu achar que elas eram suficientemente boas para seguir adiante. E conhecendo você, é o que eu achei que você fosse fazer. Por isso ficou parecendo MUITO que você não leu o que eu escrevi no começo da thread (ou deliberademente ignorou).

E o que determina a metodologia somos nós todos juntos. E nós concordamos em tentar usar metodologias ágeis. Se não estiver dando certo ou alguém discordar, isso é um problema a ser levado para a próxima retrospectiva.

[quote=“brocoli, post:4, topic:291”]Balanceamento, e como introduzir elementos emocionantes num universo balanceado

exemplo da hora de mecânica de assault

Isso foi só um exemplo, o jogo tem que ter vários tipos de mecânicas assim; e eu acho que esse tipo de mecânica precisa guiar o processo de criação de cartas. Percebe também que cartas genéricas (i.e. que servem pros 3 main tipos de naves/manobras) destróem completamente esse tipo de dinâmica.[/quote]

Ok, isso foi uma crítica bem mais interessante. Apesar de não ter dito explícitamente, você está apontando algo que ficou faltando na minha análise do jogo. Isso é bom.

Então temos que definir melhor como queremos que cada tipo de nave funcione, e impor isso no design das cartas. Eu concordo. Só acho que talvez antes de determinar o que cada tipo de nave faz, tem mecânicas mais básicas do jogo que precisam ser trabalhadas com mais urgência (como o combate, as manobras e os setores). Justamente porque eu acho que o que você falou é muito importante, prefiro deixar para fazer na próxima iteração, para podermos nos focar melhor nela. Antes, quero ter melhor definido como funciona a parte “independente de cor” do jogo (assim como no Magic a mecânica dos terrenos, das criaturas e do combate não precisam de cor para estarem bem definidos).

[quote=“brocoli, post:4, topic:291”]About: módulos

Eu falei de uma contradição de mecânica na idéia de módulos no post anterior. A solução pra isso que você propôs foi…

Então, concordamos que módulos nunca jamais podem ter nenhum tipo de estatística somável anexada a eles, certo?[/quote]

Sim, concordamos. E você acha que o sistema de atributos que propûs atende esses requisitos?

Um módulo por partida, ou um módulo por jogador?
Não entendi o que os dois tipos de “mudança de gameplay” têm a ver com ter que ter apenas um módulo. Sorry se for algo dumb, mas não consegui acompanhar o raciocínio.
E não existe a mudança “deixa mais complicado e pior”?

[quote=“brocoli, post:4, topic:291”]What’s left

Eu ainda acho que é meio perigoso dive in em criar cartas já. Tem o problema do sistema

| dano == d*space
| m >= space

onde d e m são constantes. Depois de pensar numa idéia pra resolver isso, dá pra pensar em módulos, e em cards pro jogo.
DESDE QUE não existam EVER de jeito nenhum cards que servem pros 3 tipos de nave
really, enquanto ainda existir isso, o jogo vai estar quebrado, e portanto a gente não estará testando o jogo.[/quote]

Err… O que representam ‘d’ e ‘m’?
Mas imagino que você esteja se referindo ao problema da relação potencial_de_dano/espaço. Realmente ainda não sei muito bem o que fazer a respeito, fora o que já tínhamos pensado durantes os testes: poder mover/trocar unidades de setor depois delas terem sido construídas. Assim, o jogador tem como “consertar” os setores dele. E também quero fugir do jeito Yugioh de fazer (sacrificar coisas para baixar outras mais fortes, se não me engano).

E esse é um ponto onde (excepcionalmente) acho que valhe a pena fazer as cartas e testar antes de decidir. Sabendo que vai dar errado. Porque aí pelo menos eu vou poder “sentir na pele” o que deu de errado, e assim vou poder entender melhor a natureza do problema. Acredito que será mais fácil enxergar uma solução depois disso, pois saberemos a causa que deve ser eliminada.

Suspeito que você tenha sua própria ideia do que seja essa causa, e foi o que você tentou expressar com essas equações. Mas eu não entendi >.<

Então até você voltar a responder esse post, vou fazer do jeito mais primitivo e vou testar com cartas, porque é tudo o que consigo fazer no momento.

#6

Bom, depois de conseguir finalmente sentar e conversar com o brocoli nessa terça, parecce que estamos chegando em um consenso. As seguintes mudanças serão aplicaadas às regras ainda nessa iteração:
[hr]

[ul][li]
Problema: Dano limitado pelo total de espaço disponível.
Solução: Naves não têm mais número máximo de setores, apenas tamanho máximo. Por enquanto, haverá apenas um módulo por nave.
[/li][/ul]

[hr]

[ul][li]
Problema: Jogo muito numério e pouco qualitativo.
Solução: Novo esquema de manobras/combate. Agora, a manobra que você usa determina o modo como seus setores atacarão o oponente. Todo ataque é seguido de um contra-ataque, que seguirá a manobra que o oponente estiver usando. As manobras são:
[list]
[li]
Melee: Um setor seu ataca N setores, escolhidos pelo defensor. O poder do seu setor é confrontado em cada setor defensor descontado do número de setores atacados.
[/li]
[li]
Ranged: N setores seus atacam N setores diferentes do oponente, escolhidos por você. Na falta de setores para defender, o dano atinge o deck diretamente.
[/li]
[li]
Assault: N setores seus atacam um setor, escolhido pelo defensor. Os poderes são dos seus setores atacantes são somados juntos.
[/li]
[/list]
Consequentemente, as unidades passam a ter apenas um valor de poder.
[/li][/ul]

[hr]
E acho que agora podemos nos focar em bolar decks para teste. Hoje na reunião começamos esse processo e eu já montei um deck “ranged” XD.

#7

Não sei coloco isso aqui, mas andei pensando em sistemas e a coisas legais enquanto fazia o deck ~melee~, e acabei pensando em algo que pode (ou não) ser bacana:

Chamei (provisoriamente) de Compact. A ideia geral vem de “compactar” as unidades na nave, ou seja, diminuir o espaço ocupado por elas.

  Primeiro pensei em ser um Command que seria relativamente caro e que diminui o espaço em X de uma unidade. Mas no fim, acabei pensando que ia ser forte demais, e teria de ter limitações pra não ter unidades gigantes ocupando 0 de espaço.
  Posteriormente pensei em algo que pode ser mais balanceado. Algumas unidades podem ter a habilidade Compact, e é opcional seu uso quando é abaixado a unidade. Elas nesse caso remetem à um "kicker" no magic, meio que. Você pode abaixar a unidade normalmente, ou usando Compact, que diminuirá o espaço ocupado pela Unit em X, mas será necessário Y de cooldown a mais (ou seja gasta um dado extra para instalar a unidade).
  Escrevendo na carta eu tinha pensado na notação "Compact Y : [ x ]", sendo "Y" o cooldown a ser adicionado para abaixar e "x" o novo tamanho da unidade., caso você escolha compactar a carta.

  Pensando praticamente, isso pode ser meio não prático, já que as últimas mudanças no TCG foram pra deixar ele mais rápido e com menos contadores/dados, e isso obriga a lembrar se a unidade foi posta com Compact ou não... E também pensei mais como um sistema, não sei se combinaria em deck de melee xP

  Enfim, não sei se seria algo que quebraria muito o jogo, ou se é interessante, mas acabei tendo a ideia pensando em uma nave construindo unidades em seus setores, mas "comprimindo" eles para maior praticidade, só que isso gasta um tempo adicional de instalação...

Opiniões, críticas?

(Ps: primeiro reply no fórum \o/ !)

#8

Eu diria que Compact não é tão forte assim, porque cartas menores morrem mais fácil. Mas a ideia de usar como “kicker” achei que ficou muito boa! E seguindo também os moldes de MTG, o custo poderia ser qualquer coisa. Algo do tipo “volte uma unidade sua para a mão” me parece até melhor do que só um cooldown a mais, porque você faz a carta que baixou “valer por duas” ao mesmo tempo que “perde uma”, embora mais pra frente isso seja recompensado.

#9

Olá, pessoas. Estive analizando as partidas dessa semana e fazendo algumas simulações. Primeiro preciso ressaltar as mudanças que fizemos durante as reuniões e não havíamos colocado aqui ainda:

[ul][li]Como um dos custos para se baixar cartas era o espaço total já ocupado na sua nave, haveria uma inércia muito forte quando um jogador perdesse uma quantidade razoável delas. Ele não teria como reagir e virar o jogo. Por isso fizemos que unidades sempre morriam seguindo o modelo “Deep Damage”: elas continuariam ocupando o lugar em que estavam mesmo depois de destruídas. Assim, unidade destruídas continuam contando para o custo de ocupação.[/li]
[li]No combate, por enquanto usamos o contra-ataque após o ataque. E também fizemos que o defensor pode optar por não contra-atacar.[/li][/ul]

Agora vou tentar apontar o que achei que ficou bom. Vou começar com o que já esperávamos:

[ul][li]O combate está BEM mais rápido. Nada mais de ficar calculando todas as 6 possibilidades de resultado por ambos os jogadores escolherem suas manobras ao mesmo tempo.[/li]
[li]As manobras estão mais interessantes. Elas não são apenas mais um monte de números. O jogo fica mais simples.[/li]
[li]Nada de dados infinitos.[/li][/ul]

Fora isso, me surpreendi principalmente com os Comandos. Eles ficaram realmente divertidos, achei que estamos tendo boas ideias. De maneira geral, o jogo estava também muito mais fluido e agradável.
Mas ainda tem coisas que precisam de uma mexida. Vou colocar o que lembro aqui, e se vocês puderem acrescentem o que vocês acham que pode melhorar também.

[ul][li]Atributos. Parece que não estamos usando eles direito. Além de fazer as unidades darem mais atributos, acho que precisamos pensar melhor em como usá-los. Percebi, por exemplo, que quando faltavam atributos para jogar Comandos, também faltava ocupação para baixar mais unidades. Isso significa que eles estão bastante atrelados, sem falar que eles fazem a mesma coisa: satisfazem condições para usar cartas. Se eles continuarem desse jeito, seria melhor tirar um deles, porque a redundância só deixaria o jogo mais confuso.[/li]
[li]Balanceamento Melee-Ranged-Assault. Esse foi o principal foco das minhas preocupações. Fiz algumas simulações no papel, e várias vezes encontrava um meio de abusar das manobras e fazer uma delas muito mais forte. Consegui encontrar um equilíbrio bom quando fiz o contra-ataque ocorrer ao mesmo tempo que o ataque (como no MTG) e usando as seguintes unidades para cada tipo de manobra:
[list]
[li]Melee: 3[5] (um setor com 4 dessas)[/li]
[li]Ranged: 3[3] (dois setores com 3 dessas cada)[/li]
[li]Assault: 3[2] (três setores com 2 dessas cada)[/li]
[/list]
E a ideia é seguirmos essas cartas como referência. Mas ainda não estou completamente satisfeito. Alguém tem alguma sugestão?
[/li]
[li]
Comandos resolvem apenas quando seus timers acabam. O brocoli já tinha apontado isso. O timing dos efeitos do comandos fica muito sub-utilizado se eles só podem ser ativados exatamente quando o precast acaba, ao invés de serem “guardados para depois”. Podemos tentar algo assim ainda nessa iteração.
[/li][/ul]

Por último, uma proposta minha que acho que podemos usar também ainda nessa iteração:

[ul][li]Não usar mais custo de ocupação. Ao invés disso, quando usamos uma carta, cada timer que ela exige teria que realmente deixar alguma unidade em cooldown. Por exemplo, para baixar um unidade que requer 1+1+1, eu precisaria ter duas outras unidades para ficarem com cooldown de 1, e a carta que baixei teria seu precast como sempre.[/li][/ul]

Isso impede o jogador de jogar cartas fortes logo no começo, que era o motivo por termos feito o requerimento de ocupação. E também fornece escolhas mais interessantes para ele, como “eu poderia jogar esse comando agora, mas ficaria vulnerável”. Acho que talvez só precise de um pequeno ajuste: unidades em precast/cooldown já contarem como estando em jogo, o que significa que elas poderiam tomar dano, mas por outro lado seus bônus de atributo já ficaria valendo desde o começo.