Failure To Launch

I truly do believe that every failure, if you learn from it, is a stepping stone on the path to success. Not that it isn’t painful; it hurts to admit I can’t always pull off everything I set out to achieve (at least not right away).

I’ve learned a couple of key things from this particular failure.

First, is that I need to be far more rigorous in breaking down tasks into concrete, atomic, achievable units. I also need to improve my approach to logically grouping the sequence of, and contents contained in, each milestone. To remedy this, for future projects, I am dead set on getting my project methodology (from promising idea all the way to Pomodoro work blocks) ironed out this weekend.

Second, I cannot, in good faith, delude myself into thinking I can work on multiple projects at one time. In addition to my day job and family obligations, I have room for only one side project of significance. I’ve withdrawn from RetroChallenge 2018/09 in order to focus on development of the next evolution of my Post Notif WordPress plugin. I REALLY wanted to work on improving the game I’d created during April’s RetroChallenge. But my plugin takes priority this month and its progress has been suffering because I am spread too thin.

By meticulously adhering to an adequately detailed task plan and a corresponding schedule for executing it, I should be able to complete a project in a month’s time, reassess my list of potential next projects, and then choose another one to work on the following month. This will focus me on making meaningful progress on a specific project while not forcing me to feel like I’m stuck working interminably on it, as I’ll know that four weeks later I’ll be working on something fresh.

00

RetroChallenge 2018/09: Week 1 Plan

In April, bracketing each week of my RetroChallenge project with a “to-do” post and a “done” post worked well to keep me making steady progress, from week-to-week. So I’m going to stick with that approach this time around, as well.

Here are the improvements, related to game play, that I’m aiming to knock out in Week 1:

  • Make both target and obstacle appear at random (as opposed to fixed) byte positions (horizontal location)
  • Make both target and obstacle move vertically at random speeds
  • When player earns x number of points and/or multiple of y points, give them extra car
  • Make both target and obstacle animation less flickery (via experimenting with wait lengths between erase-draw cycles)

Buckle up!

00

RetroChallenge 2018/09: Back At It!

It’s a whole new installment of John Linville’s RetroChallenge but it promises to be the same terrific motivator for me that the April event was.

Per my conclusion post, from April, I already have a lengthy, soon-to-be-prioritized, list of features and improvements to make to my 6502 assembly-written driving game.

In addition to continuing to reference Assembly Lines, I am happy to report that I have acquired a (very hard-to-find) hard copy of Hi-Res Graphics And Animation Using Assembly Language, which I expect to be leaning on extensively, particularly when it comes to improving the game play via enhanced graphical motion.

Once again, due to my incessant optimism (in the form of terminal underestimation of level of effort), I know the month will fly by, but I’m eager to see what I can get done to make version 2 more fun to play than the original.

Stick around to see what Merlin spits out!

10

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

RetroChallenge 2018/04: Weeks 3+4 Recap

Alright, so anyone paying attention might have noticed the missing Week 3 Recap and Week 4 Plan posts. Don’t worry, I have excuses…errr..I can explain!

Week 3 started off with animation tasks. It didn’t take long before I remembered what ultimately killed my first attempt at this game, back in elementary school; though delighted with the graphical output from Beagle Bros.’ Apple Mechanic, I couldn’t wrap my head around how to animate anything that might interact with the totally bitchin’ car I’d drawn with the tool1. Thirty years later I have a firm grasp on the Applesoft shape table routines but hit the point where drawing outlined images was not going to cut it for my purposes.

So, resigning myself to a return to very basic images, I went searching for graphics-specific assembly documentation online. These travels ultimately led to my discovery of a book that, sadly, seems to be (long?) out of print and unavailable for sale, even on the mighty Internet. Fortunately, there is a scanned PDF (though it is missing some pages!) on archive.org. Hi-Res Graphics And Animation Using Assembly Language by Leonard I. Malkin, Ph.D. is amazingly well written, with concepts explained simply, bolstered by flowcharts (particularly helpful when attempting realistic animation while confined to assembly’s single-threading), sample code, and thorough explanation of the code itself2. If you just so happen to have a spare hardcopy of this terrific tome, that you’re interested in selling (or know where I might acquire a copy), please do get in touch!

Anyway, despite scrapping nearly everything from the first two weeks (though working through nearly every chapter’s sample programs in Assembly Lines did give me a solid understanding of the 6502 opcodes and made me very comfortable using Merlin), in these past two weeks I still:

  • Wrote code to animate the (initially) hardcoded set of obstacles, as they scroll downward (implying that player’s car is driving “forward” on road)
  • Wrote code to animate the (initially) hardcoded set of targets, as they scroll downward
  • Generated shape data for intended collisions (with targets)
  • Generated shape data for accidental collisions (with obstacles)
  • Wrote collision detection code
  • Wrote code to display appropriate collision graphics, dependent on type of collision

Here’s an underwhelming screenshot (made particularly so, by the fact that I am still ironing out draw-erase cycles for the various objects, meaning that only the player’s car and the “+1” graphic, displayed when the player’s car collides with the target object [gas can], are visible):

RetroChallenge 04/2018 #3

Now I have the weekend and Monday to nail down a scoreboard, clean up some pesky collision-related artifact issues, and, if time permits, add some sound effects so I can get a complete, working game shipped by 4/303.

Tune in Tuesday for the exciting wrap up!

  1. As I recall, I managed, using XDRAW in BASIC, to get the car to move side-to-side but that was about the extent of my “animation.”
  2. Plus, as a bonus, there are politically incorrect limericks, straight out of the ’80s, at the start of each chapter!
  3. There will be plenty of time to polish things in v2 and beyond!
00

RetroChallenge 2018/04: Week 3 Plan

Week 3 of the RetroChallenge is upon us now and, with it, a sense of urgency to seriously buckle down and crank out code!

As a result of diving far too deeply into the Applesoft shape table routines, in pursuit of the —> ultimate <--- player's car graphic, I failed to get to several of the tasks I had slated for completion in Week 2. So it comes as little surprise that those tasks have landed back on my list for this week:

  • Write code to animate the (initially) hardcoded set of obstacles, as they scroll downward (implying that player’s car is driving “forward” on road)
  • Write code to animate the (initially) hardcoded set of targets, as they scroll downward
  • Generate shape table data for intended collisions (with targets)
  • Generate shape table data for accidental collisions (with obstacles)
  • Write collision detection code
  • Write code to display appropriate collision graphics, dependent on type of collision

Fortunately, I had a bit of buffer deliberately built into my schedule, but I’m bound and determined to get these completed this week!

OK, enough said; back to work I go!

10

RetroChallenge 2018/04: Week 2 Recap

Friday night and time for my Week 2 recap. This week I:

  • Addressed long distance branching issues that surfaced at the tail end of last week
  • Wrote code to keep player’s car within horizontal boundaries of the board (i.e., on the “road”)
  • Made road lines double width (so they appear white instead of purple)1
  • Generated improved shape for gas can (target)
  • Generated (MUCH) improved shape for player’s car

Here’s an updated screenshot of the game board:

RetroChallenge 04/2018 #2

I have become very well-versed in the inner workings of the Applesoft shape table routines, though now that I am working on animating the individual graphical elements, I am going to have to discard most, if not all, of these shapes and switch to programmatically turning on/off individual bytes on the hi-res page itself. The silver lining of this being that it may render moot the issues I have at present with disproportionately sized objects (the player’s car and target object are huge compared to the obstacle object and the overall road).

I continue to make forward progress, though due to a few time-consuming snags I hit this week, I’ve been forced to push several tasks to next week.

  1. You’ll see, in the screenshot below, however, that there is a portion of the left line that renders green; I’ll have to iron that out.
00

RetroChallenge 2018/04: Week 2 Plan

I am thoroughly enjoying this project, one week in, and am eager to get started on the next set of tasks!

So, without further ado, here’s my plan for what I intend to bust out during Week 2:

  • Write code to keep player’s car within horizontal boundaries of the board (i.e., on the “road”)1
  • Address long distance branching issues that surfaced at the tail end of last week
  • Write code to animate a (for now) hardcoded set of obstacles, as they scroll downward (implying that player’s car is driving “forward” on road)
  • Write code to animate a (temporarily) hardcoded set of targets, as they scroll downward
  • Generate shape table data for intended collisions (with targets)
  • Generate shape table data for accidental collisions (with obstacles)
  • Write collision detection code
  • Write code to display appropriate collision graphics, dependent on type of collision

OK, here we go!

  1. It IS tempting to allow the player to swerve all over the place but it rapidly litters the screen with annoying artifacts!
00

RetroChallenge 2018/04: Week 1 Recap

Alright, one week down, and I have to say I’m relatively pleased with how things are progressing. Specifically, in the first week I:

  • Wrote code to draw game board (“road”, NOT including a lane line, at least for now)
  • Generated plot map for player’s car
  • Generated plot map for other car (obstacle)
  • Generated plot map for gas can (target)
  • Generated shape table data for player’s car, obstacle car, and gas can
  • Wrote code to populate shape table
  • Wrote code to draw shapes from shape table
  • Wrote code to capture player’s keyboard input (to control “steering” of player’s car)
  • Wrote code to redraw player’s car in appropriate position on screen (within “road”) based on keyboard input

Here’s a screenshot of what the game board looks like presently:

RetroChallenge 04/2018 #1

I have a lot to digest, as I plan for Week 2. First up, dealing with some challenges around forced branches over long distances (i.e., more than 127 bytes). Fun stuff. 🙂

00

RetroChallenge 2018/04: Week 1 Plan

My target for each week is to publish a “this is what I’m PLANNING to get done this week” post on Sundays and a “this is what I actually GOT DONE this week” post on Fridays.

However, with Easter falling on the first day of the RetroChallenge, that didn’t happen (though I still managed to get through another couple of relevant [i.e., related to hires graphics] chapters of Assembly Lines).

So, better (slightly) late than never, here’s my plan for what I intend to accomplish this week (Week 1):

  • Write code to draw game board (“road”, including lane line?)
  • Generate plot map for player’s car
  • Generate plot map for other car (obstacle)
  • Generate plot map for gas can (target)
  • Generate shape table data for player’s car, obstacle car, and gas can
  • Write code to populate shape table
  • Write code to draw shapes from shape table
  • Write code to capture player’s keyboard input (to control “steering” of player’s car)
  • Write code to redraw player’s car in appropriate position on screen (within “road”) based on keyboard input

Let’s get rolling!

02