Planet X2 for the Commodore 64, The Making Of.

Planet X2 for the Commodore 64, The Making Of.

Hello, and welcome back to The 8-Bit Guy. There seems to be a bit of a revival lately
when it comes to developing home-brew video games for vintage systems. I kind of joined that bandwagon myself with
the design of Planet X2. Now, I’ve gotten a lot of questions about
how I developed the game and what it’s like to develop a game like that today in the modern
world. So, I thought I’d go ahead and make this
documentary about “The Making of Planet X2.” Now, I wanted to start with saying that I
definitely wanted to target the Commodore 64 for my first game, and I definitely wanted
to do something that was unique to the platform, something you know, for example there’s
only so many times you can play Galaga or Pac-Man or a clone of Galaga or Pac-Man no
matter how new it is. So, I definitely wanted to create something
that was different and something that had not been done before on this platform. Back in 2009, I created a game for the Commodore
VIC-20, known as Planet X1.  This was really just a new take on an old
game called Flash Attack.  It required a full 32K RAM expansion for
the VIC-20 but even then, fitting the game in 32K was a challenge.  I had made this game mostly as a challenge
to myself because I had never really programmed my own game on the VIC-20, despite it being
my first ever computer.  So, several years had gone by and I had
considered porting Planet X1 to the Commodore 64. Now, I knew the Commodore 64 had more memory
and better graphics, so I had kind of wondered what might be possible.   As I thought more and more about the game
play I realized that Planet X1 was almost, but not quite a real-time strategy game.  So, I began to wonder if I could add features
to the game that would make it more like StarCraft.  So, thinking about this for some time I
started asking the question of what features of StarCraft could and could not be done on
the Commodore 64.   I realized pretty early on that I would
need to omit mouse support and reduce the number of units that the player could control.  So, I had to rethink the whole user interface
to the game. Also, originally I wanted the game to be on
a cartridge. There’s a lot of benefits to having it on
a cartridge. First of all, there’s no loading time, and
heck, you don’t even need a disk drive. And that’s really great for these people
that are just buying a Commodore 64 from eBay for example, for the first time and they don’t
even have a disk drive or any way to get any information over there and I thought if the
game were on a cartridge then all they would need is the computer, they could stick the
cartridge in and all they’d need is a monitor or a television and they’d be ready to go. Unfortunately, the cartridge ended up not
being feasible from a financial standpoint at the price point that I wanted to be able
to sell the game. However, as a consolation, since I did have
to put the game on floppy disk, I figured at least I could make sure that the entire
game could load and run from RAM, that way there wouldn’t be any loading or saving
during gameplay. There’s nothing I hated more than playing
a game like Ultima on my C64 and every time I took 2 steps the computer was pausing to
load from disk, or stopping to tell me to insert another disk.  I absolutely did not want any of that.  The more I thought about the game, the more
I realized that the C64 was going to be a challenge.  Oddly enough, it wasn’t the 1 Mhz CPU,
the graphics, or sound that was going to be the limiting factor, but it would be RAM.  Most every design decision made would be
about RAM.  One of the first design decisions I had
to make was to choose a graphics mode.  The Commodore 64 offers essentially 5 different
ways to display information on the screen.  You have standard character mode, this is
essentially what you see when you first power on the Commodore 64.  Each character can only contain two colors,
a foreground color of your choosing and whatever the background color is for the entire screen.  This mode only consumes 1K of screen memory.  However, another option is to redefine the
characters on the screen, which can give you 256 custom characters, which you can use to
make graphics.  This takes an additional 2 Kilobytes of
RAM to store the custom character set.  And. you can also do multi-color characters
which are half resolution but allow 4 colors per characters.  Another option is Bit Mapped Graphics mode.  In this mode every pixel of the screen can
be controlled, but it requires 8K of screen RAM, and another 1K of color RAM.  Also there is a multi color mode which,
again, gives you more color at the expense of screen resolution, but otherwise requires
the same amount of RAM.   I didn’t believe I would be able to
spare the RAM for graphics mode.  Keep in mind that for the bit-mapped modes,
I would still need to store the actual graphics themselves somewhere in RAM, chewing up probably
another 4 to 8 kilobytes.   So I ended up settling on redefined character
mode.  Many C64 games actually did use this, including
games like Ultima III.  I finally decided on a screen layout, and
I actually decided to use something similar to Ultima.  So, I came up with this idea.  And I figured over here I’d use an 11
by 11 tile play area.  I decided that each tile would be constructed
of 4 characters.  Since I’m using text mode, I am essentially
dealing with monochrome graphics, but I can at least define one color for each character.  In order to help me design the tiles, I
wrote a special program called TileDraw on the Commodore 64, that way I could see exactly
what the graphics would look like, even when using a CRT display.   The program is really simple, it allows
me to plot monochrome pixels in a 16-by-16 grid.  With tile draw, you can select any of the
16 colors and assign them to one of the 4 quadrants of the tile.  So, with careful design considerations,
I was able to draw things like this tree.  As long as I kept in mind where the boundaries
were, I was able to make the top of the tree a different color from the bottom.  Same with this tank, or even with this explosion.  Doing it this way gives the illusion of
a lot more color than what is really available.  But it does take some thought because you
can’t just put any color anywhere you want.  With something like water, for example,
this tile needs to be able to line up with itself on the other side so that it can create
a contiguous area on the map.  Tiledraw doesn’t actually save anything.  However, it displays this hexadecimal information
on the side of the screen, which I use to plug directly into my source code in the graphics
section, which looks like this.  So these are all of the different tiles
and what they look like in the code. Once I had created some tiles, I needed a
way to create a map.  So I created a program called Mapdraw.  Again, very ingenious name for a program,
huh?  Anyway, this program essentially allows
me to select one of the characters I have created, and then plot those characters on
the map.  I added a few extra little features to help
speed things up, like a screen fill feature, and a copy paste feature.  I actually drew the first map in this program.  Now, once I had the layout and everything
more or less set in stone, I was able to start using PaintShop Pro to draw rough maps, by
deciding where I wanted water go to, where I wanted land to be.  And, I could even sprinkle trees and grass
in using the airbrush tool.  Then, all I needed to do was save the image
as a RAW binary file, which I could import into map draw.  Once in map draw I could add the fine details
of where I wanted everything to go. I designed all kinds of maps, including a
snowy winter wonderland I called “frozen” which features snowy pine tries, frozen rivers,
and little snowmen everywhere.  I also created a desert map with lots of
sand, cactuses, an occasional skeleton, and a few oasis here and there. I ended up using the graphics routines from
MapDraw in order to lay the foundation of the actual game itself.   And so Planet X2 was finally born.  What you are seeing here is one of the earliest
versions of the game once you could actually move things around.  And, If you’ve seen the final version
of the game, you may notice a lot of the graphics look very different.  As far along as this version of the game
looks, there isn’t actually anything you can do here besides drive around, and switch
from one unit to another.  But the basic interface was working.  So what I came up with was that this area
here would contain information about whatever unit or building you are controlling.  And this area here would tell you what options
that unit has, and how to control it.  And down here, much like Ultima, there is
a little message window for information.  The way I came up with to switch units was
a combination of methods.  If you can see the unit you want to switch
to, the easiest thing to do, is press return, which will pop up this browse feature.  Then just browse over to the unit you want
to control and press return.  Simple.  If the unit is off screen, you can press
the corresponding unit number right on your keyboard.  Below the main area, you’ll notice there
are these numbers and these represent your 10 units that you can control.  This little arrow represents which unit
is active right now, and the ones in gray don’t actually exist. Originally I tried having joystick control,
but I honestly found it to be useless being how much the keyboard is needed to control
other things, especially being that Commodore joysticks only have 1 button.  So, to save RAM I just ditched the joystick
control and made this game entirely keyboard operated.  I did give the user two methods to move,
though, they can use the Commodore cursor keys, which are sort of annoying for some
people, so I also added the WASD controls used by some other games.  So you can use either one.  I also wanted some music for the game.  Now, I had written my own song and performed
it in an episode of 8-Bit Keys, and I called it “Oh No, More square waves.”  And, when I wrote the song I had imagined
it as a background tune for something like Ultima. And so I thought it was only fitting to use
that tune in my game.  I didn’t have much RAM to spare for the
music routine, so I created my own very tiny music play routine.  I assigned each note of the piano keyboard
a number.  The easiest way for me to figure out what
numbers go into the source code was to place stickers on one of my actual keyboards, just
so I could bang out the notes, and then look at what numbers I just played.  Once I knew the numbers, I added them into
the data table in the source code like this.  And in the end it worked out pretty well.  Of course, you have to keep in mind that
the SID chip is capable of some really incredible music, but I couldn’t spare half of the
computer’s RAM just for the music, I needed all of the music and sound effects to fit
within 4K.  Still, I knew that would give me some room
for at least a few other tunes.  So, I asked Anders Jensen if he would compose
a few more tunes for the game, especially an intro tune.  OK, so David’s limitations made it clear
that I had to think like I did back in the old days of 8-Bit computing. Only 3 voices, limited to a fixed tempo, 3
types of sounds, and of course a limit on how long the songs could be. I didn’t have a proper C64 at the time David
asked me. So, I turned to my trusty Mac with digital
performer for mootwo. I needed some sort of rudimentary sound source
that could output pure sawtooth and square waves. So, I went for a free plugin called PG-8X,
which emulates the old Roland JX series. It’s usually easiest to start with a bass
line based on a chord progression. So, this became the foundation. Then, I needed some chords, but I couldn’t
tie up both of the remaining channels this way. So, it became a little complimentary melody
instead. Lastly, I could then have a little lead part
to put on top of the whole thing. Normally, I would have gone all in with lots
of bends and trills and other fancy things, but there wasn’t any room for it this time. That’s also why I went further playing with
the idea of a potential MS-DOS port of the game and made some elaborations on the theme
using the Roland MT-32. For the dedicated gamer, these sounds may
sound familiar and that’s no coincidence. You see, I did use the same sounds they used
in the game DUNE II, because I felt David’s game had many of the same qualities. Also, since the game would be severely reduced
in terms of music and sound, I thought the player could listen to the songs on a good
old music cassette while playing. Therefor, I pitched the idea to David to add
the cassette in the box to add a little extra flavor. The game wasn’t anything that I thought
it was, which turned out to be really cool, because as I had realized the game was an
RTS game, then I thought, wow, you know, how does this game even fit into the memory of
the C64. That’s a pretty impressive feat, and you
know, almost on queue, the first page of the manual talks about how the technical hurdles
were overcome. The Commodore 64 has 64K, and that was a big
selling point of the computer in 1982.  However, one thing that isn’t really obvious
is that not all pf the 64K is as easy to use.  You see, the 6502 processor can only actually
use 64K of address space total.  And, while you might think it would be simple
like just having 64K of RAM, people often forget that ROM and IO space also count as
part of this 64K.  So how is this handled on the C64? Well, it’s done by banking.  That means some parts of the memory can
be changed on the fly to be either ROM, RAM, or IO Space.  For example, this part of RAM can also be
used for a cartridge ROM.  And this part here, by default is the BASIC
ROM.  However, it can also be a cartridge ROM
too.  This littke 4K area is used for IO space
to communicate with things like the sound chip, disk drives, etc.  But it’s also used to hold the character
ROMs.  And this last 8K chunk is where the Kernal
ROM goes.   In fact, when you first power up a C64,
the memory banks look like this.  Many people have asked why, when you look
at the startup screen of the C64, that it says it is a 64K RAM system, yet only has
just under 40 kilobytes free.  Well, when you look at this memory map,
you can see that BASIC is allowed to use this section of RAM here only, and then it all
makes sense.  So, let’s take a look at how I ended up
using the memory banks for Planet X2.  This first 16K bank is where the main code
goes.  Then the next two banks are used to store
the world map.  As you can see, the map takes a sizable
chunk of the C64’s RAM.  Now, because my game is written in assembly
language, I do not need the BASIC ROM, so I turned that off, so that it becomes RAM
again.  I use this area to store the unit variables
and the different screen graphics.  The music and sound effects are all crammed
into this 4K section here.   Now, what’s really interesting is this
last section. You see, I need the KERNAL ROM to be there
because I use many of the features such as reading the keyboard, and accessing the disk
drive.  So originally, I wasn’t using that area
at all, at least not until my friend and beta tester Lorin Millsap gave me some good advice. I had become quite involved in the development
of Planet X2 from fairly early on, mostly just testing code, doing beta-testing and
stuff. And then, one day I asked David how Planet-X2
was coming along. And he said to me, “oh, not very good, that
I’ve basically run into a problem where I’m running out of memory.” And so, I took a look a the memory map that
he was using and I said, well, why don’t you move all your graphics data up into the
Kernal area? So it turns out that the memory management
system in the C64 is pretty smart so if you attempt to write to an area that has ROM,
then the write automatically goes to the RAM.  After all, there’s no point in trying
to write to a ROM.  So, I can freely write to this area under
the KERNAL all I want. So, I configured the video chip to use this
area as screen RAM and character data.  And the video chip is smart enough to look
only at RAM and ignore ROM, so that made this area idea for that because, I never really
need to read from that area.  This 4K area here is currently unused by
my code, since I need to be able to communicate with the rest of the chips in the computer. As I got closer to finishing the game, I continued
to run out of space.  As a result, a lot of the features I had
planned to do got cut, and in many cases even features I had already implemented had to
be cut. For example, I had a building called the research
lab, where you could research weapons and things like that.  However, I ended up removing this in the
final game for several reasons.  Not only did it free up some code space,
but also freed up some tiles.  You see, with the C64 having 256 characters
total, I reserved 64 characters for things like numbers and letters, which are kind of
necessary.  So that left me with 192 characters to make
tiles out of, and since I use 4 characters per tile, that means I get 48 tiles total.  That’s for everything from landscape stuff
like grass and trees, to actual units.  Plus the larger objects like factories and
alien pyramids, they actually use 16 characters each.  In fact, this is one of the reasons the
units don’t turn to face the direction they are moving.  Originally I wanted to be able to do that,
but that would mean allocating extra tiles for every unit, and there just weren’t enough
to go around. Another thing that got removed was, I had
some code that made the map more, you know, alive. Kind of like in Sim City, where for example
if you blew something up, it would catch the trees on fire and that fire would spread from
one tree to the next until the whole forest burned down. And then, eventually like if you burned an
area, whether it would be with a fire, or with your weapons, the grass would eventually
regrow to form back over that area. In the end, those routines took up about 6K
of RAM and they didn’t really add anything to the gameplay. I mean, whether they were there or not really
didn’t affect how the game was played, lost, or won, so I just decided to remove those
to make space for more important features. I had also originally planned to have a lot
of other buildings. For example, one building was going to be
something you would build next to a mineral deposit that way you could mine your resources
and put them there rather than have to take them all the way back to a factory, for example. However, I didn’t have enough RAM for that,
so I cut that out and I consolidated that feature into the factory. I also wanted to have all other kinds of flying
units and boats and just different buildings and special weapons and stuff you could build,
but ultimately there just wasn’t enough room them, so they just didn’t make it into
the game. The A.I. for the aliens was kind of challenging.   Every unit in the game gets exactly 14
bytes of RAM just to itself. And so, these are things like the coordinates,
what type of unit it is, it’s current health, destination, etc.  So, there isn’t enough RAM to store a
long pre-plotted path for a unit to follow.  So, the aliens move with insect-like intelligence.  They can avoid small objects by taking a
detour to the left or right.  If they get stuck too long, they will go
into a random movement mode for 10 cycles and then try again to keep going to their
original destination.  This works pretty well for navigating around
forests and rocks and stuff like that.  But there was no way to navigate a complicated
path around a large river or something like that.  So, one thing I did was add the ability
for the aliens to swim across water at a reduced speed.  Nevertheless, I had to carefully design
the maps to make sure there was always a functional path between the alien bases and your default
base location.  Otherwise, the aliens could get trapped
in oddly shaped obstacles and never get out.  So, a lot of people asked why I didn’t
use random base locations, well that’s the reason. I had also originally wanted some sort of
mini-map, like you might see in games like StarCraft.  I knew there wasn’t enough screen real
estate for me to be able to put a mini-map on screen with the rest of the game, but I
was thinking, you know maybe I could push some kind of key on the keyboard that would
alternate the screen over to, you know, like a full-screen map where you could kind of
see where you were and where other features like rivers and stuff were on the map. But, even though I knew I couldn’t use bit-mapped
mode, I thought maybe I could just use some crude character graphics, you know, just enough
to give you an idea where things were. Testing the game was a huge chunk of the development
time.  Early on in the game I could make a change,
compile the code, and immediately see the result when I started the game.  But, as the game became more advanced, this
became more and more time consuming.  So, for example, if I changed the behavior
of the enemy AI, I would have to play the game for 10 or 15 minutes in order to see
if the alien behaved the way I wanted him to.  And if he didn’t, then I had to go make
another change to the code, and start the game all over again. I did have a few beta testers, but I don’t
think anyone spent as much time helping out as Lorin Millsap. I did a considerable amount of beta-testing
on Planet X2. Early on it was about finding bugs and we
did find a few and we were able to fix those, and then later it became more about fine-tuning
the actual game play. The goal was to create a game that was fun
and addicting. It had to be challenging enough to engage
a player’s interest but not so difficult that it becomes frustrating to play. In the end, I think we achieved that goal
and created a game that I certainly enjoyed playing and I hope that other people do too. I ended up playing about 10 hours or so of
the game and I found a lot of bugs along the way during the beta testing and I reported
many of those to David and what I found out was that he was very well aware of the issues
I’d found. Most of them were already fixed by the time
I’d sent my email to him. When I finished the game, I literally had
12 bytes left of RAM.  However, I managed to get just enough features
working that the game had some good dynamics to it.  So I was quite pleased with it. As I begun to get closer to finishing the
game, I realized that I needed to hurry up and start getting some materials ordered like
the box, the manuals, disk labels, and of course all of that stuff had to be designed
before hand because these things can take weeks or months to arrive. So, I wanted them all here by the time the
game was done. And, of course, for the box art, I had no
idea who to even ask for that.  Around that time, I got a donation from
Neil Rieske and he had included this interesting hand drawn artwork.  So I sent him an email and asked if he’d
be interested in designing the box art for me.  I offered to pay him $100, which isn’t
a lot, but I hoped it was enough.  I sent him some screenshots of the game
and told him I’d like to see the pyramid and a tank in front of it.  And, the next day he sent me this mockup
drawing.  I told him it was exactly what I was looking
for, except that the sentry pods aren’t supposed to be flying.  However, I really liked the way that looked,
so I thought about it for a bit and I said, you know, being that we see the sentry pods
from top down, it is certainly possible that they are raised up on a pole.  So he modified the drawing a bit and added
some poles to it.  I thought that looked good, so we discussed
a few small changes, and pretty soon he had sent me this as a work in progress.  That evolved into this, and all that was
left was to do was add some stars and shadows, and this became the final artwork for the
game.  Of course, having some artwork was great,
but that’s not a whole box design.  Fortunately, Anders Jensen took on the task
of designing the box.  He happened to be over at my house one day
and we were discussing what the box should look like, and I picked up this old Origin
box for the game Space Rogue.  I am not a fan of the game that much, but
I really liked the box design, which accommodates a manual and 5 and a quarter inch floppy disk
really well.  So, he measured the box and started to design
artwork for it. After David showed me the Space Rogue box,
I started throwing some ideas together. For projects like this, I use Adobe indesigns,
since we were going to print everything professionally in the end. Firstly, I had to make sure that all of the
surfaces of the box are placed correctly. So these brightly colored areas indicate where
the design would wrap around the side of the box. I figured since this game is located on an
alien planet, some sort of dark blue theme with stars and possibly a planet in the background
would set the mood. To compliment that, I chose to use an amber
or yellowish tone to create some contrast. I had already spent some time designing the
logo in different variations. David liked the blue and yellow colors and
had implemented this design into his opening screen already. So the bar was set at this point. The rear side needed some attention too. Using David’s early screenshots, I started
laying them out to get a feel and allocate some areas for the text. So, honestly, I am thrilled with the outcome
of the box. I don’t think anyone could have done a better
job had I asked them, so I’m really thrilled with that. Now, as for the manual, I had written the
vast majority of the text, for the manual, but as far as laying it out in a way that
is comforting and organized to flip through and read it, I knew I was going to need some
help with that too. Fortunately, Anders Jensen offered to do the
manual as well. And I was totally thrilled with that, because
that was another load off my back. I found that this was perhaps the one thing
that needed the most attention. It had to be informative and pleasing, but
not too extensive and tedious. So looking at other manuals and from prior
experience, I laid down a structure that felt natural, with some introduction to the game,
a guide on how to install, run, and operate the game, before going into detail about the
various game components. And at the end, the maps for reference. So, in the end, I think we ended up with a
pretty nice product after all. Just like the box, I was totally thrilled
with the outcome of the manual. I couldn’t have asked for a better manual
for my game.  Speaking of the manual, I decided to go
ahead and include the maps on the back of the manual, since there was no way to include
any sort of on-screen mini map.  I thought that was a good compromise.  However, I did add a spoiler alert here
that some people might prefer to explore the maps on their own without using these.  However, we also came up with the idea of
leaving the last map out of the manual. So “Urban Ruins,” which is one of my favorite
maps, where you get to play in the ruins of a destroyed city,  is not actually shown
in the manual.  You’ll have to explore it on your own.  Of course, the real test of these materials
is to see how they stand up to the scrutiny of Lazy Game Reviews, so I sent him a copy
and let’s see what he had to say about them. Even before diving into the gameplay, Planet
X2 impresses by way of packaging alone. I really appreciate the tidy, clean box design
here. It has a sturdy build and a matte finish that
feels soft to the touch. And, as far as the size, it’s spot on for
the time period that’s being imitated, fitting right in along side eighties C64 and 128 boxes
from the likes of SSI, Microprose, and especially those from Origin systems. In fact, everything from the dimensions to
the system requirements in the corner to the layout on the back closely and delightfully
sticks to the Origin formula. And, of course, I am completely behind the
inclusion of extra goodies like the soundtrack on cassette tape and the full color manual. The documentation in particular here is wonderfully
put together, even better than many I have from the eighties which were often in black
and white and did not dive into extra stuff like how the game was developed. So yeah, as far as I’m concerned, huge thumbs
up for the physical goodies from Planet X2. I designed the disk labels myself and I sent
them off to a professional label company.  The labels came back on rolls of 100.  These aren’t paper labels either, these
are made of plastic.  See, you can’t even rip these things if
you try.  So these should hold up for a long time.  Of course, a lot of people ask where I got
the floppy disks.  While, it is true that I don’t think anyone
is making brand new floppy disks, there are still tons of old stock you can buy.  I actually bought hundreds of these KAO
disks from ebay.  They come in boxes of 100 and the inside
there are individual boxes of 10.  These are interesting because all of the
boxes say “for government and educational institutions only, not for resale.” So, I’m not sure what the story is on these.  But the nice thing about them is they come
with plain white sleeves.  As opposed to that, you can still find boxes
of like these Kodak brand disks, but the sleeves are not really suitable for use as a commercial
game.  The other great thing about these KAO disks
is that the brand labels come off very easily, leaving no residue. In order to get the game over to a real floppy
disk, I use my SD-2-IEC connected to my Commodore 128.  I simply copied all of the files over to
a real floppy disk.  However, this method is very slow and takes
almost 7 minutes to copy a disk. So, for actual duplication, I use an old program
called Fast Hack’em.  One of the neat things about this program
is that the code is uploaded to the memory inside the floppy drives and the code is executed
there.  So, I can actually unplug my 128 from the
drives and shut it off, and the drives will keep copying.  When a copy is done, I can simply insert
the next disk and the copy will start up again, taking approximately 60 seconds for a full
copy with verification.  Of course, I still like to test every 5th
disk or so, so I keep this Commodore 64 setup nearby for testing.  So far, I have yet to find a single disk
that failed the copy, or failed to load on the Commodore 64.  After copying is done, I apply the label,
like so.  I’m very meticulous about getting it on
straight.  And once that’s done I seal the disks
in these clear plastic bags.  The boxes came packaged several boxes like
this, individually wrapped with plastic bags.  So all I needed to do was take the boxes
apart, insert the manual, insert the completed floppy, insert the soundtrack cassette, and
it’s done. Of course, some customers want an autographed
copy, so I have to sign some of them.  Then, they get boxed up like this, and shipped
off.   So, I was surprised how strong the demand
was at first. You know, I had chatted with some other home-brew
game developers and I had been told to expect sales you know somewhere between 300 and 800
copies. So, you know, as a compromise, I ordered enough
materials to produce 500 copies.  200 of those went to Anders Jensen in Europe
for him to distribute over there.  I was surprised how strong sales were. The first day I opened sales I sold over 80
copies. I had several crates to take to the post office
the next morning.  I’ve already started getting some feedback
on the game. There were a couple of comments I read on
the review where someone said, you know, if this game was released in 1987, David would
be a millionaire. And you know, that could well be the case. I mean, I think about if someone like Zap64
or Commodore Format in the UK reviewed this game back then, they would have given it a
pretty high score, in a probably around the 92 to 97 percent. It would got the Zap Sizzler or the Gold Medal
or something like that. And, it would have been very, very popular. I totally agree with that statement. So, where do we go from here?  Well, to be honest I’m a little disappointed
that I wasn’t able to include all of the features that I wanted to include in the game. Nevertheless, the game was really well received. So, it makes me really want to create a sequel. Now, to be honest, let’s take a look at
that memory map again. I’ve thought about this quite a lot and
I think if I wanted to spend a few months re-writing bits of the code, I could probably
make use of this 4K area here, and I could probably tidy up some other code and maybe
get an extra 5 or 6K to work with, allowing me to add some more features for a sequel. I could also do a port to the Commodore Plus/4. It really wouldn’t be that difficult. It would probably take me maybe 5 or 6 weeks
to do a full port to this platform, cause it does have 64K as well and the video capabilities
are perfectly adequate for Planet X2. However, I thought if I’m going to do a
sequel, I really ought to focus my attention on a computer that just has more memory to
begin with. One prime example might be the Commodore 128. This machine here would obviously be perfectly
capable of running all of the features that I originally wanted in there. As well as, you know, something like the Apple
IIgs, would also be definitely a good platform for a game like that. But I did a poll online shortly after the
release of the game, and as you can see, MS-DOS was the most requested port.  One great thing about MS-DOS is that I’d
have 640K to work with, which is 10 times the amount I had on the C64.  So, I started playing around with a paint
program to see what the game might look like.  So this is a screenshot from the Commodore
64 version.  So, I just changed the colors around a bit
to see what 4-color CGA graphics would look like, and I came up with this.  Obviously this isn’t a real game, but
it does conform to the CGA color palette.  So, then of course I realized that the C64
version was designed in text mode, and so much of the user interface is derived from
that.  So, being that CGA is in graphics mode,
I realized I had more flexibility with where I could put things, so I came up with this
instead.  And then, of course, I wanted to take this
further and see what it might look like in 16 color EGA graphics.  So this is what I came up with.  It actually looks pretty cool. But ultimately, I think if I go the MS-DOS
route, I would probably need to hire a pixel artist to come up with some better graphics
for me, because I’m not that great at this sort of thing.  And even though I had originally planned
to do the kickstarter for the C64 version, but ended up not doing it, I think if I do
the PC version, I probably will do a kickstarter because I need to have a good idea of how
much demand there really would be in that market, because if it’s as much as I think
there would be, then I would like to outsource you know, like some of the pixel art, and
some of the music routines and stuff like that to some people that are better suited
for that, which I think would end up with a superior product, but I would need the funds
up front to be able to pay those people to do that. So, yeah, I think an MS-DOS port to something
like this old Tandy 1000 would be a great port to make. And of course obviously if it runs on the
older machines, then it would run on newer machines like 386s and 486s and Pentiums as
well so that wouldn’t be a real issue. Well, I hope I didn’t discourage anybody
from wanting to create their own home-brew game. It is a lot of work, but it’s very rewarding. So, I hope I’ve actually incentivized maybe
some people to create their own home brew games. Other than that, that about wraps it up for
this episode. I hope you guys enjoyed and I definitely have
a lot more interesting content coming up, so stick around for that, and thanks for watching!


  1. Soooo, can't you just do graphics mode by writing to the kernal address? And put the 1k for the color data somewhere else?

    The Vatican with it's newly created Jesuits (Faith in Theory Science) publish Heliocentricism, where a stationary, unmovable Earth, as stated in their Bible scriptures was replaced by a spinning, orbiting, "Heavenly Sphere"; this Theory would be promoted by the major Universities (all Faith Based). Vatican Jesuits invent the following:

    1543 – Jesuits invent Theory Heliocentricism
    1582 – Heliocentric calendar (Pope Gregorian calendar)
    1651 – Theory Mapping Moon (Selenography)
    1763 – Theory Atomic Energy
    1809 – Theory Transmutation of Species
    1923 – Theory Missing Link (bones lost, molds prove find
    1931 – Theory Big Bang (another ejaculation into the virgin source)

    From birth, you are indoctrinated to worship the man-made constructs of Heaven and Space. Our history and science has been little more then a fictional story over the last 2000 years. It began, with obedience from the indoctrinated masses these illiterates who paid tithing for Faith based religion and war. Today, the indoctrinated masses are educated idiots who pay tax on their labor for Theory based science and war. This is the reality propagated across the face of the Earth.

  3. David, this is an excellent video. Will definitely be purchasing a copy of Planet X2 for the C64. Hope to see a DOS version in the future. Keep the content coming!

  4. cool now planet x2 is done using the ultima engine canyou pleeeze 8 bit guy use the magic carpet engine and make a stroker 2 on c64?

  5. Manfred Trenz did the same method for Turrican, Katakis/Denaris, R-Type and more, but in a more advanced method. He programmed an own graphics tool which allowed to create graphic objects (modules as he called it) from HiRes or Multicolor characters in any size. These modules could be XY positioned, copied, mirrored and whatever in the screen. Because these modules weren't aligned perfectly, he added some 'filling characters'. These characters are looking like garbage, but they are blending the modules together so that they appear as a full graphic. The sprite editor he used for his games allowed to handle 768 sprites 😉

  6. Is there not maybe scope for a routine that could do a transform on the character data when turning a unit to face different directions, and thereby only have to store the data for one direction? Or is the 64 too slow to do that on demand each time a unit is moved?

  7. Could you have done X & Y location on screen and grid the pictures in the book so you could find your location?

  8. Theoretically, you could let only the related map-specific data to be copied into RAM at the loading of the map. Changing of map would swap the data in the memory. So, if the whole map data is loaded at the run time, this would leave some RAM space for dropped features. Maybe, if it isn't done yet.
    PS: I haven't ever had a C64, but it was my dream a a child to own one.

  9. It’s fascinating that you had difficulty with the ram. I never realized until now but many modern cpus have more cache than a c64 meaning your whole game could in the cache of a cpu

  10. Silly question: is there a way of making a modular C64 cart where you could use SD cards and swap them easily?

  11. When I was 15 I created a game using MS paint. War game draw all the tanks and maps. I later created a space game and draw hundreds of different space ships. I never made it into a working game but your game is inspiration for me one day bringing my game to life.

  12. It's a perfect making of video. I'm not interested in make games to c64 but I'm learning unity and it's a perfect video to learn how to approach problems, how to separe them into parts and solve step by step. Thanks for your all good videos and technical explanations in all of them. By the way if you can make development documentaries about titles popular those days that would be great (I don't know if you can achieve that much data about them just that would be good)

  13. You know what?! I don't have a C64, but I wanna buy your game, just for the sake of it! Your process and product are awsome!

  14. Anyone know where I can get a Boxed version in the UK?
    The link in description only offers the Lite version 🙁

  15. maann, if there was 128k of ram this game would be impressive with stuff like sim city like features and rotating sprites character sets

  16. I always find these types of videos entertaining. Thanks.
    Old video so I don't even know if you'll see this message, but now that you've covered vic-20, c-64 and ibm pcs, any chance of the Amiga getting any love? Seems to have been a pretty popular suggestion judging by your poll there and as someone who pretty heavily follows the scene I can all but guarantee you'll sell enough to at very least recoup your development costs.
    From a personal perspective I'd love to see a "making of" video for an Amiga game too 🙂

  17. Wow, really inspirational! I wonder how much more could have been squeezed in with an early decision to use 1×1 characters per tile rather than 2×2. That would have provided a more expansive view, and potentially 4 times as many tile types. Of course, with 8×8 graphics it's harder to make different unit types distinctive…

  18. Bought both X2 and X3 and some other items not long ago. One package from David and one from Anders. Both packages are now stuck in customs waiting for further paperwork and payment. To top it off Anders offers only worldwide shipping even if it would only have cost a fraction of that to send it to me.

    I can't help but feel scammed. I hope one day I can learn to love the products, but I'm not betting on it.

  19. I totally feel him on the beta testing. I'm working on separate versions of Hammurabi II for the Commodore 64 and the PC. (If you are not familiar with the original Hamurabi, it's a resource management game originally written for the PDP-8 mainframe in the 70s. Mine is a completely new take based on David Ahl's version). On the Commodore it takes about a minute and a half to generate the map, and then another minute and a half to draw the map, so every time I make a change to the code, I have to sit with my jaw hanging for about three minutes before I find out whether it worked or not. Urrgh, it's hell.

    Totally worth it tho 😀

  20. here a image 320×200 for the c64, if you need for a game feel free to use it! Cheers!

  21. So, what have we learned from this: You need to branch out and make the game available on more platforms and more modern platforms as well. Making it for a practically dead computer isn't a good thing. The bigger your audience, the more money you will make. By making it available for the C64, you're sort of limiting yourself and your audience. I would have used the 8-bit version to raise money to hire a team of people to make Planet-X a game that would be available on all modern platforms. The concept was used by Sam Raimi, Bruce Campbell and Rob Tapert when they made the original Evil Dead back in the early 80's.

  22. Hello, 8-Bits Guy! 🙂 I am a software engineer myself, and I am very interested in your coding set up. How did you actually write the code? How does one compile assembly for the C64? What kind of tools did you use to debug? That sort of thing!

    GREAT WORK ! Looks fantastic !

  23. The discussion of memory limitations reminds me of a similar discussion in the video on the creation and design of Micro Mages (

  24. Which language did you use to write the game? and do you have an introduction video that explains about game development for the commodore or other 80'th computers?

  25. Man… Paint shop pro!

    Very interesting video, and I like the fact that even if in these days we have such powerful computers, that simple graphics plus the characteristic music are still loved. I don't define myself as a gamer, but I definitely had more fun on a Gameboy than on a ps4.. Maybe was the age… Nah! Those games were just stimulating your fantasy more.

  26. "…this game was released in 1987, David would be a millionaire…" this is a high rating !!! If I were making a game, probably only this statement justified 50% of all the work =)))

  27. Why not have a Cartridge Emulator? Basically, it plugs into the cartridge slot, but it is not really a ROM Cartridge. Instead, it is simply a USB device with can be hooked up to a modern Mac or PC. You can store some large amounts of Standard or 44K software on it and give each a name. You simply pick the software you want and plug in the cartridge.

  28. I want one. and so many others. Why don't would you make a second batch (and c64 version. Not boring DOS port)? I'am a developer too and I appreciate what you do!

  29. I Use the PG8X VST plugin all the time sounds as close as your gonna get to a JX10 perfect for the era great choice guys.

  30. This is awesome. This is why I want a C64 or even just a 6502 with a programmer, a couple breadb oards, and some ram and rom chips. I want to know if anyone knows how to hook up a tms9900 that I took off some weird TI board. Im looking to do something like run basic programs. (I could probably find some video chips and stuff IDK?)

  31. Cant you just make the tiles themselves more generic? e.g. the alien pyramid could be more symmmetrical or something.

  32. 64 KB of RAM is incredibly tiny. Atari games are limited to 4 KB. Man, I have some C++ files that are over 200 KB and entire projects where the source code is a few MB.

  33. I totally agree with the comment that if this was released in the mid-late 80's, David would have become a millionaire – looks like amazing game play, nothing I can recall from that era even close to this. This would have been my go to game when I still rocked my C64 & C128… I didn't even know of the 8-Bit Guy back when this game was being developed otherwise I would have shelled out to grab a copy! I just discovered that the kickstarter for X3 was well funded and closed, I saw it (before this X2 video) and was about to order the $60 one, but all gone!! Hopefully more will become available soon!! Love the work that went into this and hope to see much more of it soon!!

  34. Hi David, have you considered the puzzle game Blobbo which was on the Apple platform under Classic systems.
    This puzzle had a number of levels in which the character Blobbo needs to negotiate various obstacles before he could proceed to the next level.
    The puzzles on some levels were ingenious and very challenging. In one instance the rule that Blobbo could not pass through a stone wall was broken to allow him to make the last move to exit to the next level.
    However the inventor of the game (Andreas) never completed all the levels he intended and development stopped.
    It would be a great puzzle to bring to completion. I understand there may be some copyright restrictions but this might be negotiable. Finding a puzzle creator with the same mindset as Andreas would also be a challenge.
    If I had to choose one game to motivate me to recreate an early operating Mac to use, it would be Blobbo.
    You're probably thinking I should have spent more time learning to program so I could recreate such games, and you would be right. One of the regrets of old age. Sigh.
    Great videos by the way.

  35. most games were not worth the money. What made the c64 so great was the Hayes 1200 baud modem. I enjoyed hacking long distance codes out so that I could call newyork bbs' and download games to put on my bbs'. It was great when they just started coming to me. I had the #2 pirate c64 bbs in Atlanta. no#1 got busted by the GBI and my dad made me shut mine down before we went on vacation that year. He could not understand why it had to keep running. Years later my mom was able to comprehend it. Anyway the pirating, long distance codes and credit card numbers was the greatest part of my childhood. The best games were ye ar Kung Fu , Bruce Lee, Gauntlet, anything from epyx. There were maybe 2 dozen games that I played for more than few weeks. Looking back it looks like Atari should have lived and apple should have died. I gave up on computers and had no idea how much better they had gotten (Atari/commodore). Didnt get another computer until 96. Had it not been for AOL nobody would have had much use for a desktop. The games still sucked and you really have to get a GPU to play anything decent. Vr is finally here and I'm not seeing anything worth getting excited about. Why aren't there full on simulators and virtual tourism yet? Computers today really suffer under software designers and managers who really suck. I'm always raging at my mac_who the fuck_ made this is so shitty. Thank God Linux finally got their shit together. I just formatted windows off my drives forever.
    How do you make an os suck for over 30 years?

  36. I certainly applaud the writers of awesome games, like Impossible Mission. Many screens of complex graphics, and still had snippets of voice synthesis, all squeezed into the RAM with a single load from disc. Incredible talent, really.

Leave a Reply

Your email address will not be published. Required fields are marked *