MORPH Gets Ported Over to an Another 8-Bit!

Greetings, dear readers!

It has been some time since I last posted here in my blog of mostly techy stuff. Some weeks ago, I got the strange idea to teach myself Z80 coding. Having played some games on the legendary ZX Spectrum, I thought it would be cool to create my own games for that platform. Although I didn't own a Speccy as a kid, there's something oddly cool about that 8-bit.

Like the 6502, the Z80 is an 8-bit CPU, just a bit more powerful in some ways. With this in mind, I assumed that the Z80 instruction set would be as easy to learn as the 6502 instruction set. And how right I was! After just a few days of practising, I was already coding something for the Speccy. That something would eventually evolve into a complete game:

MORPH.

But before talking about MORPH ZX, I'd like to say a few words about the Z80 CPU which the Speccy uses.

Z80

The Z80 is actually a very fun CPU to code for, despite what some people might tell you. Although the Z80 doesn't quite have an equivalent of the following opcodes,

LDA $01
LDA $01,X
LDA (ADDRESS,X)
STA (ADDRESS),Y
INC MEMORY_DIRECTLY
ASL MEMORY_DIRECTLY

there are some other powerful opcodes in the instructions set that make up for it. Such as:

LDIR

This two byte instruction would copy a block of memory from one location to another, in just 21 CPU cycles!

With the Z80 CPU, you can load 16-bit values easily with just one opcode, instead of two opcodes as it is on the 6502.

The Z80 has conditional jumps, conditional relative jumps, conditional jumps to subroutines and conditional returns, something I would love to have on the 6502.

The Z80 has 6 registers: AF, BC, DE, HL, IX, IY. The 6502 has only 3 of them: A, X and Y! The IX and IY registers of the Z80 are always 16-bit registers.

What's more, there's a copy of the AF, BC, DE and HL registers. You can easily exchange the two copies of the registers with the EXX opcode. To be exact, you have to use EXX and EX AF,AF' in order to swap all of the registers, including AF which is left intact by the EXX opcode.

When you have done 6502 coding previously, it is quite likely that you'll make some mistakes with the Z80 syntax now and then. I've lost count of how many times I've been about to type:

LDA #$05

when typing Z80 code, even though the Z80 equivalent of that opcode is:

LD A, $05

Another thing that might confuse 6502 coders is that there doesn't seem to be a "store" instruction on the Z80. For example, you would use the following instruction on the 6502 to store the A register to memory:

STA $8000

But on the Z80, we don't "store" values into memory... we "load" them into memory. So, the opcode for storing A into memory looks similar to the opcode for loading a value into A but it is subtly different. The Z80 equivalent of storing A to memory is:

LD ($8000),A

I also like the fact that you can add to the A register without carry if you want to, by using the ADD opcode. The Carry flag does not affect this opcode in any way. However, the good old ADC (Add with Carry) from the 6502 does also exist when needed, so you have them both at your disposal.

The Speccy

The Speccy was fairly easy in general to code for. The only thing that seemed initially quite difficult to handle was the bitmap of the Speccy.

The resolution of the Speccy is 256 x 192. This means that there are 32 x 24 = 768 colour cells on the bitmap.

Each 8x8 cell can have only 2 colours. If you ever wondered why Speccy games look the way they do, this is the explanation for that. That, and the fact that the Speccy has no hardware sprites.

Anyway, the bitmap memory of the Speccy is located at $4000 - 57FF.
The "colour RAM" of the Speccy is located at $5800 - 5AFF. I put "colour RAM" in quotes because it's called something else in the Speccy world. Namely, "attributes".

The way the Speccy bitmap works seems highly confusing at first. On the C64, the bitmap is pretty straight forward. For example, if our VIC2 bitmap is located at $4000 then the appearance of the top left 8x8 bitmap cell would be defined at $4000 - 4007. The next 8x8 cell would be defined at $4008 - 400F. And so on.

On the Speccy, however, the bitmap cells are defined in a different way. To give a shape to the top left 8x8 bitmap cell of the Speccy, you should load values into the following addresses:

$4000, $4100, $4200, $4300, $4400, $4500, $4600, $4700

Because, you know,

$
4000 - LINE 1
4100 - LINE 2
4200 - LINE 3
4300 - LINE 4
4400 - LINE 5
4500 - LINE 6
4600 - LINE 7
4700 - LINE 8

As you would discover from experimenting, the Speccy bitmap is kind of "divided in three":
The first third of the bitmap is at $4000 - 47FF.
The second third of the bitmap is at $4800 - 4FFF.
The third third of the bitmap is at $5000 - 57FF.

And there actually is a pretty good reason for this. Let's suppose that you have a bitmap address, such as $43EA. You would like to colour this area of the bitmap 07 (grey) for instance. How can you find where in the attribute memory the colour cell for this area of the bitmap is located?
Quite easily: you take the low byte of the known bitmap address, $EA. Then you inspect the high byte: The high byte is within $40 - 47, so we are on the first third of the Speccy bitmap, therefore the high byte of the attribute location is $58. So, the location of the colour cell is $58EA! Woohoo! :)

Porting the game

Now that I had learned all I needed, it was time to start actually porting MORPH into the Speccy.

I started out by taking the graphics from the C64 version and modifying them to suit the Speccy port.

First I would take the guy:

Then I would take the Morph ball:

And finally I would take the wall:

There! Now I would have all the needed gfx objects for the game. Well, nearly all of them. The next thing that I decided to do was create a 16 x 8 font for the game. It would be used in the scroll text on the title screen and in the text windows that appear between levels.

Creating the code for the game didn't take too long, something like a week or so. It was pretty easy to port something for which I already had the level data and graphics.

I made some slight changes to the gameplay on the Speccy version of the game. In the Speccy version, all of the 30 puzzles have a password so you can load whichever puzzle you want by pressing Enter on the title screen and giving the password of the puzzle.

Also, I removed the time limit from the Speccy version. I thought that it would be more enjoyable for the players to spend as much time as they want with the puzzles and take their time with solving them. Judging from the feedback that I got on the WOS forum, it was a good move. :)

Very shortly after registering onto the WOS forum and announcing my first Speccy game I already started receiving lots and lots of positive feedback. The people over there greatly liked my game, and they also asked me when my next Speccy game will be coming out. It's difficult to say at this point, but my answer is: Hopefully soon! :) MORPH was such a fun game to port and the Speccy was so fun to code for that I look forward to creating more games for it.

Some guys at WOS thought that I have shifted allegiance from the C64 to the Speccy. But unfortunately for them, I haven't changed sides at all. ;) Instead, from now on I will focus on the Speccy as well as the C64. However, I'd like to finish my upcoming Shiver Me Timbers game before returning to the world of Speccy coding.

All right. I'll now end my blog with screenshots of the game. If you'd like to actually try out the game on a Speccy emulator, you can download it from here: rapidshare.com/files/803069018/MORPH.SNA

See you later! TMS signing out!

The title screen

The info window which shows the level number and the number of lives

The second puzzle of MORPH

Adventure games and the design bit

Good evening, readers! I was asked to write more about my game in the Shiver Me Timbers dev blog, so here is an update for you.

Shiver Me Timbers has been in something of a stand still lately. Even though all the important code for the game is in place, it will still take a lot of time and effort to create all the rooms for the game. The room editor makes this slightly easier, but only slightly. I still have to go through many steps to create each room and make sure that they take up as little memory as possible. There are also some other things that must be manually tweaked for each room.

Also, Shiver Me Timbers is not the only project to which I've devoted my time. I've been coding some other things as well. One of them is a PC program which will take many months to complete, due to the number of features that it will have.
But that's another story. I might write more about it in an another blog. Today's subject is the room loader of my game.

Room data in adventure games

For Shiver Me Timbers, I was initially going to use 4 x 4 tiles. The nice thing with tiles is that each room has a fixed filesize, and a tile room takes up fairly little memory. Tiles themselves contain so many characters that only a few tiles (And therefore, only a few bytes) are needed to build a room.

However, I quite quickly realised that the tile system probably wouldn't be very useful for SMT. The graphics will have so much variety that with the tile method, I would surely need easily more than 256 tiles.

The next option that popped up to my mind, is compression. And that is exactly what I'm currently using in SMT. So, with this method the room is built onto the screen with groups of 3 bytes. The bytes mean the following:

1st: How many
2nd: Colour
3rd: Char

This means that every room has a different filesize. A really simple room with lots of repeating characters with one colour would take up very little space, while a more detailed room would naturally take up more space.

For example, if we had a room which consists of nothing but white char 1's, it would look like this in memory:

FF 01 01 FF 01 01 62 01 01

Each room is 32 x 19 chars =  608 chars. Or 0x260 chars... I always prefer hex! ;)

0xFF + 0xFF + 0x62 =  0x260


All right, I can't think of anything more to say, so I'll end today's blog here. Thanks for reading, and stay tuned for possible updates! Ciao!

And So the Main Code for the Game Is Finished!

Introduction

Hello there, readers! Today I shall talk about the exit blocks, which was the only element left to do for the game. I am pleased to say that my game is now pretty much finished, thanks to those blocks! :) Now I just need the rooms and the puzzles for the game, and I shall write more about that later in this blog.

Exit blocks - the way to take the player to the next room

I will make this a pretty short chapter, as there isn't that much to say.

Checking for the presence of an exit block isn't any more complicated than checking for the presence of an item. You do it the very same way.

When the game notices that you are on an exit block, some action is taken. Assuming that each exit block has 4 bytes associated to it (As I wrote earlier) and the 4th byte means 'What item is required to enter?', we would first check the 4th byte. Is it 0? Then we just jump to the teleportation code without any further checks.

But if the 4th byte is not 0, then some checks are in order. We must make sure that the value of either item 1 or item 2 matches the value that we got from the 4th byte. If they do, then we may proceed to the new room routine. Otherwise nothing happens.

Bytes 1-3 tell the room number for the new room routine, and the X and Y location, respectively.

That's it!

Right! Now all the important code is in place, and it's time for the design part: the rooms and the puzzles of the game. And this is where you come in! :)

You have the opportunity of shaping the game with your location and puzzle suggestions. If your suggestions make it to the final game, you will be credited in the game... Or at least in the tape inlay, if there's no memory left for text in the game.

Fame and fortune will await those who contribute... well, fame anyway. ;) You can send your suggestions to my e-mail which is  joonaslindberg@hotmail.com  , or you can post your suggestions on the Lemon64 forum. I visit that forum every day.

This is my final entry for the Shiver Me Timbers blog! I hope you had as much fun reading it as I had writing it. Remember to send your suggestions to me. Then you can tell your friends: "I was part of the development team!" :). I hope I will be flooded with e-mails... okay, maybe not, hehheh!

Thanks for reading, see you later!

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!