UMA ABORDAGEM PELA PROGRAMAÇÃO ORIENTADA A OBJETOS VERSUS PROGRAMAÇÃO ESTRUTURADA
Quando se tem em mente o desenvolvimento de um software, deve-se passar necessariamente pela fase de projeto, onde as idéias a respeito do que se quer fazer são confrontadas com as possibilidades técnicas do grupo de desenvolvimento e uma síntese entre intenção e realidade irá nortear o processo de construção do código. Em se tratando de jogos, a coisa pode se tornar ainda mais complicada, pois geralmente esperamos muito mais de nossos programas do que aquilo que somos realmente capazes de realizar em curto prazo.
Essa fase de projeto de software pode ser traduzida em um detalhamento mais fino das atividades, entradas e saídas que o sistema irá comportar. Isso passa necessariamente por uma escolha primordial: programação estruturada ou programação orientada a objetos. A programação estruturada é aquela que nos permite detalhar o funcionamento de um programa através das funções e procedimentos que o compõem. A programação orientada a objetos nos permite uma outra hierarquia, mais rica e mais complexa, de estruturação, com classes que comportam métodos que podem herdar características de outras classes e assim consecutivamente. A ênfase que se dá ao projeto em programação estrutura é em relação à ação que uma determinada função ou procedimento irá executar, já na programação orientada a objetos a ênfase na fase de projeto se dá ao tipo de dados que se deseja obter e a forma como esses dados serão tratados pelo programa. São dois enfoques bem diferentes e que têm implicações de projeto que resultam em conceitos diferentes para um mesmo software.
Bem, deixemos momentaneamente a questão da programação estruturada e da orientação a objeto de lado para colocar em questão o que se entende por engine e qual deve ser o seu papel.
A palavra engine pode ser traduzida como “motor” ou “máquina”. Um engine pode ser entendido, de tal forma, como uma coletânea de código orientada à ação (execução de ações por parte dos elementos do sistema) que visa ser genérica o suficiente para que possa ser reaproveitada na construção de outros sistemas, enfim, de outros jogos que executem ações semelhantes. Veja que quando falamos de ação, não estamos apenas nos referindo a jogos de ação, mas sim a como um programa toma decisões em tempo de execução com base numa interação por parte do usuário. Essa definição difere consideravelmente do que podemos considerar uma biblioteca de software propriamente dito: uma lib é orientada ao suporte de tarefas de mais baixo nível que dão muito trabalho se forem reescritas a cada novo sistema desenvolvido, ou seja, não tem essa preocupação se ser orientada à ação.
Tomemos como exemplo jogos de RPG e pensemos no papel que um engine pode ter. Essencialmente, a estrutura de programação desses jogos é a mesma, mudando apenas o conjunto de regras que irá nortear o comportamento dos usuários e a forma como os mesmos irão interagir com o sistema. Se tivermos um código genérico o suficiente para passarmos como parâmetro as regras do jogo e as formas de interação, teremos um construído um engine que, de forma geral, pode nos auxiliar em todo o desenvolvimento de jogos desse tipo.
Visto isso, voltemos agora aos conceitos de programação estruturada e orienta a objetos.
A orientação a objetos surgiu como um novo paradigma em programação visando justamente resolver o problema de reaproveitamento de código e da manutenção desse código por pessoas diferentes. Como dissemos acima, a própria ênfase da orientação a objetos se dá nos dados que uma classe deve tratar, ou seja, nos dados que devem ser recebidos como parâmetros e aqueles que devem retornar de um método encapsulado por uma classe, o que torna a tentativa de generalizar o código muito mais eficiente do que na orientação estruturada.
É evidente que tal forma de programação exige disciplina e experiência, já que sempre iniciamos nosso estudo em programação pela forma estruturada e levamos certo tempo até compreender a forma como as classes podem ser estruturadas e vantagem que isso traz ao código final. Também é evidente que para desenvolvermos pequenos jogos, a forma estruturada é mais simples e, diria mais, até mais útil. Mas, a questão que fica, é que se pretendermos desenvolver um trabalho a longo prazo, visando produtividade de construção de código, parâmetros de qualidade na fase de análise do projeto, teste e manutenção, devemos sim nos preocupar em construir engines que sejam orientados a objeto e possam ser constantemente revisados para trazer o nível de generalidade que pretendemos alcançar. Logo, a resposta ao título do texto é: depende do porte e do desenvolvimento a longo prazo do projeto que se pretende criar.