Obrigado a Giorgio Cappello Di Paglia por utilizar uma configuração de jogos retro com uma ZimaBoard 2 para explorar uma questão mais interessante do que apenas as taxas de fotogramas: conseguiriam os jogadores habituados à orientação moderna compreender e desfrutar de um jogo concebido como se fosse de 1997?
Os jogos lançados no final da década de 1990 não seguiam todos as mesmas regras de design, mas muitos esperavam que o jogador prestasse mais atenção, experimentasse, lesse manuais, memorizasse percursos, gerisse pontos de gravação e aceitasse o fracasso como parte da aprendizagem.
Os jogos modernos proporcionam frequentemente uma experiência diferente. Marcadores de objectivos, minimapas, pontos de controlo, sugestões contextuais, gravações automáticas, opções de dificuldade e definições de acessibilidade reduzem a probabilidade de um jogador ficar permanentemente bloqueado.
A experiência de Giorgio não defende que todos os jogos antigos eram melhores ou que a assistência moderna torna os jogos piores. Analisa a forma como a relação entre o jogador e o jogo mudou — e se as antigas premissas de design ainda parecem naturais hoje.
Vê antes de ler: O vídeo original em italiano desenvolve a comparação entre o design de jogos de 1997 e o moderno antes de mostrar a ZimaBoard 2 a executar uma biblioteca de jogos retro no Batocera numa televisão.
Divulgação: Giorgio identifica o vídeo como uma colaboração com a Zima e a IceWhale. A descrição também contém um link de afiliado através do qual poderá receber uma comissão. Este artigo reorganiza as ideias e a demonstração de hardware apresentadas no seu vídeo original, mantendo visível a relação comercial.
Esta é sobretudo uma discussão sobre design de jogos e uma demonstração prática do Batocera. Não é um teste controlado de emuladores, uma base de dados de compatibilidade, nem uma promessa de que todas as consolas, jogos, controladores e definições gráficas funcionarão de forma idêntica.

Giorgio enquadra o projecto em torno das expectativas dos jogadores: as convenções modernas de interface mudaram a forma como abordamos os jogos mais antigos?
O que jogar um jogo em 1997 muitas vezes esperava de ti
O design de jogos em 1997 variava bastante consoante as plataformas e os géneros. As aventuras para PC, os jogos de interpretação de papéis para consolas, os jogos de tiros na primeira pessoa, os jogos de terror de sobrevivência, os jogos de corridas e os títulos de estratégia ensinavam os jogadores de formas diferentes.
No entanto, várias expectativas surgiam com mais frequência do que em muitos jogos convencionais actuais:
- Lê o manual impresso antes de jogar ou enquanto jogas
- Ouve atentamente os diálogos para obter indicações
- Memorizar pontos de referência em vez de seguir um marcador de rota permanente
- Desenhar um mapa ou anotar códigos, quebra-cabeças e objetivos
- Guardar manualmente ou chegar a um ponto de gravação designado
- Repetir secções depois de falhar
- Experimentar os controlos e os sistemas do jogo
- Aceitar que algumas informações permaneceriam por explicar
Um jogador podia não reparar numa frase, entrar na sala errada, utilizar um item importante demasiado cedo ou esquecer-se de guardar o jogo e perder um progresso significativo. O jogo podia fornecer informação suficiente para continuar, mas essa informação nem sempre era repetida ou permanecia permanentemente no ecrã.
Isto criou uma maior necessidade de observação e memória. Também gerou frustração desnecessária quando um design pouco claro, uma tradução deficiente, limitações técnicas ou documentação inadequada dificultavam a compreensão da solução pretendida.
Porque é que os jogos mais antigos forneciam frequentemente menos orientação
A diferença não era apenas filosófica. As limitações do hardware e do armazenamento moldavam aquilo que os programadores podiam incluir.
As consolas e os computadores mais antigos funcionavam com menos memória, processadores mais lentos, meios de armazenamento mais pequenos e resoluções de ecrã inferiores. Os programadores tinham menos espaço para tutoriais falados, demonstrações animadas, sistemas de dicas dinâmicos ou grandes coleções de elementos de interface.
Por isso, os manuais impressos continham informações que hoje apareceriam dentro do jogo. Um manual podia explicar os controlos, as capacidades das personagens, as regras do inventário, as histórias de fundo, os mapas e as estratégias básicas antes de o jogador chegar ao primeiro nível.
Os programadores também concebiam os jogos para um público familiarizado com tentativas repetidas. As tradições dos arcades, as vidas limitadas, as palavras-passe, a dificuldade elevada e a progressão baseada na pontuação continuavam a influenciar os jogos domésticos. Repetir uma secção fazia frequentemente parte da experiência esperada, em vez de ser uma prova de que o jogo não tinha conseguido orientar o jogador.
Os jogadores modernos aprenderam uma linguagem de interface diferente
Os jogadores não começam um jogo sem conhecimentos prévios. Anos de experiência criam expectativas sobre o funcionamento dos objetivos, mapas, saúde, inventário, pontos de controlo e interações.
Um jogador moderno pode esperar razoavelmente:
- Um marcador de objetivo que aponta para o próximo local
- Um minimapa que mostra caminhos e atividades nas proximidades
- Objetos destacados que podem ser recolhidos ou ativados
- Uma indicação que mostra que botão executa uma ação
- Uma gravação automática antes de uma secção perigosa
- Um ponto de controlo depois de concluir um objetivo
- Um registo de missões que repete diálogos importantes
- Um sistema de dicas que reage quando o progresso fica bloqueado
Estas funcionalidades podem tornar os jogos complexos mais fáceis de aprender e reduzir a quantidade de conteúdo repetido. Também tornam os jogos acessíveis a jogadores com pouco tempo disponível, diferentes capacidades físicas, dificuldade em ler pequenos detalhes do ambiente ou problemas em memorizar informações apresentadas horas antes.
A desvantagem surge quando as orientações se tornam tão persistentes que o jogador já não precisa de estudar o ambiente, testar ideias ou decidir para onde ir. A interface pode começar a resolver o jogo antes de o jogador ter oportunidade de o fazer.
O ZimaBoard 2 torna-se a plataforma para a experiência
Giorgio utiliza ZimaBoard 2 Mini Home Server para trazer os jogos antigos para uma configuração moderna de sala de estar.
A arquitetura x86 da Intel permite-lhe executar sistemas operativos e software concebidos para PCs convencionais. A saída de vídeo direta liga-o a um televisor ou monitor, o USB suporta controladores compatíveis e o SATA oferece espaço para uma biblioteca de jogos local maior.
O mesmo hardware também inclui:
- Um processador Intel N150 com gráficos Intel integrados
- Memória LPDDR5 em diferentes configurações
- Armazenamento de sistema eMMC integrado
- Duas ligações SATA 3.0
- Duas interfaces de rede 2.5GbE
- Duas portas USB 3
- Saída de vídeo Mini DisplayPort
- Expansão PCIe 3.0 ×4
Estas interfaces significam que a placa não tem de permanecer uma consola retro dedicada. O sistema operativo ou o dispositivo de armazenamento podem ser alterados, e o mesmo sistema pode voltar a desempenhar funções de servidor doméstico após a experiência de jogo.
Os jogos retro são apenas uma das possíveis funções do ZimaBoard 2
Giorgio salienta que o Batocera representa um projeto, e não a única finalidade da placa. A combinação da compatibilidade com software x86, das interfaces de armazenamento, das redes e da expansão PCIe suporta uma gama mais ampla de configurações.

Giorgio apresenta os jogos retro como uma vertente de uma plataforma mais ampla, que também pode suportar armazenamento, multimédia, redes, desenvolvimento, Docker, cópias de segurança e sistemas operativos alternativos.
| Função potencial | Hardware relevante do ZimaBoard 2 | Requisito de planeamento |
|---|---|---|
| Consola de jogos retro | Processador x86, gráficos integrados, USB e saída de vídeo | Emuladores compatíveis, controladores, ficheiros BIOS e jogos obtidos legalmente |
| Servidor NAS e de armazenamento | SATA, duas portas 2.5GbE e expansão PCIe | Seleção de unidades, redundância, monitorização e cópias de segurança independentes |
| Servidor multimédia | Gráficos Intel, armazenamento local e redes multigigabit | Suporte de codecs, compatibilidade com clientes e necessidades de transcodificação |
| Servidor Docker | Compatibilidade x86, memória e conectividade de rede | Volumes, permissões, portas, atualizações e segurança das aplicações |
| Equipamento de rede | Duas portas 2.5GbE independentes | Regras de firewall, acesso de recuperação e manutenção planeada |
| Sistema de desenvolvimento | Suporte de sistemas operativos x86 e armazenamento expansível | Requisitos da cadeia de ferramentas, cópias de segurança e limites de carga de trabalho |
| Nó de cópia de segurança | Armazenamento SATA e acesso à rede local | Retenção, encriptação, testes de restauro e cópias externas |
Esta flexibilidade distingue o projeto de uma mini consola retro fixa. Uma consola dedicada desempenha bem uma função; um servidor x86 expansível pode ser reconfigurado à medida que os interesses e a infraestrutura do proprietário mudam.
O design de 1997 e o design moderno fazem perguntas diferentes
A comparação visual de Giorgio resume como mudou a relação entre o jogador e o jogo.

A comparação contrasta um jogador que interpreta o jogo com uma interface moderna que identifica continuamente objetivos, rotas, ações e progresso.
Um jogo ao estilo de 1997 pergunta frequentemente: «Compreendeste o que o mundo te transmitiu?» Um jogo moderno guiado é mais propenso a perguntar: «Consegues cumprir o próximo objetivo utilizando a informação apresentada?»
| Área de design | Abordagem comum em 1997 | Abordagem moderna comum |
|---|---|---|
| Navegação | Pontos de referência, diálogos, mapas impressos ou memória do jogador | Minimapas, rotas, bússolas e marcadores de objetivos |
| Gravação | Gravações manuais, palavras-passe ou pontos de gravação fixos | Pontos de controlo frequentes e gravações automáticas em segundo plano |
| Controlos | Manual impresso, experimentação ou breves instruções iniciais | Indicações contextuais e tutoriais interativos |
| Falha | Repetir uma parte significativa do nível | Recomeçar perto do encontro falhado |
| Objetivos | Recordar diálogos ou manter notas pessoais | Registo de missões persistente e lista de tarefas atualizada |
| Apoio à dificuldade | Definições limitadas e menos sistemas adaptativos | Opções de dificuldade, assistências e controlos de acessibilidade |
Nenhuma das colunas descreve todos os jogos da respetiva época. Alguns títulos mais antigos incluíam mapas e gravações generosas, enquanto alguns jogos modernos removem deliberadamente os marcadores de objetivos e exigem uma exploração cuidadosa. A comparação descreve convenções em mudança, não uma regra absoluta.
A assistência moderna não é automaticamente mau design
É fácil transformar esta discussão em nostalgia: os jogos mais antigos respeitavam os jogadores, enquanto os jogos modernos explicam demasiado. Essa conclusão ignora os benefícios genuínos do design atual.
As gravações automáticas protegem o progresso quando o trabalho, os estudos, as responsabilidades familiares ou problemas técnicos interrompem uma sessão. Os controlos remapeáveis e as definições de acessibilidade permitem que mais pessoas joguem. Os registos de missões são úteis quando alguém regressa após várias semanas. As dicas opcionais podem impedir que um puzzle pouco claro bloqueie o resto do jogo.
A questão mais útil é saber se a assistência apoia o jogador ou substitui as decisões do jogador.
Uma boa orientação pode ser apresentada por camadas:
- O ambiente fornece a primeira pista.
- O diálogo ou um diário preserva o contexto importante.
- Uma dica opcional aparece apenas depois de o jogador ter dificuldades.
- As definições de acessibilidade permitem ao utilizador escolher uma orientação visual mais forte.
- Os jogadores que quiserem mais exploração podem desativar os marcadores de objetivos.
Isto dá aos novos jogadores um ponto de entrada, permitindo simultaneamente que os jogadores experientes mantenham a incerteza, a descoberta e a resolução de problemas.
A Batocera transforma a placa numa consola retro para a sala de estar
Giorgio utiliza a Batocera, uma distribuição Linux de código aberto concebida em torno da emulação e de uma biblioteca de jogos otimizada para comandos.
Em vez de abrir um ambiente de trabalho e iniciar cada emulador manualmente, a Batocera apresenta as plataformas e os jogos compatíveis através de uma interface de televisão unificada. Depois de configurado, o sistema pode arrancar diretamente para a biblioteca e funcionar principalmente através de um comando de jogos.

A Batocera organiza vários sistemas retro e coleções de jogos numa interface concebida para utilização com televisão e comando.
Os utilizadores podem seguir o guia oficial de configuração do salão de jogos Batocera no ZimaBoard para conhecer o processo de instalação atual. A documentação de instalação da Batocera explica as imagens compatíveis, o armazenamento de destino, o primeiro arranque e os requisitos específicos de cada plataforma.
A responsabilidade pelos ficheiros de jogos e BIOS permanece com o utilizador
A Batocera não concede autorização para transferir jogos comerciais de fontes não autorizadas. O software de emulação, os ficheiros BIOS das consolas, as ROM de jogos, as imagens de discos, as ilustrações e os metadados multimédia estão sujeitos a diferentes condições de licenciamento e direitos de autor.
Os utilizadores só devem adicionar jogos e ficheiros de sistema que tenham legalmente o direito de utilizar. A disponibilidade num site de transferências aleatório não comprova que um ficheiro esteja licenciado para redistribuição.
O guia oficial da Batocera para jogos e BIOS explica onde colocar os ficheiros compatíveis, sem fornecer conteúdo comercial protegido por direitos de autor.
Que desempenho deve oferecer uma configuração para jogos retro?
Os jogos lançados por volta de 1997 costumam exigir pouco de um sistema Intel N150 atual, mas o desempenho da emulação não é determinado apenas pela idade original do jogo.
Cada plataforma requer um comportamento diferente do emulador. Os resultados podem variar com:
- A consola ou computador que está a ser emulado
- O emulador e o núcleo do emulador selecionados
- Resolução de renderização e escalonamento
- Shaders, filtros e melhorias visuais
- Latência dos comandos e do áudio
- Compatibilidade da BIOS e da região do jogo
- Os requisitos de precisão de cada título
- Serviços em segundo plano e condições térmicas
Os primeiros sistemas baseados em cartuchos e discos são, em geral, alvos mais realistas do que as consolas recentes. O facto de um jogo ser iniciado com sucesso não prova que toda a biblioteca da plataforma funcionará de forma idêntica.
Os testes relacionados aos limites de jogo do ZimaBoard 2 no Windows e Linux fornecem contexto adicional sobre os gráficos integrados Intel N150, sem desviar a atenção da experiência de Giorgio com o design de jogos retro.
Uma Configuração Simples para a Sala de Estar
A disposição física final é compacta. O ZimaBoard 2 fica junto à televisão, com os cabos de alimentação, Ethernet e vídeo ligados, enquanto o Batocera disponibiliza a biblioteca de jogos no ecrã.

O sistema concluído coloca o compacto ZimaBoard 2 junto à televisão, como uma consola Batocera compatível com comandos.
A ligação Ethernet pode suportar a gestão da biblioteca de jogos, a transferência de metadados, atualizações e transferências de ficheiros através da rede. O armazenamento ligado pode conter o sistema Batocera e os dados dos jogos, enquanto as portas USB ligam comandos compatíveis ou outros acessórios.
Uma instalação permanente deve deixar espaço livre à volta do dissipador de calor de alumínio. Deve também impedir que a tensão dos cabos puxe a placa ou o armazenamento ligado para fora da prateleira.
Ainda Conseguimos Jogar Como em 1997?
A pergunta de Giorgio é, em última análise, sobre hábitos adquiridos e não sobre capacidades perdidas. Os jogadores modernos ainda conseguem compreender jogos baseados na observação, na memória, na experimentação e na gravação manual. Podem simplesmente precisar de tempo para deixar de esperar que a interface forneça a instrução seguinte.
O primeiro ajuste consiste em aceitar a incerteza. Por vezes, não saber imediatamente para onde ir é o estado pretendido. Uma porta trancada pode ser informação, e não uma barreira. Uma conversa aparentemente insignificante pode conter o objetivo seguinte. Uma falha pode revelar como funciona um sistema.
O segundo ajuste consiste em mudar a forma como o progresso é registado:
- Tome breves notas quando uma personagem mencionar um local ou um objeto.
- Verifique se o jogo guarda manualmente, automaticamente ou apenas em pontos fixos.
- Aprenda a disposição dos controlos antes de entrar numa secção difícil.
- Observe pistas visuais e sonoras que se repetem.
- Use um manual quando este fazia parte da experiência original do jogo.
- Permita algum tempo para experimentar antes de procurar um guia.
A dificuldade nem sempre é mecânica. O verdadeiro desafio pode ser recuperar um tipo de atenção que as convenções modernas de interface raramente exigem.
Quem apreciaria este projeto com ZimaBoard 2?
- Os entusiastas de jogos retro podem centralizar vários sistemas numa única interface adequada para televisão.
- Os jogadores interessados no design de jogos podem comparar a forma como diferentes gerações comunicam regras e objetivos.
- As famílias podem apresentar jogos antigos sem manter várias consolas originais junto à televisão.
- Os colecionadores podem criar um sistema de acesso conveniente para bibliotecas pessoais de jogos preservadas legalmente.
- Os construtores de homelabs podem reutilizar o mesmo hardware em projetos de armazenamento, multimédia, Docker ou redes.
- Os programadores podem estudar como os tutoriais, os pontos de controlo, os mapas e o feedback afetam o comportamento dos jogadores.
Quem estiver interessado apenas nos jogos para PC modernos mais exigentes deverá escolher hardware concebido para o desempenho atual em jogos. Esta construção é mais valiosa como plataforma retro flexível e como forma de explorar a história dos videojogos.
O que a experiência de Giorgio demonstra
| Conclusão | O que o vídeo demonstra | O que não prova |
|---|---|---|
| Hábitos dos jogadores | Os sistemas modernos de orientação podem alterar aquilo que os jogadores esperam que um jogo explique. | Que nenhum jogador moderno é capaz de compreender jogos antigos. |
| Design de jogos de 1997 | Muitos jogos mais antigos atribuíam maior responsabilidade à observação, à memória e à experimentação. | Que todos os jogos lançados em 1997 não tinham mapas, tutoriais ou assistência para guardar o progresso. |
| Assistência moderna | Os marcadores de objetivos, as gravações automáticas e as indicações reduzem a fricção e a necessidade de repetir o progresso. | Que a assistência torna sempre um jogo menos envolvente. |
| Batocera | Uma interface unificada pode organizar vários sistemas de jogos retro para utilização na televisão. | Que todos os jogos, ficheiros BIOS e comandos funcionarão sem configuração. |
| ZimaBoard 2 | A plataforma x86 compacta pode suportar um projeto de jogos retro com Batocera. | Que substitui hardware dedicado para cada tarefa moderna relacionada com jogos. |
| Flexibilidade da plataforma | O mesmo hardware pode mais tarde voltar a desempenhar funções de armazenamento, multimédia, rede ou servidor. | Essa configuração é automaticamente otimizada para todas essas funções em simultâneo. |
Os jogos retro tornam-se uma forma de estudar como os jogos nos ensinam
O projeto de Giorgio é bem-sucedido porque utiliza jogos antigos para mais do que nostalgia. Jogar através do Batocera no ZimaBoard 2 cria uma oportunidade para analisar o que os jogos esperam dos seus jogadores e como essas expectativas mudaram.
Um jogo de 1997 pode pedir ao jogador que se lembre, experimente, falhe e tente novamente. Um jogo moderno pode preservar o ritmo através de pontos de controlo, marcadores, indicações contextuais e assistência adaptativa. Ambas as abordagens podem proporcionar experiências significativas quando a orientação corresponde ao design pretendido.
A ZimaBoard 2 facilita a transição entre estas gerações, enquanto a sua arquitetura x86, o armazenamento SATA, a rede e a expansão PCIe impedem que o hardware fique permanentemente limitado a uma única função de entretenimento.
Veja a experiência completa de Giorgio para conhecer a comparação original entre o design de jogos do passado e do presente e a configuração final da Batocera.
Se está a construir uma consola retro, a testar a Batocera ou a reutilizar a ZimaBoard 2 entre cargas de trabalho de jogos e de servidor doméstico, junte-se à comunidade ZimaSpace para partilhar a sua configuração e os resultados de compatibilidade.
Perguntas frequentes
A ZimaBoard 2 consegue executar a Batocera?
Sim. A sua arquitetura x86 e a saída de vídeo direta tornam-na adequada para uma configuração de jogos retro baseada na Batocera. A imagem de instalação, o armazenamento de destino, o comando e a configuração do emulador devem ainda ser compatíveis.
A Batocera consegue executar jogos lançados em 1997?
Muitos jogos desse período podem ser executados através de emuladores suportados, conversões ou camadas compatíveis com jogos para PC. A compatibilidade depende da plataforma original, do emulador, dos ficheiros BIOS necessários e do jogo em questão.
A Batocera inclui jogos retro comerciais?
Não se deve presumir que os ficheiros de jogos comerciais estão incluídos ou licenciados para distribuição gratuita. Os utilizadores são responsáveis por obter e utilizar legalmente os jogos e os ficheiros BIOS.
A ZimaBoard 2 pode substituir todas as consolas retro?
Nenhum emulador oferece compatibilidade perfeita com todos os títulos e periféricos. O hardware original, os sistemas FPGA ou os emuladores específicos de cada plataforma podem ainda proporcionar melhores resultados com jogos e acessórios invulgares.
A mesma ZimaBoard 2 também pode funcionar como NAS?
Sim. As interfaces SATA, 2.5GbE duplas e PCIe suportam projetos de armazenamento. Os utilizadores podem manter os ambientes de jogos e de servidor em unidades separadas ou reconfigurar o sistema, mas devem fazer uma cópia de segurança dos dados antes de alterar os sistemas operativos.
Todos os jogos de 1997 eram difíceis e mal explicados?
Não. O design variava consideravelmente. Alguns jogos incluíam tutoriais detalhados, mapas, definições de dificuldade e sistemas de gravação generosos. A comparação de Giorgio descreve convenções mais amplas, não todos os lançamentos desse ano.
Os jogos modernos tornaram-se demasiado fáceis?
Não necessariamente. As orientações modernas podem melhorar a acessibilidade e reduzir a frustração repetitiva sem eliminar o desafio mecânico. O efeito depende de a assistência apoiar as decisões do jogador ou substituí-las.
Centro de Campanhas Zima
Mais para Ler

Como a YOTECH avalia o ZimaBoard 2 como servidor doméstico compacto
A YOTECH analisa o ZimaBoard 2 como uma plataforma compacta para servidor doméstico, abrangendo a caixa de alumínio com arrefecimento passivo, os cabos incluídos,...

Como Arthur, da Hobby Support, gere serviços de rede doméstica no ZimaBoard 2
Arthur, da Hobby Support Int., monta um servidor doméstico ZimaBoard 2 com armazenamento SATA, refrigeração ativa e expansão PCIe, e explora como o ZimaOS...

Como a schvabek transforma o ZimaBoard 2 num pequeno servidor que também permite jogar
A schvabek explora as duas vertentes da ZimaBoard 2: primeiro, como um servidor doméstico ZimaOS compacto, com acesso a ficheiros através do navegador e...

