KC Munchkin The $130,000 Game preorder thread!

[Retro Rogue]

I understand what you're saying, but *PER THEM* that's not what they did. You're doing your own analysis and coming up with these points to explain how you're interpreting what you're seeing, which there's nothing wrong with, but it's just not the case as stated. Likewise with regards to Ms. Pac-Man, Tod didn't do multiple code bases just the 4k. There was no 8k Pac-Man by Tod. Additionally, Ms. Pac-Man was by GCC and done completely on their own.

 

Likewise, what you're describing as "framework" what's commonly described as "hacking" someone else's code similar to when people here have taken game ROMs and hacked the graphics or hacked them into expanded or morphed games. That certainly occurred with some of the 3rd party companies (the plethora of look a-likes and play a-likes out there wasn't a freak occurrence), but it's not what the coders at Atari did. Each game was treated as a custom new game started from scratch. There was no framework or re-use of an earlier game. In fact, every programmer we interviewed said the same thing: they were thrown the STELLA programming document and told to go at it. It seems more that because some of them came up with similar routines and such that you're interpreting it as a framework being involved. It's just not the case. Now with the coin programmers that's a different story, as some code routines from previous games were re-used in later ones.

 

Nobody here is saying it's not ok to create 2600 games with "frameworks," especially in this day and age. However what they are saying is they did not use them then, including your "clarified" interpretation of framework in the above post. There may have been instances where they someone asked midway through a game to change it into something else, such as Steve with Taz/Asterix (simple graphics swap) or Bob Polaro with Stunt Cycle/Dukes of Hazzard (graphics swap and some additional gameplay coding). Those are specific and unique instances however per what I just mentioned.

 

I left out Howard's other comment to me in regards to this thread, but feel it's appropriate now given the response:

 

This guy is clearly uninformed, but no less confident in his misinformation.

 

Feel free to come on to Facebook and take it up with the original 2600 programmers that are on there in the Atari Museum group (Howard, Tod, Steve, David Crane, many many more) and tell them they used frameworks when they didn't. I'm the messenger passing this along, not the source.

[Mr SQL]

Good post! I agree this comes down to perspective; I'm not talking about hacking games, but reusing the engines or significant portions of them. How we determine when a game builds upon a Framework, either a generic multipurpose one or based off another game?

 

I had read that Frye had a larger version of pacman that was indeed used as a codebase/framework for the development of MS Pacman; did the programmers really build MS Pacman from scratch instead of leveraging his codebase? If so then they didn't use a Framework. The arcade version certainly followed this model and used pacman as a Framework.

 

Defender II/Stargate, my other example clearly looks like it used the Defender codebase as a Framework right down to the rader display; did they really come up with entirely seperate code for a game that did mostly the same things or just enhance it and reuse the codebase? I suspect the latter and would classify it as a Framework game but you're right that it comes down to perspective where we draw the line.

 

I'm curious what HSW says regarding what I read about another developer building the graphics subsytem for ET? If he's saying he wrote the graphics subsystem too and not the other dev then I would agree he didn't use a Framework.

[Mr SQL]

Another piece of the puzzle.

 

This 1984 award RT shared on another thread suggests the graphics subsystem from ROTLA was used for ET; if another dev or HSW wrote the subsystem for ROTLA and reused the codebase, that qualifies as a Framework from my perspective.

 

[Retro Rogue]

Good post! I agree this comes down to perspective; I'm not talking about hacking games, but reusing the engines or significant portions of them. How we determine when a game builds upon a Framework, either a generic multipurpose one or based off another game?

 

I had read that Frye had a larger version of pacman that was indeed used as a codebase/framework for the development of MS Pacman; did the programmers really build MS Pacman from scratch instead of leveraging his codebase? If so then they didn't use a Framework. The arcade version certainly followed this model and used pacman as a Framework.

 

Defender II/Stargate, my other example clearly looks like it used the Defender codebase as a Framework right down to the rader display; did they really come up with entirely seperate code for a game that did mostly the same things or just enhance it and reuse the codebase? I suspect the latter and would classify it as a Framework game but you're right that it comes down to perspective where we draw the line.

 

I'm curious what HSW says regarding what I read about another developer building the graphics subsytem for ET? If he's saying he wrote the graphics subsystem too and not the other dev then I would agree he didn't use a Framework.

 

As stated, he didn't reuse and that wasn't a common practice for the Consumer programmers. As for graphics, what you're confusing is another person on the project (Jerome Domurat) did the title screen. Not sure how much more clear I can make it, he's seen this thread and specifically stated there was no framework involved. And you keep talking about a "graphics subsystem" when that's not how these games were coded or approached - your level of claimed abstractness simply did not exist for 2600 games because of the limited resources. The graphics/gameplay/etc. are all part of the same cycle counted kernel code and figured out together. At that time you would of course had taken time to physically plot out graphics on graphing paper to plan them ahead of time, but that's the extent of a "subsystem." Jerome was part of Marilyn Churchill's (she was Marilyn Theurer at the time) Computer Graphics and Animation group which she founded in 1980 when she became the first graphic artist hired by Atari for computer graphic work. These guys would assist with projects in computer and console games by creating (mapping) the sprites/icons/etc. and their animations which the developer would then implement. So for example the more detailed running man sprites that appeared in the Real Sports series. Think of them as art directors. Jerome mapped the title screen for both ET and TAZ for instance. Now if you're talking the 8-bit computers (400/800 and XL series), for those they actually developed animation software on the 800 that would allow them to create digital animations directly on and for that platform. For the 2600, most of that was primarily mapped out the old fashioned way on graphing paper for the programmer and they'd weigh in on the in game graphics with the programmer and produce storyboarding where necessary.

 

As for Frye, no that was a myth that was floating around. He only coded one version of the game. And yes, GCC did not base their game on Howard's code, two completely different companies and games and each coded with far different needs. You're really reading a lot into stuff in hindsight and running with it.

 

 

 

ETFrameworkGame.png

Another piece of the puzzle.

 

This 1984 award RT shared on another thread suggests the graphics subsystem from ROTLA was used for ET; if another dev or HSW wrote the subsystem for ROTLA and reused the codebase, that qualifies as a Framework from my perspective.

 

 

Nope, I had specifically showed that to Howard as well when I showed him the thread. The magazine was speculating when they put that in the mag, and it's not accurate at all. He also took issue with the claim of neither game doing well:

 

Also, both Raiders and ET were million sellers (even after returns), so I don't think it's a very informed opinion.

 

 

*Edit For Steve's further responses*

 

Steve just posted this as well over in the Atari Museum group regarding this discussion:

 

No templates and or frameworks were used. Who started this ridiculous myth? Did we talk to each other on how we did things, of course we did. Once you started to write your games, you ended up writing everything from scratch: Video Kernel everything. We all had different Video game Kernel requirements that always required very, very carefully hand crafted and unique code. The notion of a frame work or template is so far from reality. There were points on my projects where I had to use an oscilloscope for precise timing.

[Mr SQL]

 

As stated, he didn't reuse and that wasn't a common practice. As for graphics, what you're confusing is another programmer (Jerome Domurat) did the title screen. Not sure how much more clear I can make it, he's seen this thread and specifically stated there was no framework involved. And you keep talking about a "graphics subsystem" when that's not how these games were coded or approached - your level of claimed abstractness simply did not exist for 2600 games because of the limited resources.

 

 

The graphics/gameplay/etc. are all part of the same cycle counted kernel code and figured out together. At that time you would of course had taken time to physically plot out graphics on graphing paper to plan them ahead of time, but that's the extent of a "subsystem." Jerome was part of Marilyn Churchill's (she was Marilyn Theurer at the time) Computer Graphics and Animation group which she founded in 1980 when she became the first graphic artist hired by Atari for computer graphic work. These guys would assist with projects in computer and console games by creating (mapping) the sprites/icons/etc. and their animations which the developer would then implement. So for example the more detailed running man sprites that appeared in the Real Sports series. Think of them as art directors. Jerome mapped the title screen for both ET and TAZ for instance. Now if you're talking the 8-bit computers (400/800 and XL series), for those they actually developed animation software on the 800 that would allow them to create digital animations directly on that platform. For the 2600, most of that was primarily mapped out the old fashioned way on graphing paper for the programmer and they'd weigh in on the in game graphics with the programmer and produce storyboarding where necessary.

 

As for Frye, no that was a myth that was floating around. He only coded one version of the game. And yes, GCC did not base their game on Howard's code, two completely different companies and games and each coded with far different needs. You're really reading a lot into stuff in hindsight and running with it.

 

Nope, I had specifically showed that to Howard as well when I showed him the thread. The magazine was speculating when they put that in the mag, and it's not accurate at all. He also took issue with the claim of neither game doing well:

 

Also, both Raiders and ET were million sellers (even after returns), so I don't think it's a very informed opinion.

 

 

*Edit For Steve's further responses*

 

Steve just posted this as well over in the Atari Museum group regarding this discussion:

 

No templates and or frameworks were used. Who started this ridiculous myth? Did we talk to each other on how we did things, of course we did. Once you started to write your games, you ended up writing everything from scratch: Video Kernel everything. We all had different Video game Kernel requirements that always required very, very carefully hand crafted and unique code. The notion of a frame work or template is so far from reality. There were points on my projects where I had to use an oscilloscope for precise timing.

 

I disagree with your claim on the limits of the technology; a level of abstraction can exist with 1982 technology and just 6K, that's the configuration of the latest version of the ASDK. And the bB Framework abstracts with an even smaller footprint than this.

 

Reuse was also a common practice all over the industry in the 80's; for Steve: are you saying a large chunk of the engine for Stargate wasn't imported from Defender (gameplay has the same feel it's not just the look) or that code from pitfall didn't make it into pitfall II for example? I think there's a fine line between using some shared library routines and the point where the shared code becomes a Framework to build upon.

 

Fair enough on not having leveraged Frameworks/shared code libraries though if the developers are insisting; I'll accept that my opinion may not be correct here - visually looking at them some games seem to use some of the same codebase as others, maybe that's how these myths got started.

[+Allan]

Opinions are neither correct nor not correct. They are opinions, not truths or non-truths.

 

Allan

 

[+cvga]

Framework or not, did 3rd party programmers really get paid by the hour to create games back then? I would have guessed that most contracted games had a cost associated with them at the beginning of the project regardless of how many hours of work were needed for completion.

[Retro Rogue]

 

I disagree with your claim on the limits of the technology; a level of abstraction can exist with 1982 technology and just 6K, that's the configuration of the latest version of the ASDK. And the bB Framework abstracts with an even smaller footprint than this.

 

Reuse was also a common practice all over the industry in the 80's; for Steve: are you saying a large chunk of the engine for Stargate wasn't imported from Defender (gameplay has the same feel it's not just the look) or that code from pitfall didn't make it into pitfall II for example? I think there's a fine line between using some shared library routines and the point where the shared code becomes a Framework to build upon.

 

Fair enough on not having leveraged Frameworks/shared code libraries though if the developers are insisting; I'll accept that my opinion may not be correct here - visually looking at them some games seem to use some of the same codebase as others, maybe that's how these myths got started.

 

Then you're disagreeing with someone else. I didn't say the limits of technology in general or even 1982 technology. I specifically said "your level of claimed abstractness simply did not exist for 2600 games because of the limited resources." Nobody said it didn't exist with other technologies at the time or that it wasn't done in software coding in general. I stated it didn't exist in 2600 games because of the 2600s limited resources. Again not just my words but the words of the people who developed for it at the time.

 

Tod Frye if such a thing as a "Framework' were available, i would certainly have used it when it made sense. If such a thing were possible, i would have written it

 

As for Stargate, no, it was a completely independant code base. Per Tod Frye this evening:

 

Tod Frye Stargate 2600 did not start from Defender. It was a whole new codebase.

 

 

Likewise regarding the original framework claim:

 

Tod Frye There was nothing for 2600 dev that could be called a 'Framework'

 

 

 

Additionally, no, Pitfall II was not based on the Pitfall code base. I asked David Crane earlier today:

 

The display kernels were completely different. The main differences in the kernels were due to the DPC hardware, and to make the screen scroll vertically.

 

 

 

For those not familiar, Pitfall II for the 2600 includes a special DPC chip on it which enhanced the 2600s graphics and audio. Now certainly there may have been some mapped out sprites and such that could have been re-used (such as Pitfall Harry), but that's no different than the mapped out sprites I talked about earlier. Not a "graphics subsystem" or even the display system (also known as the display kernel).

 

 

Opinions are neither correct nor not correct. They are opinions, not truths or non-truths.

 

Allan

 

An opinion is "I don't like the taste of this" or "I love ET it's a great game." An opinion is not "The coders did it like this." He was stating these 2600 framework things as facts, and only in the post above were they first called his opinions in response to Howard sarcastically framing them as such. It was not previously stated as "I think this is how they did it..." or "My opinion is this is how they did it..." (feel free to look through all the previous posts in the thread). Regardless, when the people who did the games are telling you your "opinions" on how they did what they did are wrong, that's not how it was done, then the "opinion" was not correct. It's not a matter of preference, it's a matter of accuracy. They either coded it that way or they didn't. They're saying they didn't.

[Nukey Shay]

Re: 8k Pac-Man, it never existed. Only the flicker technique, which 2 other programmers mentioned seeing him work on - supposedly something similar to what was eventually used in Ms. Read: "not borrowed FOR Ms."...that game too was coded from scratch. BTW if anybody wants to call reusing known techniques (such as a 6-sprite display loop) as a "framework", I guess that would mean that every game is based on something developed prior (even across different companies)! Does this mean that if a programmer happens to have pizza for lunch, the resulting code is based on the pizza?

[Mr SQL]

Retro Rogue,
don't get bent out of shape; my opinions are technical and formed from having written video games in the 80's and reused code libraries (both mine and other developers), and writing frameworks for many years including the ASDK for VCS development! This is why my opinions sound assured but it doesn't mean they have to be correct, just individual perspective.

 

Likewise it is also why the opinions shared earlier that I must not know how the hardware works are also inaccurate.

 

My response to Frye is to take a look at bAtari BASIC and the ASDK; these are lightweight frameworks that can run in a small memory footprint with limited legacy resources and configurations (did you mean something else by "2600's limited resources"?)

 

As far as Stargate not using Defender as a Framework we can take this perspective to a whole new level with reverse engineering; both games are awesome fun and have the same layout/look and feel controlling the ship. I've had projects (not games) where I've had to look at the screen and the inputs and outputs and reverse engineer complex OLTP and OLAP systems with volumes of code by hand with all new code. Seems to me I still used the source system as a Framework since everything matched and worked flawlessly on switchover. Some games seem to match this Framework model as well.

 

For the developer using the oscilliscope for debugging I think that's awesome and old-school! I don't use a debugger in the 80's or now and I didn't even use an oscilliscope to write KCMM; just a RAM board from 1982 and Tron

 

That no one ever used a significant set of code libraries as a framework to build a game faster for the VCS seems a tenuous general claim, but I think the developers are entitled to make this claim individually (ie, not speaking for other developers).

 

Nukey,
excellent point, but at some point using a collection of libraries builds critical mass and becomes an accelerator framework that speeds development. Same thing for reverse engineering - getting inspired with an idea or two can reach critical mass as well at the point where the dev has reverse engineered (copied) concept in masse; this holds true for fun games as well as professional software. The DCMCA threw a curveball at some of the RE projects I used to do and right in the middle of them; no one could have reverse engineered the IBM BIOS if that was in effect in the 80's! the (fair) idea being presented therein is that Framework is conceptual as well.

 

 

[+Gemintronic]

I'm going slightly off topic by considering something that might actually get the amount listed via crowdfunding.

 

What about wrapping your ASDK in a RAD tool similar to the Scrolling Game Development Kit?

http://sgdk2.sourceforge.net/

 

The output would all be ASDK that could be compiled by DASM but the end user experience would all be drag and drop with fields for attributes/parameters.

[landondyer]

don't get bent out of shape; my opinions are technical and formed from having written video games in the 80's and reused code libraries (both mine and other developers), and writing frameworks for many years including the ASDK for VCS development! This is why my opinions sound assured but it doesn't mean they have to be correct, just individual perspective.

 

 

Heck, we didn't even use frameworks for most of the Atari 400/800 cartridges. Maybe we borrowed a few routines here and there, but that was about it.

 

The coin-op group re-used modules (e.g., math packages, coin robot drivers, etc.), but didn't really have a framework, either.

 

Atari was just not much into this.

[Mr SQL]

I'm going slightly off topic by considering something that might actually get the amount listed via crowdfunding.

 

What about wrapping your ASDK in a RAD tool similar to the Scrolling Game Development Kit?

http://sgdk2.sourceforge.net/

 

The output would all be ASDK that could be compiled by DASM but the end user experience would all be drag and drop with fields for attributes/parameters.

Nice IDE on that SDK Loon!

 

Crowd Funding looks cool too; the other Star Castle used that approach to fund development. I'm not looking for funding for the ASDK, development has been sponsored by software company - this thread was in response to a couple of negative threads to cultivate appreciation for homebrews by illustrating that homebrews and dev kits cost real money and time.

[+Gemintronic]

Yep. I worked as a software tester for a database application development company. Even small applications required plenty of man hours despite 4GL tools like Foxpro and PowerBuilder. I can't imagine the hassle of writing kernels from scratch for each and every game.

[+Random Terrain]

Things like this help to add to the confusion:

www.2600connection.com/eastereggs/26mspacman.html

The PAL version contains some Vanguard graphics – specifically the player's ship and explosion graphics, as well as the “Continue?” text. According to GCC programmer Mark S. Ackerman, game data tables were usually partially overwritten with data tables from other games, in an effort to save bytes.

[Mr SQL]

Yep. I worked as a software tester for a database application development company. Even small applications required plenty of man hours despite 4GL tools like Foxpro and PowerBuilder. I can't imagine the hassle of writing kernels from scratch for each and every game.

 

Excellent examples Loon, me too! Those tools are all awesome and represent an advance in conceptual Frameworks that goes beyond the code they embody.

 

For Tod Frye:

 

Tod Frye if such a thing as a "Framework' were available, i would certainly have used it when it made sense. If such a thing were possible, i would have written it

 

Having been exposed to the evolution of advanced concept frameworks no doubt helped Fred (bAtari) come up with the idea to create an abstract programming Framework for the VCS; he didn't need any special tools that you didn't have and it's clear (as Loon's awesome games show) that 2k and 4k games can be written so any technical limitation is out of the question.

 

The ASDK is based on the conceptual Framework of bB: hardware abstraction - high level objects for a screen buffer, x,y addressable pixels and sprites plus the logical addition of a large virtual world, tile mapping and a screen cam object, inspired by the BoulderDash engine. I didn't look at or reuse any low level code from these. What I reused, was the idea which counts just as much; moreso even.

 

If Framework evolution had advanced to the point where someone had introduced a bB like Framework for the Atari bitd, there is no doubt you could have been inspired by the idea and written one too, you're an excellent developer but concept will always be paramount - without the idea there is no code, it was certainly possible

[Thomas Jentzsch]

Interesting read, which I just found right now.

 

If there would be some kind of framework used in different games, then at least traces of this framework would exist in the code. So when comparing those games e.g. with CloneSpy, there should be some extra matches found. But IIRC they do not exist.

[Mr SQL]

Interesting read, which I just found right now.

 

If there would be some kind of framework used in different games, then at least traces of this framework would exist in the code. So when comparing those games e.g. with CloneSpy, there should be some extra matches found. But IIRC they do not exist.

 

I think there are two types of frameworks Tom, physical frameworks and conceptual frameworks. CloneSpy is only detecting the former.

 

Linux and the copied IBM BIOS are well known examples of the latter; the DCMCA (digital millenium copyright act) put a damper on this kind of fun in 2000 (I finished a high budget project just before the deadline so was very much aware of this).

 

A physical framework is purely a collection of code libraries we can manipulate in some form like a construction set; Visual Basic, the ASDK and even macro scripting languages are examples of this.

 

I used Visual Basic and yours and Andrew's awesome Boulderdash game as conceptual frameworks from which to create the ASDK:

 

bB has x,y addressable playfield pixels and sprite objects and playfield and sprite designs that can be defined inline in the code in WYSIWYG format while Boulderdash adds a CAM object and a large virtual world with tile mapped sprites like the NES.

 

I combined these concepts to create the physical framework for the ASDK, but didn't look at the respective code bases, just drew on the conceptual frameworks for both. There were similar frameworks on other systems available but these were the ones inspired me because they illustrated it could be done on the limited resources of the VCS.

 

Look at Chopper Command - a great programmer drew on the conceptual framework of Defender to write that (looks like a clone) while Yars revenge and Kool-Aid man are pretty much entirely unique.