Utopia - The game that caused my Intellivision addiction

[Numan]

For YEARS, I've wanted a version of this game with a AI so I could play it solo.

 

That, or a modern remake.

 

 

http://www.indiedb.c...emake/downloads

 

Boo, I downloaded this to try and there's no CPU AI player 2.

 

Which part of "two-player game" didn't you understand from this thread?

 

Two-player games in the 80s typically did not have any AI because there was no time or space to build it into the game. They used "NI" (Natural Intelligence from your friend or opponent. Games were either strictly one person, or strictly two-person. There are some very rare games that have both modes.

 

-dZ.

 

Frog Bog

[+DZ-Jay]

For YEARS, I've wanted a version of this game with a AI so I could play it solo.

 

That, or a modern remake.

 

 

http://www.indiedb.c...emake/downloads

 

Boo, I downloaded this to try and there's no CPU AI player 2.

 

Which part of "two-player game" didn't you understand from this thread?

 

Two-player games in the 80s typically did not have any AI because there was no time or space to build it into the game. They used "NI" (Natural Intelligence from your friend or opponent. Games were either strictly one person, or strictly two-person. There are some very rare games that have both modes.

 

-dZ.

 

Frog Bog

 

Yes, one of the few.

[intvnut]

Utopia's algorithms and so on revealed here: http://www.atariage.com/forums/topic/197259-utopia-revealed/

[intvnut]

How come alot of these INTV games had no AI?

Lack of sufficient resources, I'd say. The CPU was a limiting factor, but the RAM and ROM were probably the biggest limitations. Some of the sports games that were "upgraded" by INTV added single-player modes and computer opponents, because by the mid-80s, cartridge ROM space had become large enough and affordable enough to allow it. Some games, like MindStrike and Chess, required extra RAM for the computer opponents: MindStrike used the RAM in the ECS Computer Adaptor, while Chess was the only Intellivision game to get extra RAM in the cartridge.

 

Well, technically, there were two: Chess and Triple Challenge. Of course, the latter only had RAM because it included Chess.

 

As for needing RAM for the AI -- I'm not entirely sure it was all that tight. But, for Utopia specifically, it would need some serious cleaning up of the existing programming to free up some cycles and space, and would probably benefit from another 4K of ROM. Let's not forget Utopia did everything it did in only 4K decles.

 

 

jaybird, would it be feasible to port a full Aquarius game to CV? or just analyze the game and you still have to write the game basicly from scratch?

 

sorry for the noob question..

It's certainly possible to use a disassembled Aquarius game as a starting point, since the Aquarius and ColecoVision both share the Z80 CPU, but it would require extensive modification before it could be made to run on the ColecoVision. For instance, any code which was specific to the Aquarius hardware, such as the sound chip and hand controllers, would have to be replaced with equivalent ColecoVision-specific code. The same would be true for any ColecoVision game being adapted to the Aquarius.

 

Fortunately, the character-based Aquarius video hardware is exceedingly simple, so that at least makes it easier to figure out how the screens are being put together.

 

If you're lucky, the UI and hardware-specific code won't be *too* tied into the game logic. If it was programmed like the Intellivision version, though, the two will be tangled together rather badly.

 

I guess it all depends on the discipline of the programmer who did the port. After all, they have the benefit of hindsight and referring to a game that works. Large portions of the original Intellivision programming read like a bad first draft. I highly respect Don Daglow's genius as a game designer. The exact sequence of CP-1610 instructions laid down in ROM, though, aren't necessarily the best.

[jaybird3rd]

If you're lucky, the UI and hardware-specific code won't be *too* tied into the game logic. If it was programmed like the Intellivision version, though, the two will be tangled together rather badly.

 

I guess it all depends on the discipline of the programmer who did the port. After all, they have the benefit of hindsight and referring to a game that works. Large portions of the original Intellivision programming read like a bad first draft. I highly respect Don Daglow's genius as a game designer. The exact sequence of CP-1610 instructions laid down in ROM, though, aren't necessarily the best.

Thanks for posting the detailed information about Intellivision Utopia. Very interesting reading!

 

The Aquarius version was implemented by Stephen Roney, and was written primarily in C. It was apparently the first time that a high-level language had been used for game development at Mattel, and from what I've learned about it, Roney took on the project mainly as an experiment. Using C allowed it to be completed on a very short schedule, but one of the consequences is that the disassembled code might not be quite as efficient as a game implemented in pure assembly would have been.

 

It's been interesting to look at the code for the old Aquarius games, because I too have found some surprising mistakes and inefficiencies: pointers that are used without having been properly initialized, fill loops which do not properly check their boundaries, etc. I've also noticed some interleaved UI and game logic code. I can only assume that the techniques of code factoring and encapsulation and abstraction that many of us learned in school were luxuries that the original programmers couldn't afford, given the constraints they had to deal with, or perhaps they were simply too unschooled to know about them (I gather that many of the Mattel developers in particular were pretty green at the time).

 

As for the code quality in Utopia, Daglow himself has said that he felt himself outclassed as a programmer by some of the developers under his supervision at Mattel. Here are some remarks he made at CGE 2003, for example:

 

I think the one negative feeling I remember having, sincerely, was fear. And the fear was that I couldn't keep up with some of the other people at this table. Because some of the people at this table are phenomenal programmers and I was kind of in the hacker tradition–self-taught ... what would happen is these guys would stare at a piece of code, and Steve might look at it and he'd go, "OK, I can make that work in nine decles" ... and Mike or somebody else would kind of stare at it and rub their chin and say "No, I, I, OK, I know how to do it ... seven decles. Seven." ... and I'd look at it and I thought secretly to myself–I wouldn't vocalize this–"If I were to do this it'd take 32 decles."

 

I agree, however, that it is no reflection on his abilities as a game designer. In those early days, game designers were almost forced to be game programmers as well, but of course they are really different jobs which require different sets of skills. I suppose that's one reason why many of us who are into homebrew programming tend to gravitate toward ports: cloning an existing game on a different platform is primarily a programming challenge, but creating a new game from scratch is a design challenge and a programming challenge, and it's more than many homebrewers seem to be willing and/or able to take on all by themselves.

[intvnut]

The Aquarius version was implemented by Stephen Roney, and was written primarily in C. It was apparently the first time that a high-level language had been used for game development at Mattel, and from what I've learned about it, Roney took on the project mainly as an experiment. Using C allowed it to be completed on a very short schedule, but one of the consequences is that the disassembled code might not be quite as efficient as a game implemented in pure assembly would have been.

 

On the plus side, C compilers tend to be fairly "idiomatic", from the standpoint that a particular C construct tends to be rendered fairly similarly in assembly wherever it appears. That's way less true with today's compilers, but in 1982, that would be "state of the art".

 

On an 8-bit machine like the Z80, though, I imagine it can be a bit worse. For example, constantly reconstructing pointers into H/L. That could likely get a bit tedious. But, like I said, if you can identify the idioms, then maybe you have a chance to read through it. That said, I seem to recall one of the videos on Intellivision Lives! had Roney recounting his experience taking the output of the C compiler and hand optimizing it. That could make things a bit rougher to follow.

 

All that said, I've documented the original algorithms, so there's probably no need to analyze the Aquarius port.

 

It's been interesting to look at the code for some of the old Aquarius games, because I too have found some surprising mistakes and inefficiencies: pointers and registers that are used without having been properly initialized, fill loops which do not properly check their boundaries, etc. I've also noticed some interleaved UI and game logic code. I can only assume that the techniques of code factoring and encapsulation and abstraction that many of us learned in school were luxuries that the original programmers couldn't afford, given the constraints they had to deal with, or perhaps they were simply too unschooled to know about them (I gather that many of the Mattel developers in particular were pretty green at the time).

 

Well, the same issues appear in Intellivision games. Awhile back, I went through a number of Intellivision games looking for how they stored their scores. I was rather surprised at the variety. I just assumed most games stored a 2, 3 or 4 byte 2s complement score. Nope!

 

I've seen one game that stores the lower four digits of the score in one variable, locked to 0000 - 9999, and then the rest in a regular 16-bit variable. And, many other variations. Buzz Bombers stores "100s", "10000s" and "1000000s" in three separate bytes.

 

As for the code quality in Utopia, Daglow himself has said that he felt himself outclassed as a programmer by some of the other developers under his supervision at Mattel. Here are some remarks he made at CGE 2003, for example:

 

I think the one negative feeling I remember having, sincerely, was fear. And the fear was that I couldn't keep up with some of the other people at this table. Because some of the people at this table are phenomenal programmers and I was kind of in the hacker tradition–self-taught ... what would happen is these guys would stare at a piece of code, and Steve might look at it and he'd go, "OK, I can make that work in nine decles" ... and Mike or somebody else would kind of stare at it and rub their chin and say "No, I, I, OK, I know how to do it ... seven decles. Seven." ... and I'd look at it and I thought secretly to myself–I wouldn't vocalize this–"If I were to do this it'd take 32 decles."

 

I agree, however, that it is no reflection on his abilities as a game designer. In those early days, game designers were almost forced to be game programmers as well, but of course they are really different jobs which require different sets of skills. I suppose that's one reason why many of us who are into homebrew programming tend to gravitate toward ports: cloning an existing game on a different platform is primarily a programming challenge, but creating a new game from scratch is a design challenge and a programming challenge, and it's more than many homebrewers seem to be willing and/or able to take on all by themselves.

 

Yeah... I may have been there for that. That's not the only time he's mentioned his limited skills as a programmer. As I understand it, Eddie Drombrower wrote WSMLB, but Don Daglow designed the engine logic. That's how it should work: A good game architect should be coupled up to good game implementers. In the early days, that need may not have always been recognized.

 

For a concrete example, consider this code segment from Utopia. It toggles the variable "CURPLR" between 0 and 1:

 

       ;; Toggle CURPLR between 0 and 1.
L_595A: PSHR    R5                  ; 595A
       MVI     CURPLR, R1          ; 595B  \
       TSTR    R1                  ; 595D   |- If it's player 1, set it to 0
       BNEQ    L_5964              ; 595E  /

       MVII    #$0001, R1          ; 5960  \__ else set it to 1
       B       L_5965              ; 5962  /

L_5964: CLRR    R1                  ; 5964
L_5965: MVO     R1,     CURPLR      ; 5965
       PULR    R7                  ; 5967

 

I would have written this as:

 

       MVI     CURPLR, R1
       XORI    #1,     R1
       MVO     R1,     CURPLR
       JR      R5

 

This is a case where the code goes from 14 decles to 7. And, actually, where it gets called to do the toggle... you probably could have instead just inverted the logic.

 

I'm not trying to rag on Don at all. He got his algorithms in there, and they worked! (Well, except for that one overflow...) And, he's been able to move on to design other great games. So, who's to argue with success? :-)