Clean the skies of sector Q97-C with your trusty mining laser.
Keep an eye out for debris, not to mention Turrets and Tormentors.
Arrow keys control roll and yaw.
Z-key fires laser.
Full 3D navigation can be tricky, so keep an eye on your radar at the bottom.
It can be easier to sweep the laser up over targets than to try to hit them dead on.
Watch out because the laser uses your ship's power, which only refills slowly over time.
Added music by Robby Duguay
Added sound effects
I've mostly been able to keep this to 30fps, though it does occasionally drop when there are a lot of objects on the screen. (The engine does a pretty good job of limiting the effort put into translating and rendering items that are out of view.) The viewport size helps a little, but not as much as it does in a raycast engine.
I'm very happy with the way the colors work--I think this might have to do more with the P8 palate being genuinely pleasing than any special consideration on my part.
Updated to 1.1 with music by Robby Duguay
and sound effects.
This marks the first time that I have hit the token limit, which probably means its about time to check this one off as complete and start on another game.
If you're in need, I may provide you my WIP-toolkit to store data within the sprite/map data from a python script. This saves the need to store them in code and you gain some tokens? Works until the sound effect section, which I still need to decode/encode properly.
Next 3D game, I'll probably borrow your method for storing vertex data in the map section. What scheme did you use? 2 bytes per fixed point number--i.e. one pixel?
I could also compress the vertices into strings, which has worked well enough in the past, though tends to push into compressed code limit space while it helps with token count.
The other area that I need to figure out better is the z-clipping. For discrete objects like the asteroids, it's not really necessary because they render as smaller than the view port, and you don't want to hit them anyway. But for something with ground or internal scenes z clipping is critical.
There was a cool z-buffer demo here a little while ago, but I believe the z buffer was only calculated when the camera moved--great for fixed camera scenes like alone in the dark, but perhaps not fast enough for real time camera movement. (Just filling a 128 x 128 table takes a good chunk of a frame.)
I simply place the bytes there, although the system cares for the specialities of each section, including the music section. I compress the data with a naive approch to the huffman encoding, which saves a good third on text data. I hope to get the sfx-section available very soon, too, although it is a bit harder to use.
To save the data itself, I serialize a tree of dictionaries and arrays within python, which creates a table-tree within pico-8. Within my game, I can check for certain key elements to even add game logic from this approach, like adding conditions to elements and the ability to execute parts of the tree as very simple scripts, making it a very primitive VM.
Nice game. I like your line dithering to get a smart cheap lighting.
Storing meshes in the map data works well as there s plenty of room there. I used that on my game Hyperspace to store positions, normals, uvs and triangle indices. Basically using one byte for each value. This gives me a 256 sampling and I then multiply positions by a scale depending on the model. I didnt look into compressing more as I had more than enough memory there, I cared more about optimizing the decoding method to limit token usage.
I also have implemented a zbuffer in my terrain demo. I stored depth linearly in 8 bits per pixel. This still consume quite a lot of data and was not used for 30fps target.
But you dont need z buffer to perform z clipping, just split the triangles that intersects near plane. I havent used that in pico8 because it can be heavy (I just discarded triangles that intersect or didnt care at all for objects that I know will not intersect) but for some scene, you may have no choice if you dont want holes (like ground planes...)
I just got z-clipping working this weekend. Agreed that it's a bit heavy--I'll probably just use it on polygons with a "landscape" flag or something like that.
I'm going to try a more complete implementation of painter's algorithm. I've just been sorting by the z value of the centroid, but that often draws the large ground triangles above smaller object triangles. If I test some more cases, I can exchange speed for additional sort accuracy.
SunSailor, your data compression method sounds strange and wonderful and will likely make my head explode. I will have to check it out.
I debated a bit about controls on this one-- with the idea that roll and pitch added extra challenge and maybe added a degree of disorienting realism. I wonder if adding a more simple control option would improve things, however, and let people blow more stuff up with reckless abandon.
Log in to post a comment