Dependência de códigos é um problema comum em muitos projetos, mas muitas vezes imperceptíveis!
Pois, esse é um problema indireto e maquiado por um jogo que em teoria funciona normalmente.
Mas, que se torna perceptível ao tentarmos expandir ou implementar novos recursos em nossos jogos.
Dependência de Códigos: Como identificar?
Este fenômeno ocorre quando os desenvolvedores amaram seu jogo em um conjunto específico de códigos.
Por exemplo: é comum muitos desenvolvedores começarem a criar seus jogos codificando a partir do player.
E bom isso não é um problema em si, mas conforme o desenvolvimento avança, ele vai anexando funcionalidades no Player.
E quando menos se da conta, o Game Over, troca de fases, controle de volume, enfim tudo está atrelado ao jogador.
Porém, tudo funciona perfeito e o desenvolvedor acredita ter um feito um bom trabalho, e o jogo lançado faz sucesso.
E se depara com a necessidade de adicionar novas mecânicas, criar expansões do jogo, e enfim aqui o problema aparece.
Pois, a depender da implementação, como o sistema do jogo está todo atrelado ao player, pode inviabilizar essas implementações.
Por exemplo, não conseguir adicionar um segundo jogador, por que se o primeiro for deletado da cena o jogo bugaria.
E muitas vezes depois, de lançado, uma alteração exigiria a recodificação do jogo do zero.
Forager: um caso real!
Forager é um caso real de um jogo indie que não conseguiu implementar melhorias por conta desse problema.
Pois, era o seu primeiro jogo e o próprio desenvolvedor disse que ainda estava aprendendo quando criou o game.
Porém, seu jogo se tornou uma febre e alcançou milhares de pessoas, criando até mesmo uma comunidade.
E que pediam demais a implementação de um modo Multiplayer para conseguirem jogar com seus amigos.
Porém, o desenvolvedor encontrou dificuldades para implementar o Multplayer pro conta de um código muito dependente.
E mesmo buscando diversas equipes especializadas, não obtiveram sucesso, pois, a base de jogo estava mal codificada.
E as únicas soluções seriam refazer o jogo do zero, ou, deixar para um próximo projeto.
Por fim anunciaram que o multplayer sairia apenas em um próximo jogo, e resultou em uma insatisfação da comunidade.
Como evitar esse problema?
Não existe outra forma a não ser estudar as melhores práticas e sempre aprimorar seus conhecimentos.
E a primeira dica é sempre criar funcionalidades independentes e correspondentes a sua função.
Por exemplo, scripts referentes ao player ficam nele, para menus crie outras classes e GameObjects.
Ou seja, cada mecânica precisa ter sua classe correspondente, e ficar em um objeto criado para isso!
Pois, você pode administrar as trocas de informações entre objetos de inúmeras formas mais coerentes.
Crie gerenciadores de sons, gerenciadores de level, gerenciadores de dano, ou seja, cada sistema precisa ser independente.
E principalmente evite erros de programação, entenda as melhores funções as erem usadas, etc.
E não existe nada melhor do que aprender desde o começo as melhores práticas, e para te ajudar criamos o curso Start Gamedev.
Que é um curso onde você sai do zero e aprende as melhores práticas usadas na criação dos jogos!
Tire todas as suas dúvidas sobre o curso clicando aqui neste texto!
Ou assista a esse video review completo do curso!
E para te ajudar separamos logo abaixo uma live completíssima sobre os erros que você precisa evitar!
Seja o primeiro a comentar.