feat(sprite): HumanSprite com WASD/clique e câmera seguindo

[roxdavirox]

Summary

• Cria HumanSprite com movimento WASD + setas + clique no mapa
• Câmera segue o jogador com lerp suave (0.1)
• Colisão com layers walls e furniture
• Emite posição via EventBus com debounce de 100ms
• Integrado no OfficeScene com spawn no lobby

Test plan

• 9 testes unitários cobrindo criação, input, câmera, debounce e colisão
• 159 testes totais passando
• Typecheck limpo
• Teste manual: WASD move sprite, clique move sprite, câmera acompanha

Closes #94

[github-actions]

🤖 AI Code Review

A PR implementa corretamente o HumanSprite com movimento WASD/teclado e clique, câmera seguindo e debounce de emissãomais apresenta alguns pontos de atenção: possível race condition no tween de clique, uso de magic numbers, e falta de cleanup adequado do listener de pointerdown.

Pontos de Review

🐛 race condition entre click movement e input keyboard
Em handleInput (linhas 113-116), o clickTween é parado quando há input do teclado, mas a velocidade-setada por scene.physics.moveTo (linha 90) não é resetada. Isso pode causar movimento indesejado após cancelar clique com WASD.

🐛 memory leak no listener de pointerdown
O listener de pointerdown registrado em setup (linha 63) nunca é removido. Quando a cena faz shutdown, o listener permanece ativo. Deve-se store a função e remover em destroy(): scene.input.off('pointerdown', handler)

🐛 colisao com walls pode interrumpir clique sem stopar tween
Quando há colisão com walls/furniture durante moveToPoint, o sprite para fisicamente mas o tween continua até o destino. O collider callback deveria stopar o clickTween para consistência visual.

⚠️ magic numbers sem constantes nomeadas
SPEED=80, EMIT_INTERVAL_MS=100, dist<4 (threshold clique) estão hardcoded. Mesmo existindo constantes no topo, valores como 0.1 (lerp), 12x12 (hitbox), offset(2,4), depth(20) e tint(0x3b82f6) deveriam ser documentados ou extraídos para constantes.

⚠️ cursors pode ser undefined em handleInput
handleInput verifica 'if (!this.cursors) return' (linha 99), mas o Typescript não garante que a propriedade foi inicializada no construtor se scene.input.keyboard for falsy. Recomendado: adicionar null assertion ou validar no construtor com throw.

💡 extrair direcao para getter computado
directionFrom é chamado múltiplas vezes (moveToPoint, handleInput). Considerar getter this.direction que computa baseado em velocity atual, ou cachear durante o frame para evitar cálculos repetidos.

💡 adicionar destroy method com cleanup
HumanSprite não sobrescreve destroy() para fazer cleanup (remover listener de pointer, stopar tweens). Isso pode causar memory leaks se sprites forem recriados dinamicamente.

✅ debounce implementado corretamente
O debounce de 100ms verifica tanto tempo desde último emit quanto mudança de posição (lastEmittedX/Y), evitando emissões desnecessárias quando o sprite está parado ou não mudou de célula.

✅ normalizacao de velocidade diagonal
O código corretamente normaliza a velocidade diagonal (linhas 125-128) para evitar que movimento em diagonal seja ~41% mais rápido que movimento ortogonal.

✅ testes unitarios cobrindo casos principais
Os 9 testes cobrem criação, input, câmera, debounce e colisão. Boa cobertura de edge cases como emit apenas quando posição muda e suppression de emit dentro do intervalo de debounce.

---

Review automático via OpenCode (opencode)