Now We Have Some Items in the Game World

Introduction

Good evening, dear readers! I'm pleased to announce that Shiver Me Timbers has progressed a bit. I have now finished a rather essential part of the game engine - picking up items and showing the items that you're carrying on the status bar on the top of the screen. It shouldn't take long to get to the next phase - defining the exit blocks for the room. :)

Items and their effect on the game world

As I wrote in the previous part, items have an important role in an arcade adventure. Most puzzles involve you having the right item or items in order to progress further in the game. For example, if there's a dark room in the game, then a logical (And typical) solution for that is to have a torch in your inventory. If the room that is now lit turns out to be a shooting gallery (Example taken from Herbert's Dummy Run ;) ), then you should also have a slingshot with you (That example also from HDR :) ). That is an example of a puzzle where two items are needed.

John wanders about in an almost empty test room.

Above is a screen for which I've created three test items, just to test the item routines. What is that second inventory item, you ask? Hmmm.. don't know really, perhaps a miniature version of the MAD Productions logo? :)

Some items require you to have an another item in order to be picked up. In Pyjamarama, you need to have THE POUND COIN to get THE PENNY from the change machine.
Things could be arranged like this in the 0 page:
02 = Item 1 that you're carrying
03 = Item 2 that you're carrying
04 = Item in the current room
05 = Item required to pick up the item in this room

Our example items could be represented by the following values:

00 = NOTHING AT ALL
01 = THE POUND COIN
02 = THE PENNY
03 = THE DOOR HANDLE

Since item 01 is required to get item 02, address $05 would have the value $01. When our guy is about to pick up the item, addresses $02 and $03 will be checked - either one of them should contain 01, otherwise nothing will happen.

If we have an item such as 03 (THE DOOR HANDLE), we don't need anything to pick it up so $05 is 00 in that case.

What's up next?

As I mentioned earlier, the next phase in our game could be coding the exit blocks for the rooms. An exit block is a block that takes the protagonist to a different room when touched.

Demonstration of an exit block.

A typical location for an exit block is the handle of a door. Sometimes this door can be locked, so we might need an item named THE KEY in order to enter it.

But I shall discuss this topic in more detail in the next blog update. Until then! Thanks for reading!

The Techy Bits of an Adventure Game

Introduction

In today's blog, you'll get to read about sprite positioning in a 256 pixel wide screen, how the adventurer stores objects in two pockets and some other technical bits.

Sprites, keyboard reader and music

The IRQ is certainly a very handy feature in the 6502 processor. It is quite well known that the IRQ should be used to play music and sound FX, but the IRQ can be used for other things as well. So, you should make good use of it. Make it do things that have to be done constantly.

First, about the sprite thingy. Since I am using the Spectrum screen size in my game (256 x 192), I decided to use a nifty little technique in the IRQ that will make moving the sprites around the screen a lot easier.
Instead of using the built-in sprite X,Y addresses of the VIC2 directly, I created a little routine into the IRQ that places the sprites according to values in the zero page. For example, the X,Y location of the protagonist is defined in $10 - $11. The IRQ takes the value from $10 and uses it to define the X positions of the player sprites (The player consists of 4 sprites.). The IRQ will set the MSB's of the sprites when needed, so we don't need to do that at all outside the IRQ. This applies to the enemy sprites as well. :) The Y position for the player is taken from $11, respectively. Thanks to the IRQ, we only need to change two zero page addresses when moving the player around.
I saw this technique being used in an another game, and I thought it was pretty clever. In Shiver Me Timbers, it is certainly quite useful.

I am also making use of the IRQ to read the keyboard keys. The key that is being held down is stored in an address. I have to use my own key reader, because the Kernal is completely disabled to take full advantage of the 64 Kb and therefore the built-in key reader routines are unavailable. My routine is a bit more advanced anyway as it reports any of the 64 keys, including the CBM key and both Shift keys. If the user chooses keyboard control at the start menu, he can re-define the keys with the RE-DEFINE KEYS option, otherwise the default keys U, H, K are used for moving the guy around.

The IRQ is also used to play music & sound FX, of course. ;)

Items and a bit of realism

It has been a tradition in arcade-adventures to only allow the protagonist to carry two objects at a time. Makes sense. After all, you only have two hands in real life, too.

Typically the system works like this. You walk past an object. Object 2 is dropped and object 1 moves to object 2. Object 1 then holds the object that you picked up.

Some objects can only be exchanged with an another object, however. For example, in order to get THE PENNY in Pyjamarama, you need to have THE POUND COIN.

Wally decides to change his pound coin to a penny.

Then there are objects that might be in a certain "state" when you first pick them up, such as: a water bucket that is empty, a gun that is not loaded, a torch that is broken, and so on.

Wally filled his water bucket with water.

The items could be represented by byte values. For example, $00 for a book, $01 for a piece of paper, $02 for a crowbar, etc. The two items that you are carrying could be stored in two zero page locations, such as $02 and $03 for example. When you pick up an object, you move $02 to $03 and $02 changes to the value of the picked object, such as $00 if you picked up a book.

It might be necessary to execute some extra code in some rooms, for example to check if the player walked past a water pump while carrying a bucket, or some such.



Well, that's it for today. I hope you enjoyed reading this part of the blog. I still have lots to do for Shiver Me Timbers before all the code is in place, but I have progressed pretty nicely in a rather short time. :) As soon as everything except for the room data is ready, suggestions for puzzles and locations of the game are warmly welcome.

Thanks for reading, see you in the next part!

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!

A new Pyjamarama inspired game is coming up to your C64!

Greetings, my fellow C64 users!

As the title suggests, a new arcade-adventure game is in the works; a game which takes great inspiration from Mikro-Gen's classic Wally games.

The game will be called Shiver Me Timbers, and it is a sequel to my previous game, The Cursed Key.


As you might recall, our hero, John, found the mythical treasure from The House of Doom in his previous adventure. He had to go through a lot of trouble to find the dreaded Cursed Key, which was the only thing that would unlock the trapdoor to the attic. Now that the worst was behind, things were looking pretty good. "Now all I need to do," John thought to himself, "is to drag this treasure chest out of this building. Should be easy-peasy. I can't even imagine what could go wrong, now that I've made it this far!"
But John was clearly too confident. As he pushed the chest out of the front door, a super natural whirlpool appeared out of nowhere! The skies darkened, a storm was churning up, and he heard chilling laughter! The pirates had indeed cursed the treasure, there was no doubt about it! There was nothing he could do. He and the treasure chest got sucked in to the mighty whirlpool. A few minutes later, he found himself on a tropical island somewhere in the middle of the Caribbean (Yeah, I know it's a bit of a cliché but come on.. pirate stories are always set in the Caribbean! ;) ). The treasure chest was gone, but right now John didn't really care about that. He was more worried about other things. What happened? Where is he? How would he get back home from here?

Well that's it for the story for now. The story will eventually evolve along with the game, but the previous paragraph should give you an idea of what to expect. :)

Basically, you are in for a treat if you like Pyjamarama-esque adventure games. Like Pyjamarama, Everyone's a Wally, Herbert's Dummy Run and Three Weeks in Paradise, my game Shiver Me Timbers will contain lots of intriguing puzzles and memorable locations. In order to achieve "that Mikro-Genish look", the graphics of the game are in Spectrumesque hi-res bitmap mode (multicolour mode is strictly forbidden! Otherwise the game wouldn't look like it's from 1984! :) ) and the sounds will also be simplistic. I have some nice tunes planned for the game, though. My main focus is on the gameplay, I aim to make the game great fun, even better than The Cursed Key. I even have a rather innovative idea regarding the design of the game. I will make the development of the game "open" to others. That means that everybody, even those outside of the dev team, can suggest ideas for puzzles and locations of the game.

Anyway, I shall end the first part of my development blog here. My final words are: Stay tuned for updates! :) Bye for now!