Interesting Article on E.T. Videogame

[DLPB_]

http://www.bbc.co.uk/news/magazine-35560458

Atari soon realised that ET was not going home.

 

[Cupcake]

semi-related page explaining how most of the games "bugs" aren't bugs, how to "fix" them, and why E.T. is actually a good game

http://www.neocomputer.org/projects/et/

[nfitc1]

ET was NOT the worst game ever made at the time. I enjoyed it too and don't remember the bugs these people talk about. However, it was the biggest LOSS to the industry at the time. Atari had problems way before this, but ET was the most publicized game that flopped commercially.

Sega had similar problems. If you want to talk about the worst company crashes in the gaming industry you have to put Sega at number 1 for greatest losses.

[sithlord48]

Sega had similar problems. If you want to talk about the worst company crashes in the gaming industry you have to put Sega at number 1 for greatest losses.

Sega screwed up royaly  they tried to support systems for way way to long and back port to much stuff.

[Covarr]

E.T.'s two biggest failings were:

• The gameplay wasn't self-evident, and you actually had to read the instruction booklet to understand how to play. This wasn't as big a deal then as it is today, now that games almost never even have instructions because they rely solely on in-game tutorials, but considering the amount of players 5 and under who probably couldn't read yet, that is still a legitimate concern.
• The collision detection was unintuitive. As the page Cupcake linked explains this pretty well, I'm not gonna re-explain it fully, but it's a big enough deal that it is worth repeating. Game design is for the player more than for the hardware, and it's important to build your mechanics in a way that makes sense to the human mind. Falling in a hole because your head touched it does not work for human sensibilities.

Either of these two things would be a moderately big deal alone, but together they spelled doom for the game's sales potential and reception. Certainly enough that I could hardly blame someone for not enjoying it at the time.

[DLPB_]

The guy did well considering how you had to program back then (it was all assembly level?  If not, what was used?)  - and that ridiculous deadline.

Still, it did have flaws.  And pretty big ones, admitted to by the programmer. It really wasn't the programmer's fault - it was the deadline.

It's a bit of a shame that the biggest issues would have been easy to fix with more time, and have been by fans' hex editing.

[White Wind]

21 millions dollars for the rights (and not the same dollars as now!), and you put ONE guy to work for 5 weeks  x)

And omg, that legend about the desert was true after all..

[nfitc1]

it was all assembly level?  If not, what was used?

COBOL. Maybe Fortran. Surely not asm.

[DLPB_]

I do recall that some games were asm.  Maybe not this one since it seems a little more intricate. Or perhaps it's just that the language was very primitive.   I dunno where I heard it - so maybe it's a load of crap

[nfitc1]

There was most likely some form of BASIC that could compile into the 6502/7 machine code though the command list would be pretty limited. You can, with current tools, write stuff directly in asm which could be translated to machine code.

[New Pagodi]

I don't know about the original games, but according to this article, all of the early homebrew games were written in assembly.  Wikipedia says a basic compiler was developed in 2007.

[nfitc1]

Keyword there is "homebrew". That means people creating their own games in THIS century. The question is: What was being used back in the early 80s at the height of Atari's popularity? I'm imagining some sort of suite with graphics editors, sound generators and some form of scripted language. It was probably proprietary if it wasn't raw asm.

I know that the Commodore family had a BASIC language interpreter since I wrote a few scripts I pulled from magazines and books. That was a big contender to Atari after it came out.