diff --git a/.github/workflows/multilingual.yaml b/.github/workflows/multilingual.yaml index f7a0e8e..599499d 100644 --- a/.github/workflows/multilingual.yaml +++ b/.github/workflows/multilingual.yaml @@ -34,3 +34,6 @@ jobs: - name: Test native multilingual behavior run: bundle exec ruby scripts/test_multilingual.rb + + - name: Build published and draft content + run: hugo --buildDrafts --buildFuture --minify --destination "${{ runner.temp }}/hugo-content-check" diff --git a/content/docs/2026/julho/refactor-blog/index.en.md b/content/docs/2026/julho/refactor-blog/index.en.md index 4a1afae..d4202e9 100644 --- a/content/docs/2026/julho/refactor-blog/index.en.md +++ b/content/docs/2026/julho/refactor-blog/index.en.md @@ -151,3 +151,9 @@ First I requested an analysis through claude.ai, then wrote the following instru - For `.AGENTS.md`, with a leading dot, I used the standard `AGENTS.md` convention at the root, the name agent tools recognize, plus an `.agents/` folder for persistent setup. - The PR targeted **develop**, the repository's default branch, in four thematic commits. + +--- + +### How did it turn out? + +I was still using Notion, but wanted to extract all the text and keep it in my own repository. That started the migration to a different layout: the [Hextra template](https://themes.gohugo.io/themes/hextra/). I used AI to migrate the posts first. Since Notion can export Markdown files, moving everything at once was simpler. Then I configured the new template, added the features I wanted, and adapted its cleaner, simpler layout. This continues in “Refactoring the blog — part 2”, which is still a draft. diff --git a/content/docs/2026/julho/refactor-blog/index.md b/content/docs/2026/julho/refactor-blog/index.md index 6198a88..c41688c 100644 --- a/content/docs/2026/julho/refactor-blog/index.md +++ b/content/docs/2026/julho/refactor-blog/index.md @@ -151,3 +151,11 @@ Primeiro foi solicitado para realizar uma análise utilizando o claude.ai, segui - `.AGENTS.md` (com ponto): usei a convenção padrão `AGENTS.md` na raiz (é o nome que as ferramentas de agente reconhecem) + a pasta `.agents/` para o setup persistente. - O PR foi aberto contra **`develop`** (branch padrão do repo), em 4 commits temáticos. + +--- + +### Como tudo ficou? + +Como ainda eu estava dentro da plataforma do Notion, e eu gostaria de extrair todos os textos dele e ficar em um repositório meu +resolvi então a saga para migração de posts do blog para outro Layout que encontrei que é este [template Hextra aqui](https://themes.gohugo.io/themes/hextra/). Resolvi com uso de IA fazer a migração dos posts primeiro então como o Notion tem a opção de extrair arquivo.md é mais simples fazer tudo de uma única vez. Após isso, foi configurar este novo template e adicionar funcionalidades que eu gostaria, e também +aplicar no layout que é, mais limpo e simples, coisas que eu gostaria. Esta saga continua no post “Refatorando o Blog parte 2”, ainda em rascunho. diff --git a/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.en.md b/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.en.md new file mode 100644 index 0000000..9546879 --- /dev/null +++ b/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.en.md @@ -0,0 +1,59 @@ +--- +title: "Building a portfolio website and organizing the work I have done" +date: 2026-11-06 +slug: criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados +tags: [portfolio, engenharia-de-software, testes, documentacao] +draft: false +--- + +## Building a portfolio website and organizing the work I have done + +Recently I started organizing my portfolio in a way that would help me present my work more clearly. I wanted more than a list of technologies or repository links. I also wanted to explain what I did, how I organized the stages, and what evidence is available to check each contribution. + +The project is on GitHub: . The published version is available at . + +## What I wanted to organize + +Throughout my career, I have worked in support, frontend development, mobile and backend applications, testing, and documentation. Some of that work took place in private repositories, so it is not always possible to show the code or reproduce a run through a public link alone. + +That is why I am organizing the accounts to distinguish what was implemented, what appears in the available records, and the limits of each piece of evidence. An implementation described in a report does not, by itself, mean that every scenario was executed or that a pipeline was published. I want readers to be able to see that distinction. + +## A website with several pages + +The site is a static application built with React and TypeScript. Instead of creating one long page with every subject mixed together, I divided the navigation into pages for my career, contributions, workflow, setup, tools, and games. The homepage works as a map to reach those sections. This map is still in development, as I would like a layout inspired by Stardew Valley. + +For the visual design, I used a retro workstation reference, with cream, beige, brown, and pink tones and a pixel art illustration. I wanted the identity to connect with my Ladydebug blog while keeping the focus on reading and the work presented. + +In the **In practice** section, each contribution can be opened to read its account and references. Public projects also link to their repositories. This keeps the content in one place while giving each subject its own context. + +## Content separated from components + +An important decision was to move long texts out of the components. The introduction, about section, career history, and project accounts live in Markdown files inside `src/content/`. Components handle the page structure, and content can be edited without changing the layout. Keeping those responsibilities separate made more sense than hardcoding text into components. + +For the accounts, I use Markdown with headings, paragraphs, lists, links, and references. The `react-markdown` library turns that content into page elements. Local images can also be referenced in Markdown; the build process packages the files and generates paths that work on [GitHub Pages — see the repository here](https://github.com/remarkjs/react-markdown). + +Information with a predictable structure stays in TypeScript. Workflow stages and project data, for example, need an order, identifiers, descriptions, and links. Keeping that data typed helps reveal inconsistencies during development. + +This division also makes maintenance easier: editorial content stays in Markdown, data feeding cards and stages stays typed, and components are responsible for presentation. + +## The workflow is part of the portfolio too + +I included a page to record how I usually work. The flow involves understanding the context, building and testing, reviewing evidence, and following up on what needs to improve. The idea is to show some of the decisions and practices behind the deliveries, as well as the final result. I reached this approach through analysis, gathering information, applying tests, and validating the results. + +I also organized examples of tools and setup, along with a list of game studies. These sections reflect the subjects I follow and help show how I organize my environment and keep learning. They also include my experience with the Arch Linux-based system [Omarchy](https://omarchy.org/). + +## Testing and publishing + +The project has unit tests and browser tests with [Playwright](https://playwright.dev/). In the browser tests, I am prioritizing behaviors someone can perform: navigating between pages, opening an account, following an anchor, downloading a file, copying a command, and filtering the games list. I also check layout behavior at different widths, such as horizontal scrolling and touch target sizes. + +I organized the E2E tests into separate files by flow, including navigation, home, career, accounts, workflow, tools, and responsiveness. That makes it easier to locate a scenario and understand which part of the site it covers. The tests validate features and interface states without comparing the wording of editorial texts. + +The site is generated as [static files and published through GitHub Pages](https://github.com/kellen-xavier/ladydebug-workstation/blob/main/.github/workflows/pages.yml). The pipeline runs lint, type checks, tests, and browser tests against the production build before publishing the main branch version. + +## What I am still learning + +Building this portfolio is also helping me think about presenting technical experience clearly. I need to choose which details help explain a contribution, which links are useful, and where to state limitations instead of making claims that go beyond the available records. + +I still want to review the accounts and keep improving navigation and readability on smaller screens. The structure already lets me update each part more independently: I can adjust Markdown text, reorganize a project in the typed data, or improve a component without rewriting the whole site. + +The goal is to keep this space as a living record of my work and studies, with ways to check what is public and enough context to understand the rest. diff --git a/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.md b/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.md new file mode 100644 index 0000000..2ea285a --- /dev/null +++ b/content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.md @@ -0,0 +1,59 @@ +--- +title: "Criando um site portfolio - E como estou organizando os trabalhos realizados" +date: 2026-11-06 +slug: criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados +tags: [portfolio, engenharia-de-software, testes, documentacao] +draft: false +--- + +## Criando um site portfolio - E como estou organizando os trabalhos realizados + +Recentemente comecei a organizar meu portfólio de um jeito que me ajudasse a mostrar melhor os trabalhos que venho realizando. Não queria deixar somente uma lista de tecnologias ou links para repositórios. Também queria explicar o que foi feito, como organizei as etapas e quais evidências existem para conferir cada contribuição. + +O projeto está no GitHub: . A versão publicada pode ser acessada em . + +## O que eu queria organizar + +Ao longo da minha trajetória, trabalhei com suporte, desenvolvimento frontend, aplicações mobile e backend, testes e documentação. Parte desse trabalho aconteceu em repositórios privados, então nem sempre é possível mostrar o código ou reproduzir uma execução apenas com um link público. + +Por isso, estou organizando os relatos para separar o que foi implementado, o que aparece nos registros disponíveis e quais são os limites de cada evidência. Uma implementação descrita em um relatório não significa, por si só, que todos os cenários foram executados ou que um pipeline foi publicado. Quero deixar essa diferença visível para quem estiver lendo. + +## Um portfólio com várias páginas + +O site é uma aplicação estática feita com React e TypeScript. Em vez de montar uma única página longa com todos os assuntos misturados, separei a navegação em páginas para trajetória, contribuições, workflow, setup, ferramentas e games. A página inicial funciona como um mapa para chegar a essas partes. (Este mapa ainda está em desenvolvimento pois eu gostaria de algo no layout de Stardew Vallew) + +Na parte visual, usei uma referência de workstation retrô, com tons de creme, bege, marrom e rosa e uma ilustração em pixel art. Queria que a identidade tivesse relação com o meu blog Ladydebug sem tirar o foco da leitura e dos trabalhos apresentados. + +Na seção **Na prática**, cada contribuição pode ser aberta para consultar o relato e as referências. Os projetos públicos também levam aos respectivos repositórios. Assim, o conteúdo fica em um mesmo lugar, mas cada assunto tem seu próprio contexto. + +## Conteúdo separado dos componentes + +Uma decisão importante foi retirar os textos longos dos componentes. Apresentação, sobre, trajetória e relatos ficam em arquivos Markdown dentro de `src/content/`. Os componentes cuidam da estrutura da página e o conteúdo pode ser editado sem alterar o layout. Foi melhor deixar tudo isso separado, não tem o menos cabimento deixar harded code os textos nos componentes. + +Para os relatos, uso Markdown com títulos, parágrafos, listas, links e referências. A biblioteca `react-markdown` transforma esse conteúdo em elementos da página. Imagens locais também podem ser escritas no Markdown; o processo de build empacota os arquivos e gera caminhos que funcionam no [GitHub Pages veja o repositório aqui](https://github.com/remarkjs/react-markdown). + +Já as informações que têm estrutura previsível ficam em TypeScript. Por exemplo, etapas do workflow e dados dos projetos precisam de ordem, identificadores, descrições e links. Manter esses dados tipados ajuda a perceber inconsistências durante o desenvolvimento. + +Essa divisão também facilita a manutenção: conteúdo editorial fica no Markdown, dados que alimentam cartões e etapas ficam tipados e os componentes ficam responsáveis por apresentar tudo. + +## O workflow também faz parte do portfólio + +Incluí uma página para registrar como costumo trabalhar. O fluxo passa por entender o contexto, construir e testar, revisar as evidências e acompanhar o que precisa evoluir. A ideia é mostrar um pouco das decisões e práticas por trás das entregas, não apenas o resultado final. Exemplo como cheguei nessa lógica, foi analisando, fazendo o levantamento, aplicando testes, validando. + +Também organizei exemplos de ferramentas e setup, além de uma lista de estudos sobre jogos. Esses blocos fazem parte dos assuntos que acompanho e ajudam a mostrar como organizo o ambiente e continuo aprendendo. E também minha tragetórica com o sistema baseado no Arch Linux o [Omarchy](https://omarchy.org/) + +## Testes e Publicação + +O projeto tem testes unitários e testes de navegador com [Playwright](https://playwright.dev/). Nos testes de navegador, estou priorizando comportamentos que alguém consegue executar: navegar entre páginas, abrir um relato, seguir uma âncora, baixar um arquivo, copiar um comando e filtrar a lista de jogos. Também verifico aspectos de layout em larguras diferentes, como rolagem horizontal e tamanho dos alvos de toque. + +Organizei os testes E2E em arquivos separados por fluxo, como navegação, home, carreira, relatos, workflow, ferramentas e responsividade. Isso deixa mais fácil localizar um cenário e entender qual parte do site ele cobre. Os testes validam funcionalidades e estados da interface, sem comparar a redação dos textos editoriais. + +O site é gerado como [arquivos estáticos e publicado pelo GitHub Pages](https://github.com/kellen-xavier/ladydebug-workstation/blob/main/.github/workflows/pages.yml). A pipeline executa lint, verificação de tipos, testes e testes de navegador sobre o build de produção antes de publicar a versão da branch principal. + +## O que ainda estou aprendendo + +Montar esse portfólio também está me ajudando a pensar sobre como apresentar experiências técnicas com clareza. Preciso escolher quais detalhes ajudam a entender uma contribuição, quais links são realmente úteis e onde é necessário indicar limites em vez de fazer uma afirmação maior do que os registros permitem. + +Ainda quero revisar os relatos e continuar melhorando a navegação e a leitura em telas menores. A estrutura já me permite atualizar cada parte com mais autonomia: posso ajustar um texto no Markdown, reorganizar um projeto nos dados tipados ou evoluir um componente sem precisar reescrever o site inteiro. + +O objetivo é manter esse espaço como um registro vivo do meu trabalho e dos estudos, com caminhos para conferir o que está público e contexto suficiente para entender o restante. diff --git a/content/docs/2026/novembro/images/arquitetura-conceitual.svg b/content/docs/2026/novembro/images/arquitetura-conceitual.svg new file mode 100644 index 0000000..cbe07f9 --- /dev/null +++ b/content/docs/2026/novembro/images/arquitetura-conceitual.svg @@ -0,0 +1 @@ +Game ApplicationInicialização e ciclo de vidaGameplay SystemsRegras, personagens, inventário e IAEngine SystemsFísica, áudio, renderização e inputPlatform AbstractionGráficos, sistema operacional e driversHardwareCPU, GPU, memória e dispositivos \ No newline at end of file diff --git a/content/docs/2026/novembro/images/arquitetura-proposta-game-enginee.svg b/content/docs/2026/novembro/images/arquitetura-proposta-game-enginee.svg new file mode 100644 index 0000000..36422c3 --- /dev/null +++ b/content/docs/2026/novembro/images/arquitetura-proposta-game-enginee.svg @@ -0,0 +1 @@ +PresentationHUD · Widgets · Blueprints · Feedback visualGameplay IntegrationActors · Components · Controllers · EventsGame DomainHealth · Inventory · Score · Business RulesInfraestrutura / Persistência \ No newline at end of file diff --git a/content/docs/2026/novembro/images/image 1.png b/content/docs/2026/novembro/images/image 1.png new file mode 100644 index 0000000..81cc691 Binary files /dev/null and b/content/docs/2026/novembro/images/image 1.png differ diff --git a/content/docs/2026/novembro/images/image 10.png b/content/docs/2026/novembro/images/image 10.png new file mode 100644 index 0000000..cd21080 Binary files /dev/null and b/content/docs/2026/novembro/images/image 10.png differ diff --git a/content/docs/2026/novembro/images/image 11.png b/content/docs/2026/novembro/images/image 11.png new file mode 100644 index 0000000..37e5273 Binary files /dev/null and b/content/docs/2026/novembro/images/image 11.png differ diff --git a/content/docs/2026/novembro/images/image 12.png b/content/docs/2026/novembro/images/image 12.png new file mode 100644 index 0000000..4f148af Binary files /dev/null and b/content/docs/2026/novembro/images/image 12.png differ diff --git a/content/docs/2026/novembro/images/image 13.png b/content/docs/2026/novembro/images/image 13.png new file mode 100644 index 0000000..61d1cae Binary files /dev/null and b/content/docs/2026/novembro/images/image 13.png differ diff --git a/content/docs/2026/novembro/images/image 14.png b/content/docs/2026/novembro/images/image 14.png new file mode 100644 index 0000000..8fa95d6 Binary files /dev/null and b/content/docs/2026/novembro/images/image 14.png differ diff --git a/content/docs/2026/novembro/images/image 2.png b/content/docs/2026/novembro/images/image 2.png new file mode 100644 index 0000000..f76c76e Binary files /dev/null and b/content/docs/2026/novembro/images/image 2.png differ diff --git a/content/docs/2026/novembro/images/image 3.png b/content/docs/2026/novembro/images/image 3.png new file mode 100644 index 0000000..b13fdca Binary files /dev/null and b/content/docs/2026/novembro/images/image 3.png differ diff --git a/content/docs/2026/novembro/images/image 4.png b/content/docs/2026/novembro/images/image 4.png new file mode 100644 index 0000000..0d48846 Binary files /dev/null and b/content/docs/2026/novembro/images/image 4.png differ diff --git a/content/docs/2026/novembro/images/image 5.png b/content/docs/2026/novembro/images/image 5.png new file mode 100644 index 0000000..4ac3838 Binary files /dev/null and b/content/docs/2026/novembro/images/image 5.png differ diff --git a/content/docs/2026/novembro/images/image 6.png b/content/docs/2026/novembro/images/image 6.png new file mode 100644 index 0000000..e75a65c Binary files /dev/null and b/content/docs/2026/novembro/images/image 6.png differ diff --git a/content/docs/2026/novembro/images/image 7.png b/content/docs/2026/novembro/images/image 7.png new file mode 100644 index 0000000..fcf5c49 Binary files /dev/null and b/content/docs/2026/novembro/images/image 7.png differ diff --git a/content/docs/2026/novembro/images/image 8.png b/content/docs/2026/novembro/images/image 8.png new file mode 100644 index 0000000..52b535f Binary files /dev/null and b/content/docs/2026/novembro/images/image 8.png differ diff --git a/content/docs/2026/novembro/images/image 9.png b/content/docs/2026/novembro/images/image 9.png new file mode 100644 index 0000000..985281e Binary files /dev/null and b/content/docs/2026/novembro/images/image 9.png differ diff --git a/content/docs/2026/novembro/images/image.png b/content/docs/2026/novembro/images/image.png new file mode 100644 index 0000000..1f931f8 Binary files /dev/null and b/content/docs/2026/novembro/images/image.png differ diff --git a/content/docs/2026/novembro/refatorando-o-blog-parte-2.md b/content/docs/2026/novembro/refatorando-o-blog-parte-2.md new file mode 100644 index 0000000..0794388 --- /dev/null +++ b/content/docs/2026/novembro/refatorando-o-blog-parte-2.md @@ -0,0 +1,9 @@ +--- +title: "Refatorando o Blog parte 2" +date: 2026-11-06 +slug: refatorando-o-blog-parte-2 +tags: [] +draft: true +--- + +## Refatorando o Blog parte 2 diff --git a/content/docs/2026/novembro/testando-um-jogo-existente-na-unreal-objetivos-e-portal-no-stack-o-bot.md b/content/docs/2026/novembro/testando-um-jogo-existente-na-unreal-objetivos-e-portal-no-stack-o-bot.md new file mode 100644 index 0000000..9bb347c --- /dev/null +++ b/content/docs/2026/novembro/testando-um-jogo-existente-na-unreal-objetivos-e-portal-no-stack-o-bot.md @@ -0,0 +1,368 @@ +--- +title: "Testando um jogo existente na Unreal: Stack O Bot" +date: 2026-11-03 +slug: testando-um-jogo-existente-na-unreal-objetivos-e-portal-no-stack-o-bot +tags: [jogo] +draft: true +--- + +## Um pouco sobre Jogos, arquitetura e Testes + +A arquitetura de jogos digitais combina princípios tradicionais da Engenharia de Software com necessidades específicas de sistemas interativos em tempo real: renderização, simulação física, processamento de entradas, inteligência artificial, gerenciamento de estados e execução contínua de um ciclo de atualização (Game Loop). + +Na Unreal Engine 5.8.3, que eu instalei no sistema operacional, Omarchy, é possível desenvolver e testar esses sistemas utilizando C++, Blueprints e os frameworks de automação fornecidos pela própria Epic Games entre outros. + +Fui pesquisar um pouco sobre então, como é a arquitetura de um Jogo + +## 1. Como funciona a arquitetura de um jogo + +Uma arquitetura de jogo não é simplesmente uma organização de arquivos. Ela define como as responsabilidades são distribuídas, como os componentes se comunicam e como o estado do jogo evolui a cada atualização. + +![image](images/arquitetura-conceitual.svg) + +Essas camadas podem ser compreendidas da seguinte forma: + +| Camada | Responsabilidade | +| --- | --- | +| Game Application | Inicialização, carregamento, encerramento e configuração | +| Gameplay | Regras do jogo, combate, pontuação, progressão e interações | +| Engine | Renderização, física, animação, áudio e gerenciamento de objetos | +| Plataforma | Integração com Linux, Windows, gráficos e dispositivos | +| Hardware | Execução na CPU, GPU, memória e periféricos | + +A Unreal Engine já implementa grande parte da infraestrutura. O trabalho do desenvolvedor costuma concentrar-se nos sistemas de gameplay, conteúdo e integrações. + +### 1.1. O Game Loop + +Diferentemente de muitos sistemas web, os jogos executam um ciclo contínuo que atualiza a simulação e produz quadros na tela. + +Exemplos: + +**Um ciclo típico envolve:** + +1. Capturar entradas de teclado, mouse ou controle. +2. Atualizar estado e regras de gameplay. +3. Executar ou consultar a simulação física. +4. Produzir as informações necessárias para renderização. +5. Apresentar o quadro e continuar a execução. + +## 2. A arquitetura específica da Unreal Engine + +A Unreal utiliza um framework de gameplay orientado a objetos, com composição de componentes e classes que possuem ciclos de vida específicos. + +### Gameplay Framework + +Define classes-base para entidades, controladores, estado da sessão e representação do jogador. Inclui `Actor`, `Pawn`, `Character`, `GameMode`, `GameState` e `PlayerController`. + +### Blueprints + +Sistema visual de programação utilizado para criar comportamentos, protótipos, lógica de gameplay e integração com classes C++. + +### Levels e Assets + +Os níveis representam ambientes do jogo. Os assets incluem materiais, texturas, animações, Blueprints e outros conteúdos. + +Exemplos práticos: + +### Principais classes da Unreal + +| Classe | Responsabilidade | +| --- | --- | +| `UGameInstance` | Estado e serviços que persistem entre carregamentos de níveis | +| `AGameModeBase` | Define regras e configuração de uma sessão; no multiplayer, existe no servidor | +| `AGameStateBase` | Representa estado compartilhado da partida | +| `APlayerController` | Recebe e coordena comandos do jogador | +| `APawn` | Entidade controlável por jogador ou IA | +| `ACharacter` | Pawn especializado para personagens, com suporte a movimentação | +| `AActor` | Entidade que pode existir em um mundo | +| `UActorComponent` | Funcionalidade reutilizável associada a um Actor | + +[Fonte: gameplay framework in unreal engine](https://dev.epicgames.com/documentation/unreal-engine/gameplay-framework-in-unreal-engine?lang=pt-BR) + +Um exemplo simples: o jogador pressiona um botão, o `PlayerController` processa a entrada, o `Character` executa uma ação e um componente de saúde atualiza o estado do personagem. + +### Organização interna do código + +Uma organização por funcionalidade é adequada para um projeto de médio porte: + +```text +Source/ +└── GameEngineeringLab/ +├── GameEngineeringLab.Build.cs +├── Public/ +│ ├── Characters/ +│ ├── Combat/ +│ ├── Inventory/ +│ └── Systems/ +└── Private/ +├── Characters/ +├── Combat/ +├── Inventory/ +├── Systems/ +└── Tests/ +├── Unit/ +└── Integration/ +``` + +O papel de `Public` e `Private` está relacionado à exposição e implementação de código C++ dentro do sistema de módulos da Unreal. Não é necessário colocar todas as classes em `Public`: classes utilizadas apenas internamente podem permanecer em `Private`. + +Para projetos maiores, é possível criar módulos separados como `GameCore`, `GameRuntime` e `GameTests`, ou plugins próprios. + +Comparação com outros projetos de software, veja abaixo exemplos: + +| Aplicações tradicionais | Desenvolvimento de games | +| --- | --- | +| Entidades e modelos de domínio | Objetos de gameplay, Actors e componentes | +| Serviços e casos de uso | Sistemas de gameplay | +| Controladores de requisição | Controllers de jogador, em sentido diferente | +| Banco de dados | Estado persistido, SaveGame ou serviços externos | +| Interface web | HUD, widgets e menus | +| Processamento de eventos | Eventos, inputs e atualizações do mundo | +| Testes de integração | Testes entre sistemas de gameplay | +| Testes E2E | Simulação de fluxos completos no jogo | + +> A correspondência é conceitual, não uma equivalência de classes. Por exemplo, o PlayerController da Unreal não desempenha a mesma função de um controller HTTP em uma aplicação ASP.NET. + +## 3. Estrutura típica de um projeto de game + +Um projeto Unreal geralmente tem três grandes categorias de arquivos: código-fonte, assets e configuração. Outros diretórios são gerados automaticamente por compilação, cache e execução. + +A estrutura abaixo combina os diretórios oficiais da Unreal com uma organização modular que proponho para um projeto de estudo. + +A documentação oficial confirma que `Source/` contém código-fonte, `Content/` armazena assets e `Config/` define configurações. `Intermediate/` e `Saved/` contêm dados reconstruíveis, enquanto `Binaries/` guarda executáveis e outros artefatos compilados. + +[Fonte: Unreal Engine Directory and Structure](https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-directory-structure) + +A separação entre responsabilidades facilita a criação de testes, especialmente quando as regras de negócio do jogo não dependem diretamente de animações, renderização ou elementos visuais. + +[Automation Test Framework:](https://dev.epicgames.com/documentation/unreal-engine/automation-test-framework-in-unreal-engine) + +**No Unreal Editor 5.8:** + +1. Abra `Edit > Plugins` e procure a categoria Testing. +2. Habilite Functional Testing Editor para trabalhar com testes funcionais. +3. Reinicie o editor, caso solicitado. +4. Acesse `Tools > Test Automation`. +5. Selecione os testes disponíveis e execute com Start Tests. + +O framework de automação C++ **não exige que todos os plugins de teste estejam habilitados**. A ativação de plugins específicos depende do tipo de teste. + +## Como organizar uma arquitetura de jogos testável + +Para evoluir o laboratório, proponho uma separação entre regras de domínio, integração com a Unreal e apresentação. + +![image](images/arquitetura-proposta-game-enginee.svg) + +Essa separação permite utilizar testes de diferentes níveis sem duplicar responsabilidades. + +| Nível de teste | Exemplo | Dependência da engine | +| --- | --- | --- | +| Unitário | Cálculo de dano | Nenhuma ou mínima | +| Integração | HealthComponent + Character | Sim | +| Funcional | Personagem recebe dano em um mapa | Sim | +| E2E | Jogador inicia, interage e conclui objetivo | Sim, jogo em execução | +| Performance | Verificar tempo de quadro e consumo de recursos | Sim | + +Um detalhe importante: testes unitários de lógica pura e testes funcionais de gameplay não precisam utilizar o mesmo mecanismo de execução. A própria Epic distingue o Automation Framework dos Low-Level Tests, que são mais apropriados para isolamento de baixo nível. + +## Referencias + +As referências oficiais mais úteis para esse estudo são: + +- Unreal Engine — Gameplay Framework: fundamentos arquiteturais de Actors, Controllers e estados. +- Unreal Engine — Directory Structure: organização de projetos, módulos e arquivos. +- Unreal Engine — Automation Test Framework: estrutura e tipos de testes automatizados. +- Unreal Engine — Functional Testing: testes funcionais executados em Levels. +- Game Programming Patterns — Robert Nystrom: padrões como Game Loop, Component, Event Queue e State. Disponível em gameprogrammingpatterns.com. +- Game Engine Architecture — Jason Gregory: arquitetura interna de motores de jogos, subsistemas e gerenciamento de recursos. + +--- + +## Testando um jogo existente na Unreal: objetivos e portal no Stack O Bot + +Setting up test Environment - S.O Linux Omarchy (Arch Linux Config) | Unreal Engine + +Resolvi, refazer um dos testes que havia trabalhado a cerca de três/dois anos atrás (2023/2024) em um trabalho que era QA em Games (Simulador). + +Preparando meu setup para validações de um game pronto, da Epic Games, para o computador. Primeiro meu setup atual é o Omarchy Linux (based no arch linux - [página do S.O aqui](https://omarchy.org/)) fui verificar no GPT como estava as bibliotecas e drives (se tem suporte oficial da Unreal e afins) sem baixar drives sem updates ou maliciosos. Foi recomendado as seguinte dependências úteis. + +```bash +sudo pacman -S --needed \ + fuse2 \ + vulkan-tools \ + unzip \ + git \ + clang \ + cmake \ + ninja +``` + +Para verificar Vulkan: + +```bash +vulkaninfo --summary +``` + +### Retornos dos comandos + +![image](images/image.png) + +Como minha placa de vídeo é da NVIDIA precisei conferir os drives dela (NVIDIA geralmente é a que menos tem compatibilidade com o Linux) + +```bash +nvidia-smi +``` + +![image](images/image%201.png) + +- placa de vídeo com compatibilidade = ok + +Por recomendações instalei o Epic Games Launcher nativo [Download realizado por aqui](https://launcher.epicgames.com/) seguindo para a Intalação: Dar permissão para o install + +```bash +chmod +x EpicGamesLauncher*.AppImage +``` + +Fazer o Install: + +```bash +./EpicGamesLauncher*.AppImage + +# Extraia para uma pasta própria: +unzip Linux_Unreal_Engine*.zip \ + -d ~/Applications/UnrealEngine/UE_5.8 + +# go in +cd ~/Applications/UnrealEngine/UE_5.8 + +# error permission - run before +chmod +x Engine/Binaries/Linux/UnrealEditor + +# run +./Engine/Binaries/Linux/UnrealEditor +``` + +### Flow + +```text +Epic Games Launcher +↓ +Unreal Engine +↓ +Library +↓ +Engine Versions +↓ ++ +↓ +selecionar versão +↓ +Install +``` + +[Com base nos requisitos recomendados](https://dev.epicgames.com/documentation/unreal-engine/linux-development-requirements-for-unreal-engine?lang=pt-BR) + +Esta dentro do recomendado. + +![image](images/image%202.png) + +Omarchy setup + +![image](images/image%203.png) + +## Pesquisa de Jogo para Testes + +**Recomendação na pesquisa**: O Lyra é um projeto gratuito de referência que inclui código C++, Blueprints, personagens, armas, regras de gameplay, interface, recursos multiplayer e uma arquitetura modular. Ele é particularmente adequado para estudar Engenharia de Software aplicada a games, porque permite investigar os sistemas individualmente e testar suas integrações. + +Quais camadas você consegue testar no Lyra? + +| Camada de teste | Exemplos de cenários | +| --- | --- | +| Unidade | Cálculo de dano, atributos, cooldowns e validação de estados | +| Componente | Habilidades, inventário de armas e componentes de gameplay | +| Integração | Personagem + arma + sistema de habilidades | +| Funcional | Jogador atira, causa dano e elimina outro personagem | +| E2E | Iniciar jogo, entrar em partida, jogar e encerrar sessão | +| Multiplayer | Replicação de estado, sincronização e autoridade do servidor | +| Performance | FPS, frame time, consumo de memória e carregamento | +| Regressão | Validar mecânicas após alterações no código | + +Em particular este jogo bastante pontos que é possível validar, seguindo o tutorial para o Install do jogo segue. + +**Para instalar:** + +1. Abra a página do Lyra no Fab e faça login na conta Epic. +2. Selecione Add to My Library. +3. No Epic Games Launcher, acesse Unreal Engine → Library → Fab Library. +4. Localize Lyra Starter Game e selecione Create Project. +5. Selecione uma versão compatível com sua instalação da Unreal. + +Unreal Engine Open + +![image](images/image%204.png) + +Game adicionado a biblioteca + +![image](images/image%205.png) + +![image](images/image%206.png) + +Login conta Epic + +![image](images/image%207.png) + +Selecionar o game para abrir o projeto + +![image](images/image%208.png) + +Selecionando pasta do projeto para criar + +![image](images/image%209.png) + +Download + +![image](images/image%2010.png) + +![image](images/image%2011.png) + +--- + +### Erro ao baixar jogo Lyra + +Tentei realizar o download mas não foi possível. + +O log mostra que o link assinado já estava inválido quando o Launcher tentou usá-lo: + +- Em **2/11, às 12:16:27 (-03)**, a instalação chegou ao manifesto `Lyra_5.3` e recebeu **HTTP 410** cerca de **0,1 segundo** após iniciar a requisição. +- Às **12:20:12**, uma nova tentativa recebeu outro **410** em cerca de **0,04 segundo**, desta vez já no manifesto `Lyra_5.0`. +- Em **31/10**, houve falha semelhante, com **HTTP 403** e a mesma indicação de link assinado expirado. + +Isso torna improvável que o link tenha expirado **por causa da duração do download (ou algum problema de internet)**. O padrão sugere que o fluxo do Fab/Launcher estava entregando ou reutilizando links que **já estavam vencidos**. **Os logs não permitem determinar se a origem foi o serviço do Epic/Fab ou a renovação dos links no Launcher Linux.** O HTTP 410 indica que o recurso deixou de estar disponível; a documentação do Fab confirma que os produtos para Unreal Engine são baixados pela integração com o Fab/Launcher, mas não informa o prazo de validade desses links. + +[Link RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) + +[Documentação Fab](https://dev.epicgames.com/documentation/fab/purchasing-and-downloading-assets-in-fab) + +Para começar seu projeto agora, recomendo criar um projeto **Third Person** no Unreal 5.8. O template já vem com personagem jogável e nível básico, sem precisar baixar outro pacote do Fab. [A documentação da Epic explica como criar o projeto](https://dev.epicgames.com/documentation/unreal-engine/create-your-first-project-in-unreal-engine). + +Se você prefere um sample de jogo para baixar, a alternativa é **Stack O’ Bot**, que a Epic descreve como um projeto pequeno e ponto de partida para quem já conhece o básico. Ele também é distribuído pelo Fab, então pode encontrar a mesma falha de link no launcher. [Página oficial de samples da Epic](https://www.unrealengine.com/download). + +--- + +## Escolhendo outro jogo e Abrindo no Editor + +Escolhi este jogo mas também precisei organizar o projeto na pasta para que fique dentro Unreal Projects + +![alt text](images/image%2012.png) + +![alt text](images/image%2013.png) + +Clica no jogo para abrir e segue, pode adicionar o plugin de testes + +![alt text](images/image%2014.png) + +--- + +### References + +**Test Gameplay:** [https://dev.epicgames.com/community/learning/tutorials/DB1x/unreal-engine-gameplay](https://dev.epicgames.com/community/learning/tutorials/DB1x/unreal-engine-gameplay)