Devlog #4 · Interesse e visibilidade

Saber quem está perto é só metade do problema. A outra metade é: quem precisa saber de quem?

Numa área cheia de Aelara — uma cidade, um spot de monstros, um evento — o servidor não pode mandar os detalhes de cada entidade para cada jogador. O volume de dados destruiria qualquer conexão. Precisava existir uma camada que decidisse, com precisão, o que cada jogador precisa receber.

Campo de visão derivado do espaço

O interest system não mantém listas gigantes de "quem observa quem". A relação é derivada da posição: se algo está dentro da área relevante de um jogador, entra no interesse; se sai, perde prioridade ou vira dado agregado.

Relações "pinadas" — alvo atual, membros de party, conexões de combate — ficam materializadas, mas com limites claros. O sistema sabe o que priorizar quando há muita informação competindo pelo mesmo canal.

Prioridade sob pressão

Quando o campo de visão está lotado, o servidor não manda tudo com a mesma prioridade. Entidades mais próximas ou em combate ativo têm fila preferencial. Entidades distantes ou inativas podem ser agregadas ou atrasadas sem impacto perceptível para o jogador.

Isso é o que permite que cidades cheias e batalhas em massa existam sem transformar a rede em caos.

Bench / validação
— Iterar observadores de uma entidade: p50 100 ns
— Recalcular interesse ao cruzar célula: p50 700 ns
— Reorganização de interesse em escala: p50 460 µs
— Modelo sem listas brutas de "todo mundo observando todo mundo"
— Relações pinadas com limite definido por tipo

Próximo: replicação — transformar mudanças do mundo em pacotes para os clientes.