Neste artigo escrito pelo principal desenvolvedor da Godot. Tem opiniões relativamente chocantes, mas deve ser bom para nos fazer pensar mais eficientemente sobre nossos planos de dominar o mundo.
Eita nois, essa opinião dele sobre design patterns eu não consigo engolir… sei lá, acho que depende muito do seu objetivo, se o ponto é conseguir logo um protótipo pra mostrar pra investidor ou uma prova de conceito OK, eu concordo com ele, mas se a ideia é ter um código que vc vai fazer manutenção, dar update, colocar eventos, etc, não faz o menor sentido ter um blob enorme de código ilegível. Anyways interessante o artigo.
Pois é, né? Achei bem diferente também. Mesmo curtindo métodos ágeis, achei que ele foi um pouco extremo.
Curiosamente diz isto também:
When I work on Godot, I make sure the design and architecture are as flawless as possible. When I work on a game, I want to get things done as quick as possible.
O que ele diria então se um jogo vai usar uma engine própria ou um framework mais low-level (como a LÖVE)?
Depois, ele fala:
At this point, many readers might have noticed that Godot was created to develop games this way. It encourages productivity above all else in the design. The way the scene system works allows to apply a “divide and conquer” approach to developing games (instead of caring about meaningless things like MVC, subdividing in components, etc).
Mas, por experiência nos projetos do UGD, se as pessoas não seguem um mínimo de disciplina na hora de “dividir e conquistar”, todo o design da Godot não serve de nada.
Por outro lado, a parte que ele fala dos passos para fazer um jogo de sucesso do ponto de vista mais geral do projeto é realmente interessante.
Eita. Bem radical mesmo esse ponto do “dane-se qualidade do código” dele…
Usualmente só falam sobre a balança de qualidade/eficiência(performance) do código, não de qualidade/tempo-de-desenvolvimento.
Depois, os passos sobre fazer um jogo de sucesso, fazer protótipos e tal fica bem interessante sem ser radical hahahaha