The guys developing Strike Zone Bowling accepted some of my feedback and released a 2nd Beta recently. I just played it, and these are minor improvements but polish is everything once you have the core game defined, and these definitely improve the game.
They fixed the arrows on the lane, so that they are drawn like a real bowling lane.
Corrected lane arrows for a more authentic experience.
They also added a scaling effect so that the ball shrinks slightly as it moves down the alley, adding to the faux 3D effect. I guess you’d call this a 2D perspective game, rather than a 3D game?
The visually shrinking ball really adds to the feeling of depth.
Anyway, I had only the tiniest part in these improvements, but I DID suggest them and they DID implement them, and that makes me feel fantastic. It’s already a gift that these homebrew developers are giving the Atari community new games to play 45 years on after the 2600 was new. These tiny little changes are almost like a personalized gift to me. Thanks to easmith and kevinmos3 for their excellent work on this game.
Kool-Aid Man was one of those games that was an attempt to cash in on the popularity of the Atari 2600. Released in 1983, the year of the Crash. As an 8 year old kid, the Crash didn’t mean much to me, other than that games got insanely cheap that year, as a glut of unwanted video games were liquidated by retailers for pennies on the dollar.
The Koo-Aid Man video game was initially a special offer only game. To get a copy, you had to send in proof-of-purchases for Kool-Aid, and wait several weeks for the cartridge to arrive by mail. I don’t remember how many points you had to send in, but we drank a ton of kool-aid in my house, and one day our copy arrived.
125 points? That doesn’t seem like all that much.
People will tell you this game sucked, but I liked it. The game was fun, if simple game. The premise of the game is that there’s this swimming pool full of water, that you, Kool-Aid Man, have to protect from these creatures called Thirsties. Thirsties are thirsty, and they want to drink up all the water in the swimming pool. If that happens, the swimming pool won’t be fun anymore, and everyone’s day will be ruined. But you’re Kool-Aid Man, your job is to quench people’s thirst. So you can save the day by quenching the Thirsties’ thirst, thereby saving the swimming pool for the swimmers. Now, if only someone could fix that huge hole in the wall…
The people saying this game sucks might have been speaking literally.
The game consists in rounds lasting 60 seconds, and if you can clear all the Thirsties in the level before this time elapses, you’ll get bonus points for the remaining time, and then start a new level with higher difficulty provided by the Thirsties moving faster than before.
You spend most of your time dodging moving Thirsties. When a Thirsty drinks it stops to extend a long straw to the water in the pool. This is when it is vulnerable. Hitting Thirsties when they are drinking eliminates the Thirsty, and gives you some points. Colliding with a free-roaming Thirsty, or into one of the edges of the screen, will cause you to bounce out of control, giving the Thirsties time to drink more pool water.
You can buy yourself a few seconds of invincibility by grabbing ingredients of Kool-Aid: Water, Sugar, and Kool-Aid Mix. Grabbing these changes you into a bigger pitcher of Kool-Aid and makes you invulnerable while a tune plays, and also adds some water back to the pool. Mercifully, you can still knock out a drinking Thirsty if you careen into it while out of control, and if you luck into a power-up it renders you invulnerable, instantly returning control back to you. The fire button does nothing in this game, which is a rare thing.
If you play the game enough, you may notice that the Thirsties behavior is not random — the Thirsties always stop to drink at the same time, in the same order. By learning the pattern, you can gain an advantage over the game and get a better score, which makes the game somehow both more and less re-playable.
Unlike most Atari 2600 games, Kool-Aid Man starts a new game immediately upon turning the console on. To give you a second or two to get ready, there’s a sweet intro screen, which features a full-screen animation of Kool-Aid Man crashing through a wall around a typical suburban backyard. The invincibility tune plays, and then the game starts without any delay.
Check out that cinematic cutscene! Oh yeah!
When the game ends, the screen background goes dark, and you lose control over Kool-Aid Man, and the score stops increasing. But the Thirsties continue to fly around, and every time they crash into Kool-Aid Man, he’s sent careening around, bonking off of the walls and other Thirsties, forever.
Even in death, the power-ups make you invincible.
It seemed to me that the game programmers were a little sloppy by making the game work like this. It always made me anxious to know that I had to start playing the game immediately upon turning on the console. And while it was funny to watch the defeated Kool-Aid Man bouncing around forever, the noise from this going on non-stop was pretty annoying, and tended to make you want to turn the game off as soon as your game was over unless you were going to immediately start a new game. But overall, the game was a good test of skill and reflexes, had tight controls, decent balance, and a tough challenge curve. On the other hand, it got old fast, because there was nothing new after the first screen, the game immediately presented everything it had to offer.
Playing the Atari 2600 as much as I did as a kid, I never thought that its graphical capabilities were amazing. I could see arcade games from 19879-82, and tell that the Atari 2600 wasn’t capable of the same graphics, even if I didn’t really know why. It just seemed to make sense that a bigger machine that probably cost a lot more and only did one thing would be capable of doing it better than a smaller, less expensive machine that didn’t take up as much space and could do seemingly anything.
Comparing arcade ports to the 2600, we knew to expect that the graphics wouldn’t be as good, but usually the gameplay was just as good, if not better. It seemed like the difficulty was tuned to be a little bit more fun, a little less punishing, on the home console. And that made sense, too. In the arcade, the business model was to suck quarters out of pockets as quickly as possible, and that meant high difficulty, while at home they wanted you to enjoy playing the game for extended periods, so that you would want to seek out more games to buy.
Some arcade ports were more disappointing than others, and that was usually due to ROM space limitations preventing full featured ports. It might be a missing level, or it might be some other compromise, something they had to leave out because they couldn’t fit everything in. Sometimes it was limitations imposed by the single-button joystick being unable to replicate all the control options on the arcade cabinet.
A game like Strike Zone Bowling, a work-in-progress homebrew game for the Atari 2600, would have blown our young minds back then. It’s still fantastic now. Look at these screen captures:
I love this shifty-eyed shoe rental guy. With the mustache and red hat, he kindof reminds me of someone…The main action happens on this screen, which gives a convincingly realistic representation of a real bowling alley.Celebration screen animations for strikes and spares take the game to a new level.You can even select your bowler’s gender.After the game, depending on your score, you can hang out by the restrooms, the snack bar, pool hall, or video arcade.When you get “in the zone” it becomes easier to hit strikes and get a higher score.Anybody got a quarter?
The developer of this game has brilliantly worked within the 2600’s limitations. If you know how the 2600 draws graphics, it’s easy to see that. The 2600 does not have a screen buffer, so it draws its graphics to the display in real-time. That is, while the electron beam of the television is traversing the screen to excite the phosphors of the cathode ray tube, the Atari 2600 is sending data out the video cable to generate the signal the TV turns into a picture, generating it just in time. Sprite objects, stored in the ROM data on the cartridge as 1-bit bitmaps, are drawn one horizontal row at a time, and between each row the programmer can do clever things like change the drawing color, change the scale, mirror the image, and draw duplicates. The hardware can only draw two sprites to the screen, but if the programmer wants, they can reposition those sprites during draw time, and change the bitmap data used to draw them, to create the effect of more than two sprites. The hardware also supports the ability to draw two additional “missile” objects and a “ball” — but with even more limitations. And finally, the hardware can support drawing background graphics, meaning a background color plus a playfield. The playfield graphics are lower-resolution than the sprites for Player 1 and Player 2. And that’s it.
These limitations make the Atari much better at drawing graphics that are composed of vertically stacked rows of horizontal data.
You’ve come a long way, baby
We had a commercially-released Bowling game for the 2600 — it was called Bowling. And it was, if you can believe it, good.
Fun to play, decently challenging, especially if you were trying to score above 200, the 1978 Bowling game was perfectly acceptable, and well within expectations for what a video game was at the time. And 45 years later, Strike Zone Bowling absolutely blows it away.
If you look at the screen of Bowling, we can see that the developer was working “against the grain” when it came to drawing the screen. The player, ball, and pin graphics are all in the same horizontal row, and this necessitates use of the available hardware sprites on each row. It seems that the playfield graphics aren’t used here, and that the sprites are used to draw the scores for each player, the on-screen bowler, and and the bowling ball, while the pins and gutters might be drawn using the “missile” or “ball” graphics — to know for sure, we’d need to decompile the ROM and read the assembly code.
The designer of Bowling made the decision that because bowling alley lanes are long and narrow, using the longer horizontal axis of the TV screen’s 4:3 display made the most sense.
This new Strike Zone Bowling takes a more sophisticated approach, and presents the game from the bowler’s POV, or rather from behind the back of the bowler, looking down the lane. Use of perspective and foreshortening enables the full length of the alley to be compressed visually to fit in the screen. By doing this, the programmer is able to use row-by-row color changes to give an enhanced illusion of depth, creating a 3D-like effect. This also has the benefit of having fewer objects to draw at each horizontal row, meaning that the hardware sprites, missiles, and balls, can all be used together to create composite images that are composed of more colors than would otherwise be possible.
The game is also a lot larger, 32KB of ROM as opposed to the 2KB of the 1978 Bowling. This additional space is used to create a more full experience of going to a bowling alley, renting shoes, celebrating strikes and spares, and chilling out after the game by the pool table or at an arcade game. This gives the game more narrative elements and almost a story as opposed to simply simulating the game of bowling, it aims to simulate the total experience of going to a bowling alley.
As amazing as this beta is, it could be even better. The bowler is always right-handed, but it seems like it could be fairly simple to add left-handed bowlers by mirroring the graphics and the controls. Graphically, the ball could scale slightly smaller as it moves further away from the bowler, to create a better simulation of 3D. The title screen music is a bit basic, and could be improved. That’s about it. There could be additional controls and simulation for ball weight and velocity, but I think it would take away from the simplicity of the game, and it doesn’t really need those things to feel complete and like a good challenge.
As is, the game is already a solid A-level effort.
Phoenix was a hit arcade game in 1980-81 before being ported to the Atari 2600 the following year. A vertical fixed shooter in the tradition of Space Invaders, Phoenix was an evolution of the Space Invaders concept, which added a number of innovations: enemy variety, swooping enemies, regenerating enemies, shields, and a mothership boss — one of the first boss battles in video gaming.
The game consists of five waves, which repeat in a cycle. In the first four stages, you face waves of bird-like enemy space aliens. The first two waves consist of smaller enemies who bear some resemblance to their Space Invaders forebearers, in that they march across the screen in a tight, grid-like formation. But these enemies will break out of their formation and swoop down low to dive bomb the player, and then fly back up again.
The second wave features a larger number of enemies, and for some reason the player is afforded rapid fire on this stage only. On all other stages, you have to press the fire button every time you want to shoot, but on the 2nd wave alone, you can hold the fire button down and it will fire automatically.
Wave 3
The next two waves, three and four, feature larger bird-like enemies, which can be killed by scoring a direct hit on their body. An off-center hit will clip one of their wings, which will regenerate after a few seconds if the body isn’t quickly finished off first. These larger bird aliens fly from side to side, not in formation, and change altitude occasionally, and swoop low to touch the ground. It seems that touching the ground is what triggers their regenerative powers, but in addition to that, as they get this low they also pose a threat to the player, who will be destroyed if they collide. In the arcade, these regenerating enemies start out as eggs, which hatch and grow before your eyes to become full-grown birds, but on the Atari 2600 port this is simplified, and the egg phase of their life cycle is omitted.
Wave 5: The Phoenix Mothership. Videogaming’s first boss fight?
The fifth wave is the mothership: a huge, saucer-like ship that fills most of the screen. The boss is destroyed by shooting its commander, who sits in the center near the top of the ship. The bottom of the ship must be chipped away first, to expose the pilot’s cockpit. The rim of the saucer rotates, creating a revolving barrier that must be shot through. This takes time, during which the saucer slowly descends, dropping bombs all the while. As the mothership sinks lower, the reaction time afforded to the player to dodge these shots diminishes, making it increasingly difficult to stay alive. Judicious use of the shield and rapid fire button mashing is the way to survive.
My favored technique to defeat the mothership is to activate shields the moment the wave begins, and fire as rapidly as possible to blow through the shielding in front of the pilot, then as soon as the shield drops, I swing over to the left edge of the ship, where the shielding is thin, and blast away at the rotating rim. The body of the mothership tapers upward toward the outer edge of the ship, giving you a few more pixels of breathing room to react to incoming fire, which is very important. By being at the edge of the ship, you can always escape to safety by dodging left, completely out from under the ship’s breadth, and thus out of its reach. After shooting away the rotating rim, I wait for a clear moment when the mothership isn’t dropping many bombs, and then move back to the center, hit the shields again, and blast away until one of my shots manages to hit the pilot and destroy the ship.
In the arcade, the mothership was also protected by a fleet of escort birds, of the type from the first two stages, but on the Atari 2600 there wasn’t enough computing power to handle all that action, so they are left out, and you face the mothership one-on-one.
Then the cycle begins anew, much like the legend of the mythological phoenix going through death and rebirth.
Phoenix featured three distinct background tracks. Not full songs, these are just simple loops. The first two stages use an electronic wail or warble which somehow evokes bird-ness. The second two stages employ a loop with a swooping pitch from high to low, which evokes and reinforces the swooping motion of the diving birds. The mothership music is a more robotic, mechanical beeping that evokes classic sci-fi movie soundtracks of what space sounds like — beeping, echoing, un-melodious.
The shield adds a dimension of strategy to the gameplay. Using the shield involves a set of trade-offs. In exchange for temporary invulnerability, you cannot move. Further, the shield lasts a fixed amount of time, about 1.5 seconds, and thereafter cannot be used again until it recharges. There’s always a certain amount of luck involved with using the shield — because you’re immobile while it is up, and cannot control when it goes down, the timing of enemy fire can put one of their missiles right in front of you just as the shield goes down, without no time to move out of the way. Thus, while shields can bail you out of a jam, it can sometimes result in a mere delay of the inevitable. In addition to protecting you from the enemy’s shots, your shield will destroy enemies if they touch it, making it an essential offensive weapon for close engagements. When the enemies are very low, it’s too dangerous to take them on without the shield, as their shots cannot be dodged, and they can also crash into you. Thus, despite its slight drawbacks, learning how to use the shield effectively will help you to avoid deaths and last longer into the game.
Legacy
Phoenix is still as good as it ever was, but I don’t think it has aged as well as some of its contemporaries in the shooter genre. It’s primary drawbacks being that it gets pretty repetitive, and that this is accompanied by very little increase in difficulty after you’ve run through it the first cycle. There’s a nearly imperceptible increase in enemy aggression, but it isn’t much more than the initial cycle, and doesn’t seem to increase beyond that. The game awards a single bonus life, at 5000 points, otherwise this game would be easy to play indefinitely. Back in the day, my best scores on this game were around 135,000. While the game is generally pretty easy, accidental deaths are still tough to avoid completely.
It’s worthwhile to point to as an example of the evolutionary path shooters took, and was a noteworthy step forward in the emerging genre of fixed shooters.
Thematically, I liked Phoenix quite a bit. The theme ties in with the phoenix of legend, with its cycle of death and rebirth, giving the game a mythic quality that most video games seldom aspired to have. This gave the game an intangible quality that made it seem like more to me than perhaps it really was. I think this shows the power of narrative, and how even just a tiny bit of storytelling underlying the basic gameplay can enhance the player’s perception and reception of a game.
After publishing part 2 of this series, I played my grid map romhack a few times, and I think it’s rather good. I don’t know that I would say that I prefer it over the original map, but this is certainly a viable alternative map.
After a few playthroughs, I notice a few things:
The helicopter moves bridge pieces away from the Bridge screen much more frequently. In the original, once you’ve placed a piece at the Bridge screen, the helicopter would only rarely remove it.
The helicopter seems to move pieces from their starting screen much sooner, as well.
I like both of these differences; they make the game more challenging, and I think, more fun. You really feel like you need to race the helicopter to complete the bridge task. But I think it’s worth experimenting with the map to see if there’s a way to restore the original design intent, by reducing the number of paths into the Bridge screen. It occurs to me that an easy way to do this is to make the two screens above and below the Bridge screen connect to each other, rather than to the Bridge screen. So the Bridge will exit vertically to those screens, but reversing course will skip over the Bridge, but still place you near the Bridge; players would need to figure out that they are “around the corner” from the Bridge in this map, which is potentially disorienting, but should be less of a problem than the original map, which puts you clear across into the middle of the other end of the city.
I do think that this map has a few peculiarities that make it sub-optimal.
Some of the subway entrances are right next to their exits. There’s little point in a subway trip that results in you re-emerging on the overworld map one screen over from where you started. For example, the Red subway entrance is one screen away from two of its exits, due to being on the top left corner of the grid, and the wrapping effect. The Blue and Yellow subway entrances are about optimally located relative to their exit screens, and the Green subway entrance is directly above one of its exit screens.
It’s possible to remedy this by moving the subway entrances around, or by changing their exits to more useful screens for this map layout. I was reluctant to try this, because I wanted to keep the changes that I am making to the maps minimal, but it seems that these changes are necessary for the good of the game.
Metropolis 21/7
Another thing that strikes me is that I didn’t need to remove one screen from the overworld in order to have even rows. 21 = 3 x 7, so I could have made an overworld map of 3 rows of 7 screens. This might make the subways more useful, since it would make it easier to place the subway exits such that they are 3-4 screens from their entrances.
A 7×3 grid will allow all 21 overworld screens to be included in the new map. Again, I went to an image editor and re-arranged the screens to make a layout, then visually reviewed and analyzed the map for playabiltiy concerns, and made tweaks.
My first iteration of this was to lay the screens out in the original map’s horizontal sequence, and see how that would play. That map looks like this:
First iteration
Without actually playing it, it’s easy to miss things, but I can see that this map has a few potential issues:
The bridge pieces starting screens are all on the west end of the map, and are nearby the Bridge screen.
The Phonebooth, Bridge, and Jail are all on the bottom row, which makes the bottom row feel too important, and the top row feel unimportant.
The “critical path” relationships in the original map are broken in this map. This may not be a problem per se, but it will make the new map feel less familiar to experienced players.
The original Metropolis map has a very tight spatial relationship between the most important screens on the map. The new map layout breaks this by moving the Jail screen far away from the rest of the screens.
Otherwise, I think the map looks pretty decent. I’m not sure how I feel about the potential issues I mention above.
I do think that the Bridge should be the center piece of the map, so I shifted rows and columns in order to make it so, but the rooms are still in the original order, using the horizontal progression from the original map.
It’s interesting how shifting things around can change perspectives on things. With this view, I’m able to notice different things:
Now all the “important” screens (Jail, Bridge, Phonebooth, Daily Planet, and all but one of the bridge pieces) are on the west end of town.
But balancing that, all the subway entrances are on the East end of town.
Subway exits are somewhat evenly distributed, but there’s a few interesting things to point out: The Red subway exits all line up in a column at the far west edge of the map, while the Yellow subway exits are all distributed across the top row. The Green subway exits follow a diagonal from the northwest corner of the map, moving southeast. And the Blue subway exits are scattered about as far from each other as they could be.
Shifting the screens changes the loopback point at the top right, and as a result the screen that normally is to the left of the Phonebooth screen no longer is. Which, despite what I thought when I first decided to shift the screens to put the bridge in the center of the map, does fundamentally change the map. Then I realize… I did it wrong!
I can’t just grab the top row and move it to the bottom, and then slice the right couple of columns and move it to the left. That will not preserve the horizontal order of the screens. To do that, I need to grab the top-right screen, move it to the bottom left, and then let all the other screens shift right by one, snaking around. This approach gives this result:
Overall, it’s actually very similar to the first two iterations. It’s literally the same horizontal sequence as the first iteration, but it’s not all that different from the second iteration, either; the “important” screens are still mostly to the west, the subway entrances are still mostly to the east. I think the subway exits are a bit better distributed than in iteration 2.
The vertical path is quite different. I think this map will run slower, due to the placement of the Jail in the corner of the map, and its distance from most of the subway entrances, and the Phonebooth/Bridge screens. There might yet be some quick paths that will become apparent through repeated play, but for now I feel that the map feels disorienting because the Jail isn’t north of the Yellow subway entrance screen any longer, and I struggle to locate it as a result.
Certainly there are many other possible arrangements for the overworld map, and I haven’t even begun to re-design the subway. But I think this is enough to satisfy my curiosity, at least for the time being. I may come back and revisit this further if I feel a need to after playing the maps I already created more extensively.
There’s much more to do in a hack of Superman, as well. I would like to figure out how to randomize the starting places of the bridge pieces, for example. I would also be interested in figuring out how to put up a hard barrier around the outer edge of the map, rather than having the map wrap around at the edges. But these projects, if I ever attempt them, will have to wait until I have a deeper understanding of 6502 assembly.
For the second alternative map, I needed to carefully re-organize the screens to put them into a grid.
There are 21 overworld screens, and so I will use a 5×4 grid, omitting one of the overworld screens, since there can be only 20 screens in a 5×4 grid.
Selecting the right screen to omit is important. The removed screen must not be:
A subway entrance
A subway exit
The phonebooth, bridge, or jail screen
A bridge piece start screen
One of my goals with this redesign is to keep the layout of the screens reasonably familiar to players of the original game. This is a formidable task, and technically impossible since I am changing the layout, but my goal is to make the changes minimal, and to preserve as much of the critical paths through the map as possible.
But just as important, I want the redesigned map to be balanced and fun to play.
To achieve this, I want the subway entrances and exits to be distributed about the map, and not clustered together too much.
There are 11 unique subway exits, and 5 subway entrances (counting the Daily Planet), so 16 of these screens have something to do with the subway system, and another three are the Jail, the Daily Planet, the Phonebooth, and the Bridge screen. (Both the Daily Planet and the Jail are also subway exit screens, so are already counted among the 16 overworld screens that are related to the subway system, but adding the Phonebooth and Bridge brings the total of “must keep” screens to 18, leaving just 3 redundant screens for possible removal.) I didn’t realize how tight the map design is until I noticed this.
After considering the matter for a bit, I decided that this screen would be the one to go:
But I just as well I could have picked this one:
Or this one:
I mean, they’re all kindof the same, aren’t they?
I note that the three “dispensable” screens all have a similar color scheme to them, green and white, and wonder if there’s something being communicated through a visual language here, or if it’s just a coincidence… there are two other green/light grey screens, the Yellow Subway entrance, and the screen above the Jail, which is one of the bridge piece starting rooms. So… probably just a coincidence, then.
At the edges of the overworld grid, the map will wrap around to the next row or column. As an experiment, I think I’ll also create a variation where the map will wrap around to the same row or column, but I think this variation will only be playable on Easy difficulty — because, when Superman is struck by kryptonite, he will be stuck in the current row of the overworld map, and if Lois Lane isn’t present on that row, he’ll be unable to get revived until she wanders in, or the helicopter brings her, which could take ages, and would be unfair.
I take a picture of the overworld, cut out each room, and put it into an image editor and move them around until I have them arranged in a 4×5 grid that I think will be satisfactory. I end up needing to move things around a good bit to achieve this, but I think I managed to do it while still preserving some of the critical relationships between certain rooms.
Here’s what I ended up with:
I think this might be OK. And might make a cool quilting project, too!
Here’s the original map for comparison:
So you can see, there’s a bit of re-shuffling that I had to do in order to balance the map out, and many of the vertical and horizontal connections are different in the new map.
The major changes are:
The one-way vertical boundaries for the Phone Booth and Bridge screens are two-way.
One screen is removed from the overworld, to allow for an even grid.
The Phonebooth and Bridge screens are in the center of the map. (Although, since the edges of the map still wrap, center/edge is all relative.)
The important non-changes are:
The subway system exits are all to the same screens as before. (But, due to the shuffling of these screens relative to one another on the overworld, this does still mean there’s some significant differences. The key exits to get to the Daily Planet and Jail screens are the same as in the original, though. And several of the subway exits now get you close to the Bridge screen.)
The bridge pieces are still found on the same screens as they were in the original. I didn’t try to re-locate them. (Sometime, I’d like to introduce randomization into their starting positions, and see how that plays.)
Now that I had the design determined, I had to hack the rom to make the changes for real. To do this, I went through the original code and noted the names of each screen, and figured out from the boundary change code the correct addresses for each room, and mapped them together. This was straightforward, if a bit tedious, but fortunately the map is small.
One thing I noticed as I coded the new map connections was that there’s a peculiarity at the top-right and bottom-left corners of the map, due to the way the rows and columns wrap; if you’re in the top-right screen, going up or right will both take you to the bottom-left screen; and if you’re in the bottom-left screen, going down or left will take you to the top-right screen. This doesn’t make sense, unless you understand the way the overworld wraps. If you get to the end of a row or column, continuing in that direction wraps you around to the next row or column, and at the very end of all the rows and columns, it wraps you around to the opposite corner, and so the top-right and bottom-left screens are connected to each other in two directions.
I have only played through this map once, and mostly just to test that everything was connected properly. I think it’s a viable, and interesting variation, but I wouldn’t call it better than the original. Certainly, due to the re-positioning of the screens, the quick path to the bridge pieces isn’t as short as in the original map, which means speed running potential for this map is reduced. Beyond that, the Phonebooth and Bridge screens are not low-traffic screens any more, meaning that you’ll often find gangsters on these screens, and the helicopter may find bridge pieces that you’ve left at the Bridge site more readily, which will again make it more challenging as the helicopter removes them again.
You can download the entire collection of romhacks here:
So for the first alternative map, I will just make the Up screen the same as the Right screen, and the Down screen the same as the Left screen. This means that there will only be the Horizontal progression through the map, and that Up/Right will be “forward” and Down/Left will be “backward” through this progression.
I playtested this, and found that it works exactly as intended. The map is far simpler to navigate, and getting lost is now virtually impossible. Fly up/right to go forward, down/left to go backward, and all overworld screens appear in order. The confusing one-way vertical borders on the Phonebooth and Bridge screens are eliminated.
The downside of this is that traversing the overworld map is slower, since there are no shortcuts to be gained by using cornering techniques. You still can rapidly advance two screens in the horizontal map sequence by going diagonal from near the corner, transitioning on both the vertical and horizontal edge transitions. But compared to the original, where a vertical transition would typically advance you between three and five screens in the horizontal sequence, it’s much slower, and offers no real opportunities for useful shortcuts.
The only real shortcuts possible are via the subway system, which I left unmodified. Despite playing this game over nearly four decades, I’ve never bothered to memorize the subway in its entirety — there’s little reason to. The only exits of real importance are the ones that go to the Jail and Daily Planet. But with this map, knowing the rest of the exits is potentially more valuable, because it can get you to the other side of the overworld in less time than any other method. It may be interesting to study the exits and try to figure out alternate layouts that might make the map more interesting by providing additional useful shortcuts.
I can reliably win Superman typically in 1:30, +/- 15 seconds, but this variant took me 3:04 to win on my first play. I’m sure faster times are possible. The gangsters seemed to be bunched up more, and rounding them up preoccupied me at first, leading to the helicopter moving bridge pieces away, which I think happened earlier than normal. But because the map is essentially a two-dimensional line, finding the helicopter was trivial, making any challenge increase by the bridge pieces moving around quite minimal.
My impression is that this alternative map might have made the game more playable for very young players, ages 3-5, and as an “easy” version for beginning players, much like Superman‘s sibling Adventure offered players Game 1 with a simplified map. But overall, the simpler map makes the game less interesting and less challenging to play. But if you’re interested in the game’s design, playing this variant to see why it’s less interesting is… well, an interesting exercise. I invite you to download it and play it for yourself and make up your own mind. If you do, please drop a comment and let me know what you think.
My next Superman romhack will present the overworld map as a grid.
Open World is an art exhibit of contemporary art influenced by video games. The Open World Arcade is a one-day event, to be held on December 7th, 2019, from 11 AM – 5 PM. Games presented in the arcade are judged by a panel of museum staff and video game professionals based on novelty, professional polish, aesthetics, quality of game experience and “wow factor.”
My game Ancient Technologies was an homage to the “ancient” technology of videogaming’s past, and re-creates the experience of setting up an Atari 2600 video game system. If you “win” the challenge of setting up the system correctly, your reward is that you get to play a somewhat faithful re-creation of the game Asteroids.
I created the Ancient Technologies in about 25 hours using GameMaker Studio, Stella, and Audacity. The Asteroids game that you play inside of Ancient Technologies is a simulation, not emulated. I used graphic and audio samples generated by Stella to create the simulation. I also sampled pixel art renderings of the Atari 2600 six-switch console and joystick created by pixel artists, and a partner provided the TV image, while I created the background of the living room. The simulation is a reasonably faithful re-creation of Asteroids’ gameplay, and feels pretty authentic in many respects, although it is not completely accurate. Most notably, it is missing the UFO and Satellite enemies, which I ran out of time to implement in the game.
I have seen some of Champ’s other Atari 2600 homebrew projects, and they’re very impressive. They did a version of Scramble which is virtually indistinguisable from the arcade, which is an incredibly impressive accomplishment on hardware as limited as the Atari 2600.
Galaga is a classic arcade game, one of the most successful of its era, and can still be found in bars and arcades all over. It was one of my favorite arcade games as a kid, and I’ll still drop a quarter in one when I find one and have some time to kill.
I owned the Atari 7800 port of Galaga, and was glad I could play a version of it at home, even if it wasn’t quite exactly the same experience as playing the arcade version. What Champ has come up with, from what I can see in their video, it appears it feels closer to the arcade than the 7800 port, although the graphics are slightly inferior to the 7800 version.
Galaga (Champ Games) title screen
The motion of the incoming wave is stunning!
Fighter capture looks impressive!
Here’s a preview video showing the game in action and talking about some of the technical details:
As a Galaga fan, I really want a copy. As a game developer, I’m impressed with the effort and execution it takes to get a game looking and playing this good on such limited hardware. It simply shouldn’t be possible on an Atari VCS, which only has 5 hardware sprites plus backgrounds, and nowhere near enough CPU or memory to handle all the complex movement that is required to accurately re-create a Galaga experience.
How do they do it? Well, I asked them. And they were nice enough to answer: they build a cartridge with an ARM CPU in it, and it augments the Atari’s built-in hardware, and this is how they’re able to create games that are vastly superior to what should normally be possible with the 2600 console alone.
My response to this was disappointment, and I said as much. But I think it came off the wrong way and more than one person jumped on me for saying something negative about what is otherwise an exciting project for fans of the Atari and of Galaga. No one was particularly brutal toward me, but the creators behind the project were a bit nicer than their fans, and engaged with me and we had an interesting conversation on the philosophy of homebrew, and how their technology works. I want to thank them for that, and for creating such great games for the Atari 2600 in 2019, and keeping the system alive more than 40 years after it launched. I have a copy of Scramble and am really looking forward to playing Galaga and Zookeeper (another favorite classic arcade game) when they’re ready.
So, first things first, from a gamer’s standpoint, the only thing that truly matters is the game experience itself. It doesn’t matter what technology is inside of it, or how amazing, complicated, or messy the engineering is. The only thing that matters is the experience you have when you play the game. If it’s fun, if it’s polished, it’s a good game. End of story. And that’s exactly why I’m excited about buying a copy of this when it’s ready for release.
Now, as to my disappointment. At first I thought I was seeing something impossible, and I was really keen to hear how they had managed it. The solution of adding an ARM to the system architecture of the VCS is fine, nothing wrong with it. But it’s not amazing. My disappointment was from the vantage point of the programmer, who was mind-boggled at how this team had managed to get so much performance out of a 6507 CPU backed by 128 bytes of RAM. Well, they didn’t. They bolted on a 70 MHz ARM CPU, and got it to talk to the rest of the system, and while that also requires some neat engineering, it’s not magical in the way that somehow figuring out how to get 3x Zilog Z80’s worth of performance (which is what powered the original arcade Galaga machines) out of a MOS 6507.
That’s really all I meant by what I said. I don’t consider it “cheating” to augment the console hardware by packing in additional chips on the ROM cartridge circuit board. This was done back in the day, and was very necessary in order to extend the life of the Atari. All cartridge-based consoles that had a market life of more than a few years needed to use such tricks in order to keep their hardware competitive and relevant as computer technology doubled in speed every year.
The only real difference is that these augmentations were done using chips that were comparable (or at least within 1 generation) of the capability of the original hardware. They truly did augment the system. Whereas, with a 32-bit ARM CPU, you really could build a system around that chip alone, and do more than you could by interfacing it to a 40-year old Atari system architecture that forces it to slow down and work within the constraints of its design. I mean, with a 70MHz 32-bit ARM CPU, it should be possible to do an arcade-perfect emulation of the original arcade hardware, or if not then to certainly come much closer to that than what you can get by running the I/O and video drawing through an Atari VCS. So, rather than the ARM augmenting the Atari, the Atari is kindof bringing down the ARM. This doesn’t matter if you’re nostalgic for the Atari and like the feel of a CX40 joystick in your hands and the crude graphical style just barely possible with the 6507-driven TIA. If you don’t know or don’t care about the engineering, it just looks and feels like the best damn Galaga port you could imagine, running on an Atari 2600, and actually quite a bit better looking than anything you would have thought possible if you did know the system’s capabilities.
But really, it’s almost all due to the ARM chip’s capabilities, which are many times the power of the rest of the system.
I suppose one could take an Atari 2600 controller, put a wifi chip in it, and have it interface with Google’s Stadia console-in-the-cloud, and run Assassin’s Creed, downsampled and graphically degraded, through the Atari, as well. And… actually hell yes, that would be cool as fuck. I want to buy that too. But it’s a different kind of cool to hook an Atari up to a cloud supercomputer platform than it would be to somehow squeeze Assassin’s Creed into 4 KB of ROM, if that were even possible.
If he had somehow teleported the Statue of Liberty, and then brought it back, or if he had somehow made the Statue of Liberty disappear, how awesome would that have been? Whether by real “magic” or by some super-advanced technology that no one else had yet heard of, that would have been beyond amazing. It would have changed the world we lived in, in untold ways. But it didn’t. He just set up some elaborate rotating stage, hid everything behind curtains for over an hour while everything was being moved into position.
Eight year old me was captivated by the idea of a giant statue disappearing and reappearing, whether through magical or advanced technological means. A couple years later, though, I was old enough to realize it wasn’t “real” magic, and that it was some kind of “cheap” trick (well, relative to the cost of really doing it, anyway), and wasn’t as impressive as I had thought, and as a kid you really hate being lied to, you hate being fooled. It makes you feel embarrassed and dumb, and you want to hide the fact that you ever thought it was cool.
So for a long time after that, I kindof had this grudge against David Copperfield, and stage magic, and whenever I’d see someone pulling off some sleight of hand or optical illusion trick, I’d get annoyed and impatiently insist that magic is bullshit, and refuse to be impressed by it, because I wasn’t some fool. For maybe a year or two, I had believed that we were on the cusp of a Star Trek-promised future, with instant teleportation, or at least invisibility shields. That would have been so cool. But no, we didn’t get that.
Well, now that I’m 43, I’m back to being impressed at how convincing an optical illusion David Copperfield could create with just some lights, scaffolding, cranes, and a rotating stage that moved slowly and gently enough that an entire audience didn’t notice they were moving. Even if the entire trick required the cameras filming it to be positioned just right. That still took some serious engineering effort, and even for as limited as the result was as compared to true invisibility or teleportation, when you realize all the work and planning that had to go into it, that’s still pretty damn impressive — just in a different direction completely than I had been (mis)lead in the first place.
So this is what I meant by “disappointed” when I found out that Champ Games puts an ARM CPU in a cartridge and through some impressive engineering hacks gets it to talk in sync with the console and run a game that blows most other Atari 2600 cartridges away. Sure, the game is impressive and it’s certainly going to be fun to play. On the other hand, a ARM CPU is in a different “weight class” from a typical ROM cartridge with perhaps a little extra RAM or a sound chip soldered onto the board. This isn’t to take anything away from the experience of the game, or the technical wizardry required to build it.
But it’s a bit like putting a 1000cc engine into a go kart and then winning a go kart race with it against a bunch of stock go karts. It’s still a pretty cool project to put a 1000cc engine in a go kart, but when you find out that’s why that kart was so much faster than the others, it’s hard not to be a little disappointed that the secret wasn’t some method of suping up a 50cc lawnmower engine to get the performance of the 1000cc engine. And then you realize that the chassis of the go kart really limits how much performance you can actually get out of that 1000cc engine, compared to something engineered to get the most out of it, like, say a state of the art motorcycle chassis, transmission, wheels, etc. And then the super kart seems, well, it seems pretty fun still, but kinda wasteful of the potential of that engine.
When it comes to chip enhanced ROM cartridges, I think it’s fair to say that, at least from an engineering standpoint, once you get to the point where the enhancement hardware is not only more capable than the console itself, but is actually held back by the restrictions imposed by having to interface with the console, such that you’re exceeding the console’s limits, but not able to push the expansion hardware anywhere close to its limits, you’re at a cutoff point. While it’s entirely possible to create an awesome game experience this way, you’re really at a point where you’re well beyond the capabilities of the console, and the console is holding you back. At that point, you might as well engineer a new system.
The only practical reason not to engineer a new system would be if the existing install base for the obsolete console is still a viable market; the work it takes to establish such an install base with a next-generation system is considerable. But this is a business consideration, not an engineering consideration. And business considerations aren’t less legitimate than engineering considerations, but obviously businesses do at some point make the decision to roll out a new generation of console hardware. Which is why we’ve had several of those in the intervening 40 years.
And of course, there’s nothing wrong with doing it “just to do it”, in the way mountaineers climb the tallest mountain they can find “because it’s there”.
Update: ROMs for Galaga are now available for download.
