Já criei jogos e minha própria linguagem de programação. Em nenhum momento eu precisei, ou senti falta, de design patterns.
Respondendo a "Sim! Mas você não vai ver utilidade neles se vo..." dentro da publicação [Não disponível]
-3
2
Não sei qual é o jogo, mas se usou linguagens orientadas a objetos como C++ você poderia ter tirado proveito de padrões como Command, Observer, Factory, State, Decorator e etc.
Mas é claro, se a arquitetura que você elaborou não passa por nenhum dos problemas que esses padrões tendem a resolver, é lógico que você não verá utilidade deles.
Também é provável que você os tenha implementado de alguma forma, só não deu um nome para isso.
-2
Mas até agora não consegui entender que 'problemas' eles resolvem.
Pra mim parece que são problemas relacionados a orientação a objetos ou não são nem problemas de verdade.
2
No caso do livro do GoF os problemas que eles resolvem estão descritos nas primeiras seções de cada padrão: Intenção, Motivação e Aplicabilidade.
E são vários padrões, qual deles você não entendeu o problema que ele resolve? Talvez tenha pouca vivência no desenvolvimento OO e não tenha se deparado com eles.
Pra mim parece que são problemas relacionados a orientação a objetos
Sim, a proposta do livro é essa. É possível que existam padrões documentados para outros paradgimas como o funcional e procedural, mas se estamos discutindo sobre os padrões do livro do GoF os problemas ali são os que surgem quando se programa com orientação a objetos.
Se você não entende ou não usa orientação a objetos, de fato os padrões não servem para você. Da mesma forma que se você não pilota aviões não faz sentido entender e aplicar as regras de tráfego áereo.
1
Quão complexos foram esses jogos? tinham sistemas de inventário, árvores de habilidade, sistemas de armas, inimigos com diferentes padrões de comportamento?
Da pra fazer tudo isso sem usar padrões de projeto? sim! mas a longo prazo, a manutenção disso ficaria cada vez mais inviável.
Esses princípios, padrões, técnicas de programação não são aleatórios.
aprenda bem os princípios de Orientação a objetos, depois aprenda SOLID, depois padrões de projetos, depois arquitetura limpa/exagonal, depois DDD. você vai ver que uma coisa vai levando a outra, tudo para construir softwares capazes de crescer, escalar, mudar, sem se tornarem um gargalo para a empresa