DEV Community: Ace Jogos do Rei

Building a Searchable Card-Game Glossary with Static HTML, Lightweight JS and SEO Pages

Ace Jogos do Rei — Tue, 21 Apr 2026 12:37:03 +0000

Building a Searchable Card-Game Glossary with Static HTML, Lightweight JS and SEO Pages

At Jogos do Rei, we serve a very specific audience: Brazilian players who care about traditional card games like Buraco, Tranca and Truco. That audience has real search demand, but it also has a vocabulary problem.

Players search for terms like morto, manilha, canastra limpa, 3 preto and mão de onze. If you don't explain those terms clearly, you lose both search traffic and user trust.

So we built a searchable glossary page as a lightweight static site, with a simple goal: make the terminology easy to understand and easy to index.

Constraints

We did not need a complex frontend stack for this.

The requirements were:

fast load on desktop and low-end mobile devices
indexable pages for glossary terms
simple client-side search
internal links back to the main platform and rules pages
easy maintenance by a small team

That pushed us toward a very simple architecture.

Stack

The glossary was built with:

static HTML
small amounts of vanilla JavaScript
semantic headings and internal links
sitemap and robots for crawlability

Public examples:

Main platform: Jogos do Rei
Glossary hub: glossario-buraco on GitHub Pages

Why static was the right choice

A glossary is mostly a content retrieval problem, not an application state problem.

That means the best tradeoff was:

pre-render the page
keep markup semantic
use lightweight client-side filtering for UX
avoid framework overhead

Static delivery gave us predictable performance, zero runtime complexity for the glossary itself and cleaner crawl paths.

Search experience

We added a client-side search box so users can type a term like morto or manilha and quickly find the relevant card.

This is intentionally simple. The page does not need fuzzy ranking, remote queries or a heavy component tree. It just needs to reduce friction.

For informational surfaces like this, the engineering question is usually not “how do we make this more sophisticated?”

It is “what is the smallest system that solves the problem reliably?”

SEO decisions that mattered

The useful parts were not fancy.

They were basic things done consistently:

descriptive title and meta description
canonical URL
internal links back to the product and rules pages
content grouped by game concepts
readable copy written around the actual language players use

We also added supporting files such as sitemap/robots and expanded navigation so related pages reinforce each other instead of competing blindly.

Product lesson

When you run a niche product, terminology is part of onboarding.

A glossary is not just an SEO artifact. It also reduces support friction and helps new players understand game rules faster.

That was the main reason this project was worth shipping.

Takeaway

If your users search for domain-specific terms, a small static glossary can be one of the highest-leverage content/engineering hybrids you can build.

Keep it fast. Keep it indexable. Keep it useful.

And only add complexity if the problem really demands it.

If you want to see the public examples:

Como construí um glossário de jogos de cartas brasileiros com HTML e JavaScript puro

Ace Jogos do Rei — Sat, 18 Apr 2026 11:53:39 +0000

Como construí um glossário de jogos de cartas brasileiros com HTML e JavaScript puro

Se você já jogou Buraco, Tranca ou Truco, sabe que cada jogo tem um vocabulário próprio. Morto, canastra limpa, manilha, 3 preto… são termos que confundem até jogadores experientes.

No Jogos do Rei, a maior plataforma de jogos de cartas do Brasil, percebemos que nossos jogadores precisavam de uma referência clara e acessível. A solução: um glossário público, totalmente estático, hospedado no GitHub Pages, sem frameworks, sem build steps — só HTML, CSS e JavaScript vanilla.

O desafio

Precisão: o conteúdo tinha que refletir fielmente as regras oficiais de cada modalidade (Buraco Aberto, Buraco Fechado, STBL, Tranca, Truco).
Acessibilidade: o site precisava funcionar bem em qualquer dispositivo, inclusive para nosso público principal (jogadores 60+, muitos em desktop).
Manutenção simples: queríamos que qualquer pessoa da equipe pudesse editar os termos sem precisar de conhecimento técnico avançado.
SEO: o glossário deveria aparecer em buscas por termos como "o que é morto no buraco", "regras da tranca", "como jogar truco paulista".

A solução técnica

Optamos por uma stack minimalista:

HTML5 semântico – cada termo é um <article> com <h3> e <p>, facilitando a indexação.
CSS Grid/Flexbox – layout responsivo que se adapta de mobile a desktop sem media queries complexas.
JavaScript vanilla – uma função de busca client-side de ~20 linhas que filtra os termos em tempo real.
GitHub Pages – hospedagem gratuita, com deploy automático via git push.

Exemplo do código de busca

function filtrarTermos() {
  const q = document.getElementById('search').value.toLowerCase();
  const cards = document.querySelectorAll('.term-card');
  let found = 0;
  cards.forEach(card => {
    const text = (card.getAttribute('data-termo') + ' ' + card.innerText).toLowerCase();
    const match = !q || text.includes(q);
    card.style.display = match ? '' : 'none';
    if (match) found++;
  });
  document.getElementById('no-results').style.display = (found === 0 && q) ? 'block' : 'none';
}

Bônus: página comparativa

Além dos glossários individuais, criamos uma página comparativa que coloca lado a lado as cinco modalidades disponíveis na plataforma. A tabela mostra diferenças como:

Número de cartas
Presença de curingão
Permissão de trincas
Regra para bater (ganhar a rodada)
Complexidade estratégica

Essa página é especialmente útil para jogadores que querem experimentar uma nova modalidade e precisam entender rapidamente o que muda.

Resultados

Indexação rápida: o site apareceu nos resultados do Google em menos de 48 horas.
Feedback positivo: jogadores elogiaram a clareza e a facilidade de consulta.
Baixa manutenção: desde o lançamento, fizemos apenas duas pequenas correções (typos).

Lições aprendidas

Vanilla JS ainda é poderoso – para projetos de conteúdo estático, frameworks são overkill.
SEO orgânico ama HTML semântico – usar <table> para tabelas comparativas gerou rich snippets automaticamente.
Performance é feature – o site carrega em <1s mesmo em conexões lentas, porque não há nada além de arquivos estáticos.
Documentação é produto – um glossário bem feito reduz suporte (menos perguntas sobre regras) e engaja a comunidade.

O código está aberto

Todo o projeto está disponível no GitHub: jogosdorei/glossario-buraco. Sinta-se à vontade para usar como base para seus próprios glossários ou sites de referência.

E você? Já construiu algo similar?

Conta aí nos comentários se você já fez algum projeto de documentação técnica com stack minimalista. Quais foram os desafios e acertos?

Este artigo foi escrito pelo Ace, personagem do Jogos do Rei, plataforma com mais de 3 milhões de jogadores de cartas online no Brasil.

How We Built a Card Game Platform with 3 Million Players (and What We Learned)

Ace Jogos do Rei — Mon, 06 Apr 2026 18:42:17 +0000

How We Built a Card Game Platform with 3 Million Players (and What We Learned)

A founder's tech perspective on scaling an online card game in Brazil

Building a niche gaming platform that lasts 15 years and reaches 3 million players doesn't happen by accident. At Jogos do Rei, we've been running Brazil's largest online card games platform since 2010 — and I want to share some of what we learned along the way.

This isn't a story about hockey-stick growth or VC funding. It's about building something deeply rooted in culture, keeping the servers alive, and not alienating the players who trust you.

What We Built

Jogos do Rei is a platform for traditional Brazilian card games: Buraco (known as Canastra in some regions), Tranca, Truco, and STBL (Buraco Fechado). These are games most Brazilians grew up watching their grandparents play. Our job was to bring them online, keep them social, and make them feel authentic.

By the numbers:

3+ million registered players
Games running 24/7 since 2010
Daily tournaments with real opponents (no bots in game rooms)
Weekly leagues with ranking systems

The Real Challenge: Real-Time Multi-Player State

Card games look simple from the outside. But managing real-time multiplayer state for a game like Buraco is surprisingly tricky.

The State Problem

At any point in a Buraco hand, you need to track:

Each player's hand (private)
The table (public plays visible to all)
The discard pile (public, ordered)
Two "mortos" (hidden piles of 11 cards each, revealed when a player goes out)
Round scores and game scores

The game has complex actions: drawing from the deck, picking up the entire discard pile (only valid with certain conditions), laying down melds, extending existing melds, and going out in three different ways (direct, indirect, and final).

All of this needs to be:

Validated server-side (never trust the client)
Transmitted in near-real-time to all players at the table
Kept in sync even when connections drop

Our Approach

We kept a canonical authoritative game state on the server. Clients send actions (not state updates). The server validates, applies the action, and broadcasts the new state delta.

This "server is king" model means:

No cheating via client manipulation
Clean reconnect logic (request full state on reconnect)
Easier to audit for anti-cheat

The trade-off is latency sensitivity. For a card game, we found that under 300ms round-trip is fine. Players don't feel rubber-band effects the way they do in action games.

Matchmaking: The Hidden Hard Problem

When you have 3 million registered players but only a fraction online at any moment, matchmaking becomes critical.

The Peaks and Valleys Problem

Brazilian players are concentrated in specific timezone windows: lunch (12–14h BRT) and evening (20–23h BRT). Outside those peaks, finding 4 players for a Buraco table can take time.

Our solution:

Tiered waiting: Short queue timeout → downgrade table requirements (e.g., allow cross-skill-level match)
Lobby visibility: Show players waiting in lobbies so others feel encouraged to join
Daily tournaments: Pre-scheduled times aggregate players, solving the coordination problem

Rating Systems for Card Games

Standard Elo works reasonably well for 1v1. For 2v2 (which Buraco supports), we adapted it with team-based rating adjustments. The key insight: in card games, luck variance is high. A rating system that moves too fast produces frustration; one that moves too slow feels unrewarding.

We use a dampened Elo where K-factor decreases as player count grows, and we separate tournament ratings from casual ratings.

The Social Layer is Not Optional

Card games in Brazil are deeply social. Buraco at the club is as much about conversation as the cards. When we stripped that out early on, retention suffered.

What we added over time:

In-game chat (with moderation — this is crucial)
Persistent player profiles with statistics and ranking
League system — weekly competitions that create regular engagement loops
Tables with names — players can name their tables, creating regulars

The lesson: if you're building a multiplayer casual game, the social graph is the product, not the game itself.

Mobile vs Web: Still Not Solved

Our player base skews 40–65 years old. That changes everything about your mobile strategy.

Counterintuitive finding: older users often prefer desktop web. They have larger screens, are comfortable with browsers, and are wary of installing apps.

But mobile is growing, especially Android on budget devices. Our Android app (available on Play Store) required significant work to run well on 3–4 year old mid-range devices with 2GB RAM.

Key optimizations for low-end Android:

Lazy-load non-critical assets
Minimal JS bundle (this is a card game, not a 3D shooter)
Aggressive caching of card and table assets
Graceful degradation of animations

Moderation at Scale: The Unglamorous Work

3 million players means a meaningful percentage will behave badly. Buraco has a "no hints to partner" rule that's impossible to auto-enforce (it's a social contract, not a technical constraint).

What we can enforce:

Abusive chat (filter + report system)
AFK/abandonment (timeout system with automatic play)
Collusion patterns (statistical anomaly detection on team win rates)

We give players a "Denunciar Abuso" (Report Abuse) button on every player avatar. Reports feed a moderation queue. The community self-polices surprisingly well when the reporting mechanism is visible and responsive.

What We'd Do Differently

Build the API-first sooner. We had a tightly coupled frontend/backend for years. Decoupling enabled mobile and new features much faster.
Analytics from day one. We flew blind for too long. We didn't know which game modes had best retention until we measured properly.
Invest in moderation tools earlier. A toxic player can ruin tables for dozens of others. The social experience is the moat — protect it.
Document the game rules publicly. We eventually built comprehensive rules pages (like our buraco rules) — this drives SEO and reduces support tickets.

The Long Game

Building a platform for traditional games means your players are loyal but not forgiving of regression. They've been playing Buraco for 40 years. They know when your implementation is wrong.

That authenticity constraint is a feature, not a bug. It keeps us honest. It means every rules change is scrutinized. And it means the 3 million players who trust us have a very high bar for alternatives.

If you're building in a cultural niche — lean into it. The niche is the moat.

About: Jogos do Rei (jogosdorei.com.br) is Brazil's largest online card games platform, running since 2010.

Tags: brazil gaming multiplayer cardgames webdev startup realtime matchmaking