I own the GBA cartridge, you cretins, so I hold the moral high ground here. =] It was just getting too frustrating having to constantly refer to a translated script… you really miss a lot of the game, which is a shame when the most interesting thing about the Earthbound/Mother series is the writing.

Makin’ another game! It’s a nonogram game, inspired by Mario’s Picross (read more details about the whole genre at Game Set Watch).

Admittedly, nonograms aren’t for everyone. I enjoy them, however, because they’re simple logic puzzles that have a visual component… they’re more interesting to me than the straight-up numbers of sudoku. When I explained the concept to Chandra, she seemed interested! It’s my goal to make something that she’ll play through =]

I’m old and tenacious now. Or maybe I’m just stupid enough not to know when to quit. Regardless, I had the idea that since I’ve finished most of the other games in the Zelda series, I should go back and finish Zelda II. So I busted out the NES (no Virtual Console here, punk!) and played through the game. Having completed it, I now feel like I’m in a better position to comment on the “black sheep” of the Zelda franchise.

Zelda II is usually dismissed by gamers, due to its departure from the “traditional” top-down view that all other 2D Zelda games use. Instead, it is broken up into an overhead “exploration” view, and a side-scrolling “action” view. The “action” view, while being something of a new paradigm for the series, is also notoriously difficult. Even though Zelda II doesn’t contain much of the exploration and puzzle-solving that gamers associate with the name “Zelda,” I still like it. In my mind, it’s a great example of a sequel done right. It takes the characters and world of the first game, and instead of rehashing the first game, creates something entirely new (from a game play perspective).

While the game is difficult, it’s not impossible. The great thing is that it’s possible to progress in the game using tenacity to replace skill. If you are having difficulty dispatching some of the tougher enemies in the game, you can fight weaker enemies until your character’s attack power and life meter increase. Unlike the first game in the series, enemies do not drop health-replenishing hearts. Instead, the main character, Link, gets a “Heal” spell very early in the game. Running out of MP to cast the spell while in a dungeon puts you in a tight spot… or does it? Every 6th enemy drops a magic-replenishing jar, which (if the process is repeated enough) will fill up your magic gauge, which in turn refills your life. Plus, as you progress through the game (and gain skill at the game mechanics), these “helpers” become more and more superfluous.

My conclusion is that I like it. It’s a worthy game to invest time in completing, especially since it’s not really that long by modern standards (maybe 7-10 hours, depending on your playing ability). It’s nice to feel a sense of accomplishment from finishing a hard game, rather than one that is based on item collection or mediocre puzzles. Many games in the Zelda franchise are “going through the motions,” but it’s nice to see this early sequel adding something genuinely new and different to the series.

One thing I’ve learned about myself during its development is that I can get really bogged down working on more than one thing at a time. My personal programming time is so limited that having two active projects slows things down considerably. Plus, if a project takes too long, I lose motivation pretty quickly. When waking up early in the morning, one has to be excited about what one is doing (an aside: tips for waking up early).

For some reason the transparent pixels wouldn’t save when I uploaded to WordPress, so you get square heads.

Gannroids

CS4 has some interesting features.  One can enter media objects onto the stage and bind them to a keyword and ActionScript file.  Its seems cool at first and really easy, however it only seems useful if you have one or a few instances of a class.  For the most part I just bound the stage to my game.as file and let game.as handle everything.  I created classes for Asteroids and Bullets to learn how to do class work in ActionScript and I ran into a few problems but for the most part everything was seamless.  (As seamless as it can be writing anything in a new language).

To look at some specific problems I encountered, continue reading.

Here are the problems some encountered in no specific order:

1 – Getting graphics objects to be included in the .swf.  I never really came up with a solution, my image for asteroids is externally loaded.  I’m sure there is a way to embed graphics in the .swf and call it programatically, similar to how you can bind a symbol to a keyword I’m sure you can bind an image to a keyword to access in the code.

2 – Keeping track of things in the DisplayList.  I spent a large portion of my time here trying to figure out how to cast things into the type of objects I needed them to be and figure out the correct depths of the DisplayList.  In the end I ended up just going through every object in the display list and checking its object type if I needed to modify an object that I was using.  In other programming languages I wrote my own draw functions so I would just have a Vector containing all my objects that I had created and draw that Vector.  The DisplayList is a very similar implementation however it seemed I had less control.  I probably just don’t know the ins and outs of the DisplayList class and that will come with time I’m sure.

3 – Collision detection.  I had all sorts of problems with positioning.  The default x and y properties inherent in a DisplayObject were acting strangely so I ended up adding my own properties for x and y, which in turn caused problems with display and later with the collision calculation.  If I were to go back I would make sure to use the default x and y property better.

4 – Image centering.  One can set a registration point on a symbol in CS4 and it will set the axis of rotation (center preferably)  I could not figure out how to do this programaticlly with a property so I created a Sprite container and put an image loader object inside it and offset x and y by -imageWidth/2 (thanks Nathan)  This was another thing causing collision issues, I had multiple objects using different x/y’s and then images that were rotating were offset and I would forget what was using what.  It was close enough in the end and I was too tired to track down what was wrong with it.  Next version of anything I do I will pay more attention upfront to draw/x/y coordinates.

Overall the experience was good, I feel comfortable enough with ActionScript now and delved a little into CS4.

Obviously, getting from displaying a keyboard-controlled object to a more “game-like” state is pretty easy. Here I’ve loaded an external PNG (that represents a spaceship of some kind) and attached it to a “ship” class instance. The left/right arrow keys control the object’s internal “rotation” value, and pressing the up arrow key moves the ship. The direction is determined by trigonometry functions; the movement vector along the x-axis is cos(ship.rotation) and the y-axis movement vector is sin(ship.rotation). (For example, if our ship is pointing straight up (90°), cos(90)=0 and sin(90)=1, so it’ll move straight up.)