RetroChallenge 2018/04: Summary (or “Spy Hunter It Ain’t!”)

I’m pleased to say that I accomplished my objective for this (Retro)Challenge – I built a functioning, hi-res :), Apple ][ game, written entirely in 6502 assembly language.

Granted, the graphics are primitive and flickery. The game play is thoroughly uninspiring. There is no sound. Your number of cars (“lives”) remaining is represented simply by a single digit, and a three-digit number indicates your score (and neither has a textual label). And when your game is over, there is no “game over” message. Here’s what it looks like:

RetroChallenge 04/2018 #4

However, you ARE able to steer your car with a joystick. When you collide with a target object (a gas can graphic) a “+1” is displayed at impact and your score is incremented to reflect that. When you collide with an obstacle (another car) an explosion graphic (temporarily) replaces your car and the one you ran in to, and your “cars remaining” counter decreases by one. And when you lose your last car, the game freezes, waiting for you to press “Q” to quit (to DOS) or any other key to play again.

So, despite the warts, omissions, and shortcomings listed above, all of the pieces of an enjoyable game’s skeleton ARE there, ready for refinement and improvement.

To that end, I have already started a list of tasks to work on for version 2 (maybe for the next RetroChallenge?!); here’s what’s on it for now:

  • Implement sounds (main game sound, player moving sound, target collision sound, obstacle collision explosion sound)
  • Experiment with wait lengths to make both target and obstacle animation less flickery
  • Label cars left “Cars:”; when game over, erase this label and display “Game Over” instead 1
  • Label scoreboard as “Pts:”2
  • Fix lousy-looking digit images3
  • When player hits x number of points and/or multiple of y points, give them extra car
  • Make both target and obstacle move at random rates
  • Make both target and obstacle move at random (as opposed to fixed) byte positions (horizontal location)
  • Make it so that there can be more than one target and more than one obstacle on screen at a time
  • Make all game element graphics better-looking
  • Replace digit for cars remaining with actual images of the player’s car up at top left
  • Add center line (or multiple lane lines) to road
  • Add graphical elements to sides of road (i.e., trees, plants, houses, or the like)
  • Figure out how to do something akin to DFB assembler directive to less manually handle shape address management in code (avoid having to recode SHPADR every time code is added or removed)
  • Look into employing double hi-res and/or better-looking shape color, per the second part of the Malkin book
  • Look into more advanced movement of targets and obstacles (such as diagonally), per the second part of the Malkin book
  • Consider adding a splash screen on start up
  • Consider adding a game over graphic and restart/quit dialog

Eventually, once I’ve had a chance to sort out the logistics, I will put this on GitHub for the viewing pleasure (general amusement?) of any interested parties. But first I need to iron out my future Apple ][ development process. To preserve my actual ][e’s keyboard, I did all my work in a browser, on my Linux desktop, running the excellent Apple //jse. Because I began this adventure by working through the examples in most of the chapters of Assembly Lines, I followed Roger Wagner’s lead and used Merlin (8-bit single line editor version). This worked well enough, overall, and made me feel sufficiently retro, to boot (to atone for not actually typing the code in to the ][e directly!) :), but it left some things to be desired. I need to identify a better way to develop in a modern text editor, test via emulator, and then transfer to vintage hardware to enjoy the finished product.

Ultimately, there were several things that particularly stuck out to me:

  • Assembly, compared to the high-level languages I typically work with, is refreshing to code in due to its simplicity and speed4
  • Graphics are tedious (particularly horizontal animation)
  • Using an emulator presents challenges (though Apple //jse IS a wonderful application)
  • Linux needs a more comprehensive set of Apple ][-related tools, akin to Windows (CiderPress, in particular, seems to be a real gem for reading and writing between the various Apple ][ file types and modern text files)5
  • Most significantly, what people like Jordan Mechner, Doug Smith, and Dan Gorlin did, back in the day, is even more impressive to me today, than it was to me, as a game-crazed pre-teen, in 1985!

So, that does it for now. I want to thank John for hosting the RetroChallenge; it was precisely the motivator I needed to stop talking about how “SOMEday I am going to build a 6502 game” and actually do it.

RetroChallenge 04/2018 #5

  1. My son, an 8-bit graphic enthusiast, has already begun work on a character set for me to incorporate.
  2. See above.
  3. One more time!
  4. I’ve known this since assembly was de-mystified for me, during a college course, back in the mid-90s, where we did MIPS assembly. But, though I enjoyed the brief time we spent on it, for class, I did not have the time or motivation, at that point, to revisit my 6502 aspirations from years prior. So it wasn’t until this month-long project that I finally fully appreciated it!
  5. If you happen to use Linux and are happy with the tools you use, please get in touch!
10

Leave a Reply

Your email address will not be published. Required fields are marked *