92 lines
4.4 KiB
Markdown
92 lines
4.4 KiB
Markdown
---
|
|
id: AGD-0047
|
|
ticket: hub-suspended-game-kill-affordance
|
|
title: Hub Suspended Game Kill Affordance
|
|
status: accepted
|
|
created: 2026-07-05
|
|
resolved:
|
|
decision:
|
|
tags: [hub, lifecycle, game, ui]
|
|
---
|
|
|
|
## Contexto
|
|
|
|
A troca entre cartridges agora mata a VM do jogo anterior quando outro jogo e carregado. Ainda assim, voltar para o Hub via Home/ESC pode deixar um jogo residente/suspenso, pronto para retomar pelo fluxo existente.
|
|
|
|
Hoje o Hub nao comunica esse estado de forma clara. O usuario pode estar no Hub sem saber que ha um jogo suspenso mantendo task, sessao de VM, estado de pausa/audio e possivelmente recursos associados. A proposta e exibir o nome do jogo suspenso no canto inferior direito, dentro de uma caixa vermelha, e permitir que um clique nessa caixa feche/mate esse jogo.
|
|
|
|
## Problema
|
|
|
|
Precisamos decidir se esse elemento e apenas um indicador visual ou tambem um controle destrutivo de lifecycle. Se ele mata o jogo, a acao precisa ter contrato explicito: qual entidade e encerrada, quais estados sao limpos, como o Hub atualiza a UI, e se ha confirmacao para evitar kill acidental.
|
|
|
|
## Pontos Criticos
|
|
|
|
- Fato: o jogo suspenso/residente e uma entidade de lifecycle, nao apenas uma linha visual no Hub.
|
|
- Fato: iniciar outro jogo ja mata a VM anterior; esta proposta adiciona um caminho manual para a mesma intencao sem carregar outro cartridge.
|
|
- Risco: um clique acidental em uma caixa vermelha pode perder progresso/estado sem aviso.
|
|
- Risco: matar somente a task sem limpar sessao/render/audio/assets deixaria estado residual parecido com os bugs recentes de troca de jogo.
|
|
- Tradeoff: confirmacao protege o usuario, mas adiciona friccao a um controle que parece operacional/debug.
|
|
- Hipotese: limitar o controle a jogos `Game` residentes/suspensos evita misturar shell/system apps no mesmo affordance.
|
|
|
|
## Opcoes
|
|
|
|
### Opcao A - Indicador com kill imediato
|
|
|
|
- **Abordagem:** mostrar uma caixa vermelha no canto inferior direito somente quando houver jogo residente/suspenso; um clique mata imediatamente esse jogo e remove o indicador.
|
|
- **Pro:** simples, rapido, combina com a proposta original.
|
|
- **Contra:** risco de perda acidental de estado.
|
|
- **Manutencao:** baixa complexidade, mas exige testes fortes de cleanup.
|
|
|
|
### Opcao B - Indicador com confirmacao em dois passos
|
|
|
|
- **Abordagem:** primeiro clique arma a acao ou muda o texto/estado visual; segundo clique confirma kill.
|
|
- **Pro:** reduz kill acidental sem exigir modal.
|
|
- **Contra:** mais estado no Hub e precisa de feedback visual claro.
|
|
- **Manutencao:** moderada; adiciona timeout/estado armado se quisermos evitar confirmacao persistente.
|
|
|
|
### Opcao C - Apenas indicador, sem kill
|
|
|
|
- **Abordagem:** mostrar o jogo suspenso, mas matar continua ocorrendo apenas ao carregar outro jogo ou por controles futuros.
|
|
- **Pro:** menor risco destrutivo.
|
|
- **Contra:** nao resolve a necessidade declarada de fechar/matar o jogo pelo Hub.
|
|
- **Manutencao:** baixa, mas provavelmente incompleta.
|
|
|
|
## Sugestao / Recomendacao
|
|
|
|
Seguir com a Opcao A se aceitarmos que o Hub atual e uma superficie operacional/dev e que a caixa vermelha comunica suficientemente a natureza destrutiva da acao. O contrato recomendado:
|
|
|
|
- aparece somente para jogo `Game` residente/suspenso;
|
|
- mostra somente o nome do jogo;
|
|
- fica no canto inferior direito;
|
|
- usa vermelho como indicativo de encerramento;
|
|
- clique mata a task/sessao residente e limpa o estado relacionado;
|
|
- apos o kill, o Hub permanece no Hub e o indicador desaparece.
|
|
|
|
Se a prioridade for evitar perda acidental de estado, promover para Opcao B antes da decision.
|
|
|
|
## Perguntas em Aberto
|
|
|
|
- [ ] O indicador deve aparecer somente para jogos `Game` residentes/suspensos?
|
|
- [ ] O clique vermelho deve matar imediatamente ou exigir confirmacao?
|
|
- [ ] O kill manual deve reutilizar exatamente o mesmo caminho de encerramento usado antes de carregar outro cartridge?
|
|
- [ ] O kill deve limpar assets/compositor imediatamente ou apenas task/session/render/audio?
|
|
- [ ] Deve haver evento/log explicito para "resident game killed from Hub"?
|
|
|
|
## Criterio para Encerrar
|
|
|
|
A agenda pode virar decision quando concordarmos em:
|
|
|
|
- quando o indicador aparece;
|
|
- qual texto e posicao minima ele usa;
|
|
- se a acao e imediata ou confirmada;
|
|
- qual contrato de cleanup o kill manual deve cumprir;
|
|
- quais testes provam que o jogo suspenso foi morto e nao pode ser retomado.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Responder as perguntas em aberto e entao aceitar a agenda para escrever a decision.
|