What tools did programmers use to program 80's Arcades

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.

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.

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.

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.

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.

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?

Quote:

Original post by Marmin 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?

I wrote a turn-based wargame for the Atari STFM way back in 1991. It was my first substantial game project and I learned everything from scratch. The source code fitted inside a single text file of approximately half a megabyte in size. I was using HiSoft's GenST development software -- basically an assembler and debugger -- and OCP Art Studio for the graphics. (I have an arts background; the programming stuff is something I sort of fell into by accident.) Oh: and two floppy disk drives. (The game was called "Mythical Warriors" and completed up to the Beta stage, but never saw a release as the publisher went belly-up.)

Unlike most developers, even during my day, I tended to work from home and developed directly on the target platform. Most software houses of the day had already moved to using cross-assemblers such as SNASM and PDS, which ran the IDE and assembler software on a PC and squirted the finished game code over a cable to the target computer. The only reason I didn't do this myself was because those kits cost a small fortune and I never missed them. During my days learning to code in assembly language on the ZX Spectrum, I was using a cassette tape for storage. As you can imagine, a lot of my time and effort went into avoiding the coding of bugs in the first place as a crash meant about 5 minutes of reloading the IDE and source code.

As for the wargame itself: I wrote all my tools first, then worked on the game itself. One of the hardest parts to get right was the pathfinding algorithm. Since my maps, rather naively, included streams, this made the task even harder. In the end, I effectively ended up reinventing the A* algorithm since the World Wide Web didn't exist back then and books on the subject were hard to find. It wasn't all _that_ hard: once you hit upon the idea of 'scoring' each tile on the map, A* follows naturally.

Another trick games often use is to only create the _illusion_ of complexity. For instance, the 8-bit classic "Elite" claimed to have an insane number of galaxies for you to visit. In reality, planets were simply created by rolling a virtual die, grabbing a planet name from a set list and 'rolling' the planet's stats as if creating a character in an RPG. This was easily done using the pseudo-random number generators popular even today: give the generator a specific 'seed' number and you can guarantee you'll get the same sequence of random numbers generated each time. To create a new galaxy, you simply changed the seed and used it to 'roll' new planets.

This kind of 'fake' depth and complexity is quite common in games, even today.

Basically, they moved in and out of loops

Though I would say that they had a better idea of how to create complexity from simple rules (like above random numbers to create "endless" universes). Compare that to say SWG until a short while ago. Exactly the opposite, trying to create a complex game from pointlessly overcomplicated rules. But then, judging from hazy memory not that many games really tried to be complex anyway. Still glad I didn't care about programming back then.

First of all I must admit I felt this unusual twitch in my stomach when I was reading your posts. I was nearly convinced people who know what ZX Spectrum or Commodore is had died out a long time ago. I used to program a little in ZX Spectrum BASIC (hail to Sir Sinclair!) so reading about those retro technologies really made my eyes water.

To the list of arguments above I think I need to add the fact that all those games made a couple of decades ago didn’t have 3D graphics, shadows, blending max fps problems on different platforms and many other issues so programmers could focus on the art creative game programming. Many games were often made by independent, non-commercial developers so they were unbound by nowadays ‘best seller’ goals, many were introducing experimental approach etc. The process of creating a game was much shorter and simpler (assuming on has spend enough time to learn how to do it).

This thread brings a question I always wanted to ask: how old are computer games developers? There is an opinion that teens are the best. I’m almost 30 and sometimes feel I should give it up and focus on growing my beer belly. Am I really too old?

Quote:

Original post by ursus First of all I must admit I felt this unusual twitch in my stomach when I was reading your posts. I was nearly convinced people who know what ZX Spectrum or Commodore is had died out a long time ago. I used to program a little in ZX Spectrum BASIC (hail to Sir Sinclair!) so reading about those retro technologies really made my eyes water. To the list of arguments above I think I need to add the fact that all those games made a couple of decades ago didn’t have 3D graphics, shadows, blending max fps problems on different platforms and many other issues so programmers could focus on the art creative game programming. Many games were often made by independent, non-commercial developers so they were unbound by nowadays ‘best seller’ goals, many were introducing experimental approach etc. The process of creating a game was much shorter and simpler (assuming on has spend enough time to learn how to do it). This thread brings a question I always wanted to ask: how old are computer games developers? There is an opinion that teens are the best. I’m almost 30 and sometimes feel I should give it up and focus on growing my beer belly. Am I really too old?

I'm 34 and have moved away from programming and into writing and graphic design. Programming games has changed dramatically. When I was making my own games, I didn't have to worry about studying vast APIs, 3D graphics libraries and the like. It was just me talking directly to the hardware. No intermediaries. No third-party code libraries. It felt much more like linguistic translation then. I drifted into programming by mistake -- when I was hired to write that wargame, I was only applying for a graphics artist job. But I'd written a map editor to show some of my tile-based graphics and they liked it enough to want to hire me to develop the entire game, design, graphics, code, GUI and all. I still wish it had been published.

2004 marked the tenth anniversary of the last self-designed, self-developed game I worked on. I haven't been paid as a games programmer since 1997. Hell, for much of the last 7 years, I've been creating marketing materials, websites and the like for a family-owned private school, although I do have a part-time job doing support for an indie gamedev company.

It was great fun to be in at the beginning of the industry, but I don't really care for 3D graphics and today's "Technology Über Alles" culture. The industry is clearly on the verge of self-immolation, so I don't miss that part of it. But most of all, that wonderful frisson of creating magic has long since gone: Coding just stopped being fun.

I still like to keep an eye on the games industry. There's so little we know about _why_ we play at all that I believe this field still has much to teach us about people and human behaviour. The games industry in the 21st Century will, I think, prove to be far more interesting once it gets out of its ghetto and realises its true potential.

I think you are totally right here?

Remember the classic Atari 2600 hit "Ádventure"? This was made by a sole programmer!

Quote:

Original post by ursus First of all I must admit I felt this unusual twitch in my stomach when I was reading your posts. I was nearly convinced people who know what ZX Spectrum or Commodore is had died out a long time ago. I used to program a little in ZX Spectrum BASIC (hail to Sir Sinclair!) so reading about those retro technologies really made my eyes water. To the list of arguments above I think I need to add the fact that all those games made a couple of decades ago didn’t have 3D graphics, shadows, blending max fps problems on different platforms and many other issues so programmers could focus on the art creative game programming. Many games were often made by independent, non-commercial developers so they were unbound by nowadays ‘best seller’ goals, many were introducing experimental approach etc. The process of creating a game was much shorter and simpler (assuming on has spend enough time to learn how to do it). This thread brings a question I always wanted to ask: how old are computer games developers? There is an opinion that teens are the best. I’m almost 30 and sometimes feel I should give it up and focus on growing my beer belly. Am I really too old?

why should not this 'age' of Special programming, return, Now?

Quote:

Original post by Anonymous Poster Quote: Original post by doynax 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. Heh yeah clever people could do more. That pretty much answers the spirit of the age. It was all new, and you did by the seat of your pants. There were no long-bearded academics preaching how to do it, you just did it and found a way to do it. That is why those old games are far, far more special than any junk done today.