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!
For more infomation >> Preparing for a planned outage - Duration: 1:36. 
For more infomation >> Clemson House ready for implosion on Sunday - Duration: 2:47. 
For more infomation >> ৬ টি bad habits যা আপনার অসফলতার কারণ | bad habits for unsuccessful | Motivational video in bangla - Duration: 4:50. 
For more infomation >> How to draw a fish and coloring pages for kids step by step - drawing for kids - Duration: 4:55. 
For more infomation >> Authorities say drivers fail to move over for officers on the roads - Duration: 2:56. 
For more infomation >> Students return to school for first time after principal passes away - Duration: 2:06. 
For more infomation >> Question 12 - Gareth Hughes to the Minister for Climate Change Issues - Duration: 4:10. 
For more infomation >> 'Under Pressure': The pressure that LGBTIQ people have been under for decades - Duration: 4:10. 
For more infomation >> Mayor Darrell Steinberg Endorses Gavin Newsom's Campaign For Governor - Duration: 2:07. 
Không có nhận xét nào:
Đăng nhận xét