A maioria dos mecanismos e estruturas decentes fornece a funcionalidade de que você precisa e nunca entra no seu caminho.
Eles? Isso depende exatamente do que você está fazendo, graficamente falando.
Para muitos tipos de jogos, há respostas padrão para perguntas gráficas. O jogo 2D médio, por exemplo, pode ser bem tratado com as proezas 2D de, por exemplo, XNA / MonoGame. São apenas sprites, que podem vir em lotes para terrenos, podem ser girados e assim por diante.
Mas e se o seu jogo costumava ser um jogo 2D médio, você lê sobre alguma técnica interessante, como usar um mapa de altura para criar um impostor que tenha a aparência de profundidade em relação à tela. E você quer fazer isso.
Agora você está empregando mapeamento normal e, possivelmente, mapeamento de paralaxe. Tudo no mesmo contexto de "renderizar sprites", mas exigindo mais do que muitos motores 2D puros podem suportar. Especificamente, ele exige "sprite blitting" com várias estruturas, o que não é algo que muitos mecanismos 2D possam fazer.
O que você faz se seu mecanismo não puder se adaptar a você? Isso significa que você precisa fazer várias passagens, uma para a cor e outra para a iluminação via mapa normal. Mas isso não funciona, porque você precisa do campo de altura do mapa normal para empregar o mapeamento de paralaxe na pesquisa de cores. Então ... e agora? Você precisa do alfa para obter transparência, portanto não pode roubá-lo. E o mecanismo simplesmente não suporta multi-estruturas.
Portanto, você deve escolher um dos seguintes:
- Abandone a ideia. Isso significa que seu jogo é funcionalmente limitado pelo seu mecanismo.
- Hackeie o mecanismo para ter várias estruturas. Supondo que você tenha acesso ao código-fonte, agora você está tentando cutucar o código de outra pessoa. Isso também significa que você precisa mantê- lo e não quebrá-lo com seus tropeços.
- Faça o melhor que puder, dentro das limitações do mecanismo. Portanto, você pode obter paralaxe nos mapas normais, mas não nas cores. Pode não ser exatamente o que você queria, mas é melhor que nada.
Apenas como exemplo, considere Geometry Wars. A maioria dos motores 2D seria uma droga para esses tipos de visuais, já que a maioria deles é criada em torno de desenhar sprites, não de linhas. Esse é um jogo que precisa de um tipo muito especializado de renderizador.
No final do dia, você precisa assumir a responsabilidade pelos elementos do seu jogo que são importantes para as necessidades do seu jogo. Se a aparência visual do seu jogo for desenvolvida principalmente pelo estilo artístico das imagens e modelos que você usa, em vez de efeitos específicos, o uso de uma solução pré-empacotada é adequado. Mas se o estilo visual do seu jogo for definido significativamente pelo código de renderização personalizado, é provável que um mecanismo padrão possa se tornar uma limitação séria se você decidir fazer coisas que estão fora da caixa.
Além disso, há uma questão muito prática: nem todos os mecanismos de jogo são igualmente portáteis.
Com o recente aumento das plataformas móveis, o mercado de jogos está espalhado por vários sistemas operacionais e dispositivos de interface do usuário. Nem todos os mecanismos funcionam em todos os dispositivos. E se o seu mecanismo não funcionar em uma plataforma, você certamente não terá tempo para fazê- lo funcionar em uma. Afinal, é por isso que você usou um mecanismo em primeiro lugar, certo?
Se for importante para você que seu jogo funcione em uma plataforma específica, você precisará novamente se responsabilizar por isso. E a maneira "mais fácil" de garantir o sucesso com isso é fazer você mesmo. Para construir um mecanismo que possa funcionar em várias plataformas, talvez empregando estruturas mais específicas, específicas da plataforma, onde necessário para lidar com alguns detalhes de baixo nível. Dessa forma, se quebrar, é o seu código; você é a melhor pessoa para consertar isso.