Transformar “O Ciclo de Vida do Corpo de Software” num Visual Novel jogável: uma retrospectiva completa de uma iteração
Desta vez, não foi “só colocar uma skin de leitor”, e sim pegar o texto completo 软件体的生命周期.md e realmente transformá-lo num romance visual (Visual Novel) jogável no estilo japonês de GALGAME, obedecendo do início ao fim a uma restrição rígida: o texto original só pode aumentar, nunca diminuir — não pode perder nenhum detalhe textual.
O processo não aconteceu de uma vez; foi uma sequência típica de iterações contínuas: “primeiro fazer funcionar, e depois ir polindo aos poucos tudo o que parece estranho”. Olhando em retrospectiva, dá para dividir basicamente nas fases abaixo.
1. O ponto de partida era muito claro: não é adaptação por recortes, é transformação fiel do texto completo
Desde o começo, o objetivo já era bem rígido:
- A origem do roteiro é o arquivo local
软件体的生命周期.md - O texto completo tem que entrar no jogo
- Não dá para, por virar jogo, cortar o original e transformar em resumo, versão em falas (diálogos) ou versão de light novel
- A apresentação do texto pode ser aprimorada, mas o conteúdo textual em si não pode encolher
Então, a lógica de base deste projeto não foi “escrever um roteiro de VN”, e sim “quebrar o texto original em uma estrutura de parágrafos adequada para progressão de Visual Novel, mantendo também o texto integral disponível para consulta”.
Depois, em todo o sistema — navegação por capítulos, visão geral do original, localização por parágrafo, releitura, salvamento de progresso — tudo, na verdade, existe para servir esse pré-requisito.
2. A primeira versão rodava, mas não parecia um Visual Novel
Quando a primeira versão saiu, o maior problema não era falta de 기능 (funções), e sim a falta de ‘vibe’.
Embora já desse para avançar o texto, exibir conteúdo e dividir em trechos, a interface parecia mais um leitor web com um painel de controle, e não um GALGAME japonês. A primeira reação do usuário também foi direta: “Essa interface está totalmente errada, faça uma UI daquele tipo de galgame japonês.”
Então, a primeira rodada de refatoração depois disso não focou em adicionar recursos, e sim em acertar primeiro a linguagem visual:
- Separar novamente a camada de palco, a camada de primeiro plano e a camada da caixa de texto
- Redesenhar título de capítulo, página de título e cards de transição para um estilo de apresentação de visual novel
- Trocar a caixa de texto para um dialogue box de VN fixo no palco, em vez de um card de página comum
- Área de fala do personagem, nameplate, barra de progresso e botão de avançar num layout mais próximo de um visual novel japonês
O significado dessa rodada foi: fazer primeiro com que pareça um jogo, e só depois continuar a completar as interações que um jogo deveria ter.
3. As artes dos personagens foram completadas; o palco evoluiu de “tem imagem” para “parece um palco”
O usuário deixou um requisito claro: todo personagem tem que ter sprite/arte (立绘).
Então, o trabalho seguinte não foi simplesmente colocar imagens para alguns protagonistas, mas montar de verdade um sistema de sprites de personagens:
- Dados de sprite de personagens gerenciados de forma independente
- Cada personagem com seu posicionamento no palco e estilo de exibição
- Disposição possível para um personagem, vários personagens, ou vários em cena
- Quando um personagem fala, ele fica destacado; os que só escutam ficam atenuados
- Texto de fala suporta cores correspondentes por personagem
Mas essa parte também passou por muitas rodadas de ajuste. No meio do caminho surgiram alguns problemas típicos:
- Alguns personagens só apareciam da cintura para baixo
- A caixa de texto era grande demais e cobria o palco
- Com vários personagens em cena, o palco ficava muito apertado
- Na miniatura do save, o sprite frequentemente era cortado (cabeça) ou sobravam só as pernas
Depois, em torno desses problemas, foram feitas várias correções:
- Ajustar altura do palco e lógica de escala dos sprites
- Diferenciar três tipos de tamanho de sprite: human / digital / entity
- Permitir deslocamento horizontal/vertical e zoom do palco
- Fazer uma distribuição de slots mais razoável para múltiplos personagens em cena
- Corrigir o enquadramento da miniatura, tentando preservar o corpo inteiro e evitando que o personagem fique todo “cortado” no card de save
A partir daí, deixou de ser só “colocar algumas imagens”, e começou a ter um senso claro de palco.
4. A liberdade da caixa de texto quase virou um sistema de layout ajustável
Neste projeto, a caixa de texto foi a parte mais observada de perto pelo usuário — e também a parte que foi mais aprofundada depois.
O usuário fez várias exigências muito específicas em sequência:
- Suportar que o usuário personalize a posição da caixa de texto
- Suportar ajustar o tamanho pelos cantos
- Suportar ajuste de transparência
- Suportar velocidade máxima de texto (aparecer instantaneamente)
- Suportar cores de texto diferentes por personagem
- A caixa de texto não pode ficar travada em largura total
- Pode ficar mais estreita e também mais larga
- Não pode ficar sempre bloqueando os sprites
- Em “shunjí” (layout à direita), tem que ficar totalmente à direita
Então, depois não foi só “arrastar a caixa de texto”, e sim ir aos poucos transformando isso num sistema completo de layout:
- Suportar arrastar para mover a caixa de texto
- Suportar redimensionamento em 8 direções (4 lados + 4 cantos)
- Suportar ajuste livre de largura e altura
- Suportar layouts predefinidos: central, inferior esquerdo, inferior direito, superior esquerdo, superior direito
- Suportar ajustes de transparência, tamanho de fonte e espaçamento entre linhas
- Suportar salvar junto com o progresso e restaurar na próxima vez
- Mudança de posição da caixa de texto aciona desvio do palco (evitar sobreposição), reduzindo bloqueio de personagens
Aqui houve uma virada bem importante:
No começo, apesar de suportar mudar tamanho, ainda existia o problema de “o mais estreito ainda é largura total” e “visualmente parece travado”. Depois, foi corrigida especificamente a largura mínima, a largura padrão e a lógica de tamanhos personalizados; só então foi possível realizar de verdade a transformação livre que o usuário queria — e não “parece ajustável, mas na prática não ajusta”.
5. Título, transições de capítulo e informações de placeholder: reduzir repetidamente
Outro rumo evidente das iterações foi remover aos poucos UI desnecessária que interrompia a leitura.
O usuário reclamou de alguns pontos bem típicos:
- Esses dois quadros no canto superior esquerdo podem desaparecer automaticamente, sem deixar placeholder?
- O nome do livro e o grande título “Capítulo X” só aparecem uma vez quando muda de capítulo; não façam isso aparecer a cada frase
- Não deixem blocos de explicação sempre pendurados na tela
Então eu fiz algumas rodadas de “só aparecer quando deve aparecer”:
- Página de título / título do capítulo passam a exibir brevemente apenas em troca real de capítulo
- Durante leitura normal, esconder automaticamente o título grande e os quadros de placeholder
- Em cenas sem sprites, não mostrar mais um card vazio grande como placeholder
- HUD superior some (fade out) automaticamente quando ocioso
- Dica de leitura sai automaticamente em desktop quando ocioso
- Dica de arrastar e alças de redimensionamento ficam discretas na leitura silenciosa; só voltam ao interagir
- Etiquetas aos pés dos sprites somem automaticamente em leitura silenciosa; acendem de novo ao interagir ou quando o personagem muda
Essa sequência de ajustes, na verdade, faz sempre a mesma coisa:
diminuir a sensação de “interface de ferramenta” e aumentar a sensação de “encenação de leitura”.
6. Modos de avanço foram completados; a experiência ficou mais parecida com um visual novel de verdade
Além do avanço básico, também foram completados hábitos comuns de interação de VN de forma relativamente completa:
- Clicar fora da caixa de texto para avançar
- Scroll do mouse: próxima frase / frase anterior
- Espaço, Enter, setas para avançar
- Autoplay
- Pular (skip) textos já lidos
- Botão direito ou atalhos para ocultar interface
- Pressionar e segurar em área vazia para alternar ocultar interface (mobile)
Isso também não ficou certo de primeira.
Por exemplo, um problema que acabou de ser corrigido recentemente foi: com os controles expandidos o scroll funcionava, mas ao recolher os controles o scroll parava de funcionar. A causa foi que a área do texto estava sendo tratada incorretamente como “área que deve interceptar rolagem”. Depois que isso foi corrigido, ainda foi adicionada uma volta automática, garantindo que, “depois de recolher os controles, colocando o mouse sobre o texto, o scroll ainda avança / retrocede”.
Essas correções parecem pequenas, mas são críticas, porque determinam diretamente se o produto final parece ou não um VN realmente adequado para leitura longa.
7. Saves, releitura e visão geral do original: aqui não são recursos acessórios, são recursos centrais
Como o projeto desde o início exigia “fidelidade ao original”, então algumas funções que em jogos comuns seriam extras, aqui são as funções principais:
- Auto-save
- Quick save / quick load
- Saves manuais com múltiplos slots
- Ao carregar, restaurar posição/tamanho da caixa de texto e preferências de leitura
- Releitura dos trechos recentes
- Navegação por capítulos
- Visão geral do original e sumário
- A partir do parágrafo do jogo, rastrear o número de linha do original e localizar
Em especial, “visão geral do original” e “parágrafo correspondendo ao número de linha do original” na prática tornam bem transparente essa coisa de “adaptar para jogo”:
Você não fica limitado a avançar só na camada do jogo; você pode a qualquer momento voltar à estrutura completa do texto original e ver exatamente em que linha você está lendo.
8. Miniaturas de save e detalhes do estado de leitura: tudo saiu de microajustes rodada após rodada
Mais para o fim, o que realmente consumia tempo já não eram grandes funcionalidades, e sim um monte de detalhes que “o usuário bate o olho e se incomoda”, mas talvez não consiga explicar em uma frase.
Por exemplo:
- Sprite cortado na cabeça na miniatura do save
- Etiqueta aos pés do sprite parecendo informação de debug
- Dicas da caixa de texto e alças de arrastar muito chamativas
- HUD superior fixo roubando a cena
- Com vários personagens em cena, o foco de leitura é espalhado pela UI
Esses problemas, em geral, não foram resolvidos “adicionando mais recursos”, e sim controlando o ritmo:
- o que deve ficar sempre visível
- o que deve sumir (fade out)
- o que deve aparecer só no hover
- o que deve aparecer só como dica breve ao mudar de estado
Depois de terminar isso, a sensação do jogo muda claramente de “site cheio de funções” para “visual novel em que dá para ler em paz”.
9. Validação automatizada é a chave para seguir iterando no fim do projeto
Depois, o usuário disse algo bem direto: “Você só vai continuamente melhorar, otimizar e validar as funcionalidades do nosso serviço.”
Então, em seguida, eu não só mexi em visual, como também completei o pipeline de validação automatizada. No projeto, mais tarde, existe um conjunto de scripts de verificação de UI no estilo Playwright, para checar repetidamente estes pontos-chave:
- Se o título aparece / some no momento certo
- Se a caixa de texto padrão bloqueia o palco
- Se arrastar / redimensionar / snapping da caixa de texto está normal
- Se posição e tamanho personalizados podem ser salvos e restaurados
- Se o HUD superior some automaticamente
- Se dicas de leitura e alças de arrastar enfraquecem quando ocioso
- Se gaveta de saves, auto-save, e miniaturas do quick save estão normais
- Se múltiplos personagens em cena estouram os limites em desktop / mobile
- Se no mobile o press-and-hold para ocultar interface funciona
- Se, ao recolher controles, o scroll para avançar continua funcionando
Isso significa que as otimizações seguintes não são “mudar um ponto e torcer para o resto não quebrar”, e sim mudar e fazer regressão ao mesmo tempo.
Essa capacidade é muito importante para um projeto de UI altamente interativa; caso contrário, na fase final é muito fácil cair no “corrigi A, explodiu B”.
10. O estado atual do projeto
Até agora, este projeto GALGAME de “O Ciclo de Vida do Corpo de Software” já tem uma jogabilidade e legibilidade bem completas:
- Texto original completo preservado, sem adaptação em formato de resumo
- Interface principal no estilo GALGAME japonês
- Sprites de todos os personagens integrados
- Cores de texto diferentes por personagem
- Transições de troca de capítulo e exibição de página de título
- Caixa de texto com arrastar livre, redimensionamento e ajuste de transparência
- Velocidade de texto com suporte a exibição instantânea
- Avançar clicando fora da caixa de texto
- Scroll: anterior / próxima
- Autoplay, skip, ocultar UI
- Auto / quick / manual save
- Releitura, navegação de capítulos, visão geral do original
- Adaptação para desktop / mobile
- Polimento de múltiplas rodadas para tirar a “cara de ferramenta”
- Scripts de validação automatizada para regressão contínua
Se o objetivo inicial era “transformar um texto md em um jogo”, então agora a descrição mais precisa deveria ser:
transformar um texto longo e completo num sistema de visual novel que dá para ler, jogar, rastrear, e que dá para continuar refinando.
11. A parte mais interessante deste projeto
Para mim, o mais interessante nesta fase de desenvolvimento não foi “fiz uma página de GALGAME”, e sim que todo esse processo ilustra de forma muito típica uma coisa:
Para fazer algo ficar realmente decente, muitas vezes não é empilhar todas as funções na primeira versão, e sim o usuário ir apontando continuamente “o que está estranho”, e aí você vai removendo esses estranhamentos rodada após rodada.
O feedback do usuário desta vez foi muito específico, e muitos não eram um vago “otimiza mais um pouco”, e sim:
- aqui está bloqueando a tela
- por que aqui está travado em largura total
- por que aqui aparece em toda frase
- isso só mostra a metade de baixo do corpo
- por que no canto superior esquerdo isso não desaparece de verdade
- por que o scroll deixa de funcionar quando recolhe os controles
Foram exatamente esses pontos muito específicos de “parece errado” que no fim levaram o projeto de “dá para usar” para “parece de verdade”.
Se continuar fazendo depois, acho que ainda há direções que dá para polir mais:
- Um estilo de sprite de personagens mais uniforme
- Encenação de capítulos mais detalhada e um sistema de BGM/SE mais completo
- Um sistema mais completo de CG / troca de fundos
- Capacidade de roteirização (script) mais forte
- Uma forma de empacotamento e publicação mais formal
Mas, para esta rodada atual, isso já não é demo; é um protótipo de VN bem completo, que dá para iterar continuamente.