Main > Main Forum
Galaga
Malenko:
--- Quote from: Xiaou2 on April 03, 2013, 11:46:50 am --- One things for sure, that games back then were made to a much higher standard than today. The reason, is because the games
had to be interesting and difficult enough to keep money flowing into the Ops pockets. If a game was too easy, and people played on the machine too long.. Ops would complain, ask for refunds, and possibly canceled future orders. They spent Months testing and revising games difficulty and level design. Usually, the games could last many years without bordom, to the casual player.. and hold up many years to even the hardcore players.
--- End quote ---
Citation needed. Gyruss was in development for less than a year (I've read 4 to 7 months, but nothing firm). I hate to break your fantasy of what game development was like for arcades genesims Xaiou2, but the tweaking to difficulty happened more with dip switches than months of development. My best guess is they found what they would consider "medium" and added dips to alter that.
I'd also like to see where you found that devs would make a game to last years, which would actually hurt them in the long run. Using Gyruss as an example, you could set number of ships and difficulty. Fire it up in MAME and you'll see difficulty changes the number, speed, and fire rate of enemies and little else. If games were meant to last years, why did Konami release at least 6 games a year after 1983, and as many as 24+ games a year in the 90s (35+ in 1999)?
Also, bordom is spelled Boredom. Just one of those misspellings that irk me. That being said , Time Pilot is still a better game
Xiaou2:
--- Quote ---Citation needed. Gyruss was in development for less than a year (I've read 4 to 7 months, but nothing firm).
--- End quote ---
Gyruss is a lot more simple than something like Defender. Its also pretty much a copy of existing gameplay ( Galaga)
However, you have to understand what one Year means in the 80s game dev scene. It usually meant one or two guys programming
18 hrs a day, 7 days a week, for the duration of the project. The programmers often also did the graphics themselves. Usually traced
out on graph paper in advance. Programming I believe, was done in pure Assembly, which is the fastest language for the Processors. However, its also a real bear to program that way, and its very hard to find bugs. I believe I heard that many of the initial games were originally coded using a Typerater that made a punch card printout.. that was then fed into a different machine, to get the code transferred.
The games were reviews in meetings every so often, checking on progress, and changes being made withing them. Games were tested
regularly, by both Atari employees, Mgt., and outsiders. Games were tweaked accordingly, based on the feedback. At the final stages,
an actual machine was placed in an Arcade... and turned Live. Players were asked to rate the game and what they thought about it.
Feedback based on earnings made, and comments... further changed the game, or if it did poorly enough, it was Scrapped altogether.
Most of this was from what I read from Atari devs. In Japan, things may have been slightly different.
For example, in Atari, many of the early games were mainly programmed & designed by one guy. Where as in Sega, that guy doing an outrun mod /editor - reassembler , says theres evidence of multiple programmers working on many different section of game code.
Over time, Games development has changed drastically. Some for the better, but sometimes for the worse.
ids:
--- Quote from: Xiaou2 on April 03, 2013, 12:45:17 pm ---Programming I believe, was done in pure Assembly, which is the fastest language for the Processors. However, its also a real bear to program that way, and its very hard to find bugs.
--- End quote ---
This is all to often stated, but as someone who coded extensively in assembler back in the day, I choose to disagree. It requires a different approach than would be used today, but then today I work on systems that contain 1000's of times more code and complexity. Debugging an assembly system that is working at such a low level with hardware can be quite a challenge, but then so can debugging a massive system with hundreds of threads that talks to several other systems, hardware components (e.g. barcode reader, card reader, etc) and so on.
and fwiw, Galaga rocks :cheers:
Jumpman64:
What would be neat is a "digital spinner" I'm thinking of something that looks like a spinner, but only turns a few degrees each way and springs back to center. Any game have something like that?
Gray_Area:
Don't encourage your brother! (Bonus for knowing where that comes from.)
Some interesting counter-talk:
Part of the challenge of Gyruss, is being patient. If you try to risk moving too far too quickly... you might not make it. It results in a lot of 'that was close' moments.
And on that note, I'm surprised the spinner mention hasn't conjured up lew.
--- Quote from: Jumpman64 on April 03, 2013, 04:00:05 pm ---What would be neat is a "digital spinner" I'm thinking of something that looks like a spinner, but only turns a few degrees each way and springs back to center. Any game have something like that?
--- End quote ---
I recall there was a vertical shooter that had a control like that. Or something.... Maybe a console system...yeah, but I don't recall which. No need to mod a spinner. Just use a turn dial like on older appliances, though this one would need to be two-way.
And, lastly, I decided to play a game of Galaga. It's fun enough. I play rarely and average around seventy grand. The percentage is about average - something in me mentally obviously that brings this consistency - but obviously a little better game this time round.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version