AETHERIA/AOW Lore & Design Portugues

Referencia DSL & Demo

Todas as 37 extensoes do CMS PortalViewer — renderizadas ao vivo com explicacoes detalhadas, conteudo realista e exemplos praticos de uso para autores de conteudo.

Diretivas de Bloco

Diretivas de bloco sao os blocos de construcao mais poderosos do DSL Markdown do CMS. Elas envolvem conteudo com :::name{attrs} no inicio e ::: no final, produzindo layouts complexos e estruturados. De texto em multiplas colunas a abas interativas e acordeoes recolhiveis — diretivas de bloco transformam Markdown simples em paginas de documentacao ricas e interativas.

Um total de 21 diretivas de bloco estao disponiveis. Cada diretiva tem um nome unico, atributos opcionais entre chaves e pode conter qualquer conteudo Markdown — incluindo outras diretivas, blocos de codigo, tabelas, matematica e imagens.

Diretivas de bloco sao analisadas pelo plugin remark-directive como diretivas de container e mapeadas para os componentes React correspondentes pelo CMSViewer atraves da funcao getDirectiveRenderer. O mapeamento e baseado no nome apos o prefixo :::.


Columns

O layout de colunas e um dos elementos mais frequentemente utilizados. Com :::columns{cols=N} e ::col como separador, o conteudo pode ser exibido lado a lado. As colunas sao totalmente responsivas — em dispositivos moveis sao automaticamente empilhadas verticalmente, no desktop exibidas lado a lado. Cada coluna pode conter qualquer conteudo Markdown: texto, blocos de codigo, imagens, listas, tabelas e ate diretivas aninhadas.

O atributo cols aceita valores de 2 a 4. O padrao e 2 colunas. O grid CSS subjacente distribui a largura disponivel uniformemente entre todas as colunas com um espacamento consistente de 1.5rem entre elas.

Arquitetura do Backend — O servidor e escrito em C++20 e utiliza EnTT como framework Entity-Component-System. Todos os estados do jogo sao mantidos em uma estrutura de dados plana e amigavel ao cache. Systems iteram sobre views que sao criadas sob demanda e sao extremamente eficientes.

void MovementSystem::tick(Registry& r, float dt) {
    for (auto [e, pos, vel] : r.view<Position, Velocity>().each()) {
        pos.x += vel.dx * dt;
        pos.y += vel.dy * dt;
        pos.z += vel.dz * dt;
    }
}

A separacao estrita de dados e logica permite processar milhoes de entidades por frame sem degradacao de performance. Cada system e stateless — nao ha variaveis membro, nenhuma dependencia oculta e nenhum efeito colateral entre systems.

Arquitetura do Frontend — O cliente utiliza TypeScript com React 18 e React-Three-Fiber para renderizacao 3D. O ECS do lado do cliente e baseado em becsy e mantem paridade com o backend: components compartilhados existem 1 em ambos os lados.

@system(s => s.after(NetworkInputSystem))
export class MovementSystem extends System {
    private readonly query = this.query(
        q => q.current.with(Position, Velocity).write
    );

    execute(): void {
        for (const entity of this.query.current) {
            const pos = entity.write(Position);
            const vel = entity.read(Velocity);
            pos.x += vel.dx * this.delta;
        }
    }
}

A comunicacao entre cliente e servidor utiliza WebRTC DataChannel — unreliable para atualizacoes de posicao de alta frequencia, reliable para eventos como mensagens de chat ou alteracoes de inventario.


Cards

Cards sao excelentes para visoes gerais de funcionalidades, descricoes de modulos ou resumos conceituais. Cada card tem um icone NerdFont e um titulo como cabecalho, seguido por uma breve descricao como texto do corpo. O atributo cols do container :::cards determina o numero de colunas (padrao: 3). Cards utilizam um layout estilo Compose com animacao de hover e destaque sutil de borda.

Uma entity e apenas um ID — um handle uint32_t leve sem dados ou comportamento proprio. Entities adquirem suas capacidades exclusivamente atraves da anexacao de components. Entity 0 e valida; UINT32_MAX e usado como valor nulo.

Components sao estruturas de dados puras: apenas campos, sem metodos, sem comportamento. Sao header-only (sem arquivo .cpp), usam exclusivamente inicializacao zero e nao contem arrays (padrao entity-per-item em vez disso).

Systems sao logica de processamento stateless: sem variaveis membro, views sao criadas sob demanda. Nunca comunicam diretamente entre si — o unico canal de comunicacao sao components no registry ECS.

O Hub e a camada central de dados para comunicacao entre modulos. Todos os modulos leem via hub::get() e escrevem via hub::set(). Nenhum modulo comunica diretamente com outro — tudo flui atraves do Hub.

O sistema de agendamento organiza 66 schedules em 21 tiers. Cada system e atribuido a um schedule e pode declarar dependencias de outros systems via .run_after("SystemName").

Plugins sao extensoes opcionais e carregaveis dinamicamente na Layer 4. Adicionam novos systems e components sem modificar o nucleo. Exemplos: ase-pl-sky (ceu), ase-pl-erosion (erosao), ase-pl-predator (IA).


Figure

Com :::figure imagens podem ser incorporadas com legendas e posicionamento opcional. O atributo align suporta left, right e center — com left e right a imagem e flutuada, permitindo que o texto ao redor flua ao lado dela. O atributo width aceita qualquer valor de comprimento CSS. A legenda e automaticamente extraida do ultimo elemento *italico* dentro do container.

Largura Total (Padrao)

Sem atributo width a figure utiliza toda a largura disponivel do container — ideal para banners, panoramas e imagens de fundo.

ASE Banner O banner oficial da Antares Simulation Engine — um mundo multiplayer persistente com bilhoes de entidades, simulacoes fisicas reais e suporte completo a terraformacao

Largura Reduzida (60%)

Com width="60%" a imagem e exibida centralizada com largura limitada — adequada para capturas de tela e fotos de detalhe.

Emotion Analysis Modulo de analise de emocoes — deteccao e simulacao de estados emocionais com IA para NPCs e criaturas no mundo do jogo

Flutuando a Esquerda

Com align="left" a imagem e flutuada a esquerda e o texto flui a sua direita. Ideal para ilustracoes inline dentro de paragrafos.

House Lake Propriedade a beira do lago — arquitetura gerada proceduralmente na beira d'agua

A simulacao de construcao no ASE permite que jogadores coloquem estruturas em qualquer ponto do mundo. Atraves do padrao entity-per-item, cada elemento de construcao — cada parede, cada janela, cada porta — e gerenciado como sua propria entidade. Isso permite interacoes fisicas precisas, destruicao seletiva e alteracoes dinamicas de iluminacao por elemento. Modificacoes de terreno sao salvas persistentemente e replicadas para todos os clientes conectados via Hub. A combinacao de terreno baseado em voxel e arquitetura baseada em entidades cria uma zona de transicao continua entre paisagem natural e estruturas construidas pelos jogadores.

Flutuando a Direita

Com align="right" o texto flui a esquerda da imagem. Util para visualizacoes complementares.

Horse Armor Armadura de cavalo — pecas de equipamento modulares como composicao de entidades

O sistema de equipamento no ASE segue estritamente o padrao entity-per-item: cada peca de armadura e sua propria entidade com referencia ao portador. Um cavalo com armadura completa consiste em dezenas de entidades vinculadas — elmo, peitoral, caneleiras, sela, redeas — que podem ser independentemente danificadas, reparadas ou substituidas. Tags controlam visibilidade e comportamento: EquippedTag, DamagedTag, EnchantedTag. Sem arrays, sem campos de contagem — composicao pura de entidades.

Mais Imagens de Projetos

Living Atlas Living Atlas — mapa mundial dinamico com visualizacao de biomas em tempo real e marcadores de jogadores

Pledge System Sistema de pledge — recompensas comunitarias e acompanhamento de progresso para apoiadores iniciais

Private Island Ilha privada — area exclusiva do jogador com gerenciamento proprio de chunks e direitos de terraformacao


Aside

A diretiva aside cria uma barra lateral estilizada para informacoes complementares, conhecimento de fundo ou fatos interessantes que nao devem interromper o fluxo do texto principal. O atributo opcional title aparece como titulo da caixa. Blocos aside tem uma borda esquerda sutil em PANEL_CYAN e um fundo levemente elevado.

A Antares Simulation Engine recebeu o nome da estrela mais brilhante na constelacao de Escorpiao — Antares, uma supergigante vermelha com 700 vezes o diametro do nosso Sol. O nome simboliza a visao ambiciosa do projeto: um mundo de simulacao onde cada folha, cada bacteria e cada gota de chuva existe como sua propria entidade. A meta e mais de um bilhao de entidades simultaneas com fisica em tempo real.

O primeiro prototipo foi criado no inicio de 2024 como um experimento ECS puro com EnTT. Em poucos meses o projeto cresceu para uma engine completa com arquitetura de 6 camadas, 66 schedules, comunicacao baseada em Hub, multiplayer WebRTC e um sistema CMS trilingue com 37 extensoes DSL.


Gallery

A diretiva gallery cria uma grade de imagens responsiva. Com o atributo flag lightbox (sem valor) um lightbox em tela cheia e ativado — clicar em uma imagem a abre como sobreposicao sobre toda a pagina com fundo escurecido. A navegacao entre imagens usa teclas de seta ou clique nas areas de avanco/retrocesso. O atributo cols determina o numero de colunas (padrao: 3).

Geracao de Terreno Dispersao Atmosferica Mundo Persistente


Author

A diretiva author cria um cartao de perfil profissional com imagem de avatar, nome e funcao. Ideal para paginas de documentacao, entradas de blog ou apresentacoes de equipe. O texto do corpo aparece como biografia abaixo do nome. Todos os tres atributos (name, avatar, role) sao renderizados como elementos UI separados.

Criador e arquiteto da Antares Simulation Engine. Responsavel por toda a arquitetura ECS, o sistema Hub para comunicacao entre modulos, o sistema de agendamento em tiers com 66 schedules e a arquitetura de 6 camadas com fronteiras de isolamento estritas. Areas de foco: design orientado a dados, iteracao otimizada para cache sobre milhoes de entidades, e a visao de um mundo persistente onde cada objeto — de rochas a bacterias — e sua propria entidade.


Accordion

Secoes recolhiveis com :::accordion como container e ::panel{title="..."} como marcador para cada painel. Apenas um painel fica aberto por vez — abrir um painel fecha automaticamente o anteriormente aberto. O titulo aparece como uma barra clicavel com icone de mais/menos. O conteudo se torna visivel apenas ao expandir e e menor que o texto do cabecalho para uma hierarquia visual clara.

Uma entity e a unidade mais fundamental no padrao ECS. Nao e nada mais que um ID numerico — um handle uint32_t sem dados, sem metodos e sem comportamento proprio. O significado de uma entity e determinado exclusivamente pelos components anexados a ela. Uma entity com PositionComponent e VelocityComponent se torna um objeto movel; com TerrainChunkComponent se torna uma peca de terreno. Essa simplicidade radical torna possivel gerenciar bilhoes de entities simultaneamente, pois elas nao geram nenhum overhead.

Importante: Entity 0 e uma entity valida! UINT32_MAX e usado como valor nulo (invalido), definido como InvalidEntityId nos arquivos types.hpp dos respectivos modulos.

Um component e uma estrutura de dados pura no padrao ECS. Components contem exclusivamente campos — sem metodos, sem construtores com logica, sem comportamento de qualquer tipo. Sao definidos header-only (sem arquivo .cpp) e usam exclusivamente inicializacao zero (= 0, = 0.0f, = false, = {}).

Components seguem regras estritas: sem arrays (padrao entity-per-item em vez disso), sem std::string (arrays fixos char[N] em vez disso), sem std::vector ou outros containers STL (ase-containers em vez disso). Cada component deve ser o menor e mais focado possivel — um unico campo por component e frequentemente otimo para performance de cache.

Um system e logica de processamento stateless no padrao ECS. Systems nao tem variaveis membro, nenhum estado oculto e nenhum efeito colateral entre chamadas. Criam views sob demanda com registry.view<A, B>() e iteram sobre todas as entities que possuem os components solicitados.

A regra de ouro: systems NUNCA comunicam diretamente entre si. O unico canal de comunicacao sao components. System A escreve resultados em um component; System B le esses resultados no proximo tick. A ordem de execucao e controlada via schedules e declaracoes .run_after(), nao via chamadas diretas.

O Hub e a camada central de dados para comunicacao entre modulos. Em vez de modulos acessarem uns aos outros diretamente (o que violaria as fronteiras de isolamento), todos os modulos leem e escrevem atraves do Hub: hub::get() para leitura e hub::set() para escrita.

O Hub e baseado em um armazenamento chave-valor com acesso type-safe. Chaves sao definidas como hashes uint32_t (via entt::hashed_string), valores podem ser tipos primitivos ou estruturas serializadas. O sistema de broadcast do Hub (HubNetBctReqSystem + HubNetBctSndSystem) replica automaticamente alteracoes do Hub pela rede para todos os clientes conectados.

O sistema de schedule do ASE organiza a ordem de execucao de todos os systems em 66 schedules distribuidos em 21 tiers. Cada tier tem uma posicao fixa no pipeline de execucao — de Initialization (Tier 0) passando por Dynamics (Tier 9) ate Replication (Tier 16) e Cleanup (Tier 20).

Systems sao atribuidos a um schedule em seu modulo e podem declarar dependencias: .run_after("OtherSystem") garante que um system executa somente apos o system nomeado ter executado. Este metodo de agendamento declarativo substitui a ordem de chamada imperativa dos game loops tradicionais e permite paralelizacao automatica de systems independentes.


Tabs

Abas sao ideais para comparacoes de plataformas, variantes de linguagem ou implementacoes alternativas do mesmo conceito. Cada aba tem um atributo label que e exibido como texto da aba. Apenas a aba selecionada mostra seu conteudo. Abas podem conter qualquer conteudo Markdown, incluindo blocos de codigo, tabelas e diretivas aninhadas.

O sistema de abas usa internamente um padrao de agrupamento similar ao accordion: ::tab{label="..."} e uma diretiva leaf cujo conteudo seguinte e automaticamente atribuido a respectiva aba.

// Component: estrutura de dados pura, header-only
struct TerrainChunkComponent {
    float height_map[64 * 64] = {};  // Mapa de altura 64x64
    uint32_t chunk_x = 0;            // Posicao do chunk X
    uint32_t chunk_z = 0;            // Posicao do chunk Z
    bool dirty = false;               // Flag de alteracao
};

// System: logica stateless
class TerrainMutSystem : public ecs::System {
public:
    const char* name() const override { return "TerrainMutSystem"; }

    void tick(Registry& registry, float dt) override {
        auto view = registry.view<TerrainChunkComponent, TerrainMutReqComponent>();
        for (auto [entity, chunk, req] : view.each()) {
            apply_heightmap_mutation(chunk, req);
            chunk.dirty = true;
            registry.remove<TerrainMutReqComponent>(entity);
        }
    }
};

O backend usa EnTT como framework ECS. Components sao structs POD (Plain Old Data) com inicializacao zero. Systems herdam de ecs::System e sobrescrevem o metodo tick(). Views sao criadas sob demanda e sao extremamente amigaveis ao cache.

// Component: declaracao becsy com decoradores @field
@component
export class TerrainChunkComponent {
    @field.float32 declare heightMap: Float32Array;
    @field.uint32 declare chunkX: number;
    @field.uint32 declare chunkZ: number;
    @field.boolean declare dirty: boolean;
}

// System: system becsy com queries como membros de classe
@system(s => s
    .after(TerrainNetworkInputSystem)
    .inAnyOrderWithWritersOf(TerrainChunkComponent)
)
export class TerrainRenderSyncSystem extends System {
    private readonly dirtyChunks = this.query(
        q => q.current.with(TerrainChunkComponent).write
            .addedOrChanged
    );

    execute(): void {
        for (const entity of this.dirtyChunks.current) {
            const chunk = entity.write(TerrainChunkComponent);
            if (chunk.dirty) {
                this.updateMesh(chunk);
                chunk.dirty = false;
            }
        }
    }
}

O cliente usa becsy como framework ECS. Components sao declarados com decoradores @component e @field. A palavra-chave declare e obrigatoria. Queries sao definidas como membros de classe, nao em metodos. A declaracao de agendamento e feita no decorador @system().

// Modulos escrevem no Hub (ase-pl-sky)
void SkyCalcSystem::tick(Registry& r, float dt) {
    auto view = r.view<SkyManagerTag, SkyStatComponent>();
    for (auto [e, stat] : view.each()) {
        // Escrever resultados no Hub
        hub::set("sky.sun_altitude", stat.sun_altitude);
        hub::set("sky.brightness", stat.zenith_brightness);
        hub::set("sky.temperature", stat.color_temperature);
    }
}

// Outros modulos leem do Hub (ase-terrain)
void TerrainLightSystem::tick(Registry& r, float dt) {
    float sun_alt = hub::get<float>("sky.sun_altitude");
    float brightness = hub::get<float>("sky.brightness");
    // Iluminacao do terreno baseada em dados do ceu
    auto view = r.view<TerrainChunkComponent, TerrainLightComponent>();
    for (auto [e, chunk, light] : view.each()) {
        light.ambient = calculate_ambient(sun_alt, brightness);
    }
}

O Hub e o unico canal de comunicacao permitido entre modulos. Nenhum modulo importa ou referencia outro diretamente. hub::set() escreve valores, hub::get<T>() os le com seguranca de tipo. O HubNetBctReqSystem serializa automaticamente alteracoes para replicacao de rede.

{
    "module": "ase-terrain",
    "layer": 3,
    "dependencies": ["ase-ecs", "ase-math", "ase-hub"],
    "systems": [
        {
            "name": "TerrainChkSystem",
            "schedule": "Dynamics",
            "tier": 9,
            "reads": ["TerrainChunkComponent"],
            "writes": ["TerrainChkResultComponent"]
        },
        {
            "name": "TerrainMutSystem",
            "schedule": "Dynamics",
            "tier": 9,
            "run_after": "TerrainChkSystem",
            "reads": ["TerrainMutReqComponent"],
            "writes": ["TerrainChunkComponent"]
        }
    ],
    "hub_outputs": [
        "terrain.chunk_count",
        "terrain.active_mutations",
        "terrain.loaded_area"
    ]
}

A configuracao do modulo define pertencimento a camada, dependencias, systems com seus schedules e declaracoes de I/O do Hub. Esses metadados sao usados pelo sistema de codegen para gerar automaticamente codigo TypeScript do cliente, serializacao de rede e sistemas de broadcast.


Timeline

A diretiva timeline cria uma linha do tempo vertical com datas, icones e textos descritivos. Cada ::event tem um atributo date (texto de formato livre) e um atributo opcional icon (nome de icone NerdFont). Os eventos sao visualmente conectados por uma linha vertical e exibidos na ordem de sua definicao.

Inicio do Projeto — Os primeiros prototipos ECS sao criados com EnTT e C++20. Decisoes arquiteturais fundamentais sao tomadas: design orientado a dados, separacao estrita de camadas, components como dados puros sem comportamento. A primeira entity completa seu primeiro tick.

Camada de Persistencia — Integracao de MongoDB para armazenamento de chunks e Neo4j Aura para grafos de cena e hierarquias de inventario. Todas as entities ativas vivem em RAM; bancos de dados servem exclusivamente para persistencia, nao para consultas em tempo real.

Integracao Multiplayer — WebRTC DataChannel permite comunicacao peer-to-peer em tempo real no navegador. Dois modos de canal: unreliable para atualizacoes de posicao de alta frequencia (perda de pacotes aceitavel), reliable para eventos como chat, inventario e terraformacao.

Arquitetura Hub — Introducao do sistema Hub como camada central de dados. Toda comunicacao entre modulos flui atraves do Hub. Nenhum modulo importa outro diretamente. O HubNetBctReqSystem e HubNetBctSndSystem replicam alteracoes automaticamente pela rede.

Sistema de Schedule — Implementacao do sistema de agendamento em tiers com 66 schedules em 21 tiers. De Initialization (Tier 0) passando por Dynamics (Tier 9) ate Cleanup (Tier 20). Dependencias declarativas via .run_after() substituem ordens de chamada imperativas.

CMS PortalViewer — O visualizador CMS trilingue com 37 extensoes DSL entra no ar. Cards estilo Compose, acordeoes interativos, abas, linhas do tempo, diagramas Mermaid, matematica KaTeX e icones NerdFont — tudo gerado a partir de Markdown simples.


Quote

Citacao estilizada com atribuicao de autor. A diretiva :::quote cria uma caixa de citacao visualmente proeminente com uma grande aspas esquerda, o texto da citacao e uma linha de autor com nome e funcao. Ideal para lemas, principios de design ou declaracoes impactantes.

Tudo e entity, component ou system. Sem excecoes. Separacao estrita de dados e logica — essa e a regra de ouro. Se voce se pergunta se algo deve ser um component ou um system: se armazena dados, e um component. Se processa dados, e um system. Nao ha um terceiro caminho.


Stats

Grandes blocos numericos para metricas e KPIs impressionantes. Cada ::stat tem um value (o numero grande), um label (descricao), um icon (NerdFont) e uma color (da paleta PANEL_*). O grid se adapta via atributo cols. Stats sao excelentes para visoes gerais estilo dashboard no topo de uma pagina.


Steps

Sequencias de passos numerados com numeracao automatica. Ideal para tutoriais, guias de instalacao ou fluxos de trabalho. Cada ::step{title="..."} marca o inicio de um novo passo — o conteudo seguinte e exibido como descricao do passo. A numeracao acontece automaticamente e segue a ordem de definicao.

Certifique-se de que as seguintes ferramentas estao instaladas: CMake 3.24+, um compilador compativel com C++20 (GCC 12+, Clang 15+ ou MSVC 19.30+), Node.js 18+ e npm 9+. Em sistemas Linux, os pacotes de desenvolvimento para OpenSSL e zlib sao adicionalmente necessarios.

git clone git@github.com:antarien/ase.git && cd ase

O repositorio usa submodulos Git para separar nucleo, modulos, plugins, cliente e documentacao. Apos clonar, os submodulos devem ser inicializados: git submodule update --init --recursive.

cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build --parallel

O processo de compilacao compila todos os modulos, plugins e o servidor de jogo. A primeira compilacao leva mais tempo pois dependencias (EnTT, spdlog, nlohmann/json) sao automaticamente baixadas e compiladas. Compilacoes subsequentes sao incrementais e significativamente mais rapidas.

cd clients/ase-client-web && npm install && npm run dev

O servidor de desenvolvimento inicia em http://localhost:5173 com Hot-Module-Replacement. Alteracoes em componentes React sao imediatamente refletidas no navegador sem necessidade de recarregamento.

./build/bin/ase-server-game --http-port 8080

O servidor escuta na porta 8080 para requisicoes HTTP API e inicia automaticamente sinalizacao WebRTC para conexoes multiplayer. Use --log +DBG +TIM para logging detalhado durante o desenvolvimento.

Abra http://localhost:5173 no navegador. O cliente se conecta automaticamente ao servidor local. Pressione para o console do navegador e para um hard refresh se o comportamento do cliente estiver inesperado.


Compare

Comparacao lado a lado de duas opcoes. O atributo flag highlight destaca a opcao preferida com uma borda cyan. Ideal para decisoes arquiteturais, comparacoes de tecnologia ou contraposicoes pro/contra. Cada ::option contem uma lista com icones NerdFont para avaliacao visual.

  • Iteracao amigavel ao cache sobre blocos de memoria contiguos
  • Design orientado a dados sem hierarquias de heranca
  • Entidades composiveis atraves de montagem dinamica de components
  • Systems stateless permitem testes faceis e paralelizacao
  • Bilhoes de entidades sem degradacao de performance
  • Plugins carregaveis dinamicamente sem reiniciar a engine
  • Acessos a memoria desfavoraveis ao cache por indirecao de ponteiros
  • Hierarquias de heranca profundas com acoplamento fragil de classe base
  • Acoplamento forte entre objetos atraves de referencias diretas
  • Estado oculto em instancias de objetos dificulta depuracao
  • Problemas de escalabilidade alem de milhares de objetos
  • Arquitetura monolitica dificulta extensoes

Team

Cartoes de membros da equipe com avatar, nome e funcao. O atributo cols do container :::team determina o numero de colunas (padrao: 4). Atributo opcional link para perfis externos.


Changelog

Bloco de versao com rotulos coloridos para diferentes tipos de alteracao. O atributo version mostra o numero da versao, date a data de lancamento. No corpo, alteracoes sao listadas como itens — itens com Added recebem cor verde, Fixed laranja e Changed cyan. Essa coloracao acontece automaticamente com base no texto de prefixo em negrito.

  • Added CMS PortalViewer com 37 extensoes DSL para paginas de documentacao ricas
  • Added Cards interativos estilo Compose com layout de grid e animacoes de hover
  • Added Campo estelar parallax na navegacao Constellation
  • Added Arquitetura de broadcast baseada em Hub para replicacao de rede
  • Fixed Renderizacao de badges para uso inline de multiplos badges em uma linha
  • Fixed Agrupamento de paineis de accordion com atribuicao de conteudo
  • Fixed Secao de rodape para paginas de documentacao longas
  • Changed Migracao SSOT de cores — todas as cores CMS do colors.ts central
  • Changed Sistema de schedule expandido para 66 schedules em 21 tiers

Matrix

Tabela de comparacao estruturada com colunas e linhas nomeadas. Cabecalhos de coluna sao definidos via atributo cols como lista separada por virgulas. Cada ::row tem atributos nomeados correspondentes as colunas (minusculas). Valores comecando com nf- sao automaticamente renderizados como icones NerdFont — ideal para indicadores de status.


Terminal

Bloco de terminal com fundo escuro e linhas de comando verdes. Linhas comecando com $ sao destacadas como comandos de entrada com cor de prompt verde. Todas as outras linhas sao exibidas como saida do programa em cinza claro. O atributo title aparece como barra de janela acima do conteudo do terminal.

cdbuildcd build ./bin/ase-server-game --http-port 8080 --log +DBG +TIM +TICK -BCT [ASE] [SERVER] Initializing 6-layer architecture... [ASE] [SERVER] Layer 0: ase-math, ase-types, ase-utils loaded [ASE] [SERVER] Layer 1: ase-ecs, ase-log, ase-hub loaded [ASE] [SERVER] Layer 2: ase-kernel initialized [ASE] [SERVER] Layer 3: 8 modules registered [ASE] [SERVER] Layer 4: 3 plugins hot-loaded [ASE] [SERVER] 66 schedules registered across 21 tiers [ASE] [SERVER] Hub store initialized with 2,048 keys [ASE] [SERVER] WebRTC signaling ready on port 8081 [ASE] [SERVER] Listening on http://0.0.0.0:8080 [ASE] [SERVER] 1,000,000 entities loaded from MongoDB curlshttp://localhost:8080/api/healthpythonmjson.tool"status":"ok","version":"0.16.32","entities":1000000,"schedules":66,"tiers":21,"uptimeseconds":42curl -s http://localhost:8080/api/health | python -m json.tool { "status": "ok", "version": "0.16.32", "entities": 1000000, "schedules": 66, "tiers": 21, "uptime_seconds": 42 } curl -s http://localhost:8080/api/player/spawn -X POST -d '{"name":"TestPlayer"}' | python -m json.tool { "entity_id": 1000001, "position": {"x": 0.0, "y": 64.0, "z": 0.0}, "chunk": {"x": 0, "z": 0} }


Code (Estilo Arquivo)

Bloco de codigo com aba de nome de arquivo estilo VS Code no topo. Ideal para exibir arquivos de codigo-fonte com contexto. O atributo file mostra o nome do arquivo como rotulo da aba, lang determina o destaque de sintaxe. Difere dos blocos de codigo cercados regulares pelo cabecalho visual com nome do arquivo.

#pragma once #include

/// Runtime state for terrain chunk layer data. /// Written by TerrainChkSystem, read by TerrainMutSystem. struct TerrainStChkLyrComponent { float base_height = 0.0f; // Terrain base elevation (meters) float moisture = 0.0f; // Soil moisture [0..1] float temperature = 0.0f; // Surface temperature (Kelvin) uint32_t biome_hash = 0; // Biome identifier (hashed string) uint8_t erosion_level = 0; // Erosion state [0..255] bool needs_recalc = false; // Dirty flag for dependent systems };


Callout (Personalizado)

Caixa de callout personalizada para casos em que os quatro callouts padrao (INFO, WARNING, TIP, NOTE) nao sao suficientes. A cor e escolhida da paleta PANEL_*, o icone e qualquer icone NerdFont. Ideal para funcionalidades experimentais, avisos de descontinuacao ou categorias especiais.

As funcoes descritas nesta secao estao em desenvolvimento ativo. Assinaturas de API, chaves Hub e estruturas de components podem mudar entre versoes menores sem aviso previo. Uso em producao e recomendado apenas a partir da versao 1.0.0. Feedback e relatorios de bugs sao bem-vindos em github.com/antarien/ase/issues.


Diretivas Leaf

Diretivas leaf ficam como linhas unicas com ::name{attrs} e produzem elementos UI autonomos sem conteudo envolvido. Diferente das diretivas de bloco, nao tem ::: de fechamento e nenhum texto de corpo. Sao tratadas como elementos de nivel de bloco pelo parser Markdown (linha propria necessaria), mas tambem podem ser usadas inline atraves do pre-processamento de badges.

Um total de 10 diretivas leaf estao disponiveis — de badges coloridos a barras de progresso, incorporacoes de video e botoes de download.


Badge

Rotulos inline coloridos com design angular. Multiplos badges em uma linha sao exibidos lado a lado. As cores disponiveis correspondem a paleta PANEL_*: cyan, green, orange, purple, red, yellow. Badges sao adequados para indicadores de status, numeros de versao, categorias ou tags.

::badge{text="Estavel" color="green"} ::badge{text="00.16.32" color="cyan"} ::badge{text="Alpha" color="orange"} ::badge{text="Beta" color="purple"} ::badge{text="Novo" color="red"} ::badge{text="Planejado" color="yellow"}


Divider

Um separador horizontal com gradiente sutil — mais sutil que o separador Markdown padrao (---) e visualmente melhor integrado ao design do CMS. Nenhum atributo necessario.


Spacer

Espaco vertical com altura configuravel. O atributo h especifica a altura em rem (padrao: 2). Util para espacamento visual entre secoes onde um --- seria muito proeminente.

Texto antes do spacer — este paragrafo fica diretamente acima do elemento spacer e serve como referencia para a distancia visual.

Texto apos o spacer — 3rem de espacamento separa este paragrafo do anterior. O spacer em si e invisivel e cria puro espaco vertical.


Progress

Barras de progresso horizontais com exibicao de porcentagem. Cada barra tem um value (valor atual), max (maximo), label (descricao) e color (cor PANEL_*). Ideal para progresso de projeto, conclusao de funcionalidades ou utilizacao do sistema.


Video

Incorporacao de video com suporte para YouTube, Vimeo (baseado em iframe) e arquivos MP4 locais (video HTML5). Para videos locais os atributos autoplay, muted e loop podem ser definidos como flags. O atributo title aparece como rotulo abaixo do video.


Audio

Player de audio HTML5 com titulo e atribuicao de artista. O atributo src aponta para o arquivo de audio, title e artist aparecem como rotulos. O player de audio nativo do navegador fornece play/pause, volume e linha do tempo.


Embed

iFrame sandboxed para incorporacao de sites externos. O atributo height determina a altura em pixels (padrao: 400), title aparece como barra de janela acima do iFrame. Atributos de sandbox restringem as permissoes do conteudo incorporado ao minimo.


Download

Botao de download estilizado com icone, rotulo e tamanho de arquivo. O atributo file aponta para o arquivo a ser baixado, label e o texto do botao, icon um icone NerdFont (padrao: nf-fa-download) e size o tamanho de arquivo exibido.


Preview

Cartao de pre-visualizacao de link que exibe o hostname e a URL de um link externo em uma visualizacao de cartao compacta. Util para referencias externas importantes que devem ser visualmente destacadas.


Kbd

Atalhos de teclado em estilo key cap. O atributo keys aceita teclas individuais ou combinacoes com + como separador. Cada tecla e renderizada como um grafico individual de key cap com efeito 3D elevado. Elementos Kbd tambem podem ser usados inline no texto corrido.

Atalhos de teclado importantes: Pressione para a paleta de comandos, para um hard refresh, para ferramentas de desenvolvedor, para salvar ou , , para alternar entre ingles, alemao e portugues.


Extensoes Inline

Extensoes inline sao usadas diretamente no texto corrido — nao requerem sua propria linha e produzem elementos de texto vinculados, destacados ou dinamicos dentro de paragrafos. Sao processadas por quatro plugins remark especializados: remark-wiki-link, remark-glossary, remark-inline-ext e remark-auto-glossary.

Um total de 6 extensoes inline estao disponiveis. Elas estendem o Markdown padrao com vinculacao semantica, tooltips de termos tecnicos, icones, referencias cruzadas e valores dinamicos.


Wiki Links

Vinculacao interna com [[caminho|texto de exibicao]]. Links sao resolvidos contra a navegacao CMS (cms-tree.json) e exibidos como links de texto roxos com sublinhado pontilhado e icone wiki. A forma simples [[Titulo da Pagina]] busca o titulo na navegacao; a forma estendida [[caminho|Texto]] vincula explicitamente a um caminho.

Veja [[feat/ecs|Arquitetura ECS]] para detalhes sobre o Entity-Component-System, [[feat/net|Rede Multiplayer]] para a camada de transporte com WebRTC DataChannel, ou a [[index|Pagina Principal]] para uma visao geral completa de todo o conteudo CMS disponivel.


Glossario

Referencia de termos tecnicos com {{Termo}}. Ao passar o mouse sobre um termo do glossario, uma definicao tooltip aparece, carregada do arquivo glossary.json. A exibicao usa texto sublinhado com linha pontilhada. O plugin remark-auto-glossary adicionalmente escaneia todo o texto e marca automaticamente termos conhecidos — {{}} explicitos tem precedencia.

A arquitetura {{ECS}} da Antares Engine e baseada no principio de separacao estrita de dados. Todos os modulos comunicam via {{Hub}} — a camada central de dados que expoe hub::get() e hub::set() como sua unica API. O transporte multiplayer usa {{WebRTC}} DataChannel para comunicacao peer-to-peer de baixa latencia diretamente no navegador.


Icones Inline

Insercao explicita de icones com :icon{name="nf-fa-rocket"} em qualquer posicao no texto corrido. Icones vem da biblioteca NerdFont e sao renderizados no tamanho atual do texto. Todos os icones da colecao Font Awesome dentro do NerdFont estao disponiveis.

Inicio e inicializacao Configuracao e setup Validacao bem-sucedida Nova funcionalidade disponivel Otimizacao de performance Aviso observado Problema conhecido Trabalhos de manutencao


Referencias Cruzadas

Referencia estruturada com :ref{path="caminho" anchor="ancora" text="Texto"}. Referencias cruzadas produzem links cyan com um icone de seta como prefixo. Sao adequadas para referencias precisas a secoes especificas de outras paginas CMS. As tres formas: :ref{path="caminho"} (apenas pagina), :ref{path="caminho" anchor="ancora"} (pagina + secao) e :ref{path="caminho" anchor="ancora" text="texto de exibicao"} (com texto personalizado).

Veja para a referencia completa dos 66 schedules em 21 tiers, ou para detalhes sobre a camada de transporte baseada em WebRTC.


Versao

Placeholder de versao dinamico com {version}. Substituido automaticamente durante a renderizacao pelo valor version do frontmatter YAML da pagina atual. Ideal para paginas de documentacao que precisam referenciar seu proprio numero de versao sem mante-lo manualmente em multiplos lugares.

Esta pagina documenta a versao {version} da referencia DSL. Cada vez que o valor do frontmatter e atualizado, o placeholder e automaticamente atualizado — nenhuma operacao manual de busca e substituicao necessaria.


Tooltip

Tooltip de hover com :tip[texto de exibicao]{content="conteudo do tooltip"}. O texto de exibicao e mostrado com sublinhado pontilhado; ao passar o mouse, um tooltip posicionado aparece com o conteudo especificado. Ideal para abreviacoes, termos tecnicos ou explicacoes contextuais que nao devem interromper o fluxo de leitura.

A Antares Simulation Engine e uma simulacao de sobrevivencia de proxima geracao. Ela utiliza um design orientado a dados para simular bilhoes de entidades em tempo real.


Elementos Universais

Esses elementos funcionam em ambos os visualizadores — o DocViewer para documentacao tecnica e o CMS PortalViewer para o site publico. Sao baseados na sintaxe Markdown padrao (CommonMark) com poucas extensoes e nao requerem diretivas DSL.

Elementos universais sao processados por plugins remark/rehype padrao (remark-gfm, remark-math, rehype-katex) e funcionam identicamente em ambos os visualizadores. Diretivas DSL, por outro lado, sao renderizadas apenas no CMS PortalViewer — no DocViewer aparecem como texto bruto.


Matematica

Renderizacao matematica baseada em KaTeX em dois modos: matematica inline com sinais de dolar simples para formulas no texto corrido, e matematica display com sinais de dolar duplos para equacoes centralizadas e destacadas.

Exemplos inline: A posicao p\vec{p} de uma entidade muda com a velocidade v\vec{v} ao longo do intervalo de tempo Δt\Delta t. O angulo de dispersao θ\theta da refracao atmosferica e medido em radianos\text{radianos} e determina a cor do ceu ao por do sol. A temperatura TT em Kelvin afeta a temperatura de cor da luz solar simulada com T5778KT \approx 5778\,\text{K} para o Sol real.

Equacoes display:

Integracao de Verlet para calculo de posicao:

p(t+Δt)=p(t)+v(t)Δt+12a(t)Δt2\vec{p}(t + \Delta t) = \vec{p}(t) + \vec{v}(t) \cdot \Delta t + \frac{1}{2} \vec{a}(t) \cdot \Delta t^2

Dispersao de Rayleigh para calculo de cor atmosferica:

I(λ,θ)=I0π2(n21)22Nλ4(1+cos2θ)I(\lambda, \theta) = I_0 \cdot \frac{\pi^2 (n^2 - 1)^2}{2 N \lambda^4} \cdot (1 + \cos^2 \theta)

Formulas fundamentais de fisica usadas na engine:

E=mc2F=maF=kxPV=nRTE = mc^2 \qquad F = ma \qquad \vec{F} = -k\vec{x} \qquad PV = nRT


Blocos de Codigo

Blocos de codigo com destaque de sintaxe e tags de linguagem. Linguagens suportadas: cpp, typescript, bash, cmake, json, yaml, diff, markdown, python, mermaid, ase-math, svgbob. O destaque e realizado via react-syntax-highlighter com um tema escuro personalizado.

// ECS Golden Rule: Components = DATA ONLY
struct WeatherComponent {
    float temperature = 293.15f;    // Kelvin (20°C default)
    float humidity = 0.5f;          // Relative humidity [0..1]
    float wind_speed = 0.0f;        // Meters per second
    float wind_direction = 0.0f;    // Radians (0 = North)
    float precipitation = 0.0f;     // mm/hour
    float cloud_cover = 0.0f;       // Cloud density [0..1]
    uint32_t owner_id = UINT32_MAX; // Chunk entity reference
};

// ECS Golden Rule: Systems = STATELESS LOGIC
class WeatherCalcSystem : public ecs::System {
public:
    const char* name() const override { return "WeatherCalcSystem"; }

    void tick(Registry& registry, float dt) override {
        auto view = registry.view<WeatherComponent, TerrainChunkComponent>();
        for (auto [entity, weather, terrain] : view.each()) {
            // Temperature decreases with altitude
            weather.temperature = base_temp - (terrain.base_height * lapse_rate);
            // Humidity affects precipitation threshold
            if (weather.humidity > 0.85f && weather.cloud_cover > 0.7f) {
                weather.precipitation = calculate_rainfall(weather, dt);
            }
            // Wind simulation via hub constants
            float wind_base = hub::get<float>("weather.wind_base_speed");
            weather.wind_speed = wind_base * terrain_wind_factor(terrain);
        }
    }
};
// becsy Client ECS — Shared Component with Backend parity
@component
export class WeatherComponent {
    @field.float32 declare temperature: number;
    @field.float32 declare humidity: number;
    @field.float32 declare windSpeed: number;
    @field.float32 declare windDirection: number;
    @field.float32 declare precipitation: number;
    @field.float32 declare cloudCover: number;
    @field.uint32 declare ownerId: number;
}

// Client-only render sync system
@system(s => s
    .after(WeatherNetworkInputSystem)
    .inAnyOrderWithWritersOf(WeatherComponent)
)
export class WeatherRenderSyncSystem extends System {
    private readonly weatherQuery = this.query(
        q => q.current.with(WeatherComponent).read
    );

    execute(): void {
        for (const entity of this.weatherQuery.current) {
            const w = entity.read(WeatherComponent);
            this.updateSkyUniforms(w.temperature, w.cloudCover);
            this.updateRainParticles(w.precipitation, w.windDirection);
        }
    }
}

Caixas de Callout

Quatro tipos de callout padrao com diferentes cores e icones para diferentes categorias de informacao. Cada pagina deve conter pelo menos 3 callouts (1 WARNING + 2 outros).

A Antares Simulation Engine usa uma arquitetura estrita de 6 camadas na qual cada camada so pode depender de camadas abaixo dela. Dependencias ascendentes sao arquiteturalmente proibidas e aplicadas atraves de verificacoes do sistema de build. Esse isolamento permite que camadas individuais sejam desenvolvidas, testadas e substituidas independentemente.

Systems NUNCA devem comunicar diretamente entre si — os unicos canais de comunicacao permitidos sao components no registry ECS e valores Hub para comunicacao entre modulos. Chamadas diretas system-a-system, referencias armazenadas a outros systems e padroes singleton sao violacoes arquiteturais que levam a acoplamento forte, dependencias ocultas e comportamento nao-deterministico.

Crie views EnTT sob demanda com registry.view<A, B>(). Views sao extremamente baratas — sao essencialmente iteradores sobre os sparse sets internos. Armazenar views em variaveis membro nao e apenas desnecessario, mas esconde estado em um system que deve ser stateless. Cada chamada view() e O(1) e amigavel ao cache.

Entity 0 e uma entity valida no EnTT! Este e um erro comum: desenvolvedores usam 0 como "nenhuma entity", fazendo com que Entity 0 seja incorretamente tratada como invalida. O valor nulo correto e UINT32_MAX, definido como InvalidEntityId nos arquivos types.hpp dos respectivos modulos. Sempre verifique com entity != InvalidEntityId em vez de entity != 0.


Diagrama Mermaid

Diagramas Mermaid sao gerados diretamente de blocos de codigo Markdown com a tag de linguagem mermaid. Tipos suportados: flowchart, sequenceDiagram, gantt, graph, stateDiagram-v2. Recomendacao maxima: 20 nos por diagrama.

graph LR
    subgraph "Layer 3: Modulos"
        A[SkyCalcSystem] -->|hub::set| H
        B[TerrainMutSystem] -->|hub::set| H
        C[WeatherCalcSystem] -->|hub::set| H
    end

    subgraph "Layer 1: Hub"
        H[Hub Store] -->|hub::get| A
        H -->|hub::get| B
        H -->|hub::get| C
        H -->|serialize| R
    end

    subgraph "Layer 5: Rede"
        R[HubNetBctReqSystem] --> S[HubNetBctSndSystem]
        S --> W[WebRTC DataChannel]
    end

    W --> CL[Client Hub Store]

Tabelas

Tabelas Markdown padrao com linha de cabecalho e linha separadora. Colunas podem ser alinhadas a esquerda ou direita. Tabelas sao renderizadas responsivamente com rolagem horizontal em viewports estreitos.

Camada Nome Modulos/Plugins Dependencia Responsabilidade
0 Fundamento ase-math, ase-types, ase-utils Nenhuma Matematica pura e definicoes de tipo
1 Nucleo ase-ecs, ase-log, ase-hub, ase-neo4j, ase-mongodb Camada 0 Framework ECS, logging, bancos de dados
2 Kernel ase-kernel Camada 0-1 Game loop, carregador de modulos, scheduler
3 Modulos ase-terrain, ase-network, ase-player, ase-camera Camada 0-2 Systems especificos de dominio
4 Plugins ase-pl-sky, ase-pl-erosion, ase-pl-predator Camada 0-3 Extensoes opcionais, carregaveis dinamicamente
5 Servidor/Clientes ase-server-game, ase-client-web Camada 0-4 Executaveis, orquestracao

Listas

Listas nao ordenadas com icones NerdFont para categorizacao visual:

Listas ordenadas para fluxos sequenciais:

  1. Verificar pre-requisitos (CMake, compilador, Node.js)
  2. Clonar repositorio e inicializar submodulos
  3. Configurar e compilar backend C++
  4. Instalar dependencias do cliente web
  5. Iniciar servidor de desenvolvimento
  6. Iniciar servidor de jogo e conectar
  7. Executar testes e verificar resultados

Caixas Diff

Listas de alteracoes anotadas com destaque colorido. Linhas com + sao exibidas em verde (adicionado), - em vermelho (removido) e -> em azul (informacao).

+ Added: CMS PortalViewer com 37 extensoes DSL
+ Added: Cards interativos estilo Compose com animacoes de hover
+ Added: Arquitetura de broadcast baseada em Hub (ARCH_ASE_HUB_UNI_BCT)
+ Added: Agendamento em tiers com 66 schedules em 21 tiers
+ Added: CMS trilingue (alemao, ingles, portugues)
- Removed: Documentacao HTML estatica
- Removed: Valores de cor hardcoded em componentes CMS
- Removed: Comunicacao direta system-a-system
- Removed: Components baseados em array (entity-per-item em vez disso)
-> Info: Migracao para colors.ts SSOT concluida
-> Info: Toda comunicacao entre modulos flui atraves do Hub
-> Info: Renderizacao de badges agora suporta uso inline

::badge{text="00.16.32" color="cyan"} ::badge{text="Demo DSL" color="purple"} ::badge{text="37 Extensoes" color="green"} ::badge{text="Portugues" color="orange"}