In fairness, what else could they have done, given the time constraints? They even hired support staff to make sure he got fed! They surely didn't have source control or other systems to make it safe/easy for multiple programmers to work on it together. I imagine the code is some monolithic thing full of complicated Atari hacks that's best managed by being all together in one person'd mind.
Perhaps they could have made two games in parallel so if one failed, they'd still have a spare.
Atari didn't have source control. AFAIK, it just didn't exist. The VAX or DG mini that most people used for cross-development was probably being backed up at least weekly, but if you accidentally wiped out something important, like all of your source code, you were likely hosed.
On a project like this, adding people to it will make it later. The 2600 is a different beast from something that you can divide-and-conquer using APIs and so forth. A typical commercial 2600 game is a holistic, byte-shaved monster piece of spaghetti code, full of tricky timing and other traps. Hard to imagine that any collaboration would have resulted in a better game.
I used a VAX in college, and the DEC operating system had built-in support for file versions. E.g., something like: when you write to a file, that creates FILENAME.EXT.5 where before there were FILENAME.EXT.1 through 4. Compared to Unix it was harder to accidentally wipe your data. (It's been so long, and I didn't use it so much, that I won't opine on how much harder. But the Unix Haters Handbook ragged on Unix quite a bit for this sort of thing.)
File versioning was nice, but it cluttered stuff up. People still lost files. I know that I did. Fortunately, since I was an admin, I had arranged for daily incrementals, and didn't lose anything. :-)
It does not make any kind of business sense to spend that much money and rely on 1 programmer and such a short project time. What happened if the programmer fell down some stairs or got hit by a bus? Normal project time for a game was 6 to 8 months, they gave this guy 5 weeks and no team. Obviously the programmer should never have agreed to the time frame, but he was 24 and at that age nothing seems impossible. This was not his fault, but shows a shocking lack of planning and communication within Atari at that time.
Atari's contempt and disregard for its programmers at the time has become pretty legendary. Ray Kassar[0] (president and CEO) famously rebuked a group of programmers complaining about work conditions as being no more important than the assembly line workers who put the cartridges together - which then led to the formation of Activision. Atari also refused to credit programmers for their work (leading to the first easter egg in Adventure[1].)
Given that atmosphere, Atari would have probably just given the job to someone else (on the same deadline, of course.)
This was clearly a project driven by externals. Christmas is a fixed time, and ET was going to hit the cinemas at a fixed time. If the deal is in place with 5 weeks to go to get things into stores for Christmas, then 5 weeks is what you have.
And adding more than one programmer to a 5 week project for a platform like that would slow things down, not speed it up.
There's lots of things they probably could have done better, such as having testers on standby, but the project timeline and putting one programmer on it doesn't seem like something they realistically could have done differently.
Taking the risks they did on it in terms of volume and marketing costs, is a different matter. The poor planning that led to those timelines, likewise.
> This was not his fault, but shows a shocking lack of planning and communication within Atari at that time.
They could have had the vision to lock down the rights earlier. Raiders of the Lost Ark was already a hit. It wouldn't take much to conjecture an alien movie by the same director would hit.
I'm genuinely curious about this, since I wasn't around in those days.
For a game being implemented (and probably having design changes on the fly as problems crop up since there was no time for a design phase) in assembly, with instruction- and register-level hacks to save the 128 bytes of memory, with no source control aside from sneaker net, how many developers can reasonably work on it at the same time? 1? 2? I mean at that level don't you need to hold the whole code and memory map in your head? Each change can have huge repercussions.
> with instruction- and register-level hacks to save the 128 bytes of memory, with no source control aside from sneaker net, how many developers can reasonably work on it at the same time? 1? 2?
I don't know from first-hand experience, but my impression has always been that the main game loop would be virtually impossible to develop as a team effort.
To give a bit of back story for those that are unaware, the 2600 did not have a frame buffer for storing the current contents of the screen. To save memory, what it did instead is use a line buffer. This was a small amount of memory on the graphics controller chip (Stella) that it used (in combination with some minimal sprite logic) to render the current scan line on the screen. To display anything other than vertical stripes on the screen, the CPU had to update the line buffer and sprite registers for every change. (This is why you see vertical stripes when the 2600 crashes... the CPU isn't updating Stella, so it just keeps rendering one scan line for the whole screen.)
The other consequence of this line-buffer design is that to execute, the CPU had to run in lock step with the display update process. Developers had to know how many CPU cycles it took to render a line and frame of the screen, and write code that executed in just that many cycles. Otherwise, the CPU's display update would happen out of phase with the refresh process and you'd wind up with garbage on the screen. It is hard for me to imagine how a team of two developers could collaborate on such a small and sensitive section of code.
Another way to look at this is that developers that programmed the 2600 were almost working as hardware designers more than software designers. The 2600 CPU was essentially a super-complicated state machine sitting aside the graphics update logic. (Later Atari PC's offloaded display update to a separate chip called Antic that could pull data from a frame buffer, etc.)
Suddenly "Fantastic Voyage" [0] makes more sense: when I was a kid I thought it would work better as a side-scroller rather than an "up-scroller", because there was wasted space on the sides, and you'd have more time to react / could see farther ahead.
It of course never occurred to me that by having so many scan lines being the same, they could save a lot of work.
This is a recent (2011) Atari game that renders several concentric rotating circles, each with a gap. It's the game that Howard Scott Warshaw (the E.T. guy) decided couldn't be done on the 2600. Knowing what I know about the 2600 graphics subsystem, I can see why he came to that conclusion.
Of course, Warshaw then Star Castle as inspiration for Yar's Revenge. This game was widely considered to be excellent... leading to Warshaw having the credibility to be asked to do E.T.
Hm, yes maybe two. This type of project actually sounds like a pretty good fit for pair programming.
The assembly code is too small and tightly knotted to be able to usefully work on different parts simultaneously, but coding as a pair (given that it's an intelligent person you can stand for 5 weeks of intense) seems to me it would have mostly benefits?
Maybe I'm overlooking something obvious, but isn't the main disadvantage of pair-programming that it's not quite as good as two programmers working in parallel (and thus wasteful of workforce)?
Instead of force feeding the genius, how about giving him a competent team of 10 average programmers, and 15 testers / players ?
This way, the genius if free to imagine great games, not fiddle with screenbuffer bits and lose all contact with reality.
Well, adding people to a project that's already impossibly late will make it even later.
Atari had plenty of people imagining great games; they didn't ship much content that was compelling, and were generally held in contempt by the "real" game programmers (e.g., the folks in the coin-op division).
Also, the 2600 has no screen buffer. It's all real-time raster generation with the CPU in cycle-by-cycle lockstep with the beam. Game design on the 2600 is very tightly bound to what the hardware is capable of. For instance, you can't just say "I want this game to have a spinning blue cube that defends against enemy fire," you have to see if you can make one. If you're a Real Programmer, maybe you can (and you might ship a killer game).
If you're a poser in marketing or management who's wondering what all the fuss about this programming stuff is about and why the hell people are complaining about those blue cubes you demanded, you run the company into the ground doing design that way.
One fine day someone in the Home Computer marketing division decided that "Games involving shooting things are bad, we're going to stop making them."
Six months later there were massive purges in marketing.
Not soon enough, IMHO. I might respect a moral position, but mayyyybe you should have a business plan to back up your moral stance (if that plan is "We're going to go out of business because our resolve is strong" then, okay, I'll respect that too -- but say it so we can at least have a discussion about your continued employment). The games that resulted from that decision were horrible and never even paid for their development.
I don't think there even existed a concept of a multi-programmer gamedev team back then. When your whole application must fit into eight kilobytes of assembly with zero room for separation of concerns, it's very much a Mythical Man-Month situation. Like Brooks noted, nine women can't make a baby in one month.
Perhaps they could have made two games in parallel so if one failed, they'd still have a spare.