Today I'm going to give you the 3rd official update on the progress of Planet X3, my real-time
strategy game for MS-DOS computers.
For those who are not already familiar with this, I created Planet X2 for the Commodore
64 last year, then after the success of that, I promised to port it to MS-DOS machines.
However, this new game has taken on a life of its own.
I also launched a kickstarter a few months ago, hoping to get around 500 pre-orders or
$30,000 worth of pre-sales.
And it ended up with 2,548 backers, totaling over $113,000.
So, in this video, I want to not only show you some of the progress that has been made
since the kickstarter video, but I also want to try to answer some of the frequently asked
questions.
One of the most common questions I get is people wanting to know what language I'm
coding in, and what tools I'm using.
So to answer the first big question, even though I'm mentioned it before, I'm coding
directly in 8088 assembly language.
This is what the source code looks like.
I get a lot of people asking why I am not coding it in BASIC or C or some high level
language.
The bottom line is I need the speed and efficiency to make this work on low-end MS-DOS machines.
And as far as tools go, I'm really only using three tools.
One is notepad, which I write the source code in.
And then I use a compiler called A86 to compile the code into machine language.
So, that's my second tool.
And then the 3rd tool is DOSBOX, which I use for most of the testing.
Of course, I've had to write some of my own tools, which I'll talk about later.
For bug tracking, I am doing it very simple.
I just have another notepad with a list of bugs that I've found.
When I find a new bug, I add it to the list.
And then, I have a list of things that aren't bugs, but just stuff I haven't finished
coding yet.
Of course this list keeps getting smaller over time.
In fact, I can remove this right now, as I just finished the sentry tank's code.
And then I have another list of things that are sort of back burner, however, I already
finished this one as well, so I'll take it off.
So that's how I track bugs and what is left to do.
And what about version control?
Well, every day I just create a folder on my server.
I call it snapshot and today's date.
Then I copy all of the sources and binaries into that folder.
Every now and then I need to go back and look at an older source, or if I really screw something
up and want to just revert a subroutine back to the older version, that's how I do it.
Nothing fancy.
No need to use Github or anything like that.
So what am I working on now?
Lately I've spent a lot of time working on pathfinding routines.
Let me demonstrate what I mean.
So, if I tell my builder to pick up this rock.
And then have a look at these walls over here.
I'm using these for testing.
So if I tell it to drop the rock over here, the builder has to be able to find its way
around the obstacle.
And for simple obstacles like this it seems to be working.
So here's a bit larger obstacle.
Again, it finds its way around.
OK, so that's great for walls, what about other objects.
Let me drop the rock over here, and again, it finds its way.
This is good enough for the user-controlled units, but this same pathfinding routine will
also be used for the enemy units, so it has to work without supervision.
Now, I want to show you something else.
Pressing F1 will bring up a little cheat or debug menu at the moment.
And what it shows is everything that is stored in memory about the unit you are currently
controlling.
But also, you can use the arrow keys and scroll to other units and see all of their information
as well.
And, if I press the G key, it will take me to wherever that unit is on the map.
But this isn't just limited to my units, I can also look at enemy units.
So, if I scroll up to unit 64, which is where the enemy units are, I can go to that one,
and yeah, there's quite a few of these piled up here because they can't get across the
water, just yet.
I'll be fixing that soon.
But this is particularly helpful in troubleshooting enemy pathfinding.
For example, I can watch a unit as soon as it pops out of the pyramid and starts trying
to find its way to my base.
Now, this is on a different map here, this is called inferno.
It's kind of a wasteland with a lot of meteor impacts.
Now, this guy isn't having too much trouble navigating his way through this as it's
mostly open space.
Now, I'll skip ahead a bit.
Eventually he gets to a part of the map where there are a lot of obstacles.
At first it looks like he can handle anything that comes his way.
But, eventually he gets stuck.
The problem is, the base he's headed for is directly to the right of him about 20 tiles
over.
But there's no way through the lava without going around something quite large.
He's not smart enough to do this.
So he'll just walk around this spot forever.
And eventually, here comes one of his pals.
And over time a bunch of them will just pile up here.
So how do I solve that?
Well, a combination of ways.
First off, I can try to improve the pathfinding routine even more.
The second thing I can do is change the map to make it easier for them to find their way.
Ultimately, just like with my previous game, I'll wind up doing both.
On the map side, I will just start up the map editor, which is a separate program I
had to write.
That's one of those many little tools I mentioned earlier that I had to create.
So, I'll tell it to load the map called "Inferno" and here we are.
So this is where the originating base was.
And I made note of the coordinates where the trouble spot was.
So, I'll just find my way over there.
Yep, here it is.
I'll just go to the tile selector and pick dirt.
Then place it here so that the units can get through.
So I want to talk about another technical challenge I faced.
I'm really thrilled with how the CGA video looks.
In order to try it out on some real steal, my friend the Obsolete Geek brought over his
IBM 5155 portable.
The internal display is monochrome, but it's still compatible with CGA graphics only instead
of 4 colors you get 4 shades of amber.
But, it actually looks really good.
It's definitely very playable like this.
And, despite being a 4.77 Mhz CPU, it runs decently fast as well.
In fact, seeing this is part of the joy of having my game work on these older systems
since hardly any new MS-DOS releases have been compatible with machines like this since
probably the early 1990s.
Anyway, this machine also has a CGA composite output on the back, so you can connect a color
monitor or television.
And you'll get a full 16 colors if the game supports composite mode, which mine does.
And not only does it work, but it looks fantastic.
This is how it has looked on every IBM machine I have tried it on so far.
And it looks great!
And I keep asking myself why did so few software titles support this mode?
Well, I think I may have found part of the answer.
I have discovered a lot of clone machines don't work right.
For example, my Laser 128 will run the game in composite mode, but it often come up with
bizarre colors.
In fact it's somewhat random, because I can reboot the thing and it will come up with
a different set of colors.
Well, let me explain what I believe is going on.
If you look at the video signal being generated by these computers, and imagine this is the
pixel clock.
And, there's another signal in a composite video feed, which is the color clock or color
burst or whatever.
Anyway, on a true IBM CGA card, these are always synced like this at every single boot.
So, the color clock happens once every 4 pixels, so by arranging the pixels in different ways
you get 16 possible combinations creating 16 artifact colors.
The trouble is, Some machines like my laser 128 will lock these in one of 4 random positions
at boot up.
And you never know which one it is going to be, either.
This was really frustrating, as it could make the video boot up in all sorts of weird colors
and the only thing I could do was reboot the machine and hope for the best.
I had a 25% chance of getting the right palette.
However, eventually I had an idea.
Even though there is no way to change the synchronization of the color signal from software,
I do have control over the pixels, right?
So let me show you what I did.
In the last video I showed you how in standard 4-color mode you could change the color palette
between the cool and warm CGA color palettes.
Well, in composite mode that menu option had no effect.
So what I did was changed the code so that in composite mode, it will shift all the pixels
on the screen over by one.
And so if it still doesn't look right, just push it again.
It will rotate back around every 4 times.
But, one of the options should fix everything so that it looks right, or at least close
to right.
My Tandy 1000 also suffers from a similar problem, only it always starts up with the
exact same wrong palette.
So pressing this option twice should fix it on a Tandy.
Unfortunately, the Tandy just doesn't look as good on composite no matter what.
The pixels are somewhat in the wrong places, and I don't know why.
However, I'm not terribly concerned since I support the Tandy 16 color graphics mode
anyway so there is no need to use composite on one of these.
Anyway, this does suggest at least one possible reason why CGA composite mode was never popular.
As, many clones did start to appear in the early days.
But, at least I was able to find a way around the problem.
However, I had another similar idea.
I had recently added the CGA monochrome mode as well.
While this doesn't look terribly exciting, it is still playable.
And where this comes in particularly handy is on certain old laptops with monochrome
LCD screens.
Many of these laptops start off with the screen being inverted like a photo negative, because
they felt it made the text easier to read.
But this could be problematic when playing games.
Many machines had a special key sequence that could be used to invert the screen for games,
and some required a special DOS program, and some there was just nothing you could do.
I decided to make this menu option cause a negative image, which would look crazy on
most computers, but on these old laptops it actually corrects it to look right and playable.
So, the next thing I want to show you is another one of my tools.
And you've probably seen this before.
I created a tiledraw program to help me design the tiles.
But this program does so much more than that.
You can really change a lot of the behavior of the game from here.
For example, each tile you can define things like, can you drive on it, can you bulldoze
it, can you pick it up and move it, etc.
Also, you can define what a tile becomes when it is destroyed by changing this attribute
here.
In fact, many of the bugs I find in the game aren't even in code, but rather I have an
attribute set incorrectly in here.
Fortunately, it is easy to change.
However, over time, my artist Renaud started using his own paint program and simply sending
me the tiles as a single set.
And, so what I did as created an import feature where I could import the entire set at once
from his master image with a single keystroke.
And so that has made life a lot easier.
But I also had to create a different tile editor for every single video mode, including
the 2-color CGA monochrome mode, as well as the CGA composite mode and Tandy modes.
Speaking of artwork, I wanted to show you some of the new artwork.
I'll select this map called winter.
This is just a test map, but it shows off the winter graphics tile set.
What's neat about this is each map can load a custom tile set.
And it's more than just different tiles, as the tiles can also have different attributes.
So, for example, I have snowmen in this map, which has no analogous tile in the other maps.
So this gives a lot of flexibility to creating new landscapes.
There's not much here in this winter map, as I said it is mostly just a test map.
Also there's a bit of snow on top of some of the buildings here as well.
And moving along, this is another map called desert.
And there are a lot of neat features in this tile set as well, but again this is just a
test-map so there isn't a whole lot to see here.
In fact, yeah, there's the abrupt end to my stream.
And here's some minerals crammed up in here.
And, here's what the winter mode looks like in CGA 4-color mode.
Notice there are a few black tiles because the tile-set is not 100% completed for this
mode.
And speaking of new graphics, this is probably what everyone has been waiting to see.
Last month I created yet another tile-draw program, and this one was designed for VGA
graphics.
And just in time for the finished 256-color artwork that Renaud was working on.
It took me about 4 or 5 days to get the tile editor completely converted to work with 256
color VGA graphics.
But the great thing is, many of the screen drawing routines I had to design here were
easily transferrable to the game itself.
Now, before I show you the game itself, I wanted to mention something else.
These are all the different video modes I had planned to support.
The first 4 modes are all handled by the CGA version of the game, even the Tandy mode.
That's because all of these modes use a 16K video RAM configuration so 99% of the
code is the same.
There are only a few tweaks required to the code, and mostly it is just having different
artwork custom designed for each mode.
However, the VGA version needed its own executable.
It required quite a bit of modification to the code since the entire memory map is laid
out differently.
It took a couple of weeks to get the game working in VGA mode.
And now I have two entirely different sets of source codes I have to keep up with.
Fortunately, most of the code that I'm working on now is stuff like pathfinding routines,
which don't really deal with the video card directly.
So that means I can simply paste the new code into both sources for the most part.
So here's the VGA version of the game that everyone has been waiting to see.
Well, it doesn't look too impressive at the menu.
That's because I don't have the VGA menu graphics in from my artist yet.
So I just converted the CGA menu graphics for now, but this is actually running in VGA
mode whether it looks like it or not.
So, let's start a game.
And here it is.
Yeah, I'm pretty proud of how it looks.
And I think most of the credit here goes to Renaud for his awesome artwork.
Now, there's a few things I need to tell you about this version.
For one, you may notice these pink looking areas around some of the units like my builder,
tank, and especially the aliens.
And that's because I'm planning to implement transparency.
So what you are seeing is sort of like looking at unfinished special effects shots that are
shot in front of a blue-screen or green-screen.
I simply haven't added the code yet to fill in the transparent areas.
This is something the CGA version does not do at all.
But I felt the VGA version probably should.
So, for the moment it looks tacky, but in the next update that should be fully working.
Also, I do not have the graphics yet for winter and desert landscapes.
So I imported the CGA composite graphics into the VGA version for now, so that's what
it looks like for the moment when using maps that depend on those graphics.
I'm sure I'll have the complete VGA graphics soon.
A lot of people have been asking what sort of CPU would be required to run the VGA version.
And, I just haven't been able to give an answer to that because I didn't have any
code written so I had no way to really know.
Well, now I know.
So, while the CGA version was designed to work on a 4.77 Mhz IBM XT, the VGA version
has 4 times as much data to move around, and it really requires at a minimum a 286 running
at 10 Mhz.
Which is probably fine as it's pretty rare to see VGA running on an XT class machine
anyway.
However, I do have a video clip here from Lorin, who's one of my testers.
He has it running on an IBM PS/2 system in this video, which is a 286 running at 10 Mhz.
And it does work, although it can be a bit sluggish at times.
And when people ask my why I'm not supporting EGA , Hercules, or Tandy hi-res graphics,
the main reason is because each of these modes would require a complete conversion with its
own executable.
And since I'm just one guy, I just decided not to support these modes.
Not to say that I couldn't support them in the future, but certainly not in the initial
release.
Ok, enough about graphics modes.
Let's talk about sound and music.
Now, in the last video I kind of put out a help-wanted request to see if anybody was
wiling to code the sound and music routines for me.
And, I had several people apply for the job, but I ended up hiring Alex "Shiru" Semenov,
who is a veteran programmer for sound and music on a variety of different platforms.
And, I had a decision to make about how to support music across multiple platforms.
I wanted to support the PC-Speaker with its one voice.
And then the Tandy 3-voice sound system, along with the Adlib which has 9 voices.
I wanted to be able to use essentially the same tunes for each device.
Now, I knew that with advanced programming, you could get at least two more phantom voices
out of the PC-Speaker.
This is done by alternating the voices quickly to create an illusion of multiple voices.
So, what I decided to do was draw a line at 3 voices.
I felt like 3 would be enough, and this way all 3 supported devices would be able to play
the same tunes.
Plus, we can use some of the extra voices on the Ad-Lib card for sound effects.
And for the PC-Speaker, we'll just have to alternate between music or sound effects.
And the Tandy is an interesting case.
After all, it still has a PC-Speaker which can act as a 4th voice, so we'll probably
use that for sound-effects here as well.
This was actually a common design back in the day.
In fact, Ultima VI uses the PC-speaker for all sound effects no matter what card you
have for music.
So, I want to show you the tracker that Alex has designed.
This one tracker supports all 3 sound cards.
One thing is does for the PC-Speaker, though, is that different tracks get different priority
over the one voice.
So the left-most channel here is given the least priority, and if anything comes across
on the middle, then it is given higher priority, and of course the right channel gets the highest
priority.
And I'll show you how this sounds.
He's composed one demo song with the tracker.
OK so, right now you are hearing the PC-Speaker.
It's actually pretty impressive for a one-voice setup.
OK, let's have a listen to the Tandy 3-Voice version.
This sounds noticeably better, especially on sustained notes.
And finally here's the Ad-Lib version.
Not bad for only using 3 voices.
Now all that needs to be done is to integrate the sound and music routine into the actual
source code of the game itself, which I hope to happen sometime in the next month or so.
All right, and the last thing I wanted to mention, since a lot of people have been asking.
There were only originally 500 boxed copies of Planet X2 for the Commodore 64.
Due to minimum order quantities, I never ordered any more than that.
However, one of the options in the kickstarter was the deluxe version which comes with a
copy of Planet X2.
And, there were 836 people that selected this option, which really surprised me.
Well, I knew I had enough pre-orders then to go ahead and order separate boxes for Planet
X2.
So I've already ordered 1,000 boxes for Planet X2 so that means I can sell around
163 copies to those who might have missed out on the original boxed copy.
Plus, I also have more disk labels and manuals on the way so I'll be able to sell more
lite copies as well.
But, what about the disks themselves?
Well, just today I invited some people over where we had a little disk copy party.
We all setup our Commodore machines and made copies of Planet X2 while eating pizza and
generally having a good time.
So, disks are ready!
And I imagine we'll be doing something similar when the code is finished for Planet X3.
Only we'll have MS-DOS machines setup instead.
So, to answer the question about when I'm going to get more Planet X2 in stock, well,
they're coming real soon.
Hopefully in the next week or two you'll be able to buy that again.
Now, to answer the next two questions, which is what if you missed out on the kickstarter
for Planet X3?
A lot of people seem to think that was the only way to get one, and I just wanted to
confirm that those will be for sale after the fact, so even if you didn't get in on
the kickstarter, you'll still be able to get a copy of it, so don't worry about that.
And, of course, people are wanting to know when Planet X3 might actually be done.
And that, I don't know yet.
I'm really kind of hoping by the end of the year, so maybe around December or so.
Can't make any promises.
But that's the current plan.
So anyway, that about wraps this video up so stick around till the next one and thanks
for watching!
Không có nhận xét nào:
Đăng nhận xét