ScriptableObject é uma classe Unity serializável que permite armazenar grandes quantidades de dados compartilhados independentes das instâncias de script. O uso de ScriptableObjects facilita o gerenciamento de alterações e depuração. Você pode criar um nível de comunicação flexível entre os diferentes sistemas em seu jogo, para que, no geral, seja mais viável alterá-los e adaptá-los durante a produção, bem como reutilizar componentes.

Use design modular:

• Evite criar sistemas que dependam diretamente uns dos outros. Por exemplo, um sistema de inventário deve ser capaz de se comunicar com outros sistemas de seu jogo, mas não é recomendável criar uma referência rígida entre eles, pois isso dificulta a recomposição de sistemas em diferentes configurações e relações.
• Crie cenas como telas limpas: evite a existência de dados transientes entre as cenas. Toda vez que uma cena for alcançada, deve ocorrer quebra e carregamento limpos. Isso permite que você tenha cenas com comportamento exclusivo não presente em outras cenas, sem precisar recorrer a hacks.
• Configure os Prefabs para que funcionem por conta própria. Sempre que possível, cada prefab incluído em uma cena deve ter a respectiva funcionalidade contida nele. Isso ajuda muito no controle de código-fonte em equipes maiores, em que as cenas são uma lista de prefabs e os prefabs contêm a respectiva funcionalidade. Assim, a maioria das verificações ocorrem no nível do prefab, o que resulta em menos conflitos na cena.
• Concentre cada componente na resolução de um único problema. Isso facilita a união de vários componentes para criar algo.

Facilite a alteração e a edição de partes:

• Torne o máximo possível de seu jogo orientado a dados. Ao projetar os sistemas de jogo para se comportarem como máquinas que processam dados na forma de instruções, você pode fazer alterações no jogo de maneira eficiente, mesmo em execução.
• Se os sistemas forem configurados para ser o mais modulares e baseados em componentes possível, isso facilita a edição deles, inclusive para artistas e designers. Se os designers puderem unir coisas no jogo sem a necessidade de solicitar um recurso explícito — em grande parte graças à implementação de componentes minúsculos com funções individuais e específicas — poderão combinar tais componentes de maneiras diferentes para encontrar nova jogabilidade/mecânica, Ryan diz que alguns dos recursos mais interessantes que sua equipe trabalhou dentro dos jogos são consequências desse processo, que ele chama de "design emergente".
• É crucial que sua equipe possa fazer alterações no tempo de execução do jogo. Quanto mais você puder alterar o jogo no tempo de execução, mais encontrará equilíbrio e valores e, se puder salvar o estado do tempo de execução,como os ScriptableObjects fazem, estará em uma ótima posição.

Facilite a depuração:

Esse é, na verdade, um subpilar dos dois primeiros. Quanto mais modular o seu jogo for, mais fácil será testar qualquer parte dele. Quanto mais editável o seu jogo for — quanto mais recursos dele tiverem suas próprias visualizações de Inspector — mais fácil será a depuração. Certifique-se de que consiga visualizar o estado de depuração no Inspector e nunca considere um recurso completo até ter algum plano sobre como vai depurá-lo.

Uma das coisas mais simples que você pode criar com ScriptableObjects é uma variável autônoma baseada em assets. Veja abaixo um exemplo para uma FloatVariable, mas isso também vale para qualquer outro tipo serializável.

Qualquer pessoa da equipe, independentemente do nível técnico, pode definir uma nova variável de jogo criando um asset FloatVariable. Qualquer MonoBehaviour ou ScriptableObject pode usar uma FloatVariable pública em vez de um public float para fazer referência a esse novo valor compartilhado.

Ainda melhor, se um MonoBehaviour alterar o Value de uma FloatVariable, outros MonoBehaviours poderão ver essa alteração. Isso cria uma camada de mensagens entre sistemas que não precisam de referências entre si.

Um exemplo de caso de uso para isso são os pontos de vida (HP) de um jogador. Em um jogo com um único jogador local, o HP do jogador pode ser uma FloatVariable chamada PlayerHP. Quando o jogador recebe dano, este é subtraído de PlayerHP, e quanto o jogador se cura, adiciona a PlayerHP.

Agora, imagine um Prefab de barra de vida na cena. A barra de vida monitora a variável PlayerHP para atualizar a exibição. Sem qualquer alteração de código, ela pode apontar facilmente para algo diferente, como uma variável PlayerMP. A barra de vida não sabe nada sobre o jogador na cena, ela apenas faz a leitura da mesma variável na qual o jogador grava.

Uma vez configurado assim, é fácil adicionar mais coisas para assistir ao PlayerHP. O sistema de música pode mudar conforme o PlayerHP fica baixo, os inimigos podem mudar seus padrões de ataque quando sabem que o jogador está fraco, os efeitos de espaço na tela podem enfatizar o perigo do próximo ataque e assim por diante. O importante aqui é que o script Player não envia mensagens para esses sistemas e esses sistemas não precisam conhecer o GameObject do jogador. Você também pode acessar o Inspector com o jogo em execução e alterar o valor de PlayerHP para realizar testes.

Ao editar o Value de uma FloatVariable, pode ser uma boa ideia copiar os dados para um valor de tempo de execução a fim de não alterar o valor armazenado em disco para o ScriptableObject. Se fizer isso, os MonoBehaviours deverão acessar RuntimeValue para impedir a edição do InitialValue salvo no disco.

Um dos recursos favoritos de Ryan para desenvolver com base em ScriptableObjects é um sistema de eventos. Arquiteturas de eventos ajuda a modularizar o código ao enviar mensagens entre sistemas que não necessariamente precisam se conhecer. Elas permitem que as coisas respondam a uma alteração no estado sem monitoramento constante em um ciclo de atualização.

Os exemplos de código a seguir foram obtidos deum sistema de eventos que consiste em duas partes: um GameEvent ScriptableObject e um GameEventListener MonoBehaviour. Os designers podem criar qualquer quantidade de GameEvents no projeto para representar mensagens importantes que podem ser enviadas. Um GameEventListener aguarda até um GameEvent específico ser gerado e responde invocando um UnityEvent (que não é um evento de fato, está mais para uma chamada de função serializada).

GameEvent ScriptableObject:

GameEventListener:

Um exemplo disso é o tratamento da morte do jogador em um jogo. Esse é um ponto em que grande parte da execução pode mudar, mas pode ser difícil determinar onde programar toda a lógica. O script Player deve acionar a Game Over UI ou uma alteração na música? Os inimigos devem verificar se o jogador está vivo em cada quadro? Um sistema de eventos permite que você evite dependências problemáticas como essas.

Quando o jogador morre, o script Player chama Raise no evento OnPlayerDied. O script Player não precisa saber quais sistemas se importam com isso, já que é apenas uma transmissão. A Game Over UI está escutando o evento OnPlayerDied e inicia a animação, um script de câmera pode aguardar isso e iniciar o escurecimento e um sistema de música pode responder com uma alteração na música. Cada inimigo pode estar aguardando OnPlayerDied também, acionando uma animação de insulto ou uma alteração de estado a fim de voltar para um comportamento ocioso.

Esse padrão facilita muito a adição de novas respostas à morte do jogador. Além disso, é fácil testar a resposta à morte do jogador chamando Raise no evento por meio de algum código de teste ou um botão no Inspector.

O sistema de eventos desenvolvido na Schell Games se expandiu para algo muito mais complexo e possui recursos que permitem a passagem de dados e a geração automática de tipos. Esse exemplo foi, essencialmente, o ponto de partida para o que usam hoje.

ScriptableObjects não precisam ser apenas dados. Considere qualquer sistema implementado em um MonoBehaviour e veja se você consegue mover a implementação para um ScriptableObject. Em vez de ter um InventoryManager em um DontDestroyOnLoad MonoBehaviour, experimente colocá-lo em um ScriptableObject.

Como não está vinculado à cena, não possui um Transform e não recebe as funções Update, mas manterá o estado entre carregamentos de cenas sem qualquer inicialização especial. Em vez de um singleton, use uma referência público ao seu objeto de sistema de inventário quando precisar de um script para acessar o inventário. Isso facilita a troca de um inventário de testes ou um inventário de tutoriais em relação ao uso de um singleton.

Aqui você pode imaginar um script Player recebendo uma referência ao sistema do inventário. Quando o jogador surge, pode solicitar ao inventário todos os objetos possuídos e gerar qualquer equipamento. A IU de equipamentos também pode fazer referência ao inventário e navegar pelos itens para determinar o que deve ser sacado.