Ghost Town

A remake of the Commodore C16, C116, Plus/4 game in JavaScript. All opinions stated should clearly be yours, too.

[ghosttownhtml-blog]

Done.

[ghosttownhtml-blog]

A new TV for the game

I’ve created vector illustrations of computer monitors (you can download them at http://www.awsm.de ) that can be used as a nice retro frame for games and demos. But for Ghost Town, I thought it would make more sense to show it with a TV design.

The Commodore 16 wasn’t the popular kid to hang around with back in the days. While it was sold for cheap (here in Germany most parents bought them at ALDI), the C64 was already going full steam and was a much more capable machine in terms of gaming power (SID, VIC + Hardware Sprites).

As far as I remember, nobody who had a 264 machine actually owned a proper monitor (which could easily cost 2 to 3 times as much as the computer alone). Even fewer kids owned a floppy drive for the little Commodore. In the end, it was a low-cost, low-end beginners computer and therefore much more likely to be hooked up to a spare TV. My C16 was connected to a black & white TV, which was especially tragic as I was unable to show of the only advancement of the C16 over the C64, which was 121 colors.

So, long story short, I drew a vector illustration of a classic 80s TV. I don’t actually know the brand, it’s based on an untitled image I googled. You can see that some buttons have been “modded” to fit my needs, too.

Hope you like it.

[ghosttownhtml-blog]

23/23 - Mission accomplished.

The game is done! Feels almost surreal right now.

Let’s check the list again:

DONE: I still have no sound at all

DONE: The title screen and the intro screen need to be implemented

DONE: When the player dies, quit the game and go back to the title screen

DONE: Test if everything falls apart when playing multiple rounds

DONE: Include a better asset loader, mine is crap

The next steps remain unchanged:

Include all screens for the German version

Create a proper start menu to choose between the versions

Eventually do a “trainer” with a cracktro

Setup a nice little page where the game can be played, including additional information, trivia and so on

Offer additional features, like an inventory, turn scanlines on/off, music on/off

do a proper code review to reduce the embarrassment this project will cause me

Provide a hint system

So I’ve got some more work to do before I can publish this game free for everyone to play. Can’t wait to start on the next batch of tasks!

[ghosttownhtml-blog]

First successful playthrough

Yep. I made it.  The last gameplay screen has been implemented and for the first time I am able to play the complete game from first to last room - everything included. I wasn’t sure I would ever reach this state, therefore the satisfaction is through the roof.

The code number room was pretty difficult for me. I didn’t want to fake the view or shortcut anything and keep using the original data, not so easy. Moreover, I was stuck for way too long with my KeyboardController. It was the only piece of code I got from somewhere and I had no idea why it kept failing. In the end I had to rewrite a good portion of it, make it a proper class and it worked. On the upside, solving this issue is beneficial for the other screens left to include, so that’s something. On the downside, the code I wrote in the last two days is most likely the ugliest piece of shit ever written by anyone. I’m not exaggerating.

So, the current state:

It looks like I’m almost done, but there’s heaps of issues to take care of

I still have no sound at all

The title screen and the intro screen need to be implemented

When the player dies, quit the game and go back to the title screen

Test if everything falls apart when playing multiple rounds

Include a better asset loader, mine is crap

And then there’s the additional stuff that I’d like to do

Include all screens for the German version

Create a proper start menu to choose between the versions

Eventually do a “trainer” with a cracktro

Setup a nice little page where the game can be played, including additional information, trivia and so on

Offer additional features, like an inventory, turn scanlines on/off, music on/off

do a proper code review to reduce the embarrassment this project will cause me

Provide a hint system

And finally there’s the awesome stuff I’d like to do (but might never)

Offer a color corrected version of the game

Offer a version with different charset

Do some nice artworks to download

redo the music for the C64

convert the game to the C64 (could be easier than this project)

Change the Display class to render to Three.js (making this game 3D)

The list is almost discouragingly long. But for today, I’ve won another battle. And that’s pretty damn cool.

[ghosttownhtml-blog]

20/23

Last week I fought Belegro. I fought him hard, we both took away some scratches, but in the end, I won.

In the beginning I was a bit worried if I would be able to replicate his movements and behaviour, not knowing the actual code behind it. I decided to implement the basic movement first and take care of the adjustments later on.

So basically Belegro’s script is like this:

Is the distance between the player and me higher than 0?

Is nothing in the way to make the next step towards the player?

If yes, try to decrease the distance by moving either horizontal, vertical or diagonal

It took me a while to get this implemented, mostly because of my bad coding and lots of “if then” statements, but when it was finally in the game, I got a pleasant surprise: Belegro moved exactly like in the original game.

So, my take from this is that Udo Gertz came up with the exact same logic 30 years ago. How cool is that.

Next stop is the codenumber screen, the last missing piece for a gameplay complete milestone. I’ve started with it and making good progress, again mostly battling my own obstacles I put in my way. But the code screen already shows up and I can move the cursor left and right, even enter a character with space. That by the way required me to completely rewrite my keyboard controller code again, as now the spacebar is the new fire button.

[ghosttownhtml-blog]

19/23

Pfeww... Two more screens are in, and those where two of the supposed to be harder to implement ones. Boris the spider and the monster are now alive and deadly in their rooms. 

Animating both was pretty simple, I just need to replace values in the room array. Since the world updates regularily (hmmm... why does it do that? My god, this project is taking too long...), animations are smooth. I was a bit worried about getting the timing right, but that turned out to be very simple as all animations clock in as a multiple of 60 (fps). Both animations should be almost cycle exact with the original now.

What took me longer was to implement collision detection for both objects. Before, I check collision every time the player moves, but with the new objects moving themselves, they had to check for the player, too. 

It turned out to be pretty hacky and possibly the ugliest code I’ve written for the game so far. But it works. After all, I need something on my bucket list to fixfor the director’s cut...

Anyway, two more to go, excluding the title and intro screen (that are pretty basic - I haven’t done them yet just for convenience reasons).

I haven’t got a good idea how to do the code screen yet. And then there’s the Belegro screen. The sword is implemented and the rock is probably about the same difficulty as the monster and the spider. But the movement of Belegro will be the hardest.

On a side note, I implemented a new Keyboard Controller and now the movement ist a) independent of any OS setting and b) behaves just like the original finally.

[ghosttownhtml-blog]

17/23

Short update: the good news is that the laser fence animation worked out almost exactly like I hoped in terms of the animation itself, but was quite a bit more complicated in terms of collision detection. I’m not sure if I can apply my approach to the more complex animations of the spider, the skeleton and most of all, Belegro that little cunt.

I’m hoping for some progress over this weekend - I drank way too much the other day and had a huge hangover, so I’m not in the mood for going out for some time.

[ghosttownhtml-blog]

14/20

Two more screens are in, the one with the light bulb (easy) and the one with the nails on the ground (not so easy). I had to rethink the logic a bit to include this. All screens before had a layout where changes are permanent, but the nails keep coming back whenever the player reenters the room. The solution was easy: all rooms are stored as an additional copy that never gets changed. Whenever I need to reset a room, I just copy the original data back into the game. 

I’m hoping the changes are a solid base for the remaining screens, all of them being special:

Room 11: Animate Boris the spider. My approach would be to set an interval when I init the room and reset the room with each visit. It could be fairly easy and be done within 30 minutes if my plan works - if not, I would be stuck looking for other ideas. 

Room 12: The laser fence. If room 11 works, this one will be a matter of 1-2 minutes to implement. In fact, I would start with this one and then do room 11.

Room 17: The skeleton. Same as room 11 really, so again, no challenge if the original plan works.

Room 18: The code number. No idea yet how to implement that one. I’ve changed message data before, so it might be okay.

Room 19: Belegro. The hardest screen in the game will be the hardest screen to remake as well. Moving the boulder shouldn’t be complicated after I already completed room 11,12 and 17. I have no idea how the logic behind the movement of Belegro works though. I’m mostly concerned about the timing, which is essential here. If Belegro moves too fast, the game can not be completed. If Belegro moves too slow, it won’t be the same challenge. Most likely the last screen I will do for the game.

Room 20: The Treasure. Easy. I probably could do this one already, but I haven’t thought about how to implement the winning screen. Now that I think about it, that one might be the next room I finish.

[ghosttownhtml-blog]

12 out of 20 done

The screens colored green are those which are 100% done, meaning that all objects are in, the player can interact with them and messages or “you’re dead” screens are displayed. That’s 12 out of 20 game screens (or 60%), excluding title and end screens. Two more screens will be fairly easy to implement (the one with the light bulb and the treasure chest), but the others are more complex, which is why I avoided them so far. These require me to do some animation (laser, skeleton, boulder, spider, belegro) and hopefully do not turn out to be a complete nightmare to implement.

[ghosttownhtml-blog]

How BASIC saved me from Photoshop.

If you scroll a bit down this blog, you’ll see the character tileset/spritemap I created for the game. What I did was to display all characters by loading in a binary screen data file, make a screenshot, load it into Photoshop and then place every single character to the correct position by hand. 

Today I need to do this again as the game uses the regular Commodore charset for the text screens as well as the title and intro. I fiddled around a bit in PS again when I realized this can (and should, for christ’s sake!) be done better.

With this ugly little BASIC code, I was able to format the character almost perfectly for using them again later, therefore speeding up my time in Photoshop (thank god...).

5 scnclr 10 a = 0 11 b = 0 13 c = 0 20 poke 3072+a,b 40 a = a + 2 50 b = b + 1 60 c = c + 1 70 if c = 16 then a = a + 8 80 if c = 16 then c = 0 85 if b = 256 then goto 100 90 goto 20 100 goto 100

What it does is pretty simple: first it clears the screen, then it displays 16 characters per line till all 256 characters are displayed (and goes into a loop at the end to prevent the basic prompt messing the output).

The result:

[ghosttownhtml-blog]

I was lucky to get myself a copy of Ghost Town for the C16 from eBay. Just 10 Euro for a set of 12 classic games. However, I can’t seem to find a copy of the game that wasn’t released on a compilation. I’m still looking for a version with any of the game cover art (see below for screens).

If you’re by any chance a proud owner of a copy within your retro collection and want to make me happy, let me know! 

[ghosttownhtml-blog]

467kb

That’s how big the JavaScript conversion of Ghost Town is right now. 283kb of that is eaten up by Pixi.js. The whole original game for the C16, C116 & Plus/4 fit in less than 12kb.

[ghosttownhtml-blog]

Suddenly it all falls into place

After making some good progress the other day with walking around and going through doors, I was a bit anxious about how to integrate object manipulation to the game. I thought about having a config file, describing each object and the consequences when trying to pick it up, like gloves {position ..., replace by ..., items that need to be in inventory to pickup..., die sequence...} 

and so on. Then I thought about how to read in the configs and run them through each time an object it touched.

Today I thought “heck, why not start simple and have it all right where it is needed: in a simple script?” And due to the beauty of how the whole game is read in and displayed, the idea worked right out of the box.

This is the (still quick and dirty, but working) example code for picking up the gloves in room one:

Are we in Room 1? Is “a9″ (the hexcode for the gloves) where the player wants to go? take the glove delete the gloves from the game world That’s it. It can even be optimized (and needs to), especially when it comes to inventory handling. But anyway, it took me 10 minutes to define the first three rooms, which is nothing short of exciting for me.  Edit: quickly added proper inventory handling, so the glove example now comes down to this:

So much fun!

[ghosttownhtml-blog]

The Doors.

A great band. I listen to them a lot when I sit in the dark, crying about why I’m such a bad coder.

In other news, I got doors working. I cheated a bit in my previous animated post as it gave the impression that the player could actually walk through doors and switch rooms. I had to manually set the new room whenever I stood in front of a door. Well, not anymore.

What’s new:

When the player hits a door, he goes into the next room

Same for going into a previous room, with updated player position

I found a simple solution to check for objects, e.g. if the player wants to take the wirecutter

Next steps:

find a smart way to handle inventories for both player and the room

move stuff between inventories

update a room so that objects can be picked up

find a solution how to handle relationships between objects (”if wirecutter then open fence, if no wirecutter DIE!!!!”)

What excites me the most is that this progress is a good foundation for the mechanics to come and I added about 12 lines of code to achieve all this. I’m finally beginning to like coffeescript!

[ghosttownhtml-blog]

I found the (german) official walkthrough that was sold by Kingsoft for 2 DM back in the day. And it turns out that the white egg fruit from the first room are actually (drumroll....)..... GLOVES!

It all makes sense now.

[ghosttownhtml-blog]

First movements of the player in my JavaScript conversion of the Commodore C16 game “Ghost Town”.

[ghosttownhtml-blog]

I’m walking

Today was the first day in ages when I found some time (and, to be honest, motivation - as Fallout 4 is waiting right next to me) to make some progress with the game.

I restructured the code quite a bit, introducing a room class that hosts all data and events happening on one screen of the game. I now have a basic parsing structure working:

load in the unrefined binary data of a screen/room

create a copy to work with

parse unneeded content out of the copy

parse in the starting point of the player

parse the current state of the inventory (room) 

The idea is to repeat these steps whenever the player enters a room. It always starts fresh and manipulates the data to reflect the latest state just before rendering on screen. No idea if that really makes sense and given the amount of beer I drank during the last hour it doesn’t even make much sense while I write this.

Anyway, this is what the game currently looks like (no surprises here)

Some changes to the (temporary) UI happened on the way, too. 

So what does the “game” really do so far?

I can select a screen by clicking on one of the numbers

The screen with that number displays correctly

Some info about the room is displayed in the blue box

The player sprite starts at the correct position

The player can be moved with the cursor keys

The player’s movement is limited to the dark areas only

So essentially you can load in a room and walk around in it. That’s somethin’.

The todo list is scaringly long though

Enter and leave rooms through the doors

Adjust the player position to the correct door

Trigger events when touching items

Pickup items when possible

Use items

Die!

Show message screens

Animate objects

and so so so so soooo much more

Some stuff on the list can be beaten up with the same bat, but I wouldn’t be surprised if this requires me to rewrite 90% of what I have so far.

Anyway, progress made today, motivation in the project restored.

To be continued