R-Type for Timex Sinclair

Just finished reading It's Behind You: The Making of a Computer Game. The book was written by Bob Pape. Download a copy for yourself from his web site. Bob tells the story of how he coded a version of the game R-Type for the Timer Sinclair home computer back in the 1980s. I guess R-Type was an arcade game from the 1980s. Although there was a complex employment and contracting arrangement, the game was published by Activision.

This book covers all kind of good stuff. Some of the best parts have to do with the technical details of stuffing an arcade sized game into a small home computer with limited hardware. Other interesting parts involve the employment arrangement Bob had. He worked for some company who had a deal with Activision to write the game. Of course money dried up in the middle of development. Bob did complete the game, and apparently got paid in development hardware instead of cash.

The book also mentioned development of R-Type for other systems such as the Commodore 64. These other development efforts went on during the same time Rob was working on the Sinclair version. The funny thing about the whole situation was that, even though Rob went on to code other games, he exited the game development industry and went on to work in a different industry. You got to read the book to find out more.

I went onto Amazon to buy a print copy of this book. Seems like Bob never published his book in print form. Too bad because the version of the book I read was reading for printing. Might have to pay someone to print a copy out for me. I would love to pass a few copies on to my friends who want to get into commercial game development.

The Bug Algorithm

I found this super blog post by Matthew Klingensmith on how to implement motion planning. Be warned that his is a long and detailed post on the subject. I found the first few ideas very nice. Then things got a bit complicated. The best part was when he was explaining the theory behind "the bug algorithm". This is a technique for a computer controlled player to get from point A to B if there is an obstacle in the way.

I was happy when reading about the bug algorithm because I realized that I had implemented such a technique when coding up some Angband monster AI. Well let's just say that I implemented a poor man's version of the bug algorithm. I had found that when multiple monsters are trying to move toward the player, they get in each other's way. If I did not code in some smarts to their logic, they would crowd up in a long line. Fail.

But if the monsters could "walk around" obstacles in their way, they could get to the player better. It would look a lot better than the dumb monsters lining up. However I only got around to implementing the monsters going a few positions out of their way to try to avoid the obstacles. The bug algorithm theory let's an AI track the perimeter of an obstacle to get back on the optimal path towards the player. Great stuff I tell ya.

Dodger Becomes Chomper

Previously my Dodger game had the goal of avoiding the obstacles. Then I made the symbols mimic Pacman. Now it is time to change the rules of the game. Instead of avoiding obstacles, you are supposed to try to run into the obstacles. In other words, you need to chomp them like Pacman would.

I got rid of the ghosts from Pacman. You normally don't eat them unless you munch a power pellet. I am experimenting with what I should replace the ghosts with. Right now I have some balls that have their colors move around. The effect is nice, except it is monotonous because all the balls change their colors at the same rate.

Dodger Becomes Pacman

Today I made some changes to the symbol in my Dodger game. I made everything look like Pacman. Yeah. It might be a bit confusing because this is still a game where you dodge obstacles that fall down the screen. However this puts me ahead of the game when I get around to implementing Pacman.

Things are starting to get out of place in the code. I got one big class that draws everything and controls the movement. Really want to break things up into a few objects. I mean I should have a ghost object, a Pacman object, etc. It will make the cose a lot cleaner I think.

The goal here was just to get practice implementing the game of obstacle dodge. However I would like to come out with some objects I can reuse in future games. I don't think it will take much time to refactor into a couple classes. This is just a repackaging of the method names and where they reside.

Next I am supposed to work on a memory puzzle. You know, the one where you uncover two pieces and try to get them to match. But instead I might jump ahead and make a slider puzzle. That's the one where there are 15 tiles in a big square, with one empty tile. You can slide adjacent tiles into the empty spot. You try to get the 15 tiles in numerical order. Should be fun.

Herer Comes the Scores

All right now. I added rudimentary scoring to my Dodger game. You get one point for every time the obstacles move and you do not get hit. Yep. That means I implemented some collision detection. At first I thought I would have to check each of the corners of the obstacles to figure out if they bumped into the player. Later that seemed like a waste. I ended up figuring out the region where the upper left hand corner of the obstacle would need to be for there to be a hit.

Where do we go from here? Well if the player hits an obstacles, I just reset the score to zero. I would rather decrement the number of lives the player has. Game will be over when you get to zero lives. Then I will have to use some sexier graphics than just circles and squares. Maybe I could turn the symbology to Pacman and ghosts? Ha ha.