É inteligente usar algum mecanismo para começar a desenvolver jogos? [fechadas]

14

Comecei a programação em C #, para depois desenvolver jogos com o XNA. Eu li um bom livro de desenvolvimento de jogos para C #. Como eu já conhecia outros idiomas, pude aprender rapidamente os recursos de C # e o código de sintaxe. Então eu entrei no XNA. Como o livro que estava lendo era um pouco antigo, deixei de lado e comecei a examinar os tutoriais de desenvolvimento de jogos sobre o XNA pela Internet. Eu poderia realizar e entender a maioria deles, usando gráficos 2D. Criei sprites animados, fiz meus personagens se moverem em qualquer direção, rolei meu plano de fundo junto com o movimento dos meus personagens e assim por diante. Tudo foi feito com o XNA "bruto".

Achei algumas dessas coisas difíceis de entender e descobri que algumas delas já estão embutidas na estrutura. Encontrei outros mecanismos de jogo, que eu entendia claramente pelo menos os códigos de linha simples, como " FlatRedBall " , " Axiom " e " Quick Start Engine " . Eu já conhecia os famosos, como "OGRE" , "Unreal" e "Unity" . Ao mesmo tempo, fiquei tentado a jogar tudo fora e começar a aprender alguma famosa programação de mecanismos de jogos. Eu queria ficar com o XNA, pois levava tempo para aprender; tempo que eu não gostaria de desperdiçar.

Desta vez, deixo para os experientes. Posso passar por algum mecanismo de jogo e usar o que ele tem para oferecer, mesmo que eu esteja começando com o desenvolvimento do jogo? Algumas pessoas podem pensar que é bom se acostumar com as rotinas chatas de uma estrutura nua. Em caso afirmativo, qual seria o recomendado para começar? Ouvi dizer que isso varia de mercado para mercado. Talvez possamos considerar que eu quero um RPG específico.

Rodrigo Souza
fonte
1
Eu tinha a mesma coisa em mente ... uso XNA há 4 anos. Comecei a fazer um MMORPG ... Veja onde isso me levou, não onde. Como sempre, comece pequeno, use algo que você goste, a menos que tenha planos maiores e faça alguma coisa antes que o tempo passe.
Michael Coleman
@ Omnion, usar XNA por 4 anos tentando criar um MMORPG não é uma questão do que você está usando, mas uma questão de determinação, dedicação, tempo livre e aplicação prática. Qualquer pessoa pode concluir um MMORPG usando XNA, desde que mantenha a motivação e a dedicação ao longo do tempo. A quantidade de tempo variaria com base na quantidade de tempo livre e na velocidade do trabalho, mas, independentemente do tamanho ou do escopo do projeto, PODE SER PRÁTICO, mesmo que alguém esteja começando bem. A chave é organizar o processo de engenharia. Passos de bebê, um passo de cada vez, ao longo do tempo, consistentemente, concluem um projeto, independentemente da escala.
1
Menciono apenas isso para incentivar as pessoas a não acreditarem que seu projeto é muito grande, mas para simplesmente entender a realidade da praticidade. Se entendermos que é preciso mais do que sonhos para concluir um projeto, eles irão mais do que "nenhum lugar". Eu sempre quero incentivar as pessoas a realizarem o seu sonho, e não o comprometerem. Apenas torne prático para que PODE ser realizado, independentemente do tamanho. Com o tempo, tudo é possível.

Respostas:

11

Depende do que você quer aprender. Se você deseja "apenas criar um jogo", pode ser bom com um mecanismo. Eu pessoalmente não recomendo isso.

Se você quer realmente entender como a computação gráfica funciona, você deve aprofundar-se e aprender tudo. Desde a atualização de sua álgebra linear (pelo menos matrizes, vetores e espaços lineares) até a compreensão de como os pipelines gráficos funcionam. XNA é a melhor estrutura para começar. Meu primeiro jogo foi nele (quero dizer, jogo real, o primeiro aplicativo 3D foi tanques de batalha em openGL). Se você deseja iniciar a programação 3D, não tem planos tão ambiciosos, não pode fazer um RPG agora. Você deve tentar fazer algum jogo em que esteja voando no espaço cheio de cubos e tentando atirar nos vermelhos, para aprender o básico. Provavelmente levará mais tempo do que você pensa :). Mas isso vai te ensinar muito.

E vá em frente! A programação de gráficos 3D é a melhor coisa que você pode fazer para viver. É difícil, divertido e criativo em um pacote.

Notabene
fonte
3
Pode valer a pena conferir o MonoGame em vez do XNA. A Microsoft parou de desenvolver o XNA e não possui suporte à interface do usuário do Windows 8 Metro. De acordo com alguns posts que li no Reddit, seus representantes estão recomendando o MonoGame. E você obtém plataforma cruzada (Linux, OSX, Android, iOS) como resultado.
David C. Bishop
17

Não há nada de errado em usar um mecanismo existente, tudo se resume aos seus objetivos.

Se você estiver mais interessado em criar alguns jogos ou design de jogos, quanto mais rápido chegar ao código da jogabilidade, melhor. Algo como o Unity é ótimo aqui, pois você pode usar seu conhecimento de C # e começar a anexar scripts a objetos e executar algo imediatamente.

Se você quer se tornar um programador de jogos, precisa entender as coisas em um nível inferior. Uma estrutura como o XNA é um bom ponto de partida. Você pode confiar na estrutura para colocar as coisas em funcionamento e começar a substituir partes da estrutura por seu próprio código enquanto aprende a criar cada componente do seu jogo.

wkerslake
fonte
1
Eu gosto mais da sua resposta do que da minha. +1 para você.
Notabene
6
É especialmente útil dizer que você quer ser um programador de jogos, começar com um mecanismo e, depois, quando você faz seu próprio estudo, use aquele que você usou como um bom exemplo (supondo que tenha gostado de usá-lo) para contrastar com outros recursos encontrados. na arquitetura do mecanismo.
Michael.bartnett
Mas você ainda deve ser um sólido especialista em computação gráfica, mesmo se estiver usando o mecanismo.
Notabene
1

CONSELHOS DE UM AMADOR

// De zero a amador ao longo de anos de aprendizado


Eu definitivamente ficaria longe de mecanismos de alto nível como o Unity ou o Torque2D MIT. Eles são ótimos para protótipos pequenos, mas eu nunca os levaria a sério para desenvolver meu próprio videogame. Por que eu deveria? Qual é o objetivo, a menos que não seja nada além de um simples remake do SideScroller ou Arcade?

A maioria dos mecanismos de jogos, bibliotecas ou estruturas não faz nada além da tarefa mais simples, com um monte de código inchado com funções e recursos que você nunca usará.


Quando eu era novo no desenvolvimento de jogos anos atrás, comecei no topo. Motores de nível muito alto. Não é algo muito alto como o RPG MAKER, mas definitivamente lá no alto, como Unity e Torque. Então eu fui mais baixo, para XNA e C #, porque havia muitos recursos e tutoriais. Meu projeto principal precisava do desempenho, ou talvez eu seja apenas obsessivo-compulsivo por querer um desempenho incrível no meu software, mesmo que não seja um projeto grande. O XNA simplesmente não o cortou, e eu tive muitos problemas com o mecanismo que li exigindo uma dor de cabeça para corrigir. Qual é o sentido de usar algo "de nível superior", como XNA / C #, quando você está fazendo o mesmo trabalho (corrigindo bugs e problemas de XNA) que faria com seu próprio mecanismo em C ++?

Depois de algum tempo de aprendizado, eu finalmente aprendi sobre como os mecanismos de jogo são projetados e comecei a analisar o código dos próprios mecanismos. Lendo o que a maioria dos profissionais tem a dizer e as queixas dos críticos dos mecanismos de jogos me fizeram perceber: 'Por que usar um mecanismo? "

Escovar o meu C ++ e realmente entrar em algumas filosofias usadas nessa linguagem me ajudou muito. No entanto, eu havia passado tanto tempo aprendendo tanto que só queria começar a fazer um jogo.

Então, acabei com algo com muitos elogios, era C ++ e nível muito baixo: SDL. Infelizmente, isso foi uma dor de cabeça. É um nível tão baixo que não vejo razão para usar essa biblioteca. Prefiro simplesmente aprender OpenGL e fazê-lo sozinho do zero. Honestamente, foi principalmente o fato de que eu precisava implementar meu próprio código para fazer algo tão básico quanto virar uma imagem (e a implementação de outras pessoas não estava funcionando por causa de como eu lidei com sprites) que me levou a lixeira SDL permanentemente. É ótimo se você quer um renderizador de software, mas na IMO eu prefiro descartá-lo para ficar mais baixo com o hardware (OpenGL) ou superior (SFML).

Não querendo comprar outro livro na amazon e aprender mais uma API, fui mais alto. SFML é simplesmente maravilhoso, para não mencionar altamente elogiado em toda a internet. Eu li quase um número interminável de críticas positivas, com quase nenhuma negativa. Não posso dizer o mesmo para SDL. Ele lida com todos os conceitos básicos extremos, mas deixa o resto para mim e para outras bibliotecas de minha escolha. Eu continuo com isso desde então.


IMO, um mecanismo de jogo é apenas bobo. Bibliotecas de baixo nível são escolhas muito melhores para programadores experientes e iniciantes.

Observe também que aprendi mais sobre conceitos de programação e aprimorei minhas habilidades de desenvolvimento de software quando forçado a lidar com as coisas em um nível mais baixo do que eu já aprendi com os mecanismos de jogos WYSIWYG de alto nível.

O que algo como o Unity oferece a você sobre o XNA? Edição visual e muleta. Os novatos acabarão aprendendo que você ainda terá que codificar praticamente todo o jogo, como faria se tivesse C ++, e os editores visuais são ineficientes para algo que você mesmo pode criar.

O que algo como o XNA oferece a você sobre SFML ou sua própria implementação do OpenGL e outras bibliotecas úteis? OMI, absolutley nada de bom. Pior desempenho, C # em vez de C ++, uma infinidade de tutoriais para iniciantes, mas significativamente menos profissionalismo, e alguns poupadores de dor de cabeça porque o IMO é mais uma vez uma muleta para o que você deve aprender com C ++. Inicialmente, fiquei intimidado com C ++ e adorei C #, principalmente por causa de rumores e opiniões de tolos que tiveram os mesmos problemas que tive inicialmente com C ++: eu só queria um programador suficientemente bom. Percebi que precisava aprender mais fundamentos e aprimorar minhas fraquezas para superar os problemas que tive com o C ++, que o C # "facilitou". Eu já sinto falta da simplicidade de algumas coisas em c #? Nem mesmo! Eu sei como fazê-lo em C ++ sem problemas.


Se as bibliotecas de baixo nível ou o aprendizado do DirectX / OpenGL o intimidarem, espere até começar a entrar na complexidade de criar um videogame completo.

Minha filosofia sobre mecanismos de jogos pode ser resumida em dois exemplos que explicam a redundância e a inutilidade dos mecanismos, exceto em circunstâncias isoladas.

Os novatos que se sentem intimidados com bibliotecas de baixo nível terão um ataque quando descobrirem que, mesmo com um mecanismo de alto nível como o Unity, (além de renderização de gráficos, reprodução de áudio, carregamento de conteúdo; coisas básicas reais), será quase idêntico a criar um jogo do princípio. A complexidade está na engenharia de um jogo, no entendimento da API ou no desenvolvimento das classes a serem renderizadas na exibição.

Especialistas que não se sentem intimidados com a complexidade de criar um jogo completo em algo como Unity, não têm utilidade para o Unity, porque o tempo necessário para aprender com confiança a API e os requisitos de um mecanismo específico provavelmente é mais uma dor de cabeça e mais tempo do que o necessário para codificar as poucas classes necessárias para executar o básico.

Portanto, os motores são inúteis para iniciantes, porque iniciantes não podem fazer nada com eles porque não possuem as habilidades de engenharia. Da mesma forma, os mecanismos são inúteis para os veteranos, porque eles já têm as habilidades de engenharia para fazê-lo sem um mecanismo e também podem usar seu próprio 'mecanismo' mais eficiente e específico do que passar pela dor de cabeça de aprender a API do mecanismo de jogo, funções e peculiaridades de desempenho. Sem mencionar o pesadelo maciço de trabalhar com mecanismos que você às vezes não consegue tocar porque eles não são de código aberto (ou mesmo se estiverem, ler o código de outros pode ser um pesadelo às vezes).

Heck, mesmo algumas "estruturas de jogos" de "nível baixo" não passam de poucas classes para criar uma janela, renderizar na tela e reproduzir áudio. Isso é algo que um profissional pode fazer do zero usando outras bibliotecas como SDL / SFML ou sua própria implementação do OpenGL / DirectX / OpenAL, em uma fração do tempo necessário para concluir um videogame completo.


TLDR;

  1. Se você deseja programar, aprenda a ser um programador .

  2. Evite usar mecanismos , mas não se engane e ignore bibliotecas incrivelmente úteis.

  3. Se você quer ser um Game Designer , tente um mecanismo WYSIWYG e instale esses jogos!

  4. Se você quer ser um programador de jogos , evite motores como a muleta que são.

  5. Para mim , o uso de mecanismos de jogos de nível superior prejudicou minha capacidade de me tornar um programador. No momento em que comecei a usar bibliotecas de nível inferior, ou não usei nenhuma, comecei a aprender tanto que rapidamente passei de um novato a alguém que agora pode criar videogames sem nenhuma referência, tutorial ou livro ao meu lado. Apenas meu compilador e muita engenharia e prática.

A quantidade de aprendizado que obtive em bibliotecas de baixo nível em um CURTO período de tempo foi muito maior do que o ganho em MUITO LONGO tempo com MOTORES de nível superior. **


fonte
2
Isenção de responsabilidade: Esta é apenas minha história e meu estilo de aprendizado. Outras pessoas podem ser diferentes. Havia apenas um mundo de diferença para o processo de aprendizagem para mim quando tentei ser um PROGRAMADOR DE JOGOS (material de baixo nível) em vez de um DESENHISTA de JOGOS (dependente de motores).