Tamanho dos jogos 2D atuais

[Sergiodesjg]

Uma coisa que sempre me chamou a atenção quando comparo os jogos 2D do passado com os atuais é a diferença de tamanho dos jogos.

Exemplo disso é que quando criamos um jogo no Game Maker ele dificilmente sairá com menos de 2 ou 5 megas, enquanto que já encontrei jogos antigos melhores dos que consigo fazer atualmente, mas na casa dos kbs.

Compreendo que existe entre eles as diferenças de resoluções de telas e qualidades das imagens usadas nas Sprite, mas me pergunto qual o tamanho da influência da programação e da ferramentas que usamos nesse tamanho? E quais os melhores formas de criar coisas leves?

Pois para mim, seja programas ou jogos, quanto menor e mais leve, melhor.

[chicoweb]

Eu também já havia reparado nisso, mas você deve levar em conta que no game maker que o executável dele esconde arquivos do directx, por exemplo o "data.win" só ele tem mais de 30 mb quando descompactado. Nas outras engines eu não sei se isso acontece se alguem ai souber por favor comente.
Mesmo assim ele fica grande com 5 megas ou mais, jogos feitos diretos no c++ ficam bem menores.
Eu lembro do prince of persia que cabia em um disquete, significa que ele tinha menos de 1,44 mb.
 
Mas hoje em dia o tamanho dos games 2d não compromete o desempenho do jogo, esse desempenho ainda continua dependendo 90% da programação mesmo.
Qual quer windows xp com 2 gb de memoria com directx roda eles de boa.

[WellingtonBecker]

Jogos da era 8 e 16 bits eram feitos com outros programas mais básico como o "assembly" por exemplo. Sons em midi e sprites feitos em pixel art reproduzidos em uma resolução bem menor de escala, ou seja, não existe comparação com o que é feito hoje em dia. O game maker por exemplo já carrega varias instruções atrelado ao seu jogo automaticamente no executável, deixando-o maior ainda.

[Superbomber]

Apenas uma correção rápida: Assembly é uma linguagem de programação. Não sei se foi um erro de digitação ou uma confusão, mas eu preferi deixar claro. :)

Enquanto ao tópico, é como foi explicado.
Com o passar dos anos novas tecnologias foram sendo desenvolvidas, facilitando o trabalho do programador e dando praticidade.

Como também já foi citado, o GM utiliza do DirectX. Este que por si ocupa muito espaço. (é um exemplo de tecnologia nova)

Os sprites antigamente era um formato básico, uma simples sequência de píxels com 16 possibilidades de cores. O que ocupa muito pouco espaço comparado as milhões de cores suportadas hoje em dia.
Os sprites antes eram apenas dados de valores de píxels incluso ao jogo, hoje é um arquivo separado. (só manjando de Assembly para entender)

E como foi citado pelo Wellington, o áudio era em formato Midi. Este que não passa de uma sequência de informações tipo: "delay de 5 milissegundos, bip na tonalidade 47, delay, tom 49, delay, tom 155..." (não necessariamente é assim, estou apenas exemplificando)

Enquanto os efeitos sonoros de hoje são gravações, ondas em sequência o que ocupa muito mais espaço que uma simples sequência de tons e delays.

Mas nada impede de fazer jogos pequenos hoje em dia, é só a forma que você está fazendo que o torna grande e não a época. :)
Se você não utilizar uma Game Engine terá um código completamente puro, o que irá resultar em um jogo com melhor desempenho e menor.

Pode usar C/C++, C#, Java... Ou Assembly. :D

Para você ter uma ideia, utilizando o montador FASM você pode criar um .exe de 2 KB.

Até mais.

[gillenew]

pegue o construct2 e compile o jogo em html5, se os gráficos forem pixel art então é bem provável que ele fique leve, talvez com poucos MB

[Sir Metang]

Li uma vez que isso era simplesmente porque o GM compila todas as funções mesmo se não forem utilizadas (é como o Direct X).

[Sergiodesjg]

Agradeço a todos pelas informações, elas me serão muito úteis.

Avaliando meus projetos mais pesados e baseado nas informações que vocês me deram, conclui que o maior peso desses projetos estavam nas imagens mesmo.

Mas todas as informações foram importantes para eu entender o peso da programação no jogo e também ficar por dentro das linguagens mais leves, entre outras coisas. Valeu.

[WellingtonBecker]

Apenas uma correção rápida: Assembly é uma linguagem de programação. Não sei se foi um erro de digitação ou uma confusão, mas eu preferi deixar claro. :)

Sim, acabei escrevendo errado, obrigado pela correção.