ScriptableObjects no Unity: definições compartilhadas e estado individual em tempo de execução

Comece pela propriedade dos dados

A definição de uma arma e uma arma que um personagem segura neste momento são tipos de dados diferentes. Confundi-las pode fazer com que a alteração da munição de um personagem afete todos os personagens que usam o mesmo asset. Antes de escolher um contêiner no Unity, decida se um valor pertence a uma definição reutilizável, a uma instância criada em tempo de execução ou a um perfil de jogador salvo. Dê a cada categoria um responsável identificável.

O que um asset compartilha

Um ScriptableObject pode guardar dados independentemente dos componentes da cena. Vários objetos podem referenciar o mesmo asset e, assim, compartilhar seus valores em vez de manter cópias separadas. Isso é útil para configurações criadas por designers, mas não torna o objeto referenciado imutável. O manual do Unity 6.0 descreve esse papel de compartilhamento de dados. [1]

Construa uma fronteira deliberada

Mantenha os valores definidos pelos designers atrás de uma interface voltada à leitura e inicialize o estado de cada instância separadamente. Uma classe comum, usada em tempo de execução, costuma bastar para munição, temporizadores de recarga e dano acumulado. Se um objeto em tempo de execução precisar especificamente da identidade de um ScriptableObject, CreateInstance cria uma nova instância, enquanto Object.Instantiate clona um objeto existente. [2][3] Decida qual caminho se encaixa nas suas regras de inicialização, em vez de tratar os dois como formas intercambiáveis de carregar um asset.

Exemplo: dois lançadores de sinalizadores

Imagine uma definição de sinalizador com capacidade de 4, tempo de recarga de 2 segundos e uma referência a um projétil. Dois lançadores instanciados leem essa mesma definição. Cada lançador começa com seu próprio valor de munição, 4, e seu próprio temporizador de recarga. Quando o lançador A dispara, a munição dele passa a 3; o lançador B continua em 4. Uma alteração de balanceamento no tempo de recarga compartilhado pode afetar os dois lançadores de propósito, na próxima vez que lerem a configuração. Esse exemplo distingue leituras ao vivo da configuração de valores copiados na criação da instância: escolha uma política para cada campo e documente-a. Salve o identificador da definição do lançador e o estado que muda, e depois reconstrua o objeto por um caminho de carregamento explícito.

Limites e verificações

Um clone não garante que todos os assets referenciados passaram a ter dono próprio. Revise as referências aninhadas antes de permitir escrita no conteúdo delas. Defina quem destrói os objetos temporários do Unity e quem redefine o estado entre sessões de jogo. Trate o salvamento como um recurso separado da aplicação: editar um objeto em memória não é um formato de salvamento durável. Um teste útil cria duas instâncias, altera apenas uma e verifica o estado de ambas e também o da definição original. Repita o teste depois de recarregar a cena e depois de uma nova inicialização da aplicação, para revelar dependências acidentais do estado do Editor.

Fontes

1. ScriptableObject data assets — Unity Technologies.
2. ScriptableObject.CreateInstance — Unity Technologies.
3. Object.Instantiate — Unity Technologies.