Most of my viewers probably remember when I came out with Planet X2 back in 2017. I was
fairly proud of the game myself, but it was also extremely limited as far as realtime strategy
games go. And then, a year later I worked with a team of people to bring about Planet X3 on
MS-DOS platform. This game offered a significantly better gaming experience than the previous one,
everything from the graphics and sound, down to the gameplay itself. And then after that,
came Petscii Robots and the bajillion conversions of that to other platforms.
Well, about a year ago, I was looking to write another game for the Commander X16 and I posted
a poll with 4 different game ideas to see what people wanted the most. One option was
a sequel to Petscii Robots, taking that game to the next level. Another option was a some
sort of jigsaw puzzle game, a side-scroller type game, and finally a sequel to planet X3. And well,
the X3 sequel got the most votes, so that is the concept I decided to go with.
And so, I'm going to take you on a journey of how I created the most sophisticated game I have ever
created, and possibly even the most complex game ever created on a 6502, processor but first I
wanted to give a shout out to PCB way. They have consistently been a sponsor of the commander x16
project giving us big discounts on some PCBs and sometimes even free PCBs. And, as everyone
knows PCB stands for printed circuit board! So, the first thing I wanted to do is just sort
of show you a comparison of what I had to work with. X2 ran on a 1 Mhz 6502 with 64K of RAM. X3
ran on a 4.77 Mhz 8088 with 256K of RAM. And while it had better graphics on higher end machines, the
core of the game was still the same. And so, with Planet X16 I was going to have an 8 Mhz 6502 with
512K. And by the way, a 6502 is much more cycle efficient than an 8088, so if we really wanted
to compare with the 8088, I suspect this would be like running a 20 Mhz 286, or maybe better.
So, the point is, I could certainly afford to expand the expectations of the game a bit. But
another crucial element is the control method. So the previous two games were keyboard controlled
since mice were not common on those target systems. Well, every X16 ships with a mouse,
so I figured mouse control made total sense here. And I'll circle back to this in a minute.
The first thing I wanted to do was get to work on a map editor. And I figured
I could probably re-use much of the original VGA artwork from Planet X3. This is what the
original tile set looked like. It was 256 tiles that included both landscape and the sprites
like the tanks and stuff. This is also one of the reasons if you look at Planet X3,
most of the various units that move around can only face left or right. They don't face
up and down. And that's partly because I didn't have a lot of tile space left.
So, what I wanted to do here was split that up into two different sets,
thus giving me more freedom for both map objects and sprites. So that's potentially 512 tiles now.
But one big problem was that the original tile set was in 256 colors, and I needed to down convert it
to 16 colors. While the Commander can actually do 256 colors, one problem is available video RAM,
which is 128K. Ideally, I need to be able to store 512 tiles along with a bitmap graphics
layer. The reason for the bitmap layer is that I wanted to have a user interface
overlay much like modern RTS games have. So the RAM requirements for that would be 166K,
and well, we just don't have that much video RAM. So, I tried to convert the graphics down to 16
colors all at once using various algorithms but it just looked terrible, as you can see. So,
instead, just to get started, I just down converted the tiles to 16 shades of gray.
That actually didn't look too bad, and I started work on the tile editor, and eventually the game.
My plan was to come back and re-do the artwork later to take advantage of a neat feature of the
Commander X16, which is that tiles or sprites can select between 16 possible palettes. I did
this when I ported Xixit over a while back, as each of the blocks uses a different palette,
giving me around 84 unique colors on screen, despite working in 16 color mode.
Tthe problem is that we don't really have a tool designed for downconverting pre-existing graphics
into multiple different palletes. So, it'd be a huge undertaking to convert all of that by hand.
But what ended up happening is I realized if I created a single custom palette that had most of
the colors I needed, and simply converted one tile at a time using whatever down conversion algorithm
produced the best results for that tile, then I ended up with a 16 color tile-set that didn't
look half bad. And over time I kept tweaking it by hand. So, over the course of a few months with a
little tweak here and a little tweak there, before I knew it I had a pretty nice looking tileset.
And then there was the issue of the sprites. I contracted a pixel artist to take the existing
sprites which only faced left and right, and create up and down versions of all of those.
And on top of that, I really wanted these units to animate so I also asked for even more sprites,
so they could animate when they move. And here's what the current sprite-sheet looks like.
Another thing I asked the artist to do is make me a custom intro screen. I looked
through some of the original storyline art for Planet X3 and decided this picture here
might be a good inspiration for the title screen. And this is what he came up with.
And so let me go ahead and give you a quick look at the game in action. The first thing
you'll probably notice is a more familiar user interface, and the fact that you can
control multiple units at a time, and of course smooth pixel by pixel movement.
Also we have a fantastic musical soundtrack written just for this game by Nicco1690.
I want to talk just a little bit about path finding. This has been one of the biggest
criticisms I've gotten with games like this in the past, and maybe not even criticism is the
right word but just constant suggestions of how I could improve the path finding using this or that
algorithm, and unfortunately the vast majority of people saying things like that, I just don't
think they have a grasp of the limitations that I'm having to deal with on an 8bit computer. Now,
I have no doubt you could probably run something like A* path finding or some variant of that on
an 8-bit computer, the problem is I do not believe you could run that sort of
path finding multiplied by 256 simultaneous instances. It's just not going to happen.
So taking a look at the previous game, Planet X3, the individual units had to be driven by
hand using the cursor keys. So, pathfinding for the player units wasn't really that big of a
deal. About the only time it mattered was, for example, if you told your builder to construct a
building somewhere on the screen, it would need to drive to the location to execute the command. And
while this worked most of the time, every now and then the terrain was too complex and you'd have
to help it out some. The real concern was always making sure the enemy units could find your base.
However, since this version was going to be mouse-controlled, I realized that the
path finding was going to play a much bigger role with the player units. And,
so I spent like two weeks trying to develop the best path finding algorithm I could given
the constraints of the system. And so, I want to show you a little bit about how that works.
So imagine a crazy maze like this, and you want to tell your unit to go to the top. Now, a modern
realtime strategy game would be able to plot a course through this. But that's just not going
to happen on my game. And part of the problem is, while the solution to this maze looks obvious to
us humans, the actual units can't see that far. In fact, to kind of illustrate what they see,
it looks more like this. So the tank sees a rock above it. And it knows that it's destination is
over there, for example. so it can make the best choice possible, which in this case is
to go right. So, the unit does not hve a pre-plotted course to follow. and it has
no memory of past moves. What it does know is how far it has travelled from the original location,
and how many detours it has had to take. This can help it decide a few things.
So let me show you some examples of the pathfinding. I'm going to tell this tank
to move to the other side of this building. And as you can see, it has no trouble with that. In fact,
one thing I'd like to point out is that it doesn't always take the same path. Sometimes
it goes above and sometimes below. I actually added in a certain amount of randomness to the
decision making process when it encounters an obstacle, which actually helped a surprising
amount. Now let's give it a bit longer path. And you can see it makes it just fine around
these objects. The pathfinding routine works really well to get around small objects,
or around large square-shaped objects. Here's another place it does really well,
sending a bunch of tanks across a bridge single file. It handles this remarkably well. Here,
let's go back the other direction. Perfect. Now let me show you the type of situation it
performs poorly. Take this wall for example. Because of it's shape, the tank can't quite
seem to make it around. However, after enough detours, it enters a random mode for 10 cycles.
Then attemps to go back to the original course. And that actually works surprisingly well. In
most cases, if you give the unit enough time, it will eventually find the way. But it's
really best to help units move through complex terrain if you want them to get there quicky.
One little feature I added is that units can ask for help if they get too lost. Let me show you,
I'll take this ATV here, and I'll tell it to go somewhere that is impossible for it to reach,
like here. Now, I'll go back to my regular business and act as if I forgot about it.
After a while, I'll get a notification, "help I'm lost!." So like with all such notifications,
you can press the space bar to take you to the location where the last notification came from,
thus revealing your lost unit. At this point he just stopped and is awaiting help.
Another major improvement over X2 and X3 is the enemy AI. For example, rather than sending every
unit produced directly to your base, now they stay relatively close to their base. They will
send out a major attack wave once enough units are produced, but at the same time,
some units will stay behind to defend the base along with the sentry pods. Likewise,
when you attack the enemy base, all available protoids will converge on you to help defend.
OK, let's talk about testing a bit. I kept my X16 on my desk with a standard composite television
attached. This is mainly because I wanted to have the worst possible display device to make sure
the game is playable on that. and believe it or not, the game detects whether you are using VGA
or Composite and actually adjusts certain things accordingly. And this also led me to add a feature
where you can press shift-C to set a high contrast mode for the text, if it is a bit hard to read.
Just for fun, I also create a monochrome version of the game. And other than the title screen,
which was designed for 16 colors originally, the rest of the graphics are converted from
the 256 color original source graphics over to 16 shades of gray. And so,
just looking here you can see the monochrome graphics actually have more detail to them as a
result. Also a number of other bits of code were changed so that things like text and the little
dots on the mini-map show up better on monochrome. So, one nice thing for me is that I didn't have to
spend a lot of time and money developing a box and a printed user manual, since this game isn't going
to be sold as a physical copy. And, I think a lot of people really underestimate exactly how much
time and money it can take to develop stuff like this. And so, on the bright side, since I wasn't
spending all that time, I could devote a little bit more time to working on the code instead
of so much time working on things like this. The manual is a simple text file. You can view
it on the actual X16 itself by just typing EDIT "USERGUIDE.TXT" and there it is. It covers some of
the basics of gameplay. It also has a frequently asked questions, and an appendix with all of the
keyboard shortcuts, which is very helpful, and a list of the resources needed to build things,
health and damage, and stuff like that. Anyway, I want to show you a couple of
items that were planned but simply did not make it into this version, but they could
certainly be added in a later release. I wanted to have some sort of pop-up
description of these buttons over here, when you hover your mouse over them. And,
if you look at the sprite sheets, you'll see there are some flying units that didn't
make it into the release, as well as a boat. One question people are likely to ask is if I
plan to port this game to another platform like was done with Petscii Robots. Well,
let's first talk about what sort of system requirements would be needed. First of all,
look at this CPU visualizer which is part of the box-16 emulator. You can see that the CPU hovers
just aruond half and goes a bit over sometimes. This is also played out well on the real hardware.
For example if I jumper the computer to 4 Mhz mode, the game actually plays pretty well. I mean,
I can notice it skips a frame every now and then. The average player might not even
notice. But if I put it down to 2 mhz, then it becomes absolutely unplayable. Now to be fair,
the game tries to redraw the screen 60 times per second. With some rework to the code, it
could probably be designed to update at a slower framerate like 30 frames per second or even less.
So, which systems do I think would make good targets for this game? Obviously any good low
hanging fruit would be other 6502 based systems. The two most logical targets would be the Mega65
and the Foenix. Both of these systems should have the horsepower to run a game like this.
But what about an actual vintage computer? I think it is safe to rule out the commodore 64,
Atari 800, Apple II, etc. I think the Apple IIgs could possibly run this game if we had
the right coder. The Super Nintendo, when paired with a mouse could probably pull it off. Another
possibility would be the Apple IIc Plus, since it runs at 4 Mhz. But you'd need a mockingboard
because you'd have to have the timer chips it provides, and that is a really uncommon
configuration. Likewise the Laser 128 EX2, which also runs at 4 Mhz could probably handle it.
I mean, obviously something like a decently fast MS-DOS computer like 386sx, for example,
could certainly handle running a game like this. The problem is it'd be a monumental challenge for
someone to convert all of that 6502 code over to 8088. Nevertheless, if someone thinks they're up
to the challenge, let me know and I will help in any way I can. For those of you without an X16,
you can actually play this game for free by downloading the emulator and I'll put a link down
in the description field of where you can get both the emulator and the game. Another option would be
to play the game on Steam. It's actually not up there yet at the time of filming but hopefully
it will be shortly so check the description field for a steam link, as well another thing
I'm going to put down there is some links to some YouTube playthrough videos. So, for those trying
to learn how to play the game you could watch Dr. J struggle through and figure it out. But,
that's really it for this episode. I wasn't really planning on doing another X16 related
video until next year which would be 2024, but you know, I spent most of 2023 working on this game,
and now that I'm finished I'm just like, I kind of have to tell the world about it,
because I kind of feel like this is my crowning achievement. It's, of the five games I've made
now, this is definitely the one I'm the most proud of. And, I feel like it kind of raises the bar on
what can be done with an 8-bit system. But anyway, that's it for now. As always, thanks for watching!