# Mais 15 ideias de projetos com Zig e Lua

Pesquisa e propostas para Pablo Murad • 19 de setembro de 2026

Um segundo caderno de ideias: ferramentas para usar, programas para aprender e experiências que podem virar projetos públicos.

## O critério desta seleção

Procurei projetos reais que demonstram uma ideia interessante e usei essa ideia como ponto de partida para propor outros sistemas. Os links levam às páginas dos próprios projetos ou à documentação de quem os utiliza e desenvolve. Cada seção distingue a inspiração existente da proposta que construiríamos.

As referências não são necessariamente escritas em Zig e Lua. Algumas já usam Lua; outras mostram uma interação ou uma arquitetura que podemos estudar. Os nomes das nossas propostas são provisórios e não foram pesquisados como marcas.

Para cada projeto, explico a experiência de uso, o trabalho de cada linguagem e uma primeira versão pequena. A dificuldade é uma avaliação minha do escopo descrito, não uma previsão de prazo. Nenhuma proposta depende de IA generativa para funcionar.

## Mapa das ideias

| Nº | Nome provisório | O que seria | Dificuldade inicial |
| --- | --- | --- | --- |
| 1 | Microcosmo | Um computador imaginário com pequenos aplicativos | Alta |
| 2 | Gazeta | Um jornal pessoal montado a partir de feeds | Baixa a média |
| 3 | Câmara | Um laboratório de receitas fotográficas | Média |
| 4 | Cineclube | Um organizador e condutor de sessões de cinema | Baixa a média |
| 5 | Paisagem | Um instrumento para criar ambientes sonoros | Média |
| 6 | Escrivaninha | Um editor de textos moldado ao seu jeito de escrever | Alta |
| 7 | Farol | Um navegador para explorar a internet de texto | Média |
| 8 | Cartógrafo | Um buscador de um conjunto escolhido de sites | Média |
| 9 | Ensaio | Um servidor que simula APIs e suas falhas | Baixa a média |
| 10 | Laboratório IDEA | Simulações interativas para ensinar conceitos | Média |
| 11 | Folheto | Uma oficina de pequenos livros e fanzines | Média |
| 12 | Maestro | Uma central de comandos pessoais pelo teclado | Baixa a média |
| 13 | Rastros | Um diário local do trabalho feito no computador | Baixa a média |
| 14 | Azulejo | Um mural coletivo de pixel art | Média |
| 15 | Mesa | Um motor de jogos de tabuleiro definidos por scripts | Média |

## 1. Microcosmo: um computador imaginário feito por você

### O que ele faria

Você abriria um programa e encontraria um pequeno ambiente de trabalho: janelas, ícones, uma calculadora, um bloco de notas e alguns brinquedos digitais. Tudo teria uma identidade visual própria, com limitações deliberadas de resolução, cores e recursos.

Seria um aplicativo que representa um computador fictício. Cada pequeno programa seria um pacote com código Lua e seus recursos. A proposta é permitir que você invente esse universo e crie aplicativos para ele, começando por tarefas bem pequenas.

### Um exemplo de uso

Você inicia o Microcosmo e abre um caderno. Ao lado, coloca um relógio desenhado por você e um aplicativo que sorteia exercícios de programação. Mais tarde, escreve um novo arquivo Lua e acrescenta um jogo de cartas ao ambiente. Outra pessoa pode receber esse pacote e abri-lo na instalação dela.

### A inspiração real

O [Picotron](https://www.lexaloffle.com/picotron.php) se apresenta como uma estação de trabalho para hardware imaginário, com aplicativos Lua distribuídos em cartuchos. A referência interessante é essa combinação de ambiente criativo, identidade visual e programas pequenos.

### Zig e Lua

Zig cuidaria da janela principal, dos eventos de teclado e mouse, do desenho e do acesso controlado aos arquivos. Lua definiria os aplicativos, seus estados e suas reações aos comandos. A biblioteca gráfica seria escolhida durante a implementação.

### O primeiro resultado

Uma área de trabalho com um aplicativo aberto por vez, mais um relógio e um bloco de notas. Multitarefa, editor embutido e distribuição de pacotes ficariam para depois.

É a proposta mais ambiciosa desta lista. Uma aparência retrô não torna simples o gerenciamento de foco, texto, janelas e execução de scripts. Vale escolhê-la se o próprio ato de construir o ambiente for parte da diversão.

## 2. Gazeta: seu jornal pessoal, com começo e fim

### O que ele faria

Reuniria atualizações dos sites que você acompanha e montaria uma edição de leitura. Você escolheria os assuntos, a quantidade de itens e a frequência de atualização. Uma edição poderia ter cinco textos sobre programação, duas publicações de blogs pessoais e uma seção de fotografia.

A característica principal seria ter uma edição finita, que você consegue terminar de ler. O programa manteria a origem de cada publicação, indicaria o que já foi lido e permitiria guardar algo para depois.

### Um exemplo de uso

Você abre a Gazeta pela manhã e recebe uma página com as novidades dos feeds cadastrados. Uma regra limita quantos itens do mesmo domínio aparecem. Outra coloca os blogs favoritos no início. O aplicativo explica a seleção: “incluído porque este site está na sua lista de favoritos”.

### A inspiração real

O [Newsboat](https://newsboat.org/) é um leitor de feeds RSS e Atom para o terminal. A nossa proposta aproveitaria a leitura por assinaturas e acrescentaria regras pessoais para montar edições.

### Zig e Lua

Zig faria as consultas, o armazenamento local e a identificação de itens repetidos. Lua controlaria filtros, seções, ordenação e limites por edição. RSS e Atom seriam tratados com bibliotecas apropriadas para XML.

### O primeiro resultado

Uma lista de feeds, atualização manual, títulos e links divididos por assunto. O conteúdo completo só estaria disponível quando fornecido pelo feed; abrir o artigo no navegador continuaria sendo uma opção.

Depois caberiam busca, edições arquivadas e uma saída HTML para ler no tablet. É uma boa escolha para começar: o resultado é fácil de observar, e a parte Lua tem uma função clara desde cedo.

## 3. Câmara: receitas fotográficas que você consegue entender

### O que ele faria

Aplicaria uma sequência de operações a fotografias e mostraria o resultado ao lado do original. Você criaria receitas próprias: preto e branco com determinada curva, cores mais frias, granulação, margens ou preparação para publicação.

Cada receita teria parâmetros legíveis e uma ordem explícita de operações. Poderia ser salva, comparada e aplicada a várias imagens, sempre exportando cópias.

### Um exemplo de uso

Você escolhe uma fotografia de rua e compara três receitas. Uma preserva mais detalhes nas sombras; outra aumenta o contraste; a terceira acrescenta uma borda com data e legenda. Ao selecionar a preferida, exporta uma versão para o blog e outra em tamanho maior.

### A inspiração real

O [darktable](https://www.darktable.org/about/) trabalha com edição não destrutiva e organização do fluxo fotográfico. Seu [manual de scripts Lua](https://docs.darktable.org/lua/stable/lua.scripts.manual/) também mostra como scripts podem ampliar tarefas do programa. A inspiração é tornar o processo repetível e personalizável.

### Zig e Lua

Zig integraria as bibliotecas de imagem, executaria as operações sobre os pixels e gerenciaria a exportação. Lua descreveria as receitas e seus parâmetros. O script pediria uma operação ao núcleo; não precisaria percorrer cada pixel por conta própria.

### O primeiro resultado

JPEG e PNG, prévia lado a lado e poucas operações bem implementadas. RAW, gestão de cor mais completa e grandes lotes seriam etapas posteriores.

Eu não prometeria reproduzir exatamente uma simulação de filme da Fujifilm. O objetivo inicial seria criar sua própria estética e registrar como ela foi obtida. A dificuldade está em fazer as imagens continuarem bonitas e previsíveis fora da prévia do aplicativo.

## 4. Cineclube: a sessão de cinema como um pequeno ritual

### O que ele faria

Organizaria uma sessão completa: apresentação, curta, intervalo e longa. Você escolheria os arquivos, acrescentaria notas e deixaria o programa conduzir a sequência no computador ligado à televisão ou ao projetor.

Também poderia haver uma ficha da sessão, com o motivo da escolha e comentários para ler depois. A ênfase seria a curadoria e a experiência de assistir.

### Um exemplo de uso

Você prepara uma noite de cinema expressionista. O sistema apresenta o título da sessão, exibe um texto introdutório e inicia os vídeos na ordem definida. No final, abre um espaço para registrar uma impressão sobre o filme.

Uma regra Lua poderia inserir intervalo apenas entre obras longas ou escolher uma vinheta diferente para cada coleção.

### A inspiração real

O [mpv](https://mpv.io/manual/stable/#lua-scripting) permite extensões Lua e oferece [controle por programas externos via JSON IPC](https://mpv.io/manual/stable/#json-ipc). Isso permite pensar em um condutor de sessões usando um reprodutor já existente.

### Zig e Lua

Zig organizaria os arquivos, manteria o estado da sessão e enviaria comandos ao mpv. Lua definiria a sequência, os intervalos e os comportamentos opcionais. A decodificação do vídeo continuaria com o reprodutor.

### O primeiro resultado

Uma sessão local com lista de arquivos, apresentação textual e controle de avanço. A comunicação com o reprodutor ficaria restrita à máquina local.

Sincronização entre casas e transmissão ao vivo mudariam bastante o escopo. O primeiro programa já seria útil sem esses recursos e teria bastante espaço para uma identidade visual de cineclube.

## 5. Paisagem: um instrumento de ambientes sonoros

### O que ele faria

Misturaria camadas de áudio conforme regras: chuva, vento, passos, ruído de fita, notas de piano ou sons gravados por você. As camadas poderiam entrar e sair lentamente, criando um ambiente que muda ao longo do tempo.

Você criaria cenas como “biblioteca durante a chuva”, “estação vazia” ou “cidade vista de uma janela”. Cada cena teria sua própria combinação de sons e probabilidades.

### Um exemplo de uso

Você carrega três gravações de chuva e alguns sons distantes. O programa alterna as gravações, varia o volume dentro de limites definidos e ocasionalmente acrescenta um som de trovão. Um controle permite tornar o ambiente mais calmo ou mais intenso.

### A inspiração real

O [norns, da monome](https://monome.org/docs/norns/), é um computador de som que executa instrumentos e comportamentos programáveis. Ele usa Lua para controle e mecanismos de áudio em SuperCollider. A separação entre controle e processamento de som é a referência para nossa proposta.

### Zig e Lua

Zig integraria a saída de áudio e cuidaria da mistura e das transições. Lua escolheria as cenas, os eventos e os parâmetros. A execução de scripts ficaria fora da rotina crítica que precisa entregar áudio continuamente, evitando que uma pausa no script interrompa a reprodução.

### O primeiro resultado

Três camadas de arquivos locais, volume individual, repetição e transições suaves. Síntese sonora, efeitos complexos e controles MIDI poderiam vir depois.

O maior desafio é evitar cortes audíveis e atrasos. Para aprender, começar com reprodução e mistura de gravações é mais viável do que inventar um sintetizador completo.

## 6. Escrivaninha: um editor voltado à sua escrita

### O que ele faria

Seria um editor de texto e Markdown com funções escolhidas para seu processo: navegar pelos títulos, consultar notas laterais, inserir referências e acompanhar versões locais do texto.

Você poderia escrever pequenos comandos Lua para tarefas recorrentes. Um comando reuniria as referências usadas; outro mostraria parágrafos com uma palavra repetida; outro prepararia uma cópia do texto para publicação.

### Um exemplo de uso

Você abre um artigo sobre cinema. À esquerda, vê a estrutura do texto; à direita, um caderno de observações. Um atalho leva à próxima ocorrência de uma expressão que você quer revisar. Ao terminar, exporta o arquivo mantendo o Markdown comum, fácil de abrir em outros programas.

### A inspiração real

O [Lite XL](https://lite-xl.com/) é um editor escrito em C e Lua, com grande parte do comportamento personalizável em Lua. Ele demonstra o quanto a extensibilidade pode fazer parte do próprio desenho de um editor.

### Zig e Lua

Zig cuidaria do armazenamento do texto em memória, dos arquivos e da integração com a interface. Lua definiria comandos, atalhos, painéis e transformações solicitadas pelo usuário.

### O primeiro resultado

Abrir, editar, salvar, desfazer e pesquisar em um arquivo, com um comando Lua personalizado. Esses fundamentos já exigem cuidado com acentos, seleção e recuperação após falhas.

É um projeto difícil. Se o objetivo for ter logo um editor personalizado para usar, estender o Lite XL pode ser a escolha mais sensata. Construir um núcleo em Zig vale principalmente se você quiser aprender como um editor funciona.

## 7. Farol: um navegador para passear pela internet de texto

### O que ele faria

Permitiria visitar espaços Gemini e, numa etapa posterior, Gopher. São ambientes que favorecem páginas de texto e links, adequados a uma navegação mais simples. O aplicativo teria favoritos, histórico e um caderno de viagem separado do conteúdo visitado.

Você poderia personalizar atalhos, aparência e ações ao salvar uma descoberta. O foco seria explorar páginas pessoais e registrar caminhos interessantes.

### Um exemplo de uso

Você abre uma cápsula Gemini, segue uma recomendação e encontra um diário de alguém. Marca a página e acrescenta uma observação. Um comando reúne as descobertas da sessão em um arquivo Markdown com títulos e endereços.

### A inspiração real

O [Lagrange](https://gmi.skyjake.fi/lagrange/) é um cliente Gemini com tipografia, favoritos, histórico e outras conveniências de navegação. Ele mostra que uma experiência de texto pode receber um tratamento visual cuidadoso.

### Zig e Lua

Zig cuidaria do protocolo, das conexões e da interpretação dos documentos. Lua definiria ações do usuário, temas e exportação das anotações. As páginas recebidas seriam conteúdo; não teriam permissão para executar Lua dentro do aplicativo.

### O primeiro resultado

Um cliente Gemini de terminal que abre páginas, segue links e mantém favoritos, com tratamento correto de TLS e certificados. Gopher e uma interface gráfica viriam depois.

O Farol não abriria qualquer site moderno como um navegador convencional. Sua função seria oferecer uma boa experiência dentro desses protocolos. É uma escolha interessante se a vontade for construir um navegador de escopo controlado.

## 8. Cartógrafo: seu próprio buscador de um pedaço da web

### O que ele faria

O programa visitaria apenas os sites de uma lista escolhida por você. Extrairia títulos, texto e links, formando um índice pesquisável. Assim, seria possível procurar um assunto dentro de uma comunidade de sites pessoais, de um conjunto de documentações ou dos seus próprios domínios.

Uma segunda área apresentaria links descobertos para revisão. Você decidiria quais novos sites entram no conjunto pesquisável.

### Um exemplo de uso

Você cadastra trinta blogs sobre programação e web artesanal. Depois procura “software pequeno” e encontra os textos relevantes daquele grupo. Cada resultado mostra a origem e a data da coleta, para deixar claro quando a página foi consultada.

### A inspiração real

O [YaCy](https://yacy.net/) permite criar mecanismos próprios de busca e índices definidos pelo usuário. A proposta aqui aproveitaria essa autonomia em um recorte menor, sem começar pela parte distribuída.

### Zig e Lua

Zig faria a coleta, a extração e a atualização do índice. Lua definiria quais caminhos visitar, como classificar páginas e quais critérios usar para ordenar os resultados.

### O primeiro resultado

Dez sites, coleta manual, limite de páginas por domínio e busca textual. Usaríamos um mecanismo de indexação existente quando isso poupasse trabalho. A coleta respeitaria as regras dos sites e teria intervalos entre requisições.

Páginas que dependem de JavaScript ficariam fora da primeira versão. O desafio está na qualidade do conteúdo extraído e na atualização do índice, não em conseguir visitar o maior número possível de endereços.

## 9. Ensaio: APIs fictícias para testar sistemas de verdade

### O que ele faria

Funcionaria como um servidor local que imita respostas de outros serviços. Você definiria rotas e cenários: uma consulta bem-sucedida, um cadastro recusado, um serviço lento ou uma resposta incompleta.

Seu aplicativo apontaria para esse servidor durante o desenvolvimento. Você poderia testar comportamentos difíceis de provocar no serviço real, sem depender de sua disponibilidade.

### Um exemplo de uso

Você está construindo uma integração e quer verificar o que acontece quando o serviço externo demora cinco segundos e depois falha. Seleciona esse cenário no Ensaio e usa a aplicação normalmente. Em seguida, troca para o cenário de sucesso e repete o teste.

Também seria possível guardar uma sequência: a primeira consulta informa “processando”, e a segunda informa “concluído”.

### A inspiração real

O [WireMock](https://wiremock.org/) simula APIs, incluindo respostas dinâmicas, atrasos e falhas. A oportunidade para nosso projeto seria uma ferramenta menor, cujo comportamento pudesse ser descrito diretamente em Lua.

### Zig e Lua

Zig receberia as requisições HTTP, controlaria os limites e registraria o que aconteceu. Lua examinaria os dados recebidos e produziria a resposta. Cada cenário teria seu próprio estado, que poderia ser reiniciado para repetir um teste.

### O primeiro resultado

Rotas GET e POST, respostas JSON, atraso configurável e um registro das requisições. Começaria vinculado apenas ao endereço local da máquina. Reproduzir todos os detalhes de um provedor específico dependeria da documentação daquele provedor.

Esta é uma das melhores opções para aprender as duas linguagens juntas. Você vê imediatamente o efeito de uma mudança no script e ganha uma ferramenta para seus outros projetos.

## 10. Laboratório IDEA: aprender mudando as condições de uma simulação

### O que ele faria

Apresentaria pequenos cenários interativos em que o aluno muda parâmetros e observa consequências. Um exemplo seria uma fila de atendimento: alterar a quantidade de atendentes, a velocidade de chegada e o tempo de serviço muda o tamanho da fila e a espera média.

Outras simulações poderiam tratar de estoque, logística, redes de computadores ou sequenciamento de tarefas. Cada cenário teria uma explicação, controles e perguntas para orientar a observação.

### Um exemplo de uso

Em uma aula de gestão, o aluno experimenta uma central de atendimento com dois funcionários. A fila cresce. Ele acrescenta um terceiro e compara o resultado. Depois percebe que aumentar a equipe pouco ajuda quando outra etapa continua limitada.

O professor poderia alterar as regras sem reescrever a interface. Os resultados seriam apresentados como consequências do modelo e das premissas escolhidas, não como previsões prontas para uma operação real.

### A inspiração real

O [NetLogo](https://docs.netlogo.org/) é um ambiente programável para simular fenômenos naturais e sociais. A ideia que interessa aqui é explorar um sistema mudando regras e observando seus efeitos.

### Zig e Lua

Zig manteria o relógio da simulação, os eventos e as medições. Lua definiria as regras de cada cenário: quando alguém chega, quanto uma tarefa demora e o que acontece quando um recurso fica ocupado.

### O primeiro resultado

Uma simulação local de fila, com três controles, visualização simples e comparação entre execuções usando a mesma semente aleatória. Essa semente permite repetir a sequência de sorteios, facilitando a comparação.

Para usar dentro do Portal IDEA, seria necessário planejar a interface web e a execução do modelo. Zig e Lua não chegam automaticamente ao navegador: poderíamos servir a simulação por um backend ou estudar uma versão WebAssembly. Essa decisão viria depois de validar a primeira aula.

## 11. Folheto: uma oficina de fanzines e pequenos livros

### O que ele faria

Transformaria uma seleção de textos e fotografias em uma publicação paginada. Você escolheria um modelo, ordenaria o material e geraria um documento para ler ou imprimir.

Os modelos poderiam incluir ensaio fotográfico, caderno de leituras, diário de viagem ou pequena apostila. O cuidado estaria no ritmo das páginas: onde entra uma imagem grande, onde a legenda aparece e como um novo texto começa.

### Um exemplo de uso

Você seleciona doze fotografias e escreve uma introdução curta. O sistema prepara uma capa, distribui as imagens e mostra uma prévia. Você troca duas posições, escolhe a versão em preto e branco e exporta o fanzine.

### A inspiração real

O [Paged.js](https://pagedjs.org/) transforma documentos HTML em PDFs preparados para impressão. Ele mostra uma rota possível para aproveitar HTML e CSS na composição de páginas.

### Zig e Lua

Zig organizaria os arquivos e a construção da publicação. Lua definiria os modelos e as decisões editoriais: como selecionar fotos, quando começar uma seção e qual composição usar. Uma opção viável seria gerar HTML e usar um renderizador existente para a paginação final.

### O primeiro resultado

Um modelo de ensaio fotográfico e um de texto, com capa, legendas, numeração e prévia. A exportação para impressão teria verificação visual das páginas. A ordem especial de folhas para dobrar um livreto seria um recurso posterior.

A tipografia e a paginação são o trabalho principal. Se usarmos Paged.js ou outro renderizador externo, ele será uma dependência real do sistema; não faz sentido prometer um executável autossuficiente antes de escolher essa arquitetura.

## 12. Maestro: comandos pessoais que acompanham seu trabalho

### O que ele faria

Ofereceria uma caixa de comandos acessível pelo teclado. Você digitaria algo como “abrir projeto”, “conectar servidor” ou “iniciar sessão de escrita”, e o programa executaria uma sequência previamente cadastrada.

As ações poderiam abrir pastas, iniciar programas, preparar um terminal ou gerar um arquivo a partir de um modelo. Cada comando teria descrição e parâmetros visíveis.

### Um exemplo de uso

Você escolhe um projeto e o Maestro abre sua pasta no editor e inicia um terminal no diretório correto. Em outro comando, seleciona uma máquina de uma lista e abre a conexão SSH usando sua configuração existente.

Lua permitiria compor essas ações: o comando “escrever artigo” criaria o arquivo com título e data, abriria o editor e registraria onde ele foi salvo.

### A inspiração real

O [Hammerspoon](https://www.hammerspoon.org/) conecta Lua às funcionalidades do macOS para criar automações. A referência é essa ponte entre scripts e ações do sistema. O projeto original é voltado ao macOS, não é uma solução pronta para Linux ou Windows.

### Zig e Lua

Zig integraria os recursos disponíveis no sistema escolhido. Lua definiria o catálogo e a composição dos comandos. Os argumentos seriam enviados aos programas como dados, com cuidado para não transformar nomes de arquivos em comandos de shell.

### O primeiro resultado

Uma paleta dentro do terminal, com cinco ações e seleção de projeto. Escolheria um sistema operacional primeiro. Atalhos globais e controle de janelas exigiriam integrações específicas e ficariam para uma etapa posterior.

É uma proposta útil, mas vale manter o catálogo pequeno. A simplicidade desaparece quando o programa tenta controlar toda aplicação e todo ambiente gráfico ao mesmo tempo.

## 13. Rastros: um diário local do que você fez

### O que ele faria

Organizaria pequenos registros de trabalho em uma linha do tempo: um período de escrita, uma sessão de programação, uma reunião anotada manualmente ou a conclusão de uma tarefa.

O objetivo seria recuperar o contexto: em que você estava trabalhando, o que avançou e por onde retomar. Você poderia acrescentar observações e corrigir a classificação dos registros.

### Um exemplo de uso

Ao terminar o dia, você abre o Rastros e vê que passou a manhã em um projeto e a tarde revisando um texto. Acrescenta “parei na integração do formulário” e marca a próxima ação. Na manhã seguinte, o diário mostra exatamente esse ponto de retomada.

### A inspiração real

O [ActivityWatch](https://activitywatch.net/) registra atividades no dispositivo e permite analisá-las por categorias. A proposta aqui daria mais espaço às anotações sobre o trabalho e às regras pessoais de agrupamento.

### Zig e Lua

Zig armazenaria os eventos e, quando habilitado, receberia dados de integrações locais. Lua agruparia sessões, classificaria atividades e montaria resumos determinísticos. Um resumo poderia dizer “duas sessões no projeto X”, com base nos registros, sem inventar uma interpretação.

### O primeiro resultado

Iniciar e encerrar sessões manualmente, anexar uma nota e consultar o histórico. Essa versão já permite testar o hábito. A coleta automática de aplicativos e janelas viria depois e dependeria do sistema operacional e das permissões disponíveis.

O programa seria pessoal, com exclusão de registros e pausa explícita. O valor estaria em lembrar do trabalho, sem criar mais uma obrigação de preencher relatórios longos.

## 14. Azulejo: um mural coletivo que muda com os visitantes

### O que ele faria

Manteria uma tela compartilhada onde cada participante pinta pequenos blocos de cor. O resultado poderia aparecer em um site, em uma janela local ou em um monitor na parede.

Você definiria as regras da edição: tamanho da tela, paleta, frequência de contribuições e duração. Uma edição poderia virar uma imagem arquivada ao final do dia; outra permaneceria em construção por semanas.

### Um exemplo de uso

Você convida amigos para desenhar um bairro imaginário. Uma pessoa começa uma casa, outra coloca árvores e alguém desenha um gato no telhado. Ao final, o sistema permite rever a sequência de contribuições.

### A inspiração real

O [Pixelflut, documentado pelo CCC Göttingen](https://wiki.cccgoe.de/wiki/Pixelflut), permite enviar alterações de pixels por rede para uma tela comum. A nossa proposta acrescentaria uma experiência voltada à colaboração, com regras de participação e histórico.

### Zig e Lua

Zig manteria a imagem, receberia as contribuições e distribuiria as atualizações. Lua definiria as regras de cada edição: cores permitidas, áreas disponíveis e intervalo entre contribuições. Os participantes enviariam operações de desenho; somente o administrador instalaria scripts.

### O primeiro resultado

Uma tela pequena, poucas cores e acesso para um grupo convidado. Uma página simples poderia funcionar como cliente, o que acrescentaria HTML e JavaScript à interface, enquanto Zig e Lua permaneceriam no servidor.

Antes de abrir ao público, entrariam identificação, limites por participante e meios de reverter intervenções. Essas funções fazem parte do produto porque uma tela coletiva também precisa lidar com conflitos entre desenhos.

## 15. Mesa: jogos de tabuleiro cujas regras cabem em scripts

### O que ele faria

Executaria pequenos jogos por turnos. O núcleo saberia representar jogadores, peças, cartas, movimentos e histórico. Os scripts definiriam quais jogadas são permitidas e como elas mudam a partida.

Você poderia criar jogos próprios, experimentar regras de um jogo de estratégia ou desenvolver atividades educativas com decisões e consequências. Cada jogo seria um pacote separado.

### Um exemplo de uso

Você inventa um jogo de organização de uma pequena oficina. Em cada rodada, o jogador escolhe qual tarefa executar e como distribuir recursos. Depois altera uma regra em Lua e compara como a partida muda.

Também poderia começar com um jogo de tabuleiro muito simples para aprender estados e turnos, antes de introduzir cartas, sorteios ou adversários automáticos.

### A inspiração real

O [boardgame.io](https://boardgame.io/) organiza jogos por turnos em torno de funções que alteram o estado da partida, com recursos de sincronização e histórico. A inspiração é separar as regras do jogo da infraestrutura que o executa.

### Zig e Lua

Zig gerenciaria o ciclo da partida, o armazenamento e a interface. Lua definiria a preparação, as jogadas válidas, os efeitos e a condição de término. O núcleo poderia registrar cada ação para reproduzir uma partida depois.

### O primeiro resultado

Um jogo local para duas pessoas no mesmo computador, com turnos, validação de movimentos e salvamento. O histórico mostraria por que uma jogada foi recusada. Partidas pela internet e informações secretas de cada jogador seriam problemas posteriores.

É uma boa opção para aprender a modelar regras. A dificuldade cresce mais por causa das regras e da interface escolhidas do que pela necessidade de gráficos sofisticados.

## Três exemplos do tipo de Lua que escreveríamos

Estes trechos são propostas de API, não código compatível com os projetos citados. As funções e os objetos teriam de ser implementados no nosso núcleo. Eles mostram o que significa deixar o comportamento editável em Lua.

### Uma regra para a Gazeta

```lua
edicao {
    nome = "Leituras da manhã",
    limite_total = 12,
    limite_por_site = 2,

    incluir = function(item)
        return not item.lido and item.categoria ~= "promoções"
    end,

    prioridade = function(item)
        if item.site_favorito then
            return 10
        end
        return 1
    end
}
```

O núcleo consultaria as funções para decidir quais publicações entram e em que ordem. As funções não precisariam conhecer HTTP, XML ou o banco de dados.

### Uma falha reproduzível para o Ensaio

```lua
rota {
    metodo = "GET",
    caminho = "/pedidos/123",

    responder = function(requisicao)
        return {
            atraso_ms = 1500,
            status = 503,
            json = { erro = "serviço temporariamente indisponível" }
        }
    end
}
```

O script descreve a resposta. O servidor Zig faria o agendamento do atraso e a serialização do JSON, sem precisar paralisar as demais requisições.

### Uma receita para a Câmara

```lua
receita {
    nome = "Rua em preto e branco",

    etapas = {
        { operacao = "monocromatico" },
        { operacao = "contraste", intensidade = 0.15 },
        { operacao = "granulacao", intensidade = 0.08 },
        { operacao = "borda", pixels = 24, cor = "#ffffff" }
    }
}
```

Cada operação seria implementada e documentada pelo núcleo. As escalas numéricas acima são ilustrativas; seu significado teria de ser definido de forma consistente na aplicação.

## Minhas escolhas para você

| Se a vontade principal for... | Eu escolheria | Por quê |
| --- | --- | --- |
| Aprender Zig e Lua com um começo controlado | Ensaio | A relação entre entrada, script e resposta fica muito clara |
| Criar algo para usar quase todo dia | Gazeta | É fácil começar pequeno e ajustar as regras ao seu gosto |
| Unir programação e fotografia | Câmara | As receitas permitem experimentar e comparar resultados concretos |
| Fazer um projeto com identidade cultural | Cineclube | A curadoria e a apresentação dão personalidade ao sistema |
| Explorar uma aplicação no Portal IDEA | Laboratório IDEA | Uma boa simulação pode ajudar a explicar conceitos difíceis |
| Criar algo mais excêntrico e autoral | Microcosmo | Você inventa tanto o ambiente quanto os programas que vivem nele |
| Convidar outras pessoas para participar | Azulejo | A interação é simples de entender e produz um resultado compartilhado |

Se eu fosse reduzir a três candidatos para discutir agora, escolheria **Câmara, Cineclube e Ensaio**. Câmara conversa com seu interesse por fotografia; Cineclube pode ganhar uma identidade muito sua; Ensaio tem um escopo inicial mais fácil de controlar e ajuda diretamente no desenvolvimento dos seus outros sistemas.

O Laboratório IDEA merece uma conversa própria se a intenção for aplicar o projeto à empresa. Antes de pensar no motor genérico, eu escolheria uma única aula em que mexer nos parâmetros realmente ajude o aluno a entender alguma coisa.

## Uma base técnica suficiente para começar

Para qualquer uma das propostas, o primeiro marco deveria ser pequeno: o programa carrega um script, entrega alguns dados e recebe um resultado útil. É nesse ponto que você aprende a fronteira entre as linguagens e descobre se a ideia tem graça na prática.

Uma estrutura inicial poderia ter `src/` para Zig, `scripts/` para Lua e `data/` para os dados locais. Um banco seria acrescentado quando a necessidade de consultas e persistência justificasse. Projetos de imagem, som e paginação usariam bibliotecas ou programas existentes nas partes especializadas.

Também convém distinguir configuração de programação. Se um arquivo só informa nome, cor e porta, um formato de dados pode resolver. Lua passa a valer a pena quando o usuário precisa expressar decisões, filtros, acontecimentos ou sequências de ações.

Escolher duas linguagens aumenta o trabalho de integração. Por isso, eu manteria poucas funções expostas ao Lua, mensagens de erro compreensíveis e scripts instalados pelo próprio usuário nas primeiras versões. Compatibilidade entre sistemas, recarga sem reiniciar e execução de código de terceiros exigem decisões adicionais; nenhum desses recursos aparece automaticamente ao embutir Lua.

## Referências consultadas

As descrições factuais das inspirações foram verificadas nas páginas abaixo. As propostas, nomes, recortes de primeira versão e avaliações de dificuldade são elaboração deste documento.

| Referência | O que inspirou |
| --- | --- |
| [Picotron](https://www.lexaloffle.com/picotron.php) | Ambiente criativo e aplicativos distribuídos como cartuchos |
| [Newsboat](https://newsboat.org/) | Leitura de feeds no terminal |
| [darktable](https://www.darktable.org/about/) e [scripts Lua](https://docs.darktable.org/lua/stable/lua.scripts.manual/) | Fluxo fotográfico e automação por scripts |
| [mpv: Lua](https://mpv.io/manual/stable/#lua-scripting) e [JSON IPC](https://mpv.io/manual/stable/#json-ipc) | Controle de reprodução e extensão de comportamento |
| [monome norns](https://monome.org/docs/norns/) | Instrumentos e controle programável de áudio |
| [Lite XL](https://lite-xl.com/) | Editor extensível por Lua |
| [Lagrange](https://gmi.skyjake.fi/lagrange/) | Navegação em Gemini e cuidado com a leitura |
| [YaCy](https://yacy.net/) | Busca em um índice escolhido pelo usuário |
| [WireMock](https://wiremock.org/) | Simulação de respostas, atrasos e falhas de APIs |
| [NetLogo](https://docs.netlogo.org/) | Modelos programáveis para explorar fenômenos |
| [Paged.js](https://pagedjs.org/) | Paginação de publicações a partir de HTML |
| [Hammerspoon](https://www.hammerspoon.org/) | Ponte entre Lua e ações do sistema operacional |
| [ActivityWatch](https://activitywatch.net/) | Registro local e classificação de atividades |
| [Pixelflut no CCC Göttingen](https://wiki.cccgoe.de/wiki/Pixelflut) | Tela compartilhada que recebe pixels pela rede |
| [boardgame.io](https://boardgame.io/) | Separação entre regras, estado e infraestrutura de jogos |