Conduta - Manifesto de

Padrões de Nomenclatura e Organização Namespaces Espelhados: O namespace deve refletir estritamente a estrutura de pastas do projeto. Exemplo: Um script em

Manifesto de Desenvolvimento Técnico - Projeto Conduta

Para o projeto Conduta é necessário levar em conta os seguintes pontos:

1. Padrões de Nomenclatura e Organização

Namespaces Espelhados: O namespace deve refletir estritamente a estrutura de pastas do projeto.
- Exemplo: Um script em Assets/Scripts/Core/Network deve ter o namespace Core.Network.
Inglês Técnico: Todo o código (nomes de variáveis, classes, métodos e docs) será escrito em inglês.

2. Documentação e Comentários

Clean Code First: O código deve ser autoexplicativo.
Sem Poluição: É estritamente proibido o uso de comentários de linha para controle de versão ou notas temporárias (ex: //alterado aqui, //teste).
Documentação Funcional: Desde a primeira versão, métodos e classes devem conter XML Summaries (///
) e campos serializados devem conter o atributo [Tooltip].
Comentários Explicativos: Comentários profundos sobre a lógica interna serão adicionados apenas na fase de finalização (“bater o martelo”).

3. Arquitetura Data-Driven e Híbrida

Scriptable Objects (SO) como Fonte da Verdade Local: A base de dados do jogo (balanceamento, definições de papéis, configurações) residirá em Scriptable Objects.
Sincronização com Cloud Save: A arquitetura deve prever que valores nos Scriptable Objects possam ser sobrescritos ou populados por dados vindos do Unity Cloud Save. Isso permitirá Live Ops e balanceamento remoto sem necessidade de atualização do client.
Separação de Dados e Lógica: Scripts não devem conter “hardcoded values”; eles devem consumir dados dos SOs.

4. Internacionalização (Localization)

Zero Strings Soltas: Nenhum texto de UI ou mensagem de sistema deve ser escrito diretamente no código (“hardcoded strings”).
Unity Localization Package: Todo texto deve ser referenciado via String Tables e Asset Tables do pacote de Localization da Unity.

5. Princípios de Engenharia (SOLID)

Single Responsibility Principle (SRP): Cada classe deve ter uma única responsabilidade.
Anti-God Script: É proibida a criação de classes monolíticas (ex: um GameManager que controla UI, Rede, Áudio e Turnos ao mesmo tempo).
Refatoração Contínua: Ao notar que um script está acumulando muitas funções, ele deve ser imediatamente refatorado e dividido em subcomponentes, criando novas pastas e namespaces se necessário.

6. Interface do Usuário (UI)

UI Toolkit: Todo o desenvolvimento de interface utilizará o framework UI Toolkit (UXML e USS).
Desacoplamento: A lógica da UI deve ser separada da lógica de simulação do jogo (View vs Model/Controller). O Canvas legado (UGUI) não será utilizado para nada além de testes.

Conduta Design Document