Estados no Bevy: coordenar transições pendentes, trabalho de entrada e limpeza

Instale um estado e separe suas funções

Na API do Bevy 0.20.0 citada, init_state instala os recursos de estado atual e de estado pendente e habilita os schedules de transição. O suporte a estados exige o StatesPlugin, incluído na coleção de plugins padrão. Use OnEnter para o trabalho de entrada, OnExit para o trabalho de saída e uma condição in_state para sistemas que devem rodar enquanto um estado está ativo. São contratos de execução distintos. [1]

Em um menu, a construção pertence à entrada e a interação pertence às atualizações contínuas. Colocar a construção em um sistema que roda continuamente pode recriar objetos, a menos que lógica adicional do projeto impeça isso.

Trate uma requisição como dado pendente

NextState enfileira o destino solicitado. Seu valor pode ser sobrescrito por outro sistema antes de as transições rodarem; não é uma fila de eventos que preserva cada requisição. Só importa o valor pendente no momento do schedule de transição. [2]

Por padrão, StateTransition roda antes de PreStartup e, depois, após PreUpdate a cada frame. Uma requisição feita mais tarde no frame, portanto, espera o ponto de transição seguinte, a menos que o projeto execute o schedule explicitamente em outro lugar. O código não deve presumir que solicitar um destino muda imediatamente o estado atual ou executa seus sistemas de entrada. [3]

Resolva um conflito concreto durante o carregamento

Imagine os estados definidos pelo projeto Menu, Loading e Playing. Selecionar uma fase solicita o carregamento. O estado de carregamento inicia o trabalho e aguarda que ele esteja pronto; só depois disso a lógica do projeto deve solicitar o jogo.

Agora suponha que a conclusão do carregamento e o cancelamento do jogador cheguem na mesma atualização. Escolha uma regra documentada do projeto, como dar precedência ao cancelamento, e deixe um único sistema de decisão escrever a requisição final. Caso contrário, vários sistemas escritores podem substituir o valor pendente uns dos outros sem expressar a política pretendida. Ao depurar esse caso, registre tanto a requisição quanto a transição aplicada. Este é um desenho ilustrativo, não a reprodução medida de uma condição de corrida. [2]

Dê aos objetos temporários um responsável pela saída

Mantenha os objetos do menu distinguíveis dos objetos persistentes, para que o trabalho de saída do menu remova apenas o que lhe pertence. Um menu projetado com 4 botões deve voltar a ter 4 botões ao retornar a ele. Revise o caminho de saída com o mesmo cuidado do caminho de entrada, incluindo o cancelamento durante o carregamento.

As condições de execução de estado decidem se sistemas selecionados rodam; por si sós, elas não descrevem todos os recursos e entidades que devem sobreviver a uma transição. Defina esse tempo de vida na lógica de configuração e de limpeza. Garanta que o trabalho de entrada inicial consiga obter suas dependências no ponto de transição de inicialização documentado. [1][3]

Escolha deliberadamente a semântica de requisições repetidas

O NextState::set referenciado executa os schedules de entrada e saída mesmo quando o destino é igual ao estado atual. Use NextState::set_if_different quando requisições redundantes para o mesmo estado devam pular esses schedules; a referência observa que um set explícito anterior para esse mesmo estado no mesmo frame ainda pode fazê-los rodar. [2]

Essa distinção importa se a entrada reinicia o progresso ou se a saída apaga objetos temporários. Revise a ativação repetida de um botão, o retorno ao menu e uma requisição para o mesmo estado. Adapte os nomes dos métodos e o comportamento à versão do Bevy do projeto; estas verificações propostas não foram executadas aqui.

Fontes

1. AppExtStates — Bevy contributors.
2. NextState — Bevy contributors.
3. StateTransition — Bevy contributors.