Core loop: a menor unidade de diversão repetível

Resultado e mapa da aula

Ao final desta aula, você vai conseguir olhar para qualquer ideia de jogo — inclusive a sua — e escrever, em uma frase de quatro ou cinco passos, o core loop: o ciclo exato de ações que o jogador vai executar centenas ou milhares de vezes até terminar o jogo. Essa frase vira, mais adiante na trilha, o primeiro pedaço de GDD que você escreve (Aula 14) e o primeiro sistema que você implementa no Godot (a partir da Aula 14 técnica). Sem um core loop nomeado, qualquer conteúdo que você adicionar a um protótipo — mais inimigos, mais itens, mais fases — continua parecendo solto, exatamente o problema descrito na Aula 1.

1. Vemos por que "ter várias mecânicas" não é o mesmo que "ter um loop que sustenta uma sessão inteira".
2. Definimos loop com o modelo de quatro passos de Dan Cook e vemos seu exemplo mais granular: o pulo do Mario.
3. Formalizamos "core loop" com a definição acadêmica de Emmanuel Guardiola — e um caso real medido: o jogo Blue Estate.
4. Aprendemos por que um loop perde graça sem variação, com o estudo de caso de Raph Koster.
5. Praticamos nomeando o core loop do protótipo de cristais das Aulas 1–2 e verificamos com 10 perguntas de recuperação.

O problema real: muita mecânica, nenhum loop

Retome o cenário da Aula 1: personagem que anda, pula, colide com paredes — funciona, mas não sustenta uma sessão. Uma resposta comum de quem está começando é "adicionar mais coisas": um inimigo, um item, uma segunda fase. O problema raramente é falta de conteúdo. É a ausência de um ciclo nomeado que o conteúdo novo deveria reforçar. Sem saber qual é o loop central do seu jogo, você não sabe se um inimigo novo fortalece esse ciclo ou só compete com ele por atenção.

O designer Dan Cook — autor cujos modelos deste tópico são referência na comunidade de game design desde 2005 — descreve o loop como algo que ocorre em múltiplas escalas ao mesmo tempo: "These loops are fractal and occur at multiple levels and frequencies throughout a game. They are almost always exercised multiple times, either within a game or by playing the game multiple times" Cook, "Loops and Arcs", Lost Garden, 2012. Esta aula foca no menor nível dessa escala: o loop que, sozinho, decide se um protótipo é ou não é interessante de jogar por mais de cinco minutos.

O loop como ciclo de quatro passos

Repare que esse ciclo é o mesmo "feedback" da Aula 1 e a mesma "Dinâmica" da Aula 2, agora descrito como um mecanismo concreto com passos nomeados: modelo mental → ação → resposta do sistema → feedback → modelo mental atualizado → repete. Cinco anos antes de formalizar esse modelo geral, Cook já havia descrito a versão mais granular dele — o que chamou de skill atom — com um exemplo que qualquer pessoa que já jogou um platformer reconhece:

Note o detalhe pedagógico: um único pulo já é um loop completo — ação, simulação, feedback, modelagem mental —, mas ele só ensina alguma coisa quando se repete: "Implicit in this model is that the atom is often looped through multiple times before the user understand what it teach" Cook, "The Chemistry of Game Design", 2007. É exatamente por isso que a aula chama o core loop de "a menor unidade de diversão repetível" — não é a menor ação, é a menor ação que precisa se repetir para gerar aprendizado e, com ele, a Estética discutida na Aula 2.

Loop vs. arc: o que se repete e o que não se repete

Cook também nomeia o contraponto do loop — o que ele chama de arc: "An arc is a broken loop you exit immediately" Cook, "Loops and Arcs", 2012. Uma cutscene, um diálogo único de história, um evento de fase que só acontece uma vez — nada disso se repete, e por isso não é loop, mesmo fazendo parte do jogo. Loops e arcs cumprem funções cognitivas diferentes: "Loops are very good at building 'wisdom', a holistic understanding of a complex system [...] Arcs are highly efficient at communicating 'success stories' [...] This is a brilliant learning shortcut but the acquired knowledge is often quite different and less robust in the face of change than 'wisdom'" Cook, 2012. Um jogo bem-sucedido normalmente mistura os dois: um core loop que o jogador domina por repetição, e arcs pontuais (uma revelação de história, o fim de uma fase) que marcam progresso sem se repetir.

LOOP (se repete)                    ARC (não se repete)
modelo mental → ação → sistema  →   evento único que quebra
↑                    ↓          o ciclo e não volta a
└── feedback ────────┘          acontecer da mesma forma
Cook: "an arc is a broken loop you exit immediately."

Formalizando "core loop": a definição acadêmica e um caso real medido

O termo "core loop" circula na indústria com sentidos diferentes — e confundi-los é um erro comum. O pesquisador e diretor de jogos Emmanuel Guardiola, em um artigo acadêmico revisado por pares, faz questão de separar três usos:

Ou seja: "OCR" (Objetivo-Desafio-Recompensa) é útil para falar de um jogo em nível macro, mas grande demais para desenhar um sistema concreto; o "loop de interação" (o ciclo entrada→resposta a cada input individual, o mesmo que a Aula 2 chamou de Dinâmica em escala mínima) é pequeno demais para descrever uma sessão inteira. Core loop, no sentido que esta aula ensina — o mesmo de Guardiola —, fica entre os dois: "the set of actions the player will iterate the most, and in which the winning/losing condition are real outcomes" Guardiola, p. 3.

O artigo documenta um caso real de produção — o jogo Blue Estate: The Game — onde a equipe formalizou o core loop como:

Quase 2.000 repetições do mesmo ciclo de cinco passos. Se qualquer um desses passos for tedioso, confuso ou mal calibrado, o problema se multiplica por 2.000 — é essa matemática que justifica gastar tempo desenhando o core loop antes de qualquer outra coisa em um projeto novo.

Guardiola também mostra como um estúdio expande um core loop sem alterar seu núcleo: "we kept the core loop as a central framework and peripherally added ideas of activity which could modify or increase the intensity of the challenge" (p. 5) — variações entram ao redor do loop, não dentro dele.

Cuidado com uma palavra sobrecarregada: o "loop" de Jesse Schell

O mesmo Jesse Schell citado nas Aulas 1 e 2 usa a palavra "loop" para duas coisas diferentes — e é fácil confundi-las. A primeira é a "Rule of the Loop": "The more times you test and improve your design, the better your game will be" [Schell, The Art of Game Design, cap. 7, p. 80]. Isso descreve o ciclo de iteração do processo de design (prototipar → testar → melhorar) — não é o assunto desta aula.

A segunda é a "Loop of Interaction", muito mais próxima do que estamos estudando: "Information flows in a loop from player to game to player to game, round and round. It is almost like this flow pushes a waterwheel that generates experience when it spins" [Schell, cap. 13, p. 228]. Essa é a mesma ideia do skill atom de Cook, com uma regra prática de calibração citável: "it is a good rule of thumb that if your interface does not respond to player input within a tenth of a second, the player is going to feel like something is wrong with the interface" [Schell, p. 231]. Guarde esse número — um décimo de segundo — para quando a trilha chegar em input no Godot (Aula 15).

Por que um loop perde graça: o estudo de caso do jogo de tubarões

Um core loop bem desenhado ainda pode ficar tedioso se nunca mudar. Raph Koster, autor de A Theory of Fun for Game Design, descreve o momento em que reconheceu esse limite jogando um jogo educativo de digitação com seus filhos:

O loop em si (digitar a palavra certa antes que o tubarão alcance o personagem) continuava tecnicamente funcionando — mas parou de gerar padrões novos para aprender, e por isso parou de ser interessante. Koster resume o princípio de forma direta: "Games that are too hard kind of bore me, and games that are too easy also kind of bore me" Koster, cap. 1. Um core loop sustenta uma sessão inteira não porque se repete — repetição sozinha cansa — mas porque cada repetição continua exigindo um ajuste pequeno e novo de quem joga. Koster chama esse reconhecimento de padrão de a própria essência do jogo: "Games are largely about getting people to see past the variations and look instead at the underlying patterns" Koster, cap. 5, 2004.

A ponte com a Aula 2: loop é a Dinâmica tornada concreta

Nenhuma das fontes desta aula cita o framework MDA diretamente — a conexão a seguir é uma síntese didática desta trilha, não uma citação literal, da mesma forma que a Aula 1 sintetizou "regras, objetivos e feedback" a partir de autores que não usam exatamente esses três termos juntos. A própria definição de Dinâmica da Aula 2 já descreve o que um loop é, em outras palavras: "Dynamics describes the run-time behavior of the mechanics acting on player inputs and each others' outputs over time" [Hunicke, LeBlanc & Zubek, MDA, p. 2]. Um core loop é esse comportamento em tempo real tornado concreto e nomeável: a sequência específica de Mecânicas que, repetida centenas ou milhares de vezes, produz a Dinâmica observável do jogo — e, por consequência, a Estética que o jogador sente.

MECÂNICA           →  CORE LOOP                →  DINÂMICA        →  ESTÉTICA
(as regras/ações       (a sequência específica     (o padrão          (a experiência,
individuais)           dessas ações, repetida       observável         Aula 2)
centenas/milhares de         que emerge)
vezes — Aula 3)

Testando o conceito no protótipo de cristais das Aulas 1–2

Retome a versão final do protótipo (tempo limitado, parede avançando, pontuação a bater). Seu core loop, no formato de Guardiola:

Aplique o teste de Cook — "What repeats and what does not?" Cook, 2012 — a esse ciclo: os cinco passos se repetem dezenas de vezes em 90 segundos (o loop). O fim da rodada, com a comparação contra a melhor pontuação salva, acontece uma vez por tentativa e não se repete dentro dela (o arc que fecha cada sessão). E, seguindo Koster, o loop continua interessante porque a distância dos cristais varia a cada rodada — sem essa variação, o mesmo loop viraria o jogo dos tubarões depois de poucas tentativas.

Abordagens incorretas — e por que falham

Confundir "core loop" com OCR

Dizer "o core loop do meu jogo é: objetivo, desafio, recompensa" descreve qualquer jogo do mundo — é grande demais para guiar uma decisão de implementação. Guardiola já avisa: OCR serve para discutir um jogo em nível conceitual, não para desenhar um sistema concreto [Guardiola, p. 1]. Escreva o loop com verbos específicos do seu jogo (mover, coletar, reavaliar), não com categorias abstratas que servem para qualquer jogo.

Adicionar conteúdo sem checar se ele reforça o loop

Um inimigo novo, uma arma nova, um cenário novo — cada adição deveria caber em algum passo do core loop já definido (mais uma coisa para "identificar", uma nova forma de "decidir o risco"). Conteúdo que não se encaixa em nenhum passo do loop compete por atenção com ele, em vez de fortalecê-lo, e costuma ser a causa raiz de um protótipo que "parece bagunçado" mesmo tendo mais coisas do que antes.

Projetar um loop perfeito e nunca variar o desafio

Mesmo um loop bem desenhado, com os cinco passos claros de Blue Estate, cansa sem calibração de dificuldade — o caso do jogo de tubarões de Koster. Um core loop sozinho não é suficiente: ele precisa de uma curva de desafio ao redor dele, tema que a Aula 5 (progressão e curva de dificuldade) desenvolve em detalhe.

Prática guiada: nomeie o core loop da sua própria ideia

Uma resposta incompleta

"O jogador luta contra inimigos até vencer." Isso nomeia um objetivo (Aula 1), não um core loop — falta o passo a passo verificável. Não dá para saber, só com essa frase, o que exatamente vai se repetir centenas de vezes.

Uma resposta que fecha o loop

"Detectar inimigo próximo → posicionar-se para atacar sem ser atingido → atacar → observar o dano causado e o dano recebido → decidir se recua ou continua → repetir." Cada passo é uma ação verificável (a mesma granularidade do exemplo de Blue Estate), o feedback central é "observar o dano causado e recebido" (sem ele, o jogador não sabe se a decisão de atacar foi boa), e a variação vem de que inimigo aparece, com que padrão de ataque — o que evita repetir exatamente a mesma decisão a cada volta do loop.

Verificação: leia seu loop em voz alta como uma receita de cinco passos. Se algum passo não é uma ação concreta que o jogador realmente executa (um verbo, não um substantivo abstrato como "diversão" ou "progressão"), reescreva-o.

Perguntas de entrevista e de mercado

"Como você define o core loop de um jogo em uma frase?" Cite a definição de Guardiola: o conjunto de ações que o jogador mais repete, no qual vitória e derrota são desfechos reais — e diferencie explicitamente de OCR (macro demais) e do loop de interação input/feedback (micro demais).

"Me dê um exemplo real e documentado de core loop, com números." Use Blue Estate: identificar alvo, escolher alvo, mover a mira, permanecer no alvo, atirar, reiniciar — repetido quase 2.000 vezes para terminar o jogo. Isso mostra que você entende a escala de repetição que justifica o cuidado no design do loop.

"Por que um jogo com um loop tecnicamente bem feito pode ainda ficar chato?" Responda com o caso do jogo de tubarões de Koster: o loop parou de gerar desafio novo. Conecte com a régua de Koster ("too hard... too easy... kind of bore me") e com a forma como Guardiola resolve isso em Blue Estate — variação periférica ao redor de um núcleo fixo.

Recupere da memória: 10 questões

Feche o modelo mental

Um core loop é o ciclo de ações que o jogador mais repete — pequeno o bastante para ser escrito em quatro ou cinco verbos, grande o bastante para incluir uma ação, uma decisão e um feedback que fecha o ciclo. Ele não é o mesmo que OCR (grande demais) nem o mesmo que o loop de interação de cada input individual (pequeno demais) — e não é o mesmo "loop" que Schell usa para descrever o processo de testar e melhorar um design. Ele precisa se repetir centenas ou milhares de vezes (o caso de Blue Estate) sem esgotar o jogador (o alerta do jogo de tubarões de Koster), o que significa variar o desafio ao redor de um núcleo estável — o assunto direto da próxima aula.

Aulas anteriores: Aula 01 — O que faz algo ser "um jogo" e Aula 02 — O framework MDA.

Próxima aula planejada: tipos de jogos e gêneros — como a escolha de gênero já implica um core loop típico, e quando vale a pena fugir dele.

Referências primárias para aprofundar

O modelo de loop de quatro passos, o skill atom e a distinção loop/arc vêm de Daniel Cook, "Loops and Arcs", Lost Garden, 2012 e Daniel Cook, "The Chemistry of Game Design", 2007. A definição acadêmica de core loop e o caso real de Blue Estate vêm de Emmanuel Guardiola, "The Gameplay Loop: A Player Activity Model for Game Design and Analysis", ACE 2016 — ACM Digital Library. A distinção entre os dois usos da palavra "loop" em Jesse Schell vem de The Art of Game Design: A Book of Lenses — página da editora. O estudo de caso sobre desgaste de um loop sem variação vem de Raph Koster, A Theory of Fun for Game Design, Capítulo 1 — trecho oficial gratuito e do Capítulo 5, via captura arquivada em HTTPS.

Consulte também o registro de pesquisa desta aula em learning-paths/desenvolvimento-de-jogos/research/core-loop.md, no repositório do curso.