4 ms·

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 c

by Nutmog 11y ago

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.

cornholio 11y ago
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.
- muzani 11y ago
  10 programmers and no source control sounds like a recipe to make this even worse than it had been.
- kabdib 11y ago
  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.
  - kabdib 11y ago
    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.
- Sharlin 11y ago
  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.
kalleboo 11y ago
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.
- mschaef 11y ago
  > 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.)
SeanDav 11y ago
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.
- krapp 11y ago
  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.) [0]https://en.wikipedia.org/wiki/Ray_Kassar https://en.wikipedia.org/wiki/Ray_Kassar [1]https://en.wikipedia.org/wiki/Adventure_%281979_video_game%29#Easter_egg https://en.wikipedia.org/wiki/Adventure_%281979_video_game%2...
- vidarh 11y ago
  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. Here we are in total agreement.
  - 11y ago
bluedino 11y ago
Why wouldn't they have just re-branded an existing game in development with E.T.?
vehementi 11y ago
> In fairness, what else could they have done, given the time constraints? In this case "the best move is to not play"
kabdib 11y ago
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.
- abecedarius 11y ago
  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.)
  - kabdib 11y ago
    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. :-)

by Nutmog 11y ago

cornholio 11y ago

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.

muzani 11y ago
10 programmers and no source control sounds like a recipe to make this even worse than it had been.
kabdib 11y ago
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.
- kabdib 11y ago
  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.
Sharlin 11y ago
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.

kalleboo 11y ago

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.

mschaef 11y ago
> 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.)

SeanDav 11y ago

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.

krapp 11y ago
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.) [0]https://en.wikipedia.org/wiki/Ray_Kassar https://en.wikipedia.org/wiki/Ray_Kassar [1]https://en.wikipedia.org/wiki/Adventure_%281979_video_game%29#Easter_egg https://en.wikipedia.org/wiki/Adventure_%281979_video_game%2...
vidarh 11y ago
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. Here we are in total agreement.
- 11y ago

bluedino 11y ago

Why wouldn't they have just re-branded an existing game in development with E.T.?

vehementi 11y ago

> In fairness, what else could they have done, given the time constraints? In this case "the best move is to not play"

kabdib 11y ago

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.

abecedarius 11y ago
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.)
- kabdib 11y ago
  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. :-)