Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Nowadays, game programming is like a big business-ish, technological, academical, programming havoc. There are dozen of engines, free or not, don't-reinvent-the-wheel dos and don't, plenty of different platform, plenty of game genres, and a lot of languages.

The video game economy boomed around the 90's (I guess, with the NES etc), and just before that, I wonder how game programmers were doing their job, what languages they used, what was the equivalent of the current "dev kit", anyways what were those few guys technics and tools to achieve a working game on such tiny computer power ?

I read that the playstation had only 3MB memory total: besides CD-swapping, how could they achieve to build an executable to hold on 2mb or ram, for complex games like Metal Gear Solid or Vagrant Story ?

Since I'm young and I missed all that, I have some questions...

Were game makers only or most programmers ? Why do I think a game programmer who has played a lot, has a more important role that game designers, 3D artists, because they know how a game is really made ? Since C was invented in the 70, did all programmers use it, or were they forced to use ASM to get the best optimisation ? Is being a game programmer a safe job (I mean in the job market) ? Since computers are so freaking fast today, how has the optimisation task changed ? Do we use computer/console power to their maximum, or do we waste it because we can't come up with complex enough gameplay ?

share|improve this question

closed as too broad by congusbongus, Kromster, Alexandre Vaillancourt, Josh Petrie May 29 at 21:20

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Wow, so many questions in one thread. Please spin off different questions into different threads. – Noctrine Sep 1 '10 at 14:01
-1, there isn't really a single question here that can be answered. – Tetrad Sep 1 '10 at 16:25
@Tetrad, how do you figure? – dash-tom-bang Sep 1 '10 at 20:47
I mean no single question in that there's just a jumbled mass of unrelated questions (could you mark a single answer as "accepted" for the question and have it make sense?), not that a single portion of it couldn't be answered. – Tetrad Sep 1 '10 at 20:59
@Tetrad, why not either close it or wiki it, then? – Cyclops Sep 2 '10 at 0:23
up vote 2 down vote accepted

Remember a lot of memory is blown by resources. On the PSX you had much less vertex throughput so models were smaller by default, no shaders so vertex data was smaller, and also the killer resource - textures, were smaller as they were not 32 bits but generally 8 bit palettized. Audio was either streamed from CD or in a mod/midi like format - no MP3 or wav eating memory like there's no tomorrow. On generations before that, there was no textures, and audio was a table of note pitch/note length mostly
As for assembly vs C, yes there was a C compiler for the PSX but it was relatively immature, we recoded our 3d engine in assembly in order to squeeze out performance, and it paid off. I guess it's also a mindset thingy, if you know you code in assembly you keep performance in mind, if you code in C (let alone C++) you might not think about it continuously.

share|improve this answer

You may find the Tonc Tutorials, which cover the GBA, quite interesting from a hardware history standpoint. I can also highly recommend the iPhone apps 2600 Magic and Dragster Magic for a look back even further toward the dawn of consoles.

I can also recommend Steven Levy's book Hackers: Heroes of the Computer Revolution, which covers a lot of the game industry's formative years.

To address one specific question:

Most computers/consoles, old or new, are not used even close "to their maximum" until they've been around for several years; as the developers get used to them and learn (and sometimes share) tips and tricks, the games come closer to utilizing the "full potential" of the hardware. (However, even on "ancient" systems, it's going to be hard to say if you ever really reach 100% potential -- there are always crafty ways remaining to use these complex systems which may eek out more performance or new behaviors, and I'm sure there are a few centuries worth of computer science advances left in humanity.)

share|improve this answer

Were game makers only or most programmers?

In the earliest days of arcade games, and later Atari home systems, Spectrums, and C64's you would often have 1-2 man teams where people all had multiple hats and nearly everyone could program. By the time you hit the NES and later the art requirements for games required people dedicated to that role full time, and audio also had full time individuals who were often shared between multiple concurrent projects. Design was often someones part-time role, and not a dedicated field.

Old games, how the F&%K did they work?

You look at the power of machines in the past with the ability to compare them to machines today. At the time those things were pretty fast, even if every machine has it's specific weaknesses. 20 years from now people will look back at x360/ps3 and wonder how we dealt with them.

You just learn to deal with the issues, no different than using any other tool.

Do we use computer/console power to their maximum, or do we waste it because we can't come up with complex enough gameplay?

Actually it's the opposite. The more simple the gameplay the more power you can utilize from the machine. If all you want to do is throw polygons at the screen you can easily optimize that. As games get more complex we start throwing more and more systems together and being able to predict what's going to be on screen at any moment becomes more difficult. So everything has to be more general purpose and thus less efficient.

share|improve this answer
Regarding the last answer, I think he meant "or can't we come up with gameplay that is complex enough to even require optimisation" (which I think we definitely can and do) – Bart van Heukelom Sep 5 '10 at 21:37
"You look at the power of machines in the past with the ability to compare them to machines today." I believe it was easier back then, since you only had to support one processor architecture, with one ASM manual which contained EVERYTHING you needed to know. Nowadays you have layers upon layers of abstractions, a lot of different processors and operating systems, people who are experts in networking, graphics, design, etc. – rootlocus Dec 19 '14 at 13:52

As far as I know, all Atari 2600 games (released in 1983?) were programmed entirely in assembler. The Atari Jaguar had a compiler, but my understanding is that it never actually worked reliably enough to use.

The Sony PlayStation had a C compiler that worked well, so by that time we were coding in C. (This is when I joined the industry.) This machine had 2M RAM and 1M VRAM. So how did you do it? Well- the first game I shipped on it had a separate executable for each level, with all of the assets baked into the executable itself. After that though we went to a setup that allowed us to stream everything; our levels were 10+ megabytes so we had to come up with some way to bring it in bits at a time. When streaming off of the disc, we streamed in terrain chunks and the textures that went with them. Some modern PSP games on the other hand stream almost everything; area-specific animations for the player, enemies, and whatever else isn't necessary throughout the whole game. I.e. we wouldn't stream the player character because he's needed everywhere.

Remember, the PlayStation was CD-based. CDs could hold 660 megs of stuff, so you could fill memory 300 times over just with what was on one disc. The PSP's 1.8Gb UMD relative to its 24M RAM isn't quite that ridiculous, but still you can put a lot of stuff on the disc, the trick is getting it off at the right time without presenting the user with a "loading" screen.

share|improve this answer
So basically you created the progenitor to megatextures and 'megameshes'? :) – Jonathan Dickinson Mar 13 '12 at 16:22
I don't know about that; we did what made sense to us but there was nothing automatic about it either. It was a pretty low-tech solution to us. We wanted levels to be bigger than what would fit into memory so this was the solution! – dash-tom-bang Mar 20 '12 at 1:31

You may find this interesting: Llamasoft History

It's all about how Jeff Minter (Yak) got into both programming and game development, which led him to start Llamasoft in the early 80s.

share|improve this answer

I know the question is already answered but there is a great book by Steven L. Kent called The Ultimate History of Video Games it actually starts off with coin-operated games like pinball and works into the video games beginnings. I would recommend you check it out if you are looking to read about the history of games.

It really gets into details about how certain things were done and Mr. Kent interviewed a lot of people involved in the industry from the past and present.

share|improve this answer
I love this book! I often just open it to an arbitrary page and start reading. – kirk.burleson Nov 6 '10 at 14:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.