Antes de mergulhar no projeto de demonstração ScriptableObject e nesta série de mini-guias, lembre-se de que, em sua essência, os padrões de design são apenas ideias. Elas não se aplicam a todas as situações. Essas técnicas podem ajudá-lo a aprender novas maneiras de trabalhar com Unity e ScriptableObjects.

Cada padrão tem prós e contras. Escolha apenas os que beneficiam significativamente seu projeto específico. Seus designers dependem muito do Unity Editor? Um padrão baseado em ScriptableObject pode ser uma boa opção para ajudá-los a colaborar com seus desenvolvedores.

Em última análise, a melhor arquitetura de código é aquela que se adapta ao seu projeto e à sua equipe.

Os enums são uma maneira prática de gerenciar um conjunto fixo de valores nomeados em seu código. No entanto, eles têm algumas limitações. Como os valores de enum serializados são armazenados como inteiros em vez de seus nomes simbólicos, a remoção ou reordenação de um valor pode levar a um comportamento incorreto ou inesperado. Isso significa que as enums, especialmente quando você tem muitas delas, podem criar dores de cabeça no desenvolvimento do Unity.

A abordagem padrão

Esta é a aparência de um enum típico:

[System.Serializable]
public enum HandGestures
{
Rock,
Papel,
Tesouras
}

Você pode serializar um enum com o atributo System.Serializable e ele aparecerá no Inspetor.

O problema

Reordenar ou excluir um valor pode causar problemas. Como cada valor interno é um número inteiro, o que ele representa pode se tornar algo diferente. No exemplo dado, a exclusão do valor Paper faria com que Scissors assumisse o valor 1.

Ou, se adicionarmos um valor como no exemplo abaixo.

O valor do enum selecionado será alterado se vier depois da entrada excluída.

Isso pode causar problemas ao manter e atualizar projetos, especialmente quando o enum contém vários valores. Você pode atenuar esse problema deixando um elemento em branco ou não utilizado ou definindo explicitamente valores inteiros. Entretanto, nenhuma das soluções é ideal.

As enums baseadas em ScriptableObject oferecem a funcionalidade das enums tradicionais, mas são armazenadas como ativos individuais. Por exemplo, observe o PlayerIDSO ScriptableObject no projeto PaddleBallSO no exemplo abaixo.

Essencialmente, trata-se de um ScriptableObject em branco.

Você pode usar isso para criar vários ativos ScriptableObject no projeto, como P1, P2, etc. Mesmo quando eles não contêm dados, você pode usar ScriptableObjects para comparação. Basta criar um novo ativo ScriptableObject no projeto e dar um nome a ele.

Você pode criar quantas IDs de jogador precisar dentro do projeto e alternar facilmente entre elas. Basta alterar o ativo atribuído no script GameDataSO.

Se você estiver verificando a igualdade, isso funciona de forma semelhante a um enum. Duas variáveis se referem ao mesmo ScriptableObject? Se for o caso, eles são do mesmo tipo de item. Caso contrário, não são.

Mesmo sem nenhum dado extra, o ScriptableObject representa uma categoria ou um tipo de item.

No PaddleBallSO, o PlayerIDSO se torna uma designação de equipe. Usamos os ativos P1 e P2 no GameDataSO para diferenciar as duas pás.

O script GameSetup atribui a cada raquete uma ID de jogador. Durante o jogo, os scripts de raquete comparam a entrada do jogador com a ID da equipe designada.

Isso se aplica a qualquer tipo de jogo multijogador. Como alternativa, considere a possibilidade de adotá-las em qualquer outro lugar em que você utilize um enum.

Como são simplesmente atribuições no Inspector, os ScriptableObjects não estão sujeitos aos mesmos problemas de renomeação e reordenação.

Deseja alterar os nomes dos identificadores para "Player1" ou "Player2", respectivamente? Você pode fazer isso e tudo continuará funcionando. Como adicionar mais ScriptableObjects? Não há problema - a atribuição de ativos no Inspector permanece a mesma.

Esse comportamento é útil para criar jogabilidade. Na demonstração Patterns, clique no botão Switch Enum para mudar de equipe. Um MonoBehaviour no DemoBall atualiza o SpriteRenderer de acordo.

A bola causa danos a um bloco quando colide com ele? Descubra executando um teste rápido de igualdade. Veja uma maneira de compará-los no exemplo de código abaixo.

Esse método pode determinar se dois GameObjects estão na mesma equipe, o que é útil ao verificar interações entre amigos e inimigos. Essa comparação simples pode ser aplicada a coletas de itens, danos ou qualquer outra coisa que tenha uma "equipe" ou "alinhamento".

A parte divertida acontece quando você adiciona lógica aos seus ScriptableObjects. Diferentemente de um enum convencional, um ScriptableObject pode ter campos e métodos, além de conter dados.

Use-os para que cada ScriptableObject possa ter uma lógica de comparação especializada. Por exemplo, você pode ter um ScriptableObject que define efeitos especiais de dano (por exemplo, frio, calor, elétrico, mágico e assim por diante).

Se o seu aplicativo exigir um sistema de inventário para equipar itens de jogo, os ScriptableObjects poderão representar tipos de itens ou slots de armas. Certos personagens não podem ter certos itens? Alguns itens são mágicos ou têm habilidades especiais? Os enums baseados em ScriptableObject podem adicionar métodos para verificar isso.

O MonoBehaviour DemoBall do exemplo anterior inclui o método AreEqual para comparar ScriptableObjects. Ao estender o comportamento, você pode agrupar a lógica de comparação dentro do próprio ScriptableObject.

Na demonstração Patterns, você pode modificar a bola para que ela seja mais seletiva ao colidir com um objeto. Veja um item de uso geral para colisão no exemplo de código abaixo.

Isso poderia alcançar resultados semelhantes aos da demonstração atual, mas agora tem um campo m_Weakness. Isso permite que cada ScriptableObject defina outro ScriptableObject para destruir na colisão.

Em vez de chamar o método AreEqual, cada ScriptableObject simplesmente gerencia sua própria lógica de comparação.

O resultado é mais flexível e extensível. Em vez de fazer com que a bola destrua um bloco de uma equipe diferente, você pode ser específico. Várias bolas na cena podem destruir blocos diferentes, dependendo de seus CollisionItems individuais.

Isso prepara o cenário para interações diferentes e mais complexas. Se você quisesse criar um sistema de pedra-papel-tesoura, poderia definir três ScriptableObjects: Pedra, papel e tesoura. Cada um poderia ter seu próprio m_Weakness exclusivo e usar o método IsWinner para lidar com as interações.

Ao contrário das enums, os ScriptableObjects tornam esse processo modular e adaptável. Não há necessidade de contar com estruturas de dados adicionais ou adicionar lógica extra para sincronizar com um conjunto separado de dados. Basta adicionar um campo e/ou método extra para lidar com a lógica.

Depois de se familiarizar com as enums baseadas em ScriptableObject, você descobrirá que elas podem melhorar seu fluxo de trabalho, especialmente ao trabalhar com colegas de equipe. Como são ativos, atualizá-los gera menos conflitos de mesclagem, reduzindo o risco de perda de dados.

Adicionar novas enums baseadas em ScriptableObject é como criar outro ativo. Ao contrário dos enums tradicionais, a adição de novos valores não interromperá o código existente. Além disso, o Unity já tem ferramentas integradas para pesquisar, filtrar e organizá-los, assim como qualquer outro ativo.

Como bônus, o uso da interface de arrastar e soltar do Editor permite que os designers ampliem os dados de jogabilidade sem suporte adicional de um desenvolvedor de software. Você ainda precisará coordenar a configuração inicial dos campos, mas os designers poderão preencher esses campos com dados por conta própria.

Os enums baseados em ScriptableObject são mais um recurso que a sua equipe pode usar para melhorar a colaboração e a eficiência.

Leia mais sobre padrões de design com ScriptableObjects em nosso e-book técnico Crie uma arquitetura de jogo modular no Unity com ScriptableObjects. Você também pode saber mais sobre os padrões comuns de design de desenvolvimento do Unity em Eleve o nível de seu código com padrões de programação de jogos.