Como Fazer um Jogo de Tabuleiro Digital: Guia Prático

Um jogo de tabuleiro digital é, na minha opinião, um dos melhores primeiros projetos que existem em desenvolvimento de jogos. Ele parece modesto perto de um plataforma ou de um RPG, e é exatamente por isso que funciona: as regras já estão prontas, não existe física para afinar, não existe ação em tempo real para sincronizar, e o jogo inteiro anda no ritmo que o código consegue acompanhar, um turno de cada vez. Neste guia você vai ver como escolher o jogo base sem cair em armadilha jurídica, como estruturar os turnos com uma máquina de estados, como representar o tabuleiro em código, como dar um oponente de IA ao jogador e por que o multiplayer local vem antes do online. Os exemplos são em GDScript tipado, no Godot 4.

Por que um jogo de tabuleiro digital é um ótimo primeiro projeto

Quando você faz um jogo de ação, três frentes difíceis chegam juntas: game design (as regras precisam ser divertidas), game feel (o controle precisa responder bem) e programação (tudo precisa rodar a 60 quadros por segundo sem engasgar). Um iniciante trava porque está aprendendo as três ao mesmo tempo.

O tabuleiro digital corta duas dessas frentes de uma vez.

As regras já foram testadas por séculos. Dama, ludo, trilha e jogo da velha funcionam. Você não precisa descobrir se o jogo é divertido; precisa só implementá-lo corretamente. Isso transforma um problema aberto de design num problema fechado de programação, que é o tipo de problema que ensina mais no começo.

Não existe tempo real. O jogo espera. Se a sua função de validar jogada demorar 5 milissegundos ou 50, ninguém percebe. Não há física, colisão, coyote time nem interpolação. Um bug não passa voando na tela: ele fica parado no tabuleiro, esperando você inspecionar o estado com calma.

O estado do jogo é pequeno e legível. Um tabuleiro de damas cabe numa matriz 8x8 de números inteiros. Você consegue imprimir o estado inteiro no console e ler. Poucos gêneros oferecem essa transparência para depurar.

O que sobra é justamente o músculo que todo dev de jogos precisa desenvolver: estruturas de dados, validação de regras, separação entre lógica e tela, e um fluxo de turnos bem organizado. É treino puro, sem as distrações caras.

Escolha do jogo base e a armadilha dos direitos

A primeira decisão é qual jogo implementar, e aqui mora uma confusão jurídica que vale desfazer logo.

Regras e mecânicas não têm copyright. A lei de direitos autorais protege expressão, não ideias nem sistemas. A mecânica de "mover na diagonal e capturar pulando" não pertence a ninguém. Por isso existem dezenas de apps de damas, xadrez e ludo na loja, todos legais.

Nome, arte, textos e marca têm proteção. "Monopoly" é marca registrada da Hasbro. O tabuleiro com aquelas cores, os desenhos das cartas, os nomes das ruas e o texto das regras são obra protegida. Recriar Monopoly com o nome Monopoly e o visual reconhecível é pedir para ser derrubado da loja. Recriar um jogo de compra e aluguel de propriedades, com nome próprio, arte própria e textos próprios, é perfeitamente possível.

A rota mais segura para um primeiro projeto é escolher um clássico de domínio público, onde nem o nome tem dono:

• Jogo da velha: o menor de todos, ótimo para fechar o ciclo completo (regras, IA, vitória) em poucos dias.
• Trilha (Nine Men's Morris): um degrau acima, com fases de colocação e movimento.
• Damas: o ponto ideal, na minha visão. Movimento, captura, promoção a dama e um espaço de jogadas rico o bastante para uma IA interessante.
• Ludo: adiciona dado e sorte, bom se você quer 4 jogadores.

Se depois de dominar um clássico você quiser criar as próprias regras, esse é outro projeto, com outro tipo de trabalho: o de como inventar um jogo do zero, testando e cortando regras até sobrar o essencial. Para o primeiro tabuleiro digital, pegue regras prontas e foque no código.

A estrutura em turnos: uma máquina de estados

Todo jogo de tabuleiro digital tem o mesmo esqueleto, e ele é uma máquina de estados. Em vez de espalhar ifs pelo projeto perguntando "de quem é a vez?", você declara os estados possíveis e controla as transições num lugar só:

# jogo.gd
# A maquina de estados que rege a partida inteira.
extends Node

enum Estado {
    TURNO_JOGADOR_A,  # A escolhe e executa uma jogada
    TURNO_JOGADOR_B,  # B (humano ou IA) faz o mesmo
    FIM_DE_JOGO,      # alguem venceu ou empatou
}

var estado: Estado = Estado.TURNO_JOGADOR_A

# Sinal para a interface reagir sem a logica conhecer a tela.
signal turno_mudou(novo_estado: Estado)
signal partida_terminou(vencedor: int)

func tentar_jogada(origem: Vector2i, destino: Vector2i) -> void:
    # So aceita jogada de quem esta no proprio turno.
    if estado == Estado.FIM_DE_JOGO:
        return
    if not validar_jogada(origem, destino):
        return  # jogada ilegal, nada muda

    executar_jogada(origem, destino)

    var vencedor: int = checar_vitoria()
    if vencedor != 0:
        estado = Estado.FIM_DE_JOGO
        partida_terminou.emit(vencedor)
        return

    # Alterna o turno.
    if estado == Estado.TURNO_JOGADOR_A:
        estado = Estado.TURNO_JOGADOR_B
    else:
        estado = Estado.TURNO_JOGADOR_A
    turno_mudou.emit(estado)

Leia esse fluxo com atenção, porque ele é o jogo inteiro: recebe uma tentativa de jogada, valida, executa, checa vitória, alterna o turno. Tudo o que vem a seguir (tabuleiro, IA, multiplayer) só preenche as funções que esse esqueleto chama. Se você já montou o loop de turno de um jogo de cartas no Godot, vai reconhecer a estrutura: é a mesma ideia, com o baralho trocado por um grid.

Representando o tabuleiro em código: o grid 2D

O tabuleiro é uma matriz: cada casa guarda um inteiro dizendo o que está ali. Como o GDScript não tipa Arrays aninhados, o padrão mais limpo é um Array[int] achatado, indexado por posição, com Vector2i como endereço de casa:

# tabuleiro.gd
# O estado do jogo vive AQUI, nunca nos nodes da tela.

const TAMANHO: int = 8       # 8x8 para damas; use 3 para jogo da velha
const VAZIO: int = 0
const PECA_A: int = 1        # peca do jogador A
const PECA_B: int = 2        # peca do jogador B

var casas: Array[int] = []

func _ready() -> void:
    casas.resize(TAMANHO * TAMANHO)
    casas.fill(VAZIO)

func dentro_do_tabuleiro(pos: Vector2i) -> bool:
    return pos.x >= 0 and pos.x < TAMANHO and pos.y >= 0 and pos.y < TAMANHO

func obter(pos: Vector2i) -> int:
    return casas[pos.y * TAMANHO + pos.x]

func definir(pos: Vector2i, valor: int) -> void:
    casas[pos.y * TAMANHO + pos.x] = valor

A regra de ouro é a mesma de qualquer jogo bem arquitetado: a lógica lê e escreve nesse Array; a parte visual (sprites das peças, destaque de casa selecionada) apenas espelha esses dados. Quando uma jogada acontece, você atualiza o Array e depois redesenha. Nunca o contrário.

Com o grid pronto, as duas funções centrais do jogo ficam curtas. Primeiro a validação, no espírito de damas simplificadas (movimento diagonal de uma casa para frente, sem captura ainda):

# Retorna true se mover a peca de origem para destino e legal
# para o jogador da vez. Regras de damas simplificadas.
func validar_jogada(origem: Vector2i, destino: Vector2i) -> bool:
    if not dentro_do_tabuleiro(origem) or not dentro_do_tabuleiro(destino):
        return false

    var peca: int = obter(origem)
    var jogador: int = PECA_A if estado == Estado.TURNO_JOGADOR_A else PECA_B
    if peca != jogador:
        return false          # so move a propria peca
    if obter(destino) != VAZIO:
        return false          # destino precisa estar livre

    var delta: Vector2i = destino - origem
    # A avanca para baixo (+1 em y), B avanca para cima (-1 em y).
    var direcao: int = 1 if jogador == PECA_A else -1
    # Diagonal simples: uma casa para o lado, uma na direcao certa.
    return abs(delta.x) == 1 and delta.y == direcao

E a checagem de vitória, aqui na versão de jogo da velha (grid 3x3), que é o caso mais didático: retorna 0 se a partida continua, ou o número do jogador vencedor:

# Retorna 0 (ninguem ainda), PECA_A ou PECA_B.
func checar_vitoria() -> int:
    # Linhas e colunas.
    for i in range(TAMANHO):
        var linha: int = obter(Vector2i(0, i))
        if linha != VAZIO and linha == obter(Vector2i(1, i)) and linha == obter(Vector2i(2, i)):
            return linha
        var coluna: int = obter(Vector2i(i, 0))
        if coluna != VAZIO and coluna == obter(Vector2i(i, 1)) and coluna == obter(Vector2i(i, 2)):
            return coluna
    # Diagonais.
    var centro: int = obter(Vector2i(1, 1))
    if centro != VAZIO:
        if centro == obter(Vector2i(0, 0)) and centro == obter(Vector2i(2, 2)):
            return centro
        if centro == obter(Vector2i(2, 0)) and centro == obter(Vector2i(0, 2)):
            return centro
    return 0

Em damas, a mesma função contaria peças: se um lado ficou sem peças ou sem jogadas legais, o outro venceu. A assinatura não muda, só o miolo. É por isso que a máquina de estados lá de cima não precisa saber qual jogo está rodando.

Uma IA de oponente em camadas

O erro clássico é tentar fazer uma IA esperta de primeira. O caminho certo é por camadas, cada uma jogável:

Camada 1: aleatória válida. Liste todas as jogadas legais do jogador B e sorteie uma. Repare que você já tem a peça central pronta: validar_jogada. A IA só percorre o tabuleiro testando pares origem e destino:

# Devolve todas as jogadas legais do jogador da vez.
func listar_jogadas_legais() -> Array[Vector2i]:
    # Cada jogada vira um par: indice par = origem, impar = destino.
    var jogadas: Array[Vector2i] = []
    for y in range(TAMANHO):
        for x in range(TAMANHO):
            var origem := Vector2i(x, y)
            for dx in [-1, 1]:
                for dy in [-1, 1]:
                    var destino := origem + Vector2i(dx, dy)
                    if validar_jogada(origem, destino):
                        jogadas.append(origem)
                        jogadas.append(destino)
    return jogadas

Sortear um par dessa lista já produz um oponente funcional. Fraco, mas funcional, e o jogo se torna jogável sozinho no mesmo dia.

Camada 2: heurística gulosa. Em vez de sortear, dê uma pontuação a cada jogada: capturar uma peça vale 10, chegar à última linha (virar dama) vale 8, avançar vale 1. A IA escolhe a jogada de maior pontuação, com sorteio só para desempatar. Isso já pune descuido do jogador e dá sensação de oponente de verdade.

Camada 3: minimax. É o próximo nível, não o primeiro. O minimax simula a árvore de jogadas futuras ("se eu jogar isso, o que ele responde de pior para mim?") e escolhe o ramo que minimiza o prejuízo. Para jogo da velha ele é imbatível e simples; para damas exige poda e limite de profundidade. Cite no seu roadmap, implemente quando as camadas 1 e 2 estiverem rodando.

Multiplayer: hot seat primeiro, online depois

A tentação de fazer online logo de cara é grande, e é a segunda maior assassina de primeiros projetos (a primeira é escopo de arte). A boa notícia do tabuleiro é que ele tem o multiplayer mais barato que existe: o hot seat, dois jogadores no mesmo dispositivo, alternando a vez.

Olhe de novo a máquina de estados: TURNO_JOGADOR_A, TURNO_JOGADOR_B. Para hot seat, você não muda nada. Os dois turnos leem o mesmo input, e a única cortesia é a interface indicar de quem é a vez. É o mesmo raciocínio do multiplayer local com tela dividida no Godot: resolver o jogo a dois no mesmo aparelho ensina 80% das lições do multiplayer sem nenhum custo de rede.

Quando o online chegar, a arquitetura em turnos vai te pagar de volta. Um jogo de ação online precisa sincronizar estado dezenas de vezes por segundo; um jogo de tabuleiro só precisa transmitir uma jogada por turno, um par de Vector2i. O receptor roda o mesmo validar_jogada e executar_jogada localmente, e os dois tabuleiros ficam idênticos por construção. Poucos gêneros tornam o online tão tratável.

Fechando: o projeto que termina

Um roteiro honesto para as próximas semanas: escolha um clássico de domínio público, monte o grid e a máquina de estados, feche o jogo da velha completo (com vitória e empate) para validar o esqueleto, depois migre para damas simplificadas no mesmo código. IA aleatória, depois gulosa. Hot seat funcionando de ponta a ponta antes de pensar em rede.

O valor desse projeto não está na loja de aplicativos, está no que ele deixa em você: a disciplina de separar dados da tela, o hábito de validar toda entrada e uma máquina de estados que você vai reutilizar em praticamente todo jogo que fizer depois. Termine este, e o próximo projeto começa com metade do caminho andado.