POO torna tudo mais complexo

SamL
(usa XUbuntu)

Enviado em 23/12/2021 - 10:47h

Não sei se já repararam nisso, mmas a POO (programmação orientada a objetos) deixa alguns ttipos de programas altamente complexos.
Um exemplo claro disso são com jogos, não falo de joguinhos tipo pong e breakout, mas jogos mais profissionais.
Rapaz, reparei aqui na complexidade excessiva com pensar em objetos para jogos.
Por exemplo, é comum começar com uma classe base que serve tanto pro player quanto pra inimigos. Daí vai avançando e precisa adicionar classe pros itens, depois pros chefes e assim vai indo, até que se tenha um monstro em forma de código.

Recentemente descobri a programação orientada a dados, e com ela há uma possibilidade maior para jogos do que a limitação da POO.
Exemplo, é comum num jogo um certo código para uma classe ser necessário em outra classe. Usando OO você teria que adicionar o mesmo código numa classe base, para assim as derivadas terem acesso a ele. Isso é bem comum, porém, gera muita complexidade além de sobrecarregar a classe base com responsabilidades a mais.

Já com oriteação a dados, tudo é bem separado, dados da classe da lógica, o que faz com que qualquer elemento do jogo possa usar qualquer outro método/função de dados diferentes. É o mesmo que somar: Player = Renderizador + JumpAction + MoveAction + Controls. Diferente usando OO onde cada uma dessas propriedades seria um componente de uma classe.

Enfim, só quero dizer aqui que há limitações com POO que não são nada legais de se ter. Vou investir em desaprender a pensar com objetos e passar usar orientação a dados.
O que você acha disso? Concorda? Discorda?

removido
(usa Nenhuma)

Enviado em 23/12/2021 - 13:04h

Bom, não sei como funciona especificadamente o desenvolvimento para jogos, mas quando uma classe começa a ficar inchada e com muitas responsabilidades, ai é problema de implementação. O código também começa a ficar muito ruim de debugar para resolver possíveis bugs.

Por isso, lógico, dependendo de cada projeto e de cada necessidade, é importante dar destaque aos design patterns, para ter uma boa referência de implementação e organização das classes.

SamL
(usa XUbuntu)

Enviado em 23/12/2021 - 14:46h

Cara, dev com jogos parece até um universo paralelo do desenvolvimento. Se tu perguntar pra alguém experiente como ele implementa por exemplo um sistema de powerups, ele vai dizer que usa X, mas se perguntar pra outro, ele vai dizer que usa Y. Essa diferença entre cada sistema mostra que, em jogos, a POO não funciona tçao bem como em software comum. Apesar de existirem os design patterns voltados especificamente pra software com gui, ainda não existem tantos outros patterns para jogos, sendo que, como os jogos AAA em geral são closed source, tu não pode nem estudar ou mesmo avaliar como o código é feito, sendo assim não há uma cultura de "criar" patterns para resolver problemas pontuais. E por isso, muitos jogos ficam complexos de mais de se manter, mesmo o programador sendo habilidoso e cuidadoso no planejamento das classes e afins.

rafael_grether
(usa FreeBSD)

Enviado em 23/12/2021 - 14:52h

Olá,

Não tenho experiencia com jogos, mas não concordo exatamente com isso que você falou.
Geralmente quando uma classe está sobrecarregada, inchada, com muitos dados, é uma falha do programador, de não ter estruturado corretamente o código.

Talvez para o desenvolvimento de jogos, orientação a dados seja mais simples. Mas não vejo a POO como limitação nem nada do tipo. Já programo em C++ por 20 anos.

SamL
(usa XUbuntu)

Enviado em 23/12/2021 - 15:26h

Nossa, legal cara! Bom saber que tem gente experiente por aqui.
Então, eu vi sobre ECS (Entity Component System) que é um pattern criado no ramo de jogos, e ele usa orientação a dados. Antes dele, eram comuns outros como criar nós de cena em engine e então "derivar" um nó de cena para criar os elementos de jogos. Concordo que pode ser falha do programador, até porque precisa ganhar experiencia pra ficar bom de verdade. O ruim que vejo na OO pra jogos é relativo a como a orientação a dados trabalha, digo, comprando diretamente, orietação a dados é muito mais simples mesmo que OO para jogos, já que tu pode usar um ECS e então adicionar em runtime comportamentos que não são possíveis ou simples de fazer com OO.

Por exemplo, supondo que tu programe um joguinho como o super mario bros 1 de nes (com c++ por exemplo). Se for fazer no modo OO, tu vai terminar com classes especializadas em determinada funções pré-definidas, porém, tu não vai poder fazer facilmente o player controlar um goomba com os mesmos controles do mario, essa é a limitação principal que vejo, depois de feito um código não tem como reaproveitar os métodos de um objeto para outro sem fazer adaptações "milagrosas". Não há tanta flexibilidade quanto usar orientação a dados. Se não for previsto isso em planejamento, uma classe vai acabar inchando e ficando especializada somente naquelas funções já pensadas de inicio, e como eu disse, com orientação a dados, tu aproveita tudo, inclusive podendo fazer um goomba ser controlado por o player mesmo que isso não tenha sido planejado de antemão, já que há uma separação entre os dados das classes e o código em si que passa a ser compartilhado globalmente.

Ainda tô estudando sobre orientação a dados, pelo que vi, me parece algo bem bacana de usar em jogos. Espero poder modificar minha engine feiosa pra usar isso.

rafael_grether
(usa FreeBSD)

Enviado em 24/12/2021 - 10:44h

Legal, mas confesso fiquei perdido!
Não jogo e nunca programei pra jogos, então não conheço nada a respeito de ECS. Já ouvi falar em super mario, mas também não sei nem o que seria esse goomba kkkk
Sinceramente eu não conheço a engine de um jogo, como isso tudo funciona. A primeira vista (sem conhecer os detalhes e particularidades) eu poderia herdar um objeto de uma classe e utilizar tanto para personagem A como personagem B, sobrescrevendo apenas o que necessita de mudanças, como velocidade do personagem por exemplo. Assim mantenho os mesmos comandos para mover o Mario e aquele amigo verde dele, herdando o mesmo objeto; e só defino a velocidade do cara verde como algo diferente.

Mas não sei os complicadores de um jogo, deve ter muitos.

Em tese não tem uma melhor linguagem, e sim a que melhor se adapta para o que precisa.
Eu programo em C++, mas administro servidores Unix. Não utilizo C++, para o preciso faço tudo em standard shell (posix).

Talvez para programação de jogos, orientação a dados seja mais eficiente. Eu infelizmente não conheço nada de jogos para poder ter uma discussão mais técnica e profunda contigo. O ultimo videogame que joguei foi o Atari, e hoje os jogos são bem diferentes :)

SamL
(usa XUbuntu)

Enviado em 24/12/2021 - 11:46h

@rafael_grether
rsrsrs O goomba é um inimigo dentro do super mario bros, com orientação a dados, torna-se possível controlar qualquer elemento, da gui inclusive, com os mesmos controles que o player usa para controlar o mário.

É difícil entender sem mostrar código, por isso, deixo aqui uma sugestão pra tu ler esse link:
https://austinmorlan.com/posts/entity_component_system/
Ali fala sobre o pattern ECS, só que sem usar jogos, é pra jogos mas não usa um jogo como exemplo, é puro C++.


Isso é exatamente o que eu faria normalmente, acontece que ele gera problemas no longo prazo, como métodos complexos e gigantes.
Com orientação a dados, tu só precisa programar os métodos uma única vez e então, acomplar um dado para aquele método;função e está feito.
O ruim de pensar com objetos em jogos é que a classe torna-se altamente especializada somente naquilo que ela foi programada pra fazer.
Então, se tu tem o mario e o luigi (o amigo verde) tu teria uma única classe com propriedades para ser controladas por cada jogador, porém, se tu quiser fazer o goomba (inimigo) ser controlado pelos players, ai o bicho peg feio porque terá de reimplementar os controles na classe base dos players para ser possível o goomba também ser controlável.

Já usando orientação a dados, tu faz somente uma classe Controles com os dados necessários, mas sem nennhum método/função, e em separado tu cria o sistema, que é uma função que apenas recebe o Conrtoles e faz mover qualquer objeto que tenha esse componente.

No caso, nem é preciso adicionar o Controles dentro de nenhuma classe, já que é possível apenas "adicionar" num array do ECS e então executar de acordo com a necessidade programadas. Fica melhor de entender o que eu disse se tu olhar ali no link do ECS.

É muito interessante orientação a dados, não sei nem como fiquei tanto tempo sem descobrir algo assim. Encontrei até um framework com ECS para jogos.
Dá uma olhada nesse exemplo de uso da EnTT:
https://github.com/Kerndog73/EnTT-Pacman/blob/master/src/core/factories.cpp
Ali mostra como é construido cada personagem do jogo, sendo possível adicionar qualquer compoente em runtime.

rafael_grether
(usa FreeBSD)

Enviado em 27/12/2021 - 16:07h

@SamL

Legal, jogos é realmente um universo bem a parte.
Vou dar uma lida no material que você passou. Sem o código, realmente fica um pouco complicado entender.
Tenho um colega que trabalha na Prothos, eles desenvolvem jogos. Depois troco uma ideia com ele sobre isso.

Valeu!