What kind of programming tools did the programmers of the successful 80ies Arcade games use, to compile their programs? I assume they must have used some kind of assembler program. But, they could not use any object oriented programming language. How could they manage their code? Most of the games are extremely complex, even for today's standards. How could they make such advanced, creative games, without todays comfortable, stable programming tools? (maybe this thread should be in the lounge, i'm not sure)

They used assembly language and/or C. Usually. Some companies had their own weird, in-house toolkits, but in the main, it was just assembly language or C.

I started out coding for 8-bit microcomputers -- now there's a term you don't see much these days -- initially in BASIC, but then in assembly language (usually Zilog Z80A or, occasionally, 6502.) Even on the Atari ST and Commodore Amiga, I preferred Motorola's 68000 assembly language. I only bothered to learn C in the early '90s, when the PC finally began its inexorable rise to prominence in the UK's computer games scene.

You can find out how some early handheld "Game & Watch"-style games were made on Tom Sloper's website. Check out the devkit on that page.

It helped that the computers of the era were pretty simple. The Sinclair ZX Spectrum, for instance, had absolutely _no_ hardware acceleration for _anything_. If you wanted to display a sprite on the screen, you'd have to draw it, byte by byte. If you wanted to clear the screen for the next redraw, you had to physically set each byte of the memory set aside for the display to zero. (I still remember setting the stack pointer to the end of said memory and pushing zeroes onto the stack in a loop to do this. It was quicker than using a more traditional loop.) Sound was generated by physically telling the speaker to move in or out. (The original Spectrums only had a beeper, much like that on a PC. Later models had the popular General Instruments AY-8912 sound synthesizer chip.)

You didn't have to worry about umpteen APIs and code libraries written using umpteen coding standards: you had to create your own! Of course, once you'd written your own libraries of utilitiy code, you were so familiar with it that cranking out new games became much easier.

Games of that period may have looked complex, but they weren't really. Much of the depth and complexity is an illusion. Gauntlet, for instance, may have looked complicated for its day, but throwing lots of sprites around on a screen was trivial for the hardware involved compared to writing good AI. Watch the game in action and you'll notice that the monsters are very, _very_ dumb.

Please feel free to add assorted "Bah", "Humbug" and "Kids these days" mutterings to the above.

That's a great link, Stimarco, thank you for that.

Quote:Original post by Marmin
... Most of the games are extremely complex, even for today's standards.
How could they make such advanced, creative games, without todays comfortable, stable programming tools?

The arcade games made 20 years ago were not extremely complex. They were extremely simple compared to games made now or even compared to other kinds of software written back then.

Quote:
The arcade games made 20 years ago were not extremely complex. They were extremely simple compared to games made now or even compared to other kinds of software written back then.

Those arcade games had not been programmed before, the programmers had to find solutions to comletely new problems with minimal tools and low freq. CPU's .. Rygar for example must have been be very hard, almost imposible to program with a simple assembler tool. How did they keep track of all the data? Paperwork hm.. and . the debugging and testing?

I didn't own a C64 but a MSX, and I did some Z80 - assembler programming. What I found difficult was to keep track of all the labels etc. (what is now easier with OOP.)
Would those software houses still have their source code?