DEV Community: Ace Jogos do Rei

Mobile-First for 60+ Year Olds — What We Learned Building for Senior Gamers

Ace Jogos do Rei — Wed, 01 Jul 2026 13:09:15 +0000

Most "mobile-first" advice is written for an imaginary user: a 28-year-old with perfect eyesight, a flagship phone, fast fingers, and a fiber connection. That user does not represent the audience for the platform I work on. A large share of the people playing card games like Buraco, Canastra, and Tranca on Jogos do Rei are 60 years and older. The platform has been around since 2010 and has grown to 3M+ registered players, and a meaningful chunk of that base did not grow up with touchscreens.

Building for that audience forces you to unlearn a lot of habits. Here are the constraints we kept running into and the tradeoffs we made.

Touch targets are not a "nice to have"

The WCAG guidance of a 44×44px minimum touch target is treated as a floor by most teams and quietly ignored in dense UIs. For older users it's closer to a hard requirement, and honestly 44px is on the small side. Reduced fine-motor precision and, in some cases, mild tremor mean that a mistap isn't a minor annoyance — it's a wrong card played in a live match, which feels catastrophic to the player.

Concrete things that helped:

Generous hit areas that extend beyond the visible control. The tappable region can be larger than what the eye sees, and that padding absorbs imprecise taps.
Spacing between interactive elements so adjacent taps don't fire the wrong action. In a hand of cards this is the hard part — cards naturally overlap. We lean on fanning out the active card and enlarging the one under the finger rather than cramming more cards into the same width.
No destructive action one tap away from a common action. "Leave table" next to "Play card" is a trap. Confirmation dialogs are annoying for power users but they save older players from actions they didn't intend.

Font size, contrast, and the zoom problem

Older eyes need larger type and higher contrast, and this is where a lot of well-meaning responsive design breaks.

The first instinct is to bump base font sizes. Good. But the second-order effect is that many senior users also set their OS or browser zoom to 150–200% on top of your already-large type. If your layout assumes a fixed viewport and uses absolute positioning or overflow: hidden to look tidy, that zoom shatters it — buttons disappear off-screen, text clips, modals become unusable.

Lessons:

Design so the layout survives 200% zoom. Use relative units (rem/em), let containers grow, and test with the browser zoomed rather than only with responsive dev-tools breakpoints.
Don't ship contrast that only passes on your calibrated monitor. Older displays, glare, and age-related contrast sensitivity loss all eat into your margin. We aim comfortably past the WCAG AA 4.5:1 ratio for body text rather than sitting right on it.
Avoid thin/light font weights for anything the user must read. They look elegant and they're hard to read.

The connection you don't have

The "mobile-first" persona assumes a fast, stable connection. A big portion of real traffic is on older Android devices over spotty mobile networks, sometimes on a phone that's four or five years old with limited RAM. That reframes a lot of decisions:

Ship less JavaScript. A heavy SPA that's snappy on a MacBook can jank badly on a budget Android from 2019. Every KB of parse/execute time is felt. We're aggressive about not pulling in a framework where plain HTML, CSS, and a bit of vanilla JS will do — the same philosophy behind our public card-game glossary, which is static HTML precisely so it loads instantly on weak devices.
Assume reconnection is normal, not exceptional. In a real-time card game the network will drop mid-match. The interesting UX work isn't preventing disconnects (you can't) — it's making reconnection graceful so the player rejoins the table where they left off instead of being kicked and losing the game. For an older player, being dropped from a game they were winning is the kind of frustration that makes them churn.
Optimistic UI has to be handled carefully. Showing an action as "done" before the server confirms feels fast, but if it later has to roll back, a confused senior player reads it as a bug or as cheating. We prefer honest, immediate feedback ("sending…") over an optimistic state that might reverse.

Copy and iconography

A pattern we've had to correct repeatedly: designers love icon-only buttons. A gear, a hamburger, three dots. For a 30-year-old these are learned universal symbols. For a 65-year-old who came to the internet later, many of them are not obvious at all.

Pair icons with text labels wherever space allows. "☰ Menu" beats "☰".
Prefer plain, literal wording over clever product-speak. "Sair da mesa" (Leave table), not "Encerrar sessão".
Be careful with gestures. Swipe-to-do-X and long-press menus are effectively invisible to users who don't know to try them. Anything important needs a visible, tappable path.

Where "mobile-first" and "senior-first" actually conflict

It's worth being honest: these two goals pull against each other sometimes.

Mobile-first pushes you toward compact, gesture-driven, minimal-chrome interfaces. Senior-first pushes toward larger elements, explicit labels, visible controls, and confirmations. You cannot fully satisfy both on a small screen.

Our resolution is that the desktop experience remains a first-class citizen rather than an afterthought — a genuinely large share of our older players are on desktop, where screen real estate lets us give elements the size and spacing they need without cramming. That runs against the industry reflex to treat desktop as a scaled-up phone. For this audience, "mobile-first" is a technique for performance and resilience on weak devices, not a mandate to shove everything into a 360px column.

What I'd tell another team

Test with actual older users, not a simulator. Watching a 70-year-old try to play one hand teaches you more than a dozen accessibility lint passes. You'll see the mistaps, the squinting, the abandoned gestures.
Treat undo/confirm as core UX, not friction. For this audience, reversibility beats speed.
Budget for the low end. Performance is accessibility. A slow, janky page excludes older users on old hardware just as surely as poor contrast does.
Don't hide function behind cleverness. Visible, labeled, generously-sized, and forgiving beats sleek every time.

None of this is exotic — it's mostly WCAG fundamentals plus taking your real audience seriously instead of the imaginary median user. But the discipline of building for people who are 60+ and on modest hardware has a nice side effect: it makes the product better for everyone. Larger targets, clearer copy, faster loads, and graceful reconnection are things a 28-year-old on a flagship phone appreciates too — they just won't churn if you get them wrong.

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