The Making of an Arcade Adventure

Hi there, and welcome to the second part of my development blog for the upcoming C64 game, Shiver Me Timbers! Today I shall write briefly about a bit of my personal history, how I got interested in this kind of games. And then, of course, I shall get to the fun part where I tell how these games are typically made. :)

My love for these games began when I played Mikro-Gen's Herbert's Dummy Run for the first time. That's right, I first played the fourth Wally game in the series. I played Pyjamarama a bit later. Anyway, I found HDR a really clever and addictive game with interesting rooms and puzzles. It's a bit of a pity that HDR is actually regarded by many as the weakest game of the Wally series. Sure, the arcadey sections of the game were a pretty strange idea, and quite cruel for players who lacked the skills for non-adventure games. But overall, I think HDR continued the nice Mikro-Gen tradition of nice graphics, not-too-obscure puzzles and gameplay that made you want to return to the game even after you had completed it. And I have completed HDR, in case you were wondering. ;) Truly an underrated gem.
Pyjamarama was also a great game, and it had a great story. Wally was stuck in his own nightmare, and in order to escape the dream world he had to find the clock key for his alarm clock. The game was great fun, with a surreal environment, funny humour and very well thought out puzzles. Completing it was a great pleasure.

There are many ways to start the development of a game. I always start out with the programming. In the case of a Pyjamarama-esque game, creating the game logic is not a difficult job. I mean, there are no tricky raster timings, worries about 50 Hz refresh rate, does my code consume as few CPU cycles as possible, etc. etc. Typically, you only have to worry about such performance critical things in shmups, platformers and other 'fast-paced' games. Creating the game logic IS a huge and sometimes tedious job however, and that's why I personally think it's a wise idea to start out with it. When you are done with the coding, the hardest part is then behind and you can congratulate yourself. Then you can spend more time on the visuals, sonics and other polishing.

You might also want to create some tools for yourself during the development, such as a text editor for the game, enemy data editor, room editor, etc. These programs are usually not included in the final game, but it is worth dedicating some time to create them because they will significantly speed up and facilitate the development of the game. Since the end user won't see those tools, there's no need to make them user-friendly or visually attractive.

Below is the screenshot of a test screen that I've been using during the game logic programming.

 

John walking and jumping around in a test screen.

I used the screen above to make it easier to finish the platformer routine. After one night of coding, John can now walk around the screen and jump onto the blocks. The block detection routine is finished. So, quite a major part of the engine has been completed! :)

Here's another editor which will be quite useful later on in the development:

The text editor that I made for myself.

Writing text messages for the game is much more pleasant with a WYSIWYG (What You See Is What You Get) tool. :)



All right, I think it's time to end part 2 here and get back to the coding. Be sure to check out the next part when it comes out, you will probably find it a very interesting read. See you later!