Como o desenvolvimento de jogos é diferente de outro desenvolvimento de software? [fechadas]

18

Para um desenvolvedor de software de uso geral sólido, o que especificamente é diferente no desenvolvimento de jogos, fundamentalmente ou apenas diferenças de grau?

Eu fiz jogos de brinquedo como Tic-tac-toe, Tetris e um solucionador de sudoku de força bruta (com interface do usuário) e agora estou embarcando em um projeto de tamanho médio (tamanho médio por ser um desenvolvedor único e não ter fiz muitos jogos) e uma coisa que descobri nesse projeto em particular é que a separação de preocupações é muito mais difícil, pois tudo afeta o estado, e cada objeto pode interagir com todos os outros objetos de inúmeras maneiras.

Até agora, consegui manter o código razoavelmente limpo para minha satisfação, mas acho que manter o código limpo em jogos não triviais é muito mais difícil do que no meu trabalho diário.

O jogo no qual estou trabalhando é baseado em turnos e os gráficos serão bastante simples (baseados na Web, principalmente através da manipulação do DOM), de modo que o tempo 3D e o trabalho em 3D não sejam realmente aplicáveis a mim, mas eu ainda seria interessado em respostas relacionadas a essas, se forem interessantes. Principalmente interessado em lógica geral do jogo.

PS Sinta-se à vontade para refazer a marcação, não tenho certeza de quais tags são aplicáveis.

game-design

— Davy8
fonte

23

Há uma grande diferença. Na minha opinião, é a única diferença que realmente importa.

Podemos revisar os detalhes técnicos de por que é diferente, com certeza. Motores 3D, física de partículas, muitas coisas diferentes entram em jogo.

Mas muitas formas diferentes de software têm amarras. O software de modelagem precisa fazer as mesmas coisas. Todo software importante possui uma biblioteca especializada que precisa ser usada.

Então, o que torna os JOGOS diferentes?

Aqui está: O software foi projetado para atender a uma necessidade comercial. Você quer um sistema de inventário? Você pode definir quais tipos de itens você deve manipular. Você pode definir o que deseja para sua programação de produção. Você pode fazer tudo isso. Ou, se você deseja um software bancário, pode definir o que deseja fazer com ele.

Com os jogos, sua necessidade comercial é "divertida". Tente escrever uma especificação técnica para "diversão".

Na minha humilde opinião como desenvolvedor, isso é o que torna os jogos diferentes dos softwares comuns. Você simplesmente não pode dizer "Ótimo! Este software agora está completo, conforme as solicitações do cliente!" porque tudo o que eles querem é se divertir.

Dito isto, você não precisa de gráficos 3D e física extravagante para que algo seja divertido. Por que as pessoas ainda jogam Tetris? Sua física consiste em "mover o bloco para baixo", "não deixar o bloco sair dos limites" e "parar o bloco quando bate em alguma coisa" e, ao longo dos anos, houve inúmeras versões, algumas com gráficos mais sofisticados do que outras, mas o linha inferior é - é divertido !!

Portanto, se você quer ser um ótimo desenvolvedor de jogos, não jogue fora o que aprendeu como desenvolvedor de software comum. Ainda é uma coisa muito útil. E o @Sion está certo em separar seus componentes, como faria em um software comum. Mas o recurso mais importante que você pode adicionar ao seu jogo é divertido. Divertido divertido divertido divertido divertido. É por isso que o desenvolvimento de jogos existe, é isso que você precisa para tornar seu jogo bem-sucedido. E confie em mim, por mais divertido que seja jogar, é pelo menos 10 vezes mais divertido de se fazer !!

Boa sorte com seu jogo-dev'ing !! : D

— corsiKa
fonte

2

Se você trocar "divertido" por "útil", acho que enfrenta o mesmo problema ao criar um produto (em vez de escrever um software para um cliente). Suponho que exista uma diferença de grau. Às vezes, as pessoas estão erradas sobre o que seria útil, geralmente não têm idéia do que faz com que algo seja "divertido" para elas. (+1 embora)

— Davy8

1

Houve uma infame decisão da corte suprema em relação à indústria de filmes adultos e o que classificou de "hardcore" nos anos 60. A justiça disse: "Eu nunca conseguiria [defini-lo], mas eu sei quando o vejo". Eu acho que o mesmo pode ser dito por diversão. Quero dizer, posso anotar as coisas que gosto nos jogos, mas muitas vezes me vejo jogando e me perguntando "O que torna isso divertido?" (Obviamente, eu quero saber para que eu possa recriá-lo em um dos meus jogos!) As pessoas não sabem o que torna uma coisa divertida, mas definitivamente sabem quando a encontraram!

— 27611 corsiKa

Eu realmente gostei desta postagem. Você está tão certo. Eu realmente gosto de desenvolvimento de jogos, mas não tenho em mim o que é "divertido" para as pessoas "comuns". Que teve o efeito que eu só fazer jogos que eu e alguns outros mergulhões como eu como :)

— Phil

1

@ Phil e isso é bom. Se você sabe o que é divertido para você, é preciso lembrar que existem apenas algumas centenas de arquétipos de personagens neste mundo. Olhe ao redor do seu local de trabalho e combine as personalidades de seus colegas de trabalho com aquelas com quem você estudou no ensino médio ou na faculdade. Você verá que a maioria deles pode ser comparada. Então, se algo é divertido para você, provavelmente será divertido para mais pessoas do que você imagina. O truque é fazer com que eles saibam sobre o jogo para que possam se divertir!

— corsiKa

Esta é a melhor resposta que eu vi até agora. Existem vários artigos para idéias de nichos de negócios de software e assim por diante, mas não muitos sobre desenvolvimento de jogos. Hmmmm.

— 31916 johnny

21

Sou principalmente um desenvolvedor de jogos e não um desenvolvedor de software tradicional, mas acho que existem várias diferenças importantes.

Essas são obviamente várias generalizações e não são abrangentes:
equipes maiores. Origens mais variadas (artistas, programadores, produtores, com cada uma delas há ainda mais variação). Ciclos de desenvolvimento mais longos. Padrões mais altos de desempenho. Maior escala de projetos. Risco maior e mais caro de falha. Ambiente mais estressante.

Quanto às interações com objetos e ao layout de sua arquitetura, você ainda pode desacoplar adequadamente os sistemas. Seus objetos e comportamento de jogo terão claramente dependências um do outro e desses sistemas. Essa é a natureza do jogo (trocadilhos), ele combina todos esses sistemas em uma única unidade coesa, e não há nada de errado nisso. Pode parecer assim, porque a escala de tudo isso é maior do que você está acostumado.

Alguns sistemas facilmente identificados e segregados?

Detecção de colisão
Resposta à colisão
Física
Animação
Gráficos (2D e 3D)
Inteligência artificial
Entrada do Usuário
Entrada / Saída de Arquivo
Trabalho em rede

— Sion Sheevok
fonte

+1 para uma boa resposta para a pergunta, embora, no meu jogo em particular, eu não precise lidar com a maioria delas (baseada em turnos e baseada em blocos, para que não haja colisões reais, física ou gráficos, que consistam em sprites e joguem mais JQuery para ele, para 2 jogadores, portanto, sem IA, as entradas do usuário são tratadas principalmente de maneira RESTful, que também cobre o aspecto da rede) Não sei bem o que você entende por File IO, exceto por salvar / carregar um jogo. tipos de IO são necessários em jogos típicos?

— Davy8

4

Concordo com a maior parte deste post e recebo +1 de mim, mas questionaria a linha "maior e mais caro risco de falha". Se você trabalha em um banco, uma grande empresa de manufatura ou um site de tráfego muito alto, sua falha pode ser medida em centenas de milhares por minuto de tempo de inatividade como resultado de uma falha. Em uma hora, você pode perder (em vendas perdidas, clientes perdidos, etc) mais do que alguns meses em lojas de jogos para desenvolvedores, no valor total da folha de pagamento. Não estou dizendo que não pode ser grande, só estou dizendo que não estou convencido de que seja maior que o software tradicional.

— 27611 CorsiKa

@glowcoder Eu sei o que você está dizendo, mas acho que também entendo o argumento que Sion está tentando dizer, que nos jogos geralmente todo o projeto é um sucesso ou um fracasso, e geralmente é um fator do que você mencionou na sua resposta : é divertido? Você pode fazer correções para bugs, mas não pode corrigir falta de diversão.

— Davy8

3

Não estou absolutamente convencido de que "equipes maiores" sejam verdadeiras, mesmo como generalização. Certamente, os jogos AAA têm grandes equipes - mas o mesmo acontece com produtos de software não relacionados à complexidade. Um grande número de jogos é produzido por indivíduos ou equipes de duas ou três pessoas.

— Peter Taylor

@ Davy8 oh se apenas o sucesso comercial de um jogo fosse proporcional ao quão divertido é. :)

— tenpn

2

Eu não acho que a programação de jogos seja diferente de outros domínios de aplicativos, do ponto de vista de ser mais difícil escolher a separação certa de preocupações. Sempre que você levar suas habilidades para um tipo diferente de domínio de aplicativo, descobrirá que a transição não é tão suave quanto você poderia esperar, porque sempre há diferenças. O que funcionou em seu aplicativo de banco de dados tem muitos padrões / expressões que não funcionam tão bem em seu aplicativo incorporado, que possui muitos padrões / expressões que não funcionam tão bem naquele sistema em tempo real que também possui muitos padrões / expressões que não funciona na programação de jogos. No entanto, os programadores de jogos têm os mesmos problemas quando deixam o domínio de programação de jogos. É tudo apenas uma questão do que você está acostumado.

Com isso dito, acho que a programação de jogos parece mais difícil para muitas pessoas, porque exige que você trabalhe com partes do computador com as quais a maioria dos programadores nunca precisa lidar no seu trabalho real (gráficos e sons de baixo nível) e mais matemática aplicada do que muitas as pessoas se sentem à vontade e não por causa da separação de preocupações. Embora sempre haja dificuldades para determinar a escolha certa para a separação de preocupações, acho que a dificuldade com a separação de preocupações que você está enfrentando é simplesmente mudar para um novo domínio do problema. Depois de criar alguns aplicativos, será como qualquer outra coisa, você aprenderá o que gosta e não usará o que não gosta.

— Dunk
fonte

0

e uma coisa que eu descobri com esse projeto em particular é que a separação de preocupações é muito mais difícil, pois tudo afeta o estado, e cada objeto pode interagir com todos os outros de várias maneiras.

Eu acho que você tem uma resposta lá, existem muitas interações. Eu fiz alguns jogos com XNA (C #), agora estou fazendo um jogo de tamanho médio, como você diz, um jogo de simulação de estratégia, trabalhando nele há quase 2 meses e faço sozinho sem ajuda, então eu deve manter meu código simples. Uma enorme diferença, eu acho, é entender e projetar algumas classes para funcionalidade e outras para desenho, isso ajuda e torna seu programa mais limpo. Obviamente, se você estiver fazendo um jogo, precisará ter mais recursos, como imagens (2d ou 3d) e música (ou sons). Então existem diferenças, acho mais difícil, mas muito engraçado.

— Zukki
fonte

0

Eu acho que a programação de jogos é mais divertida. Você pode testar constantemente seu jogo, implementar uma física diferente, o que resulta em comportamentos diferentes.

Pela minha experiência, a programação de jogos é realmente muito mais divertida em comparação com o desenvolvimento de software. No desenvolvimento de software, você tem certas regras de negócios a serem seguidas, fica um pouco chato. Você está criando um software, não é divertido. O uso de software é ótimo, útil, útil, mas não divertido.

Jogos são divertidos. Talvez seja apenas eu, mas acho o desenvolvimento de jogos muito mais intrigante e emocionante do que o desenvolvimento de software tradicional, independentemente do uso das ferramentas.

PS: Eu uso as ferramentas mais recentes para desenvolvimento de software, HTML5, Asp.Net, C #, etc. Ainda acho o DirectX, UDK, XNA, Unity mais divertido de codificar.

— harsimranb
fonte