The Game Makers Brasil

Com tantas bibliotecas, frameworks e game engines surgindo atualmente, tenho visto uma dominância quase que total em POO (Programação Orientada a Objetos). Aliás, posso até citar alguns exemplos.
E por aí vai. Em game engines, isso às vezes muda o nome para ficar mais bonitinho: Construct 2 usa families, GameMaker usa parents, etc.

Mas e o paradigma procedural? Isso ainda tem algum uso em jogos? Aliás, isso ainda tem algum uso em algum software de fato? Imagino que devesse existir alguma adoção a este paradigma na época, mas muitas coisinhas mudaram desde então: jogos eram desenvolvidos usando um set limitado de sprites, paletas de cores e recorrer a métodos de compressão e descompressão de dados simplesmente para que os gráficos coubessem num cartucho. Isso num tempo que, acredito eu, nem a linguagem C era totalmente viável ainda.

Hoje em dia temos performance o suficiente para instanciar uma fase usando um XML de centenas de linhas, frameworks que nos obrigam a extender e implementar um monte de classes diferentes, desenvolvimento multiplataforma e mais um monte de coisas monstruosas. Usar goto virou crime, variáveis globais são o mal do século e todo campo que não possuir religiosamente um getter/setter (mesmo para coisas estúpidas, como posição X e Y) deve ser queimado na fogueira. Orientação a objeto a todo vapor, UHUL!

É óbvio que eu consigo enxergar parte das vantagens do POO (não se enganem com o parágrafo anterior ), mas eu queria ver se conseguia debater com alguém daqui e ver se o paradigma procedural tem pelo menos alguma vantagem hoje. Deve dar para fazer algum jogo assim (alguns jogos incompletos meus seguiam algo mais ou menos desse naipe), mas quais os ganhos, afinal? Existe pelo menos algum jogo que visivelmente siga este paradigma? Alguém já teve a curiosidade de programar algo assim? Se sim, como foi a experiência?

Bem, é isso. A propósito: vale deixar claro que eu estou falando sobre o paradigma de programação procedural, NÃO geração procedural. Só avisando para evitar confusão.

o/

Creio que você confundiu programação procedural com programação sequencial.

Por exemplo, o GML é procedural.(não confundir com sequencial)
E o conceito de "parents"(parentesco) não tem nada a ver com POO.

Talvez tenha se confundido por causa dos ditos objetos, mas definitivamente GML é procedural.

Deve dar para fazer algum jogo assim (alguns jogos incompletos meus seguiam algo mais ou menos desse naipe), mas quais os ganhos, afinal? Existe pelo menos algum jogo que visivelmente siga este paradigma? Alguém já teve a curiosidade de programar algo assim? Se sim, como foi a experiência?

Bem, a alguns dias comecei a fazer uma biblioteca em Assembly para poder fazer um jogo que rodasse no DOS.
Eu parei pois trabalhar em modo gráfico é bem "complicado", e não estava afim de fazer um jogo em modo texto.
Devo dizer que se fosse mesmo terminar, não teria tantos problemas...(fora desenhar os malditos pixels na tela. )

A diferença mesmo seria em relação a organização, que em POO seria bem mais adequada.
Mas em procedural existem estruturas(Em Assembly, inclusive), que pode organizar valores e acessa-los por ponto e assim teria uma organização adequada das instâncias do jogo.

Bom, deixa eu lhe mostrar um jogo que fiz a uns anos em Batch:
http://pastebin.com/prq7akRr
P.S.: Existem bugs que não resolvi, e jamais resolverei.

Esse sim é um exemplo de jogo programado de forma sequencial.(com os malditos gotos)

Bom, resumindo: POO facilita a organização, mas programação procedural não impossibilita ou torna complexo o desenvolvimento de um jogo.

MrRafael,
Ainda existe sim. Eu mesmo gosto de programar jogos utilizando o QB64 (derivado do antigo QBasic) e uso o DarkBasic Pro (que gosto muito). Agora que estou, e muito devagar, conhecendo essas ferramentas tipo "maker", como o GameMaker Studio. 

O game maker acredito que é OO porém não te permite criar classes a níveis de código... Toda a codificação é em scripts, só o Unity mesmo é que você cria classe na mão grande como se fosse num visual studio ou outra IDE de java/c++.

Negativo Daimon.

O Game Maker usa sua linguagem própria chamada de GML, a mesma contém os elementos de jogos nomeados de objetos... Isso não faz com que a linguagem deixe de ser procedural.

GML não contém classes, herança nem nada do tipo.
Objetos não passam de elementos do jogo, e parentesco não passa de uma associação entre objetos que não se compara a herança.

Leia: https://pt.wikipedia.org/wiki/Orientação_a_objetos

Bem, não sei se o que posto a seguir segue a idéia pura do tópico. Não sou programador, sou apenas um curioso que gosta de brincar de desenvolver jogos 2D. Minha praia mesmo é a parte gráfica, desenhar os assets e/ou concepts.

Mas assim mesmo, brincando sem compromisso, estou fazendo isso aqui: http://gamejolt.com/games/navinha-little-ship/192960



Neste simples jogo de nave, ao qual tentei dar a aparência dos clássicos dos arcades e do mega drive, eu estava sem tempo de desenhar um mapa completo para o jogo. Então lembrei de algo que tentei há alguns anos, no flash, para outro jogo meu, "PIXEL FIGHTERS" . Nele, eu adaptei um pouco da idéia que Carol Shaw usou em RIVER RAID: criar um script que resultasse na geração aleatória dos elementos de cenário. No devlog de "NAVINHA", eu explico com quase todos os detalhes a técnica que eu usei. Mas em resumo, consta de usar no mínimo dois objetos contendo vários frames. Esses objetos surgem no alto da tela (sendo o jogo  de rolagem vertical) e no momento de sua criação, uma variável indexada ao número de seus frames terá seu valor definido aleatoriamente; Quando o objeto surge, de acordo com o número aleatoriamente escolhido, será exibido na tela o frame correspondente ao número setado na variável. Recomendo usar no mínimo dois objetos nesse esquema porque assim a exibição do mapa não é interrompida, caso contrário, se usar apenas um objeto, este exibirá sua parte do mapa e somente o fará após sumir da tela, sendo "resetado" e mandado de volta para o alto da tela, com outro número de variável, e consequentemente, outra imagem a exibir. Por outro lado, se inserir objetos demais o mapa fica muito cheio de elementos e dependendo do lay out utilizado, torna o jogo confuso aos olhos do jogador. Em "NAVINHA" utilizei quatro objetos para formar o cenário, após aperfeiçoar o esquema. Quando comecei a imaginar a firula, usei seis objetos em "PIXEL FIGHTERS", e acabei sacrificando a performance, como vocês podem ver na página de teste do jogo. Só roda bem em máquinas parrudas :) 

Vejam a primeira versão do sistema rodando no flash: https://www.youtube.com/watch?v=VAe4HodY7Zg

Em "NAVINHA", o esquema funcionou perfeitamente e o jogo roda liso. Tomei o cuidado de adicionar um código para "respawn randômico" desses objetos, e assim, eles nunca nascem na mesma posição, quando exibem o mesmo frame. Já cheguei a observar o mapa passando até duas horas e não repetiu nenhuma ilha (a 1ª fase se passa sobre o mar) exatamente como da vez anterior. Para mim, o resultado ficou muito bom e os códigos para isso, nos objetos não passam de dez linhas, quando chegam a isso. Na página do jogo, vocês podem ver alguns videos e assim conferir o resultado. Na imagem a seguir, uma montagem mostrando vários tipos de ilhas criadas aleatoriamente. Eu gostei, vou usar esse esquema em outros jogos.

Não sei se minha idéia se encaixa exatamente no puro conceito de programação procedural, mas aí está :)

tiaoferreira escreveu:Não sei se minha idéia se encaixa exatamente no puro conceito de programação procedural, mas aí está :)

Pelo que entendi da sua explicação e também pelo vídeo do sistema funcionando em flash, não é geração procedural, a geração das suas fases está randômicos em blocos, na geração procedural o cenário literalmente é construído pela programação, seguindo algumas regras como tiles para os cantos, o que encaixa em determinado local, etc.

"River Raid, de 1982 da Activision que usou uma sequência de números pseudo-aleatórios gerados por um registro de deslocamento linear feedback shift register, a fim de gerar um labirinto de rolagem de obstáculos" - Wikipedia - https://pt.wikipedia.org/wiki/Gera%C3%A7%C3%A3o_procedural_em_jogos_digitais

Baseei minha idéia em River Raid e funciona direitinho. E se o conceito da Wiki vale para River Raid, então também vale para PIXEL FIGHTERS e NAVINHA. E mesmo se não valer, não importa, funciona LISO :) E não é totalmente aleatório não, há certas condições para a exposição de determinada parte do cenário; Se a fase for de gelo, todos os componentes do mapa serão cobertos de gelo ou neve, se for deserto, terão areia amarela, dunas e oásis e por aí vai. Funciona redondinho agora, é o que importa :) E partindo da premissa que o motor é programado para gerar os números aleatórios que resultarão na criação e combinação dos elementos do mapa, então o cenário foi sim, construído pela programação :)

variáveis globais são o mal do século e todo campo que não possuir religiosamente um getter/setter (mesmo para coisas estúpidas, como posição X e Y) deve ser queimado na fogueira.

Concordo plenamente que essa é o melhor jeito de fazer bibliotecas e frameworks pois deixa muito mais intuitívo.

Mas para meus projetos pessoais eu ainda uso essas duas práticas que você falou, geralmente por ser uma implementação mais rápida. Mas quando vejo que o projeto vai ser numa escala maior, já mudo para OOP para evitar development hell.