Tuesday, January 27, 2015

programming the atari 2600 part i: joustpong

In mid-2002, I decided to port my original Visual Basic videogame called JoustPong to the Atari 2600 - a system that had been released a quarter of a century earlier!

JoustPong (or FlapPing as it was later renamed, since the Atari Corporation feels it has exclusive rights to games with the word "Pong" in the title) is among the simplest of games. It came from this quote from a person named "Otter" on the old Usenet group rec.games.video.classic. In 1998 Fairfield Research had kind of spammed the group about Gaming 2001-- The Future of Gaming! and he replied:

"The future of gaming can be summed up in two words -- Pong and Joust" 
Dan Mazurowski then brainstormed this idea:
JoustPong - what a great idea! Two great tastes that taste great
together! Hey, your Joust is in my Pong! Well your Pong is in my Joust!
Seriously, the idea is intriguing. Each side has a bird that can move
vertically (and ONLY vertically) by flapping. They bounce an egg back on
forth. If they miss the egg, it lands in a hatching area (nests?) and
three riders are born. Then they all jump on birds and attack the two
players. When they are knocked from their mounts, you have eggs bouncing
around pong style again, which eventually end up in the nests, to
produce three more riders. Each generation is different, just like in
regular Joust. After three generations, the level ends. Higher levels
could feature more eggs, obstacles in the playfield, bonuses, and
perhaps special items to bounce at the other player to kill them. Of
course there would also be visits from the Pteradactyl, and perhaps the
lava troll could climb out of his pit once in a while for some fun. For
a one player game, the gameplay would be similair to handball (keep egg
in play to avoid hatchlings and rack up major points).
I can't believe I have just come up with an arcade game idea that
requires only ONE button to control it.   :)
I was then inspired to actually make this game -- or at least the first six sentences and concluding remark of Mazurowski's pitch. I used Visual Basic - a language I taught myself in the early 90s, and actually had taught in a class at Tufts University. (In their "Experimental College", where anyone, even undergrads can propose a for-credit course to teach.)

I simplified the game down to its Pong-like layout, and came up with a pleasant surprise: not only did it play well, it was easy to make a computer opponent that could pay a decent but imperfect game. For human and computer player alike, pressing the button to flap against gravity was simple enough, but it was easy to overshoot as well.

(I'd like to add that VB3 and VB4 were delightful little languages, and empowering. Around the same time I had to learn 16-bit Windows programming in C, but it was so cool to be able to whip up a little game like this (or InterGalactic SpaceMan BlastFest, an original concept so desperately in need of remaking) in a short amount of time. I had nothing quite like these languages until I discovered Processing in 2004 and could put my Java skills to work and share my stuff online.)

In 2002, having already made a few ports of the title (including one for the Palm Pilot using a fun little on-device compiler and runtime called "PocketC" and a Java servlet) and seeing the flexibility of the concept, I thought that the time was ripe for porting this game so it could run on an actual, physical Atari 2600, the pre-eminent system of the early-1980s, and a nexus of my childhood playtime. (The circumstances of the Great Video Game Crash had left me with a larger than average Atari collection.) There was a small scene for Atari homebrew, focused on the Stella mailing list, and over the course of the project I received support from the site AtariAge.com - still going strong as the preeminent classic Atari resource. (They're the ones who produced the physical cartridges in the end.)

The Stella list was full of smart people, most of whom understood assembly language and the peculiarities of the Atari 2600 chipsets much better than I did. Many of them loved programming the Atari because it was so challenging, unlike me who loved it despite of the difficulty. (I tried to pay back to the community by making a tutorial for the novice, 2600-101 - I've gotten feedback from people who found it a great help.)

The Atari is such an odd beast to code for - having to do so in primitive assembly language was only the first hurdle. The best description of the effort is Nick Montfort and Ian Bogost's book Racing the Beam. Unlike systems that had a reasonable amount of memory, the Atari didn't map memory so that you could, say, turn on a pixel at a certain coordinate. Instead, the programmer had to stuff graphics data into memory locations at just the right time as the electron beam swept across the TV screen, and he or she didn't have many programming instruction cycles to do it in. It is a testament to the design of the original system, designed for ports of simple late-70s games like "Tank" "Pong" and "Outlaw", that it could be geared up to do some amazing feats of visual game design (I've always been impressed by the port of Battlezone.)

I kept a Developer's Blog throughout that time, 2002-2004 (including a year hiatus in the middle) Sadly, and strikingly, those dates are also bookends for my first marriage, mentioned as asides in the blog itself. While I think it's unfair to say that this project "destroyed my marriage", there's certainly a chance I should have been focused on showing my partner that I was interested in growing to be a better partner, rather than indulging my inner man-child on projects like this. Live and learn! Or live, anyway. (Still, tough to know if such diverted focus is a symptom or the disease.)

Anyway, I got the game done. Reading through, I had forgotten what an immense struggle it was at times! Since I was hoping to make something interesting enough for collectors to purchase, over time I added a few elements back into the simplistic formula. "Pterry", the pterodactyl from the original title, flew figure-8-ish patterns, and would add a bit of chaos and unpredictability by batting around both the ball and the players themselves. I also threw in a variation with defensive walls - looking a bit like a vertical version of Breakout, but it was the original pun title "Poorlords" that stuck, since the awesome 4-player game "Warlords" also featured defensive walls, and this was like a 'poor' version of that.

And now, this programming projects dirty little (not-quite) secret... the heart, and hardest part of any from scratch Atari game, is the "kernel" (where you're actually drawing the screen / "racing the beam") and I had a clever but not brilliant one. Because the Atari only has 2 player sprites at once, when I added Pterry I used the "flicker" strategy: one frame would display Player 1 and Pterry, the next frame would have Pterry and Player 2, the next would have both Players and no Pterry sprite... but at 60 FPS, the flicker is slight.

However one of those Stella wizards, a man by the name of Paul Slocum, figured out how not have to do a flicker at all. The Atari has a few tricks they threw in to mix things up, including doubling or tripling either player sprite (making 2 or 3 identical copies on screen.) Slocum's genius was to push one sprite all the way to the right of the screen, and THEN duplicating it, which shoves the clone back to the left side of the screen. By carefully tweaking the timing and putting in the right bits at the right moment, both players could share the single sprite, and so Pterry could have his/her own as well. This was a kind of programming genius!

So once I was finished I had physical cartridges made and sold, including color manuals and label arts... we even released it with limited edition custom T-shirts!

I still think JoustPong is kind of a terrific game.

There is something so cool about a game that can be even simpler than Pong - a single click-button suffices where otherwise a fancy twisty knob would be needed. (Of course, Pong is a bit more complex than people give it credit for - not only is there a lot of "English" to put on the bounce, the original arcade game even has a fancy ending screen!) And the iOS enfant terrible Flappy Bird used the same basic "flap against gravity" mechanic. (Actually if you aren't inspired enough to download an Atari Emulator and grab the Rom from the AtariAge page you can get the idea from the processing.js/HTML5 port of FlapPing that I made for a "Flappy Bird Game Jam" - one player only, but it has an acoustic (Tuba) cover of the 2600's theme music.)

I've enjoyed seeing my game in action - at the now defunct New England Classic Gamer's trademeet, we held a tourney, and the drama of it was palpable. The tension among the spectators ratcheted up with each brick knock from the players' defensive walls - this game is a very decent quick deathmatch.

So despite the possible cost to my personal life, and despite having humbly acepted a much more finessed version of the heart of the code, I am still proud of having slogged it out. I think my circa-2003 self should somehow be a rolemodel for my current edition. (If a bit more mature and more aware of the emotional needs of the people I love.)

(Heh, googling up Dave "liveinabin" Exton, who made the cover art, I found this interview I had given to Gameroom Blitz and then totally forgotten about. That's at least 16 seconds of my Andy Warhol-promised fame!)

Monday, January 26, 2015

unixish recursive copying of files newer than X

This probably isn't the most efficient way of doing this (more of a note to my future self, because this is good enough.)

Googling for how to just copy files newer than a certain date, I realized I didn't want to copy per se, that it was probably better go ahead and do the tar command:

tar -cvf newerstuff.tar --newer-mtime '22 days ago' .

Now in practice, I brought this down to my local machines to test and inspect the results. (After gzip'ing it). This command makes folders for the whole structure, even the empty folders that had nothing new in them... so  

find . -type d -empty -delete

got rid of those, and I felt a little better about the result of tarring and gzip'ing that instead. I presume there might be some way to have the first tar command ignore 'empty' folders, or the fact is it wouldn't have hurt anything if they were included when I untar'd in the new location, but still.

Update: this page shows an alternate method for skipping those directories, but it's still a little clunky, relying on a temporary file touched to reflect a certain date. 

Wednesday, January 21, 2015

groovy and ambiguity

I'm learning grails/groovy for work.

Grails is kind of cool, though I think its insistence on DRY (Don't Repeat Yourself) and "convention over configuration" lead to code that is easy to write, but harder to learn really well, because there's so much there the novice or intermediate coder might not know. Increasingly I'm aware of a bathtub-curve spectrum of coders, those who prefer power and conciseness, and those who prefer understandability and explicitness.

Anyway, a trivial JSON Controller in Grails:

package someapp

class SomeJsonController {

    def index() {
        def foo = params.foo
        render(contentType: "application/json") {
            ["key":"value", "a list":["1",2,foo]]

Put in the correct folder that gets automagically mapped so
{"key":"value","a list":["1",2,"3"]}

I was mildly bummed when I realized my observation that Groovy used JSON as its native list and map syntax was a bit off. It uses [] as delimiters for both, as opposed to JSON which uses [] for its lists and {} for its maps. So you see GWIM (Guess What I mean) magic at work in the code example.

I was curious what happened with the empty collection [] - how would it know what it was?  ... I ran the experiment with that Controller, and it's the empty list. Reading about groovy Collections I find out [] is canonically empty list, which makes sense, and [:] is the empty Map, which seems a little wrong to me - it feels more like a one member Map with null key and value, but I guess that ain't really a thing.

Saturday, January 17, 2015

wide screen

Sometimes the answer to a number of web design questions is "well what is company X doing?" -- the assumption being that these are smart companies who might even be doing A/B testing with a lot of thought and metrics. So following FB's lead, it's a decent practice to request a web browser at least 1400 pixels across to show everything? To me that implies they think people tend to run FB maximized, or at about that width - relatively few screens are near double that.

Of course, there was a quiet revolution in the 2000s that tended to abstract literal pixel resolution from what every program feels it's working with. Compared to some early attempts in the first half of that decade, the results are astonishingly transparent to users and developers alike.

Friday, January 16, 2015

Thursday, January 15, 2015

under the hood

Man. Nothing has made me feel more like a toddler in a toy store than this article on new-ish features on CPUs in a while. Most coders have NO IDEA what's going on in them there chips, myself included.

Wednesday, January 14, 2015

"the problem with angular"

A friend tweeted me The Problem with Angular. The tl;dr is that A. the syntax is very server-coder minded (I've noticed the resemblance to JSTL etc before) and that it's not super-performant. Personally, I also note that it's not particularly easy to model what's going on in your head.

One disagreement I have is with this bit:
Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework.
Personally, I've seen the opposite, I'm kind of impressed by the number of supporters vs how many places I see using it.

As has been said before:

Working on getting to one of the peeks. I think; I wonder if Angular 2.0 combined with WebComponents will make it less relevant rather than more, as time goes on...