Jump to content
  • Advertisement
Sign in to follow this  
Marmin

What tools did programmers use to program 80's Arcades

This topic is 4636 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)

Share this post


Link to post
Share on other sites
Advertisement
Quote:

But, they could not use any object oriented programming language. How could they manage their code?


Good paper work. An object oriented structure may not have been optimal for performance reasons, but whatever structure your code lacks, you can write on paper. Tag your code with comments and document what it does and how it fits with the rest of the project.

Share this post


Link to post
Share on other sites
It may come as a shock, but programming has been around a lot longer than object oriented programming.

BASIC has been around since 1963, and we all know how many games are written in that language....

Some games today don't rely on OOP at all (especially many of those in the Your Announcements section of the forum).

Good design principles have been around since before the days of punch cards. Follow good design principles and you can make good software, be it games or a business app. OOP just gives you additional tools.

Example: Look at the Pyramids, the Colossus of Rhodes (well, drawings of it before the earthquake), the great wall. How did they do all that without modern construction equipment? Answer -- planning, careful leadership, and an endless supply of cheap labor.

frob.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Marmin
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)


You obviously never saw or programmed a C64 or Atari 8-bit ;-)

They were not very hard to make games like Asteroids and Space Invaders on these. The old hardwares had hardware to help with graphics operations like blitting, etc.

The tools used, well, you have to understand these machines were *very* small, they had no multitasking OS, so your tools were usually your editor. Pixmaps were just numbers in an array, fonts, etc. You poked, peeked, popped and pushed them all around. It was really a lot of fun. Keep in mind you had maybe 64K of RAM and maybe 48K of that was all yours, as the hardware would map on addresses, and the BASIC or Assembler you used took up RAM too.

Share this post


Link to post
Share on other sites
Take a look at the book Hackers by Steven Levy. It's more about the people than the tools they used, but it's still fascinating reading. It also has a large section devoted to 80's games.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
You obviously never saw or programmed a C64 or Atari 8-bit ;-)

Keep in mind you had maybe 64K of RAM and maybe 48K of that was all yours, as the hardware would map on addresses, and the BASIC or Assembler you used took up RAM too.
On the C64 I generally throw away the OS (it isn't good for much anyway) and mapped out the ROMs. Accessing the full 64 kB isn't a problem =)

The sad thing is that I've still never used up anywhere near the full 64 kB.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!