Por que um desenvolvedor de jogos escreveria seu próprio mecanismo em vez de usar os existentes?


41

Eu observei que muitos desenvolvedores de jogos grandes e conhecidos geralmente desenvolvem seus próprios mecanismos. Exemplos incluem Valve, Crytek, Ubisoft, Epic Games e Square-Enix.

Poderia ser simplesmente porque eles podem, ou é provável que os motores existentes não atendam a requisitos suficientes, para que possamos desenvolver os nossos? Eu mal posso imaginar um jogo que requer um mecanismo específico. Unity ou Unreal são simplesmente suficientes para criar qualquer tipo de jogo; mesmo se não, eles têm código fonte, que pode ser modificado para satisfazer até algumas necessidades extraordinárias.

Por que um desenvolvedor de jogos escreveria seu próprio mecanismo em vez de usar os existentes?



1
Eles não querem licenciar os mecanismos de jogos de outras empresas e pagá-los.
János Turánszki

Eu acho que é o que você faz quando você tem 9K + empregados, que volta ...
glampert

3
Existem vários contra-exemplos de grandes estúdios que criam títulos AAA usando mecanismos de terceiros como Unreal ou CryEngine .
Philipp

3
A Valve começou a usar o mecanismo do Quake e depois escreveu os seus próprios para jogos posteriores. Geralmente, é uma questão de aprender a usar o que está disponível e, finalmente, querer alcançar algo mais do que o mecanismo existente oferece. Nesse ponto, você precisa fazer modificações pesadas ou fazer o seu próprio.
Nairou

Respostas:


53

Há várias razões pelas quais um estúdio pode optar por "construir" em vez de "comprar" sua tecnologia:

  • Tecnologia legada; um estúdio pode ter começado a construir sua própria cadeia de ferramentas antes de existir um middleware viável para ela.
  • Requisitos específicos; um estúdio pode ter uma coleção específica de requisitos que não é adequada para o middleware ou
  • Preocupações orçamentárias; um estúdio pode não ser capaz de arcar com as despesas ou obrigações contratuais do middleware existente.
  • "Síndrome não construída aqui;" a liderança técnica dos estúdios pode ser cautelosa (razoavelmente ou irracionalmente) com a tecnologia que eles não construíram e, portanto, não entendem completamente.

Em geral, faz sentido possuir e controlar as coisas críticas para o sucesso dos seus negócios e terceirizar as que não são.

Para alguns estúdios, o aspecto de design ou narrativa de seus jogos pode ser o recurso crítico que eles esperam capitalizar para obter sucesso. Para esses estúdios, faz sentido simplesmente comprar tecnologia que permita que seus projetistas realizem a visão apropriada.

Para outros, a tecnologia pode ser a base do sucesso. Os estúdios que constroem MMOs, por exemplo, geralmente precisam construir essa infraestrutura porque são críticos para seu sucesso (e o middleware existente é geralmente inapropriado, pelo menos para títulos "AAA") maiores.

Observe que alguns dos estúdios que você listou (Crytek e Epic em particular) basicamente pararam de tentar dominar diretamente o mercado de jogos e quase certamente fazem muito mais como fornecedores de middleware do que como desenvolvedores de jogos.


20
Eu acrescentaria que às vezes há vantagens em tecnologias "construídas aqui". Um exemplo é como o Unity3D altera seus EULAs a cada versão e adiciona restrições estranhas, como "jogos de azar". Quando você licencia uma tecnologia, fica à mercê do licenciante para não revogá-la e revogá-la por nenhum motivo específico (isso acontece com os direitos de IP para a criação de jogos licenciados) ou decide cobrar pela correção dos erros deles.
Skrylar

sério, Unity diz "não há jogos de azar"? Eles até costumavam ter uma página específica sobre jogos de azar na seção Comunidade do site deles!
Jhocking 18/03/2015

A página da Unity aqui, unity3d.com/industries/gambling, diz que você pode comprar uma "licença de jogo da Unity". Não encontrei um preço, mas parece que eles ainda permitem que você jogue jogos de azar, desde que você pague por licenças especiais.
Alex

1
Além disso, é mais fácil começar com o que você já sabe e acabar criando um mecanismo, nem mesmo sabendo o que é um mecanismo. Um mecanismo nada mais é do que uma coleção de casos de uso; se você está tentando reduzir a redundância, acaba criando um mecanismo e, se está tentando criar o jogo, acaba com um sistema monolítico. É muito, muito difícil conseguir um mecanismo de jogo e aprender a exibir um pixel, então perceba que ele não pode fazer isso porque vê tudo como uma textura. Você não precisa lidar com isso quando escreve o seu próprio.
Dmitry

18

como disse Josh Petrie :

" Síndrome não construída aqui ;"

Também estou escrevendo meu próprio mecanismo, e suponho que o motivo será diferente para todos os desenvolvedores existentes, mas, na verdade - geralmente não gosto de trabalhar no código de outras pessoas. Sou compulsivo no sentido de que, se sinto que posso construí-lo, não há sentido em me contentar com outra coisa .

Eu testei vários tipos de mecanismos de jogos, renderizando API e outros, como Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, etc. muitos mais ... Eu queria começar a escrever jogos - baixei muito procurando um bom conteúdo e ponto de entrada bem documentado ...

Meu problema, no entanto, era que eu não fazia ideia do que estava acontecendo abaixo do motor. Eu queria um bom controle e uma estrutura que eu conheça como as costas da minha mão. Eu tive a idéia "Ei! Acho que a única maneira de aprender como a coisa funciona e entender é tentar construir meu próprio mecanismo de maneira completa e completa do zero. A maior parte do meu histórico de programação foi com soluções de processamento e web - este foi um jogo totalmente novo para mim.

Foi o que acabei fazendo.

Então, escolhi configurar o XNA já que conhecia C # e comecei a pensar em como ou por onde começar. Eu precisava de uma ideia.

Eu decidi que, não importa o quê, eu iria direto para o 3D .

Descobrir o básico foi legal - o material do lote de sprites, mas à medida que progredi acabei descobrindo novas barreiras e obstáculos - o meu primeiro verdadeiro sendo o limite do lote . Meu objetivo era construir um jogo que pudesse render pelo menos 10000 entidades no view frustum a qualquer momento.

Eu iniciei uma nova jornada de implementação do Shader Based Instancing (e aprendi HLSL enquanto estava no assunto), abandonei os objetos Model and Effect embutidos no XNA para escrever minhas próprias substituições. Eu tive problemas para entender os fluxos VBO no início; Eu quebrei as coisas - fiquei on-line fazendo perguntas sobre o material instanciado e continuei até finalmente entender o que a GPU estava fazendo. Valeu a pena; agora eu tinha mais de vinte mil entidades de teste dando zoom na minha viewport depois de alguns dias depurando meu VBO com PIX (dxsdk).

Agora eu tinha "alguma" idéia de como os pipelines de renderização funcionavam, mas ainda não haviam terminado - acabei criando meu próprio estado de jogo, câmera, pós-efeitos e objetos de entidade, afastando-me do XNA Content Pipeline construindo meu próprio Os carregadores (antipatia pessoal em relação à coisa XNB), criaram uma cadeia de geometria complexa, classificada em profundidade e com estado de mistura, e também instanciava sprites e texto sendo projetados na cena do jogo.

Continuei adicionando, consertando, mudando e experimentando isso continuamente por quase um ano inteiro. No final, saiu muito bom. Agora eu tinha uma compreensão do que está acontecendo sob o capô, porque eu o criei - meu bebê.

Agora meu motor estava praticamente estável e quase acabado. Não é perfeito: o script é honky e a GUI não era ótima. Mas eu ainda adorei. Milhares de linhas de código, ativos e mídia - escondidas em um repositório git privado de 2 GB e todas as dores de cabeça que tive que passar ao tentar fazer um tipo de desenvolvimento que nunca fiz antes. Todo obstáculo que superei foi uma lição aprendida - e um alívio.

Tirei quase tudo o que queria nele.

Mas no final - eu decidi que era hora de colocá-la no chão. Por mais que me satisfizesse escrevendo um mecanismo tão grande sozinho, com conselhos da rede e de outros amigos do jogo, decidi que faria tudo de novo - e melhor - porque agora desta vez eu sei principalmente o que eu estou fazendo.

Esse projeto ainda está escondido no meu repositório GIT.

Minha segunda passagem para escrever um novo mecanismo (desta vez no MonoGame) está progredindo bem. Quando algo quebra, é mais fácil de corrigir. Menos bagunça. Espero mostrar publicamente meu jogo em algum momento deste ano, porque tendem a ser um pouco "muito" apegados ao meu código.

No final, escrevendo meu próprio mecanismo é como aprendi 'como' fazê-lo, enquanto sou capaz de dizer que sei e entendo exatamente o que cada componente faz e como eles devem funcionar. Na verdade, eu odeio ler o código de outras pessoas, especialmente para grandes projetos não documentados. Quero que tudo o que eu use seja construído por mim.

Este sou apenas eu. Duvido que algum dia use um mecanismo pré-fabricado, provavelmente porque acho mais divertido escrever minhas próprias estruturas do que sentar e lidar com o código de outra pessoa - controle total.


13
Isso parece muito mais com uma anedota pessoal desmedida; você provavelmente poderia editar isso para torná-lo muito mais conciso e seria uma resposta melhor.
Josh

2
Isso certamente é ótimo para aprender e também para criar seu jogo quando você tem tempo para fazer tudo. Quando de fato é só você. Mas e se você quiser colaborar com alguém? Ou trabalhar em uma empresa com outros programadores? Se alguém gostaria de participar do seu projeto, não é um pouco estranho que eles devam ler seu código - para o código de outras pessoas ... exatamente o que você odeia. Acho que a leitura de código também é uma habilidade muito importante. Sem ofensas, tenho certeza de que você aprendeu muito e escreveu um mecanismo interessante - apenas uma nota de que não é tudo o que existe.
Antont

Estou ciente disso, apenas todo trabalho que tive envolvendo qualquer tipo de código em qualquer idioma sempre foi solo para mim;
Codie Morgan

Devo dizer que sei exatamente por que razões uma pessoa lança seu próprio motor / ferramenta / qualquer coisa. Mas tem um preço (como todas as coisas) ... Eu tenho a sensação de que todos os chefes simplesmente o odeiam quando você não consegue ler / entender o código mais péssimo do mercado, então vá em frente e se jogue como ** * toneladas de códigos mal escritos e mal conservados, sem documentação, basta ter uma idéia dele (o mundo "real"). Sem ofensa.
Quonux 26/09/14

Essa é a razão pela qual nós, programadores, não podemos ter coisas boas. Porque sempre queremos fazer tudo sozinhos, em vez de usar métodos confiáveis ​​e de trabalho. Eu tenho necessidade compulsiva de escrever tudo sozinho, mas estou lentamente aprendendo a confiar nos outros e até agora me faz mais bem do que mal :)
Maurycy

15

A principal razão absoluta para escrever seu próprio mecanismo (e me surpreende que ninguém tenha dito isso ainda) é a depuração .

Se você escreveu um jogo grande e complicado, e há um bug de falha nele, e você possui o código fonte (e está intimamente familiarizado com esse código fonte em virtude de ter escrito), você pode simplesmente anexar um depurador ao o processo e descubra o que está causando a falha. Feito.

Se você estiver usando o mecanismo comercialmente disponível de outra pessoa e não tiver o código-fonte para esse mecanismo (normalmente não o faz), a depuração de qualquer problema que surgir - mesmo dentro do seu próprio código - continuará ser monumentalmente mais difícil. E se você encontrar um bug dentro do próprio mecanismo, não poderá resolvê-lo sozinho. Como você gostaria de ficar uma semana fora da data de lançamento e pedir para alguém descobrir um bug de falha no mecanismo que você está usando - um bug de falha que você não pode consertar porque está dentro de um mecanismo proprietário ao qual você não tem o código fonte? Vi isso acontecer - você não tem escolha a não ser fazer uma ligação urgente de suporte com o fornecedor e esperar que ele possa (e esteja interessado em) corrigir o problema para você, enquanto você brinca,

O desenvolvimento de jogos é difícil, mas a depuração é uma ordem de magnitude mais difícil. No meu livro, qualquer coisa que dificulte o desenvolvimento de jogos, mas seja mais fácil a depuração, é uma enorme vitória líquida.


3
Essa é uma grande vantagem que experimentamos ao usar um mecanismo de código aberto (cocos2d-iphone). Podemos depurá-lo exatamente da mesma maneira que o código que escrevemos. Na verdade, acho que a maneira de pensar em código aberto é que é o seu código. Se houver erros que vamos ter de corrigi-los, como em qualquer outra parte do nosso código ..
antont

1
Isso pode ser dito de qualquer middleware. O código de depuração é 80% do trabalho de um programador, e o manuseio de middleware é um problema comum com a tecnologia em que estamos hoje, com mais middleware do que podemos contar. Aprender a superar isso é apenas parte do trabalho. Se o motor não quebrar, outra coisa que você não tem controle sobre a vontade. Menos partes móveis são uma boa ideia, mas quando ficar complicado como o desenvolvedor de jogos, você terá que lidar com muitas delas de qualquer maneira.
Tim

@ Tim Eu discordo veementemente - que uma coisa externa possa se comportar mal de uma maneira difícil de depurar não implica que devemos apenas dar de ombros e nos resignarmos a deixar que tudo se comporte de maneira difícil de depurar. Obviamente, é preciso levar as coisas caso a caso, mas um mecanismo é um grande sistema em que erros complicados geralmente se escondem. Por que você não quer isso sob seu controle, se você pode se dar ao luxo de fazer isso sozinho?
Trevor Powell

@TrevorPowell Obviamente, tudo se resume à complexidade do projeto e, como você diz, caso a caso, mas simplesmente reinventar uma roda (especialmente se for uma roda grande) precisa ser seriamente considerado em relação ao tempo economizado por não fazer isto. O middleware facilita as coisas. Como desenvolvedores, acreditamos que sempre podemos reinventar uma solução para torná-la melhor sem considerar o quão bem essa solução é montada. Alguns solavancos> reinvenção> A solução errada completamente
Tim

2
@ Tim RE: "Middleware facilita as coisas", tive experiências muito diferentes das suas, aparentemente.
Trevor Powell

9

Há respostas muito boas aqui, mas faltam um ponto adicional importante.

Muitos dos mecanismos licenciados de hoje começaram como mecanismos dedicados .

Vamos usar o Unreal como exemplo, porque é tão onipresente.

Hoje, quando você pensa na Unreal, você tende a pensar em um mecanismo licenciado e que pode usar em vez de ter que construir o seu próprio, mas esse nem sempre foi o caso, e uma vez o mecanismo Unreal nem existia como uma entidade separada.

Era uma vez um jogo chamado Unreal . Os desenvolvedores decidiram construir seu próprio mecanismo, em vez de licenciar um mecanismo existente . Avanço rápido em várias iterações e esse mecanismo se torna o mecanismo Unreal que conhecemos hoje.

A questão é que esse é um problema de galinha e ovo. Todo bit de middleware que você pode licenciar começou em algum lugar, e muitas vezes nem começou como middleware (às vezes nem foi escrito com a intenção de se tornar middleware e seu status atual é efetivamente um acidente ). As pessoas escrevem seus próprios mecanismos porque, em última análise, alguém precisa escrevê-lo, e o mecanismo dedicado de hoje pode se tornar o middleware licenciável de amanhã.


2
Vale ressaltar que, antigamente, quando os jogos como Unreal foram construídos pela primeira vez, simplesmente não havia outra opção como escrever tudo do zero. É apenas o passado casal de anos em que temos uma escolha de N motores ...
joltmode

3

Há outras razões pelas quais um estúdio pode optar por "construir" em vez de "comprar" sua tecnologia:

  • Novas plataformas : novo sistema operacional móvel, console ou controladores. Pense em leapmotion, google glass, etc. O suporte a várias plataformas é difícil
  • Nova mecânica de jogo e / ou editores no jogo : Pense no FEZ, há alguns anos (2D vs 3D)
  • Falta de bons editores de jogos de código aberto gratuitos . Falta de boa documentação sobre a fonte existente de jogos antigos
  • Evolução das ferramentas na cadeia de ferramentas do estúdio (ou adicione novas)
  • Preços de motores e guerras de licenças

Também concordo com solicitações / necessidades específicas, e preços de mecanismos e guerras de licenças forçam alguns estúdios a implementar alguns mecanismos.

Os bons motivos para "comprar" ou "usar" outros mecanismos são:

  • Reutilização de código : um mecanismo já usado em outros jogos é mais testado, mais estável e pode ter a maioria dos recursos necessários, a partir do primeiro dia.
  • Estender : você pode estender alguns mecanismos de código aberto.
  • Gratuito : ou quase gratuito, já que até os mecanismos de código aberto gratuitos, precisam de algum tempo para o desenvolvedor aprender.

2

Razão histórica (principalmente).
Que está relacionado ao preço.

Todos os jogos que você assistiu ao Unreal ou CryEngine nos últimos anos tiveram que pagar uma quantia enorme de dinheiro. Especialmente se você deseja obter o código fonte (ou seja: você queria o UE, não apenas o UDK.)

Mas isso mudou. Agora todos podem comprar motores ainda maiores, quando a corrida de preços começou.
O que isso significa...

  • Você verá muito mais jogos usando o UE4 e o CryEngine.
    No entanto, eles não serão jogos AAA como foram.
  • Os requisitos e necessidades personalizados para cada projeto não desaparecem.
    Veja o mecanismo Warhammer40k / COH na Relic ou o que os generais usaram na EA.
    Portanto, mesmo que alguém possa comprar os motores maiores, eles não necessariamente oferecem uma escolha melhor.
  • Existem outros no mercado. Como unidade.
    As pessoas adoram por sua facilidade de uso, desempenho rápido e a enorme loja de ativos.
    Obviamente, o Unity é capaz de implantar em quase qualquer plataforma.

Então sim. Necessidades, preços no passado e tal.


1
Eu não chamaria Havok de "fortemente modificado".
Josh

Havok não é apenas um mecanismo de física?
Philipp

É, e o GW2 não fez muita coisa que me lembro.
Josh

Você não quer dizer (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Desculpe, para ser sincero, eu não sou experiente em Havok / nunca brinquei com ele. Então, eu me deparei com o arquivo LICENSE do GW2 e depois visitei sua página wiki há alguns dias e vi Havok. Então eu tinha uma lembrança antiga de ver "Havok" no início do jogo, onde pensei que esse era o motor. Mas então eu também procurei Havok naquela época e sabia que era um mecanismo de física. tl; dr: Eu misturei coisas sobre Havok. || #Philipp: É um pouco mais do que isso, mas na verdade não é um motor de jogo, meu mal. || #Keavon: Certo, fixo. Obrigado!
Apache

0

E a organização da equipe?

Por trás do material de depuração estão a documentação e o suporte, não o código, porque no final eu não queria que meu grupo de construção tocasse no código do meu próprio mecanismo. Isso pode ser uma bagunça.

Então, eu preciso de um grupo de apoio para fazer isso. Mas isso aumenta os custos: mais pessoas, mais lugares, mais linhas telefônicas, mais administração ...

Uma solução para isso pode ser terceirizada ... para uma empresa de middleware, liberando recursos para o meu negócio de fazer jogos, ou seja, para o grupo criativo e escritores.

Para uma empresa iniciante, não é uma má opção usar e não construir. E, depois de obter uma massa crítica de renda, pode ser, apenas pode ser, você desejará criar seu próprio mecanismo ...


0

bem. para a maioria dos jogos que usam seu próprio mecanismo criado por seus desenvolvedores. frequentemente. eles não podem fazer coisas com o mecanismo de terceiros. então eles fazem o seu próprio para facilitar o desenvolvimento de seu próprio jogo. ou possível, pelo menos.

e muitos jogos que usam seu próprio mecanismo de maneira geral. trabalhe melhor. porque são mais personalizados e 100% adequados à sua tarefa. e o jogo em si parece diferente. é realmente fácil jogar um jogo e dizer que é feito por. motor irreal ou o que quer. geralmente um mecanismo mais personalizado e deve resultar em um jogo único. parece único e funciona de maneira única e deve ter um desempenho melhor do que um jogo criado em um mecanismo pré-fabricado.


0

Minha resposta difere das existentes, então eu a adiciono, embora seja tarde:

Se você pegar o exemplo Valve da pergunta ou a série Witcher, o processo foi:

  • Licenciar um mecanismo
  • Modifique / adapte o mecanismo ao seu objetivo
  • Solte o jogo e gere dinheiro
  • Crie um mecanismo próprio para o próximo jogo

A mesma abordagem é adotada por quase todos os desenvolvedores financeiramente razoáveis ​​que desenvolvem seu próprio mecanismo. Ao modificar um mecanismo, eles adquirem conhecimento de como um mecanismo funciona e se deparam com restrições de design resultantes de um mecanismo licenciado. No final, eles têm o conhecimento interno necessário para criar um mecanismo, o dinheiro para financiar a criação de um mecanismo e um projeto que se beneficiará de um mecanismo dedicado. Nesse ponto, o motivo da construção de um mecanismo é: porque é a coisa mais inteligente a se fazer.


-2

meu professor de programação nos disse, use apenas APIs / métodos / classes / funções que você sabe criar

porque se você não sabe como construí-lo e está usando as chances de trabalho de outra pessoa, não sabe como funciona e quando não sabe como algo funciona, é muito mais suscetível a erros e problemas, atingindo paredes de confusão

aprender coisas simples pode, quando combinada, resultar em problemas estranhos, muito menos em algo complexo como um mecanismo de jogo, especialmente quando você deve usar esse mecanismo para executar seu jogo, o que pode levar a muitos resultados e problemas inesperados

e o mecanismo de jogo não segue código lógico ou qualquer outra lógica quando eles são criados, com certeza há algumas coisas que podem ser esperadas, mas, na realidade, tudo será construído com base em alguém que entenda e tenha conhecimento de alguma linguagem de programação ou como funciona algum sistema

por exemplo, se eu optar por escrever uma equação matemática, eu posso escrevê-lo de várias maneiras, posso representá-lo com polinômios, cálculo diferencial ou geometria básica ou álgebra ou o que for mais adequado para mim, mas às vezes eu escreveria em uma determinada forma / formato, porque eu quero para poder manipular o que está facilmente disponível, como se eu planejasse fazer muita manipulação de vértices, eu poderia escrever esse modelo matemático usando geometria básica; no entanto, se eu quisesse mudar a curva usando gradientes, poderia me concentrar no cálculo diferencial para poder para manipular facilmente os gradientes, etc, e o mesmo vale para o que quer que eu planeje ter acesso mais fácil a

e, às vezes, o mecanismo de jogo atual pode não me dar a flexibilidade do que pretendo fazer ou até mesmo oferecer a você essa opção, mas é muito difícil fazê-lo porque o mecanismo de jogo se concentra nas forças da física como sua principal fonte de movimento e manipulação de objetos no jogo

de qualquer maneira, espero ter deixado claro o que eu estava tentando apontar


6
-1 Se você trabalha em um projeto de tamanho respeitável, espera-se que você use funções / classes que você não sabe como foram escritas, e talvez não seja capaz de escrever uma sem ter que estudar o número de livros no tema. Não estou falando sobre o que todo programador deve saber, mas um mecanismo de jogo é um projeto enorme, e espera-se que o tópico especializado X do programador X não tenha conhecimento no tópico Y e, portanto, precise usar a função, também não sou o que implica que você não deve saber como usar a API, mas talvez não tenha conhecimento suficiente para escrever uma.
usar o seguinte

2
Seu professor sabe como construir um carro completo a partir de elementos químicos a partir do zero? Ou ele dirige assumindo que simplesmente funciona ;-)
Kromster diz que apoia Monica

1
@ concept3d existe uma diferença entre trabalhar em um projeto em que outra pessoa projeta as funções / classes que você usa, porque geralmente se você não entende algo, isso pode ser facilmente explicado, um programador que usa classes / funções / bibliotecas de código que ele / ela não sabe que é uma pessoa tola, até mesmo as classes e APIs disponíveis publicamente vêm com manuais e wiki que explicam o que essas APIs ou funções fazem, apenas esperar usá-lo sem saber o que faz é como tentar nadar águas profundas sem saber nadar, e realmente ignorante e propenso a erros
thingybingytie

@ hopjoppe5 Se você verificar a resposta aceita, esses são os únicos motivos pelos quais as pessoas constroem sua própria tecnologia. Muitas bibliotecas / códigos são terceirizados no mundo real, e você precisa usá-lo. A leitura dos manuais é diferente de conhecer a implementação. Para alguns algoritmos, você é desencorajado a implementá-lo e deve ser implementado por especialistas no assunto. Se você teve alguma experiência no mundo real, entenderá isso. Saber tudo é impossível.
precisa

Um dos principais motivos da abstração é escrever código para que as pessoas que não sabem como ele funciona ainda possam usá-lo. Ao trabalhar em um jogo maior que o pong, não é provável que você esteja familiarizado com cada pedaço de código. E, na maioria dos casos, isso é uma coisa boa, porque significa que você pode focar sua mente no que está trabalhando no momento, em vez de se preocupar com o modo como o sistema de entrada pode lidar com sua solicitação de um evento "On Action Key Down".
Aidiakapi 23/09/2015
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.