Legacy versus ARM-based 2600 Game Development

[Thomas Jentzsch]

5 minutes ago, Karl G said:

Has anyone actually said there should be a "warning label" for ARM games?

AFAIK not. But some people tend to dismiss arguments by intentionally twisting and misinterpreting them.

[+Al_Nafuur]

31 minutes ago, Thomas Jentzsch said:

AFAIK not. But some people tend to dismiss arguments by intentionally twisting and misinterpreting them.

Communicating with people is much more difficult than communicating with computers.

[+D Train]

20 minutes ago, Al_Nafuur said:

Communicating with people is much more difficult than communicating with computers.

on the other hand, computers always do exactly what you tell them to, which isn't always what you mean for them to do...

[+KaeruYojimbo]

1 hour ago, Karl G said:

Has anyone actually said there should be a "warning label" for ARM games?

Not in those exact words. When I say "warning label" I'm saying it jokingly. But there were a few posts by people who seemed to want an ARM label so they could easily spot the games that don't conform to their idea of a real Atari 2600 game. (I actually went back and deleted most of the post you quoted, apparently while you were typing your response, because I really didn't like it upon re-reading it.)

 

It's probably time to do what I should have done a while ago and self-ban myself from this thread.

[kisrael]

27 minutes ago, D Train said:

on the other hand, computers always do exactly what you tell them to, which isn't always what you mean for them to do...

quoted for truth

[Prizrak]

I haven't commented on this topic that I recall but wanted to give me .02. These ARM releases are amazing and amaze me at what can be done on a system of this age and hardware limitations. As a kid I would have loved these games every much as now and would not have cared what wizardry was involved to make it work. To me the ARM enhanced games are no different than a super charger, DPC, SARA or any other type of enhancement over the years that has been made to games on the system. The only difference is those other methods are tech for that time period and this is modern tech. Same theory behind their design (improved graphics and gameplay) but this modern verison is just more powerful than other methods. As other folks have said here, adding an ARM is not cheating or doing something like the RaspPi in a NES cart. This is still using all the 2600 original hardware and the ARM helps do some heavy lifting for the original hardware to help process things. It's basically a 21st century supercharger and nothing more. I understand there's purists and stuff but back in the 80s these guys were not afraid to add things to improve the games and the same should go for us now.

Sent from my SM-N960U using Tapatalk

[+thegoldenband]

On 5/20/2021 at 4:35 PM, kisrael said:

I personally still ask "isn't it arbitrary to target the 2600 if you don't want to be constrained by its constraints?"

I've been mulling this sentence over because I think it's an excellent way of asking an important question, with a couple different and distinct answers. Here's one of them.

 

(Warning: wall of text, so don't complain and moan about it -- you've been warned.  )

 

Anyone who hangs around forums has seen an endless number of posts from new posters who want to do something that sounds ridiculous and impressive, e.g. "I want to hack Super Mario Bros. into Metroid Prime, how do I do that?" or "I want to port Super Mario Kart to the Atari 2600, tell me how", etc.

 

I don't think these posters actually want to do those things -- they want to have done those things. It's a status thing, like saying you climbed Everest or sniped a target from a mile away or whatever. Obviously they have zero chance of actually making those things happen, but it's worth having some insight into their mindset: what motivates them is bragging rights, a trophy to show off, ego validation.

 

The Atari 2600 has the biggest name recognition, by far, of all the pre-NES systems. Many people perceive it as crude and perennially stuck in 1979, so it's easy to see how a budding "trophy-hunter" programmer would feel they don't have to take graphic and sound design seriously, because expectations are so low. And since it seems simple, people assume (quite erroneously!) that it's easy to program for and emulate.

 

So in some people's minds -- and I'm talking here about people who make, essentially, shovelware with short development times -- I think the Atari 2600 is an opportunity to get a trophy. They have no particular affection for the system, but see it as low-hanging fruit, and a status symbol of sorts.

 

On most other systems, doing a slapdash job with graphics and sound would stand out like a sore thumb. But if you expect that creating something on the Atari 2600 that even vaguely resembles, say, Pokémon or Streets of Rage would be received as a marvel -- like the old quote about the dancing bear: "The marvel is not that the bear dances well, but that the bear dances at all" -- then it's easy to see a temptation there.

 

And frankly a lot of popular video game reviewers don't seem to realize just what the Atari 2600 is capable of -- they really do seem to think that a game that looks like Adventure is about the best the console can do, and marvel at anything more.

 

To use a musical analogy, it's like the Atari 2600 is a tuba, and they understand that a tuba can't play fast or high, but they don't understand what it can do that other consoles can't. They have no particular appreciation for its unique flavor or strengths, or the way that its limitations make it interesting. It's just a "bad NES" to a lot of them, and making it look like exactly that is enough.

 

-------

 

I guess this is the only thing that worries me about ARM and other similar aids: that it facilitates a certain kind of shovelware, in which an unskilled trophy-hunting programmer will put out some game that uses a licensed character (video game or otherwise!) without permission and get a ton of attention for it, while other, better games get ignored. They get kudos for working within perceived constraints even while, behind the scenes, technology is keeping them from having to deal with those constraints in a meaningful way.

 

I embrace ARM in the hands of people who use it to solve problems that can't otherwise be solved, and we've seen some absolutely brilliant results in that department. I want that to keep happening, and to be supported.

 

But I'm more hesitant about it in the hands of people who are using it a way to advance goals that have nothing to do with programming for the 2600, and who even view the 2600 as little more than a kind of joke (akin to the fake-2600 games Homestarrunner.com used to do in their heyday).

 

For many of them, it seems like the point is to make some shallow facsimile of an existing video game property, or to shoehorn some popular media character into a game that took a week to develop, and have that be treated as some sort of achievement when it's really just a meme.

 

I'm not saying I'm right or wrong to feel that way, only that I do. And all democratizing technologies have this effect: it's the nature of opening up any space to those who are less technically skilled. Lowering the barrier to entry inherently facilitates low-effort work.

 

The real problem, as always, is humanity -- most people are strongly attracted to novelty, "news", the appearance of something being done that was thought impossible (whether or not it actually was), and the prospect of some sort of fame. And most of us want all those things with as little expense or expenditure of time as possible; it's only a small minority that loves the work for its own sake, and embraces taking the time (and experiencing the frustration!) necessary to make something as good as it can be.

 

[+Karl G]

5 minutes ago, thegoldenband said:

I guess this is the only thing that worries me about ARM and other things: that it facilitates a certain kind of shovelware, in which an unskilled trophy-hunting programmer will put out some game that uses a licensed character (video game or otherwise!) without permission and get a ton of attention for it, while other, better games get ignored.

Is this a theoretical concern, or have you seen examples of this? As mentioned in this topic and others, creating ARM-assisted games takes quite a bit of specialized knowledge and skill. Developers who make use of it do not do so because it is easier, but because it allows for more complex graphics, sound and/or game logic than can be accomplished without the hardware assistance. The devs who are well-known in the community for their ARM-assisted CDFJ/DPC+ games have put out very high quality games.

[Thomas Jentzsch]

16 minutes ago, Karl G said:

Is this a theoretical concern, or have you seen examples of this?

Some bB games using enhanced tech come to mind.

[+thegoldenband]

8 minutes ago, Karl G said:

Is this a theoretical concern, or have you seen examples of this?

I don't want to get into a bB discussion (partly because I'm a sometime bB user and don't want to see it dragged). But yes, for example, I've seen people developing shovelware-ish games using a bB kernel with DPC+, and my impression is that they've been able to execute effects that wouldn't have been possible otherwise.

 

Mind you, I'm totally OK with that being used to develop original games. But I've also seen it used to mimic the appearance of known media entities -- characters from other video games, cartoons, whatever -- in a way that I don't think would have been possible for a bB user to pull off without DPC+.

[kisrael]

14 minutes ago, thegoldenband said:

I don't think these posters actually want to do those things -- they want to have done those things. 

Sounds like me and "going to the gym" 

 

Some great thoughts re "trophy coding accomplishments" and "lowered expectations". I know some of the appeal to me doing JoustPong in 2004 was that you COULD one-person-show the graphics and sound, I had enough pixel doodle and musical background to do an ok job at both, but at the 2600 level and maybe not the NES level.

(Interesting seeing how CHAMP games uses a team approach!)

Here's what I wrote for "why the atari" back when I made https://alienbill.com/2600/101/ , soon after Joustpong:

• To connect in a fundamental way with the grandmaster of our misspent childhoods.
• The challenge of it all. Like writing haiku while drunk and on the back of a charging rhino.
• Actually, I hate challenges, but there's something cool about making a game out of such simple little pieces, kind of like Legos when they were all square, with maybe a few wheel pieces thrown in.
• To interact with something you made on a real live TV.
• The groupies.
• Ok, I'm kidding about the groupies.
• Why not program for other, more modern consoles? Despite (or because of) the difficulty of the 2600, there is a community and set of resources for it that I haven't seen for other systems you could potentially homebrew for. (YMMV)
• Why not just make games for Windows, in VB? Or a more powerful language? Or online, in Shockwave or Flash or Java? Yeah, go on, cry to mama you little wuss! But seriously: most successful modern games are big budget productions done by teams of people. Your program is likely to languish in shareware/freeware hell, ignored by millions, and competing for attention with thousands and thousands of other little games. Make a decent classic game, and you will get a lot of attention from the classic game collectors and their friends. You can even sell copies at shows like CVGE and PhillyClassic, and be duly admired in cash form. (If you work out the hourly rate for your programming efforts, you'd probably be better off flipping burgers, but that's not the point.)

So in some ways, some of that is the same kind of "scaled back" stuff you're talking about.

 

Also. Pondering on this question now that you mirrored it, and what I wrote almost 20 years ago I would add:
Atari-era games tended to have a focus than the NES era and after: more on motion + physical interaction, vs an emphasis on content and large area exploration. You can still see the old Atari/arcade feel in show up in modern gaming: I think of the perennial Mario Party series, many of the minigames are very much "retro feel in new(ish) clothing". But that's another legit reason to stick on this platform, even beyond nostalgia it is the best home for a certain kind of game interaction - joystick over crosspad, one button and not 2-4.

(Also, I think there is something to your "trophy" idea, at least for some coders. Maybe that's some of why batari Basic drove up certain resentment. It made a certain kind of simple game very easy (hell Loaded4Bear was a GameJam weekend, and by getting a good guy on sound and leaning on 2 player fun, it came out ok, IMO ? (later I added AI to it) )
 

17 minutes ago, thegoldenband said:

To use a musical analogy, it's like the Atari 2600 is a tuba, and they understand that a tuba can't play fast or high, but they don't understand what it can do that other consoles can't.

Hey, as a tuba player ( https://kirk.is/tag/tuba ) -- tubas players have the biggest range of all the brass  We can play fast and high (though usually we shouldn't) 
 

[+thegoldenband]

29 minutes ago, kisrael said:

Here's what I wrote for "why the atari" back when I made https://alienbill.com/2600/101/ , soon after Joustpong:

• To connect in a fundamental way with the grandmaster of our misspent childhoods.
• The challenge of it all. Like writing haiku while drunk and on the back of a charging rhino.

[...] So in some ways, some of that is the same kind of "scaled back" stuff you're talking about.

I totally relate to what you describe, and I think the key is that you actually wanted to make a game for the Atari 2600 -- and because you wanted to do that, you embraced its constraints, limitations, the essence of the task itself.

 

The kind of programmer I'm describing wants to have made a game for the idea of the Atari, if that makes sense: not the reality of the 2600, but a kind of abstracted, Flash-game version of it. The constraints and limitations are only an obstacle, to be avoided as easily as possible, because the point is to get the trophy as quickly as possible. (Or, in a few unfortunate cases, to sell the limited-edition CIB copies as quickly as possible...)

  

29 minutes ago, kisrael said:

(Also, I think there is something to your "trophy" idea, at least for some coders. Maybe that's some of why batari Basic drove up certain resentment. It made a certain kind of simple game very easy (hell Loaded4Bear was a GameJam weekend, and by getting a good guy on sound and leaning on 2 player fun, it came out ok, IMO ? (later I added AI to it) )

It's nice to see acknowledgment that a certain kind of game is actually really easy to make if you have even the most minimal programming experience. We sometimes act like everything everyone does is a real achievement, but that's not so. I did a shitty game demo with multidirectional scrolling in bB and it took me, I don't know, maybe 3-4 hours tops? It looks sort of impressive but there's no game there, and the process didn't force me to understand what I was doing or how to develop the idea any further.

 

ASM would've taken 10-50x longer but I would have understood the anatomy of my own game in a way that simply wasn't required of me with bB -- but, on the other hand, the odds of me making that game in ASM were approximately zero. I suppose part of me thinks we should all build only the things that we can understand from the ground up, but that's wildly unrealistic.

  

29 minutes ago, kisrael said:

Hey, as a tuba player ( https://kirk.is/tag/tuba ) -- tubas players have the biggest range of all the brass  We can play fast and high (though usually we shouldn't) 

Heh, brass player here too, and I have tons of respect for tubists. Y'all can scream in the upper register, but most tubists I've known usually seem to prefer that we don't ask you to do that ("Why not just write for euphonium?").

 

And absolutely, you can play fast, but all low brass players are up against the limitation that no instrument will "speak" as quickly in lower registers, thanks to acoustics. Play a note-perfect transcription of a Freddie Hubbard solo on tuba, and it'll sound muddy simply because of the time it takes for each note to speak -- for the attack to coalesce in your embouchure, or even for the note itself to complete its waveform (a low B at 60Hz requires one frame, at least in NTSC!  ).

 

So let the tuba be a tuba, not a flabby, oversized trumpet; let the Atari 2600 be itself, not a bad NES.  My point being, to be clear, that good work begins by embracing the platform you're writing for, not writing despite that platform. And I think some of the awesome homebrew using ARM epitomizes this virtue -- it heightens the Atari 2600, rather than routing around it.

[kisrael]

1 minute ago, thegoldenband said:

I totally relate to what you describe, and I think the key is that you actually wanted to make a game for the Atari 2600 -- and because you wanted to do that, you embraced its constraints, limitations, the essence of the task itself.

Yeah... actually my story is even more of that... the game was JoustPong, which came from a random suggestion in the old Usenet rec.games.video.classic ("The future of gaming can be summed up in two words -- Pong and Joust") and I had previously made in Visual Basic, Java, and even PocketC for PalmPilot. I love that it's a reasonably rich game that just needs one button! (years later FlappyBird discovered the exact same thing) Also it was easy to make a good but not perfect AI component. So limitations came into play in a very good way. 
(later when i wanted to make it release/purchase-worthy I added in Pterry to mix things up, and the Breakout-like wall modes. Sometimes I realize if I had had batari it would have been a month, not a year, kind of project. But it's not clear I would have pushed to extend it as much as i did)

Heh. Thinking more about "trophy" game makers looking to sell CIB stuff... my guilty thought - especially for my art joke "game" Sisyphus - is ... when do we start making NFTs for these? 

6 minutes ago, thegoldenband said:

It's nice to see acknowledgment that a certain kind of game is actually really easy to make if you have even the most minimal programming experience. I did a shitty bB game demo with multidirectional scrolling and it took me, I don't know, maybe 3-4 hours tops? It looks sort of impressive but there's no game there, and the process didn't force me to understand what I was doing or how to develop the idea any further.

Which game was that, is it around?
 

And yeah. One of my focuses is as a tool maker - (in part because I was only gonna be Just Ok at the gamemaking and i didn't have many brilliant games i was dying to make) and most of my tools or tutorials focus on being able to spit out some runnable code. So for people who view insta-shovelware as a problem... well, I'm an enabler, a bit. 

In some ways the wonkiness of batari is ALMOST a saving grace  would love to see something like @SpiceWare's SpiceC come in and capture the same "don't sweat the kernel" vibe but with a more robust system, not so white space dependent...

Cool you're brass too. Actually I was glad I didn't have get to defensive about tuba, you were pretty fair! I remember in college I snagged a "Tubby the Tuba" solo part from a senior, in part because she wasn't able to make enough practices, but also because I was willing to just play it down an octave (hell I've played enough trombone sheets that I barely noticed i was doing that) - but in part , if the damn piece is "Tubby the Tuba", why should it be in that stupid high Euphonium register, as you say....

(that said... well... these days I'm an activist "street player", in it for the fun and not the finesse )

PS I had my reservations about digging up an old contentious thread and knew we'd get some of the same old same old "but if Pitfall 2 did it..." arguments, but I feel some of these tangents have redeemed it!

[+thegoldenband]

37 minutes ago, kisrael said:

Which game was that, is it around?

It's here, under the name "Maciste in Hell":

Just a silly little game demo, really, but at least it does something relatively unusual (multidirectional scrolling). I had ambitions of figuring out some way of using a LFSR (or pair of LFSRs) to generate a much larger playfield. That task proved to be well beyond my abilities, though.

[+batari]

The comparison between bB and CDFJ is a bit contentious. Yes, CDFJ optionally supports coprocessor coding in a high-level language and bB is a high-level language, but that is about where the similarities end.

 

People do know that bB lowers the bar to entry, and that you can write a working game in a short amount of time and/or without years of programming experience, and never really need to know one whit about assembly or 2600 kernels to do it. CDFJ, however, does NOT lower the bar to entry at all.

 

CDFJ only saves the programmer from doing game logic in 6502 assembly, but it does NOT save the programmer from writing a 2600 kernel.

 

Pure 2600 assembly is tough to be sure, but it's the kernel that is the toughest and takes a long time to understand. Programming for DPC+ or CDFJ is actually a level above that, like 2600 programming on steroids, as you have to already know 6502 assembly and how to write a 2600 kernel before you can even begin, as CDFJ interacts directly with the kernel. You not only have to understand how a 2600 kernel works, but also have to understand the inner workings of the CDFJ scheme as well to understand how it interacts with the kernel.

 

Now if someone were to abstract out the 2600 kernel with CDFJ or another scheme in the future with some C libraries or something, we might have something to talk about regarding comparisons between bB and whatever that will be.

[+splendidnut]

5 minutes ago, batari said:

Now if someone were to abstract out the 2600 kernel with CDFJ or another scheme in the future with some C libraries or something, we might have something to talk about regarding comparisons between bB and whatever that will be.

Working on it...

 

 

Hopefully I can get it into a releasable state soon... At least an alpha/beta version.

 

[+D Train]

I would just like to say that brass is the best.  you haven't lived until you've been clobbered by the brass soundwave of a high school marching band up close at a mardi gras parade...

[+sramirez2008]

4 minutes ago, D Train said:

I would just like to say that brass is the best.  you haven't lived until you've been clobbered by the brass soundwave of a high school marching band up close at a mardi gras parade...

Our younger son played Tuba for his HS Military Marching Band.  He was pretty good too (All State).

 

Now back to our regularly scheduled program...

[+Nathan Strum]

7 hours ago, thegoldenband said:

So let the tuba be a tuba, not a flabby, oversized trumpet;

Right - that's the flugelhorn's job!  

 

(Former) trumpet player here. Still have my horns. Including a vintage rose brass Yamaha YFH-631 flugelhorn (same model Chuck Mangione played... but I could never get that kind of a sound out of it).

 

I suppose I should post something on-topic now.  

 

I've probably mentioned this before, but to me, the tools, development environment, programming language or cartridge hardware don't matter at all in terms of the actual quality of a finished game. What matters is the outcome. How much fun is the game to play? How engaging is it? Do I want to play it again, or is it frustrating mess? Having been on the ZPH Award nominating committee a couple of times, I've played dozens (if not hundreds) of homebrews. And what jumps out at me are the details. The details programmers get right, and the details they get wrong. I've played more homebrews than I can count that had amazing concepts and/or cool graphics that catastrophically failed because the programmer reached the "I'm done" point too soon and didn't put in the effort to properly finish the game. They didn't follow through on perfecting the controls or physics or difficulty ramping or enemy AI or other issues that have to do with gameplay that are entirely about programming. Whether they lacked the knowledge or lost interest, the end result was a game that failed to reach its potential. No amount of extra hardware is going to compensate for that. You still have to put in the work, and grind through the tedium of polishing every last aspect of whatever your game is until all of the rough edges are knocked off. And for programmers who don't know how to do that, there are plenty of programmers around here who do, who are perfectly willing to share that knowledge.

[Thomas Jentzsch]

3 hours ago, Nathan Strum said:

I've played more homebrews than I can count that had amazing concepts and/or cool graphics that catastrophically failed because the programmer reached the "I'm done" point too soon and didn't put in the effort to properly finish the game. They didn't follow through on perfecting the controls or physics or difficulty ramping or enemy AI or other issues that have to do with gameplay that are entirely about programming. Whether they lacked the knowledge or lost interest, the end result was a game that failed to reach its potential. No amount of extra hardware is going to compensate for that. You still have to put in the work, and grind through the tedium of polishing every last aspect of whatever your game is until all of the rough edges are knocked off. And for programmers who don't know how to do that, there are plenty of programmers around here who do, who are perfectly willing to share that knowledge.

This and 1000 times this!

[+Andrew Davie]

53 minutes ago, Thomas Jentzsch said:

This and 1000 times this!

I agree, too. It touches tangentially on issues like "how do you find totally trustworthy, reliable play-testers" which is something I've been wondering about. Back in the day, programmers tended not to believe bugs reported by our QA people... so much so that all play-testing was videotaped, so the programmer could be dragged in by the balls and shown the actual bug happening.  All my '2600 efforts have had practically zero external play-testing - and the recent Audacity effort does show the value of a bit of focus on that part of development.  Especially if we want to be "professional" like them.

[Jstick]

12 hours ago, Nathan Strum said:

I've played more homebrews than I can count that had amazing concepts and/or cool graphics that catastrophically failed because the programmer reached the "I'm done" point too soon and didn't put in the effort to properly finish the game.

This applies to many original commercial 2600 releases as well (mainly due to extremely short development schedules that were measured in weeks).

 

To me, this is actually where unfair comparisons come into play, where homebrew developers today have the luxury of taking 2 years to polish a game, vs 2 months to hit the Christmas sales window.  Fancy new technology or not, you still need time for iteration and polish a to make a really enjoyable game (to Nathan's point).

[+SpiceWare]

4 minutes ago, Jstick said:

homebrew developers today have the luxury of taking 2 years to polish a game, vs 2 months to hit the Christmas sales window.

 

Writing homebrew games is not a full time job, the time is comparable:

• 2 years at a few hours per week ~= 300 hours
• 2 months at 40 hours per week ~= 300 hours

 

[kisrael]

29 minutes ago, SpiceWare said:

 

Writing homebrew games is not a full time job, the time is comparable:

• 2 years at a few hours per week ~= 300 hours
• 2 months at 40 hours per week ~= 300 hours

 

Yeah I was thinking similar! 

I guess you could also compre projected sales volumes as well as ballpark money, if that's too crass. And then personal recognition like Activision started using vs Atari's "toil in anonymity, you're roll is similar to the people assembling the cart"

 

Yeah, gaming is a great things in games. That was a weird thing about 4K - at some point you can say... alright that's all about all I know how to pack in there  (though of course there are always people who will show you how to get just a bit more in.)  But I know I pushed JoustPong to be more than it would have had it just been a "trophy" port of my basic JoustPong concept

[Thomas Jentzsch]

1 hour ago, SpiceWare said:

 

Writing homebrew games is not a full time job, the time is comparable:

• 2 years at a few hours per week ~= 300 hours
• 2 months at 40 hours per week ~= 300 hours

Right. And I doubt they worked only 40 hours per week.