I've been noodling this game idea in my head for several years, and finally decided to do it on the Commander X-16. This isn't in a playable format yet; I spent several months just generating the lookup tables for it, and this is the first time I've had anything at all to show. I'm gong to use this thread to post updates and releases as progress happens.
Asteroid Commander will be a game sort of like SimCity, in space, with a storyline. There's no sound in this video.
The asteroid is procedurally generated, and the image is raytraced - for certain very limited definitions of raytracing. The shadows are very rough right now and I can see I have a bit of work to do on the ray maps, but the toughest part of the game engine is basically done.
I love the look! And of course I like the idea of a new sim game.
Thanks, but it's about to look much better, as I'm reworking the ray maps. This is just the medium view, there will also be a closeup view and a far-out view. And at the rate I'm going it'll take me a year to finish this.
Thanks, but it's about to look much better, as I'm reworking the ray maps. This is just the medium view, there will also be a closeup view and a far-out view. And at the rate I'm going it'll take me a year to finish this.
All of my hobby projects take awhile, and most of them don't get finished.
So how do you want the sim to work?
Oooh, I just had a thought that it could be combined with a space-station-building game.
Since it's an asteroid colony, you'd have
support buildings (power and life support)
science buildings (for contracts),
revenue buildings (mines, refineries, fabs?),
and habitats...
hmmm this could be really fun. I don't want to kitchen sink it, but I imagine personnel would have to transfer in and out via a shuttle service (perhaps behind the scenes). That would enforce a population "phase" into the game that could be interesting (or not).
Yeah, the far-out view is for stuff orbiting the asteroid. I don't think I'll get quite so detailed as to have the player micromanaging shuttles or other vehicles. The player will mostly be deciding what buildings to place or upgrade and trading with other locations in the solar system. As far as the asteroid population, they're part of the storyline (which will be optional; the player can ignore the story and just be Asteroid Mogul).
I don't think I'll get quite so detailed as to have the player micromanaging shuttles or other vehicles.
Agreed - I wasn't suggesting a kitchen sink, and while I like "build-it" simulations, I don't like "micromanage it" simulations so much.
Quote
The player will mostly be deciding what buildings to place or upgrade and trading with other locations in the solar system. As far as the asteroid population, they're part of the storyline (which will be optional; the player can ignore the story and just be Asteroid Mogul).
YES. This sounds like it hits the sweet spot for me.
So I finally found the bug that was glitching the display on the outside edge of the asteroid, missing a single INC command. I also slightly increased the speed of the display. The asteroid won't be spinning this fast in the game, I just needed to do this for the test. I've also tweaked the terrain primitives a bit, and now I'm starting to see craters on the surface. This is particularly noticeable on the low areas on the other side of this particular asteroid, and with a little more tweaking I should have it showing craters on the high areas too. After I'm satisfied with the look of the asteroid, I'll start on the other display elements and bring in the mouse. You'll be able to click on the direction arrows in the middle to navigate around the asteroid and rotate your view. The next step after that is to start displaying text, and then I'll work on the buildings and the background stars and sun.
Making progress. Now there's craters. Some of them are a result of the revamped terrain primitives, and just occur as a result of putting the terrain pieces together. The rest of them are "buildings", up to 16 of them placed around the asteroid. The terrain is based on a bunch of bits extracted from the commander name and the asteroid name. There's about a million possible asteroids, which is actually kind of low; there's an estimated quadrillion asteroids of this size (~1km) in our solar system. If you name yourself Invader Zim and call the asteroid X16 Of Doom, this is the asteroid you'll get.
The asteroid is based on an icosahedron. This was tessellated once to give a figure with 80 triangular sides, 20 equilateral and 60 isosceles but close to equilateral, with a total of 42 vertices. Each of those 80 triangles was further subdivided into 81 triangular "cells", which are grouped in three groups of 27 cells in a wedge shape. So there's 6480 cells on the map, grouped into 240 "wedges" each with 27 cells. There are also 16 terrain primitives, each with 27 cells. The 80 big triangles are all assigned a height, either High or Low, and the 42 vertices are also assigned High or Low depending on the surrounding triangles; if at least 3 neighboring triangles are High, the vertex is High, else Low.
Those Highs and Lows correspond to the corners of the 240 wedges; one is the triangle the wedge is on, one for each of two neighboring triangles, and one for the vertex. So each of the 240 wedges can be described by 4 bits, corresponding to the 16 terrain primitives. From the original 80 bits of the triangle heights, the four corners of each wedge can be derived and hence the terrain data for that wedge copied over.
Most of the map is just 16 small chunks of terrain in different orientations. Terrain primitive 0000 has a 120 degree curve on it slightly higher than the surrounding terrain, and three such wedges put together forms some of the craters in the low areas in the bottom picture. Terrain primitive 1111 also has a 120 degree curve on it, much higher than the other terrain, with a deep pit at one corner of the wedge. Three such primitives put together form a crater like the two close together on the high terrain in the middle picture. All the other terrain primitives have a transition from high terrain to low terrain, and in cases where a low area is completely surrounded by a high area all those primitives put together also look like craters, as you can see in the top two images.
The crater on the left in the first image and on the right in the second image are the same crater. This is one of the craters that is placed as a "building" in a pseudo-random (again based on the asteroid and commander names) scattering. There could be as many as 16 of these but probably not, as there's only 122 locations to put buildings (the 80 triangles and 42 vertices) and I'm pretty sure only about 6 will actually show up, as there's usually multiples of the same building area chosen for these types of craters. There are two types of these craters, and both are visible in the first image, but one of them is right at the center and the terminator line is on it so it's harder to see from this angle.
Every cell on the map has a sunrise and sunset value based on its longitude, and comparing the sun position to those values determines whether to show the daytime color or nighttime color for the cell. The cell also has a height value from 0 to F; actually 00 to F0. The low four bits are the color value, and 0 indicates terrain, whose color value is dependent on the height. For other building types the color will be chosen from 15 pairs of day/night colors associated with the building type, along with 0 for terrain color.
Because of various symmetries, I'm able to view this asteroid from directly above each of the 122 building areas using only 4 raytracing maps. There are 88 8x8 8bpp tiles that make up the asteroid, a 10x10 grid with three missing at each corner. These are arranged on the screen from top to bottom going left to right. For each pixel there is a corresponding radius from the center of the image and an angle measured from a line pointing down, going clockwise. The radius is FF if it is more than 40 pixels from the center, and the very last pixel is given a radius of FE. All others are values in [0..39]. The angle is measured in bigrees, 256 bigrees = 360 degrees. So each of the 88x64 pixels that make up the asteroid has a radius byte and an angle byte. These are stored in VRAM in an 11kb block.
When the image is being calculated, the radius and angle byte are read from VRAM, and if FE we're done, and if FE or FF we just have that as the result. For a radius of 0 to 39, we calculate a ray. First the angle byte of the pixel is added to the view rotation (you'll be able to rotate the image by 30 or 18 degrees, depending on whether you're on a hexagonal or pentagonal building area). Then for each of the four map types there is a 40x256x2 lookup table, and the radius and resultant angle are the lookup indices; the two bytes stored there are pointers, a low byte and a combination ram bank/high byte; when these two bytes are converted to three, they point to the start of a ray. So that's 10 banks of RAM just for lookup pointers to the rays.
For each of the building areas, the wedges are assigned a "relative wedge" number; the ones that make up the building area itself have the lowest numbers, the ones at the horizon are all clustered around the number 120, and the ones on the opposite side of the asteroid approach a relative wedge number of 239. No matter how low the ones directly on the horizon are, and how high the ones around the limb are, only 160 out of the 240 could ever possibly be visible. So for each building area there is a page of RAM set aside in banked RAM, four banks for the building area data. The first 160 bytes of the page of data for a work area lists the first 160 relative wedges.
The rays themselves start with a relative wedge number, then one byte to list a minimum height for the wedge (if no cell in the wedge is above that minimum height, we can skip the whole wedge) and the number of cells to be tested in the wedge; no ray will ever cross more than 11 cells on a single wedge. For each wedge once the asteroid is created the maximum height of all the cells in that wedge is found and stored, so the comparison to the minimum height is pretty fast; from the relative wedge number and the building area I can find the actual wedge number and then look up its maximum height and compare to the minimum height for the ray. If at least one cell in the ray is higher than the minimum height, we can go on and test the cells on this wedge. The minimum height test is skipped if there is only one cell to test in this wedge. And for radius 0 to 35, the minimum height is 0 anyhow.
After those first two bytes, there are pairs of bytes listing a cell number and a height. If the cell in that wedge has a height value greater than the ray's target height value, then that wedge and cell are the result; if not we go on to the next cell and the next until all the cells in that wedge have been checked. After that the next byte is another relative wedge and minheight/numcells until the target height is 0or the relative wedge number returned is FF.
The two bytes for wedge and cell (actually the high byte of the address of the cell data) are then pushed back into another 11 kb section of VRAM; the automatic increment really came in handy for both reading the radius/angle table and creating the wedge/cell table. All I had to do was keep going until encountering FE.
Then to actually draw the asteroid, it reads that wedge/cell data out of VRAM and pushes a color byte back into the tile data section of VRAM. One of two spots in the tile data actually, as I'll have one set of tiles displayed while another is being drawn. If the wedge is FF it pushes 00 to the tile data, and if the wedge is FE it pushes 00 to the tile data and stops. For any other wedge number it puts the wedge and cell high byte into two consecutive locations in zero page. At this point an earlier version of the program went through several steps to figure out the color, but since then I've had the program calculate the day and night color for every wedge and cell and stored both in lookup tables, so now the program just looks at the sunrise, sunset, and current sun position to determine day or night color. Then if it is a day color it's one lookup table and if it is night it is the other; that's two more banks of RAM for that. Whatever it chooses is the color pushed to VRAM. When you see the terminator line moving across the asteroid in that second video, all that is changing is the sun position, and the asteroid is redrawn with the appropriate day or night colors.
There's about 165 kilobytes of these pre-calculated rays spread out over 22 banks of RAM, so the 80 kb of ray pointers and the rays themselves are less than 256 kb. It would have taken a supercomputer to generate these ray maps back in the 80s, and parts of the process bogged down my 8GHz laptop with GPU for half an hour or more.
The space in these banks that isn't used for rays or pointers is filled up with other tables and even garbage code for now, because the code that creates the asteroid uses the names to generate an address in one of these 32 banks of RAM along with a bit offset from 0 to 7, and then extracts the next 80 bits to generate the heights of all the big triangles. The 11 bytes that are the source for those 80 bits are also further manipulated to locate the extra craters on the map.
So the next step is to start working with the mouse subroutines and get the navigation buttons (except for zoom in and out) working.
