next »

[nova++]

Tonight I got the interstellar navigation GUI working properly. I am pleased to finally be able to say that the core loop of galactic exploration is now in place - you can take off from the surface a planet, jump between planets, jump between stars, and land again. Yay.

Interstellar navigation has proven to be an annoying problem. Who would have guessed that finding a way to let the player select which small dot they want out of an assortment of thousands of small dots would be difficult?

As much as I would have loved to have a classic 3D star map with circles on sticks, that just wasn't working very well. It's really nice to be able to see your trajectory in 3D and rotate around your current point, but when you do that you have to have an unrealistically small number of stars or it becomes very difficult to find your way. Look at the star map in Frontier, for instance:



There are only a small number of stars around, all confined to a relatively flat plane, yet it's already getting a bit messy. To properly execute this method, you need some sort of smart filtering that can automatically show or hide stars based on their expected relevance to how you're presently viewing the map. And that's a serious pain.

So I took a different direction. Instead of a sort of orbiting god-camera, the game instead gives you a first-person, "sensor's-eye-view" of the starfield. In terms of lore, it would be displaying every star that your ship's sensors have detected. (In terms of game mechanics, it's displaying [almost] every star that's actually been loaded [which looks like this from outside, if you're curious])

So what does that look like?



Ok, so we still have work to do. But what's that "Filters" button?

That's what passes for a solution around here

It does exactly what it says. The filter menu lets you sort through this mess of stars presented to you by a few criteria, although distance is the most important one. I think I'd like to have some presets as well, which automatically set the values to ones that correspond to certain types of star. Low mass and low temperature = red dwarf stars, for instance.



Is this the best solution? Probably not. But it is growing on me. In-theme with the way that the system map is a more abstract representation of the solar system you're in, the star map being effectively a literal map of the stars as you can see them creates a disconnect between what the player sees on the map versus what they see with their eyes. And that's a disconnect I find desirable for this game, because if you want to know what things really look like, you have to visit them yourself.

From another angle, the star filtering also feels (at least to me) a bit more like you're actually navigating a spacecraft and carefully selecting a target rather than just throwing a dart at the wall and picking something at random (although you can still totally do that although it's still basically doing that).

Regardless. I'm happy with it for the time being.

[szczm_]

From another angle, the star filtering also feels (at least to me) a bit more like you're actually navigating a spacecraft and carefully selecting a target rather than just throwing a dart at the wall and picking something at random (although you can still totally do that).

While filtering allows you to make the results more readable, it doesn't necessarily make choosing a star a lot more well informed choice. Judging from your screenshot, there are still many unknown variables not displayed in this view, such as planet count, possibility of life etc. Also, since we can safely assume that with robust interstellar travel also came AGI, who's to say you can't ask the AI that's (obviously) controlling the ship to throw a random dart for you?

Amazing progress on this project so far. Although I must say, when I noticed NEW! by the thread's name, and I opened it and noticed the star map from Frontier, I thought for a second you made some bad decisions 

[nova++]

While filtering allows you to make the results more readable, it doesn't necessarily make choosing a star a lot more well informed choice. Judging from your screenshot, there are still many unknown variables not displayed in this view, such as planet count, possibility of life etc. Also, since we can safely assume that with robust interstellar travel also came AGI, who's to say you can't ask the AI that's (obviously) controlling the ship to throw a random dart for you?

Yeah, that's why I said "a bit" 

The amount of information displayed to the player is something I still need to refine. I don't want to "spoil" too much to the player, that is to say I don't want to give too much information in advance. I want to encourage looking into different nooks and crannies to see what's there. Or rather, not discourage it by saying "nope, nothing interesting over there, don't bother"... hmm, when I phrase it like that, it sounds slightly devious.  But maybe you get what I mean. It's a balance that I'll probably be working out for a long time.

[szczm_]

I want to encourage looking into different nooks and crannies to see what's there. Or rather, not discourage it by saying "nope, nothing interesting over there, don't bother"... hmm, when I phrase it like that, it sounds slightly devious.  But maybe you get what I mean. It's a balance that I'll probably be working out for a long time.

I fully understand what you mean. It's an amazing approach too, I must say. If you play your cards well, I think the gameplay is going to be very well driven just by curiosity. Comparing to No Man's Sky and Space Engine, the former's resource farming system overtook the curiosity aspect by a long shot, and in the latter (although I don't wish to diminish it's appeal) I often decided on where to go by curiosity, but it was driven by data ("elliptical galaxy? ternary system with life?") and lots of clicking.

Also, have you ever considered adding alien life? I'm thinking less No Man's Sky, more Fermi paradox.

[nova++]

Also, have you ever considered adding alien life? I'm thinking less No Man's Sky, more Fermi paradox.

If possible, yes, with a chunky asterisk attached to that. The most easily achievable aspect of that is also the most conspicuous. The galaxy you explore was once the site of a grand galactic civilization, which seems to have just packed up and left one day, leaving the odd megastructure here and there to get ravaged by the passages of aeons. Will there be an answer as to why? I honestly don't know yet where I'd want to go with that. It would be nice to have some sort of nonlinear mystery to unravel in that respect, but we'll see where that goes.

For the smaller scale, I would love to have everything ranging from microbial goop to actual animals, although in all likelihood it will stop at trees and tree-like objects, since those are a lot easier to spread all over the terrain and could hijack systems used for rocks and stuff.

I envision the spread of life throughout the galaxy (in both the game, and in my opinion, real life) as being similar to the spread of life on Earth - microbial life ubiquitous, with more advanced forms of life growing more and more rare as complexity grows. Finding a planet with trees would be very attention-grabbing. Although, the fact the old civilization plopped down big domed cities and ringworlds here and there DID skew the nice smooth distribution with a few jarring spikes of additional complexity in places that lacked it before.

[nova++]

Today I set up light colors for different types of stars, which turned out a lot faster and easier than I'd been expecting.

Technically speaking, the color of light emitted from a star falls on the blackbody spectrum, which looks like this:



That is to say, a star of a given temperature corresponds approximately to the appropriate color on this spectrum. However, stars emit a broad spectrum of wavelengths, and the way we perceive light complicates things further. To our eyes/brains, light becomes more washed out the brighter it gets. The light from even a very red star would only appear somewhat orange-tinted, while the disk of the star itself would look more like a bright pale orange/yellow. Look at an incandescent light bulb - that's actually quite a good approximation for a red dwarf star. In addition, the brain can compensate for small changes in light color, further reducing the apparent tint of the sunlight.

Besides the scientific rationale, there's also the actual visuals and artistry to consider, and I've always felt in this regard that subtler is better. The color tint shouldn't be distracting, or so brute-force it starts screwing up your color vision.

Anyway, because I haven't gone all-in on HDR yet, I went with good old fashioned lies and trickery to communicate this in-game. I've just defined a bunch of gradients for different things that require star colors, and retrieve them as needed:



Nice and easy to tweak as needed. And I think the results (which I'm sure you're eager for me to get to) are quite nice thus far:








Who needs f.lux when you can just hang out around red dwarf stars?

[nova++]

I'll have more specific things to write about again soon, but for now have a bit of random sightseeing

[Schrompf]

The panorama windows are absolutely great! I can really see myself redecorating it. And anyone else can, too, through the windows.

Do you have any ideas on how the player could spend her time in this room? Redecorating it carries only for soo long, but I'd also want to spend some time "living" in it after I'm done decorating.

[nova++]

The panorama windows are absolutely great! I can really see myself redecorating it. And anyone else can, too, through the windows.

Do you have any ideas on how the player could spend her time in this room? Redecorating it carries only for soo long, but I'd also want to spend some time "living" in it after I'm done decorating.

I've got a few ideas for that sort of activity... the simplest would be being able to sit on furniture, but I've also long been fond of the idea of being able to collect plant specimens from various planets, and growing them in pots (or under domes if they breathe methane or something). While not a living activity per se, the interior in general would be the staging area for any repairs you need to make, since replacement parts need to come from the replicator.

Perhaps some sillier things too, like brewing space coffee. 

[Schrompf]

Or reading up on entries in the encyclopedia of stuff you discovered. Or talking to an AI which gets new dialogue options every now and then, both progressing and reflecting on the meta story.

[nova++]

I recently realized it's coming up on a year since I started working on ZSpace. I plotted out when I believe I have been doing work on it based on both memories and stuff in my screencaps folder:



(yellow = only a few days of touching it, green = almost the whole month)

This has been hitting me kind of hard. I feel like more should be done.

But maybe some perspective. Is the rate of progress acceptable?

[Schrompf]

Sure. You're doing complex stuff there, handling different coordinate systems to capture both a tiny human and a huge solar system is a huge burden on any game's progress. So don't worry. Or better said: worry more about the actual workload in the future where you need to add all the content you want people to explore.

Procedural generation only carries your game, until players build a mental model of how your generator works. Which is, seeing that the human brain is a great pattern matcher, very soon. From there people stick around as long as they discover new content beyond the generator's means.

[nova++]

worry more about the actual workload in the future where you need to add all the content you want people to explore.

Yeah, way ahead of you on worrying about that...

[nova++]

I never did write about what I meant to.

I recently built the framework for the databank system, which is the core of the discovery mechanic in the game. Effectively, it keeps track of where you've been and what you've seen, and lets you retrieve that information later.

...That doesn't make it sound very impressive, does it? Well, I'm happy with it at least.

When first arriving in the system, your mass scanner picks up the larger objects orbiting the local sun. But that's all you know at first - that there is a mass there. When viewing them in the navigation screen, though, it makes some educated guesses based on mass and a range of density, giving a range of sizes, which it displays to you as a set of circles:



The visual is definitely going to change, but I just wanted to get something together first.

As you encounter/sight the object in different ways, different pieces of information become available to you. Being close enough to an object to see it as more than a point of light gives you a better radius estimate, and getting closer still will refine that. Being within its gravitational field gives you its mass. Entering its atmosphere will give you atmospheric composition data, landing on the surface will give you surface composition, and so on.

Now, how much of this will be automatic and how much will be manual is still something I'm debating. Having it be fully automated removes some busywork for the player, but it perhaps could be confusing to see information just suddenly become available without warning. Automatic for now, though, since that's easier to implement 

The other part of the databank, the interface, has yet to be built. You will be able to go back to any object you've previously discovered, and view all the known information about it, including surface maps if available. While I haven't started making it yet, I do have a mockup of one idea:



Oh, that reminds me. The Alhess name there is just my current generic star designation. Alhess + random number. The idea I am currently working toward, though, is that the galaxy will be divided into numerous standard sectors (or specifically shaped regions based on galactic geometry), each with its own name. As you visit a star in a sector, it will be named "[Sector name] - [Order visited]". So, in the Alhess sector, you'd start at Alhess 1, and count up from there. Moving into a new sector would start the numbering over again with the new sector name, and probably display a popup message informing you you've reached a new sector, accompanied by a cheerful little tune to help you feel excited about this.

Meanwhile... I had hoped to have some pictures of the spacecraft remodel I was doing ready. But I didn't like how it was coming and kind of threw it all out and plan to start over again later. So, another time...

To finish off, here is a picture of me being irresponsible and hanging out in the lounge while the engines run at full throttle through the atmosphere of a gas giant:

[Schrompf]

I love the image. It's great to see you're putting so much thought into this naming and structuring. Although I personally don't care much as long as I can discover some nice places and stories, I'm sure there are people out there who do.

[szczm_]

I also wanted to quickly let you know that, in my opinion, you're doing great and I wouldn't worry so much if I were you. I am judging solely on your messages and screenshots, but your work is coherent, consistent and I always look forward to new updates.

[nova++]

Pebbles!



I've been playing around with shaders some, and came up with this. Still need to make it render shadows, but the gist of it is it's a geometry shader that can procedurally replicate an existing mesh fed to it, and scatter it on the surface of another, arbitrary mesh. This will be perfect for things like pebbles, grass, shrubs, etc.

Edit: And now with shadows and normal maps

[nova++]

Let's talk about the above pictures a little more.

I'm not sure if what I'm doing is the fastest way I could be doing it, but it's been a bit of an adventure nonetheless. To start at the roots - the rocks are generated via a geometry shader. A geometry shader basically intercepts the normal stream that takes the vertex data and sends it to the pixel function, and lets you inject new data into it. In this case, I am using the terrain mesh as a base mesh. Another place I use this is for star sprites - every vertex in the star mesh becomes a four-vertex, two-triangle quad with a star texture on it.

Rocks are obviously going to be trickier. While I could painstakingly map out every vertex of a desired mesh and leave it baked into the shader - which would certainly be faster than what I'm doing - I instead took a bit of a weird shortcut.

Outside of the shader, a template mesh is specified, which is then deconstructed and put into a buffer. The geometry shader is given that buffer, and its size, and then iterates through each vertex on the mesh and reconstitutes it procedurally. This feels so unbelievably hacky that it kind of bothers me that it works.

As for actually scattering them across the mesh - as mentioned, the geometry shader interrupts the original vertex function. You can specify what you want it to operate on, though - individual vertices, triangles, lines, etc. In this case, I chose triangles. Using the vertex index as a seed value for some very simple pseudorandom numbers, random point is selected on the triangle, and that's used as the origin point for rebuilding the mesh template.

This is where things get annoying, though... you are only allowed to have a maximum of 1024 elements being output by the geometry shader. It sounds like a lot at first, but 1 "element" = 1 floating point value. So, a position value is 3 floats, a normal is 3 more floats, etc... and I have other data like texture coordinates and such. The end result is that unless you have a VERY low-definition rock, you can only fit in maybe 2 in the best case scenario before you run out of elements to work with.

Two rocks per triangle is not very many... but then, a damn miracle - I discovered the magic of geometry shader instancing: https://docs.microsoft.com/en-us/windows/desktop/direct3dhlsl/overviews-direct3d-11-hlsl-gs-instance

As simple as that, you can tell it to run the geometry shader multiple times. The instance ID then gets used as a further hashing value for randomization and presto - rocks EVERYWHERE.

...of course, I still feel like I'm doing this in the most roundabout possible way. I'm almost afraid to look for more efficient ways though after having torn so much hair out getting it to work as well as it does now. HOWEVER even if I end up going with something else for rocks, I think this will still be an excellent technique for things like grass, which only need to be a few quads with a transparent mesh. Soon I am going to experiment with other methods of instancing, and will report back with those results.

Hopefully some of that made sense...

[nova++]

Terrain props update:

AUGH. I'm a fool; I'm a damn, damn fool. I became so preoccupied with whether I could, I never stopped to ask myself whether I should. Yes, the geometry shader solution technically works, but I'm doing something graphics cards hate: sequential operations. Every rock mesh it builds has to, one by one, build up every vertex that represents it, and that involves a for loop dozens of elements long. The end result is really bad performance for something GPU-driven. Sure, it's acceptable when there aren't many rocks, and shadows aren't enabled, but turning up the rock count or enabling shadows - ooooh boy, especially enabling shadows - can cause FPS to absolutely tank. Combined with the fact all the mesh data has the element count restriction I mentioned, and this is quickly becoming a problem due to the limited mesh detail you can actually have.

Making matters worse still, I completely forgot to take into account the triangle sizes of the actual terrain, which are much larger than the tiny ones I was testing with. Given I am limited to about one rock per geometry shader pass, then 32 instances of that geometry shader, this is about the density a more realistically sized terrain triangle would give you:



Which is just kinda sad. It's possible to spawn more copies of this mesh and adjust the seed of each one to ensure they're unique, but even when doing this and using proper instancing, performance becomes absolutely unacceptable.

Here, let's go crazy for a second. 50 copies of the scatters.



I would love to be able to properly achieve this density, but I-



Christ in constantinople that's bad.

See, it's probably not obvious, but I know that objectively, for what I am rendering, this is terrible. I have personally seen much higher instance counts of meshes done with different techniques. And those are the techniques I am going to try kicking at soon...

But this also brings back an annoying problem; something I thought I had cleverly tap-danced around with my geometry shader trickery. I'll still have to decide where to place the meshes. Easy enough when working triangle-by-triangle in the geometry shader, but otherwise...

Come to think of it, it might not be so difficult after all. See, the triangles and vertices of every terrain chunk are fixed and known. Yes, the vertices get moved around, but their ordering and the triangles between them never change... bearing that in mind, it should be relatively easy to tell a compute shader to work through the triangle list, access the corresponding vertices, and assign a fixed number of random points per triangle to render objects on...

This might actually work... but we'll have to see.

Deus eleison.

[nova++]

Wow, that was a lot easier than I expected.



I'll write a post mortem tomorrow (ish), but indirect mesh instancing is kind of amazing. But remember that whole thing about only being able to have ~32 objects per triangle in the last post? It doesn't matter anymore. The ground mesh above is only 2 triangles, each one populated with several thousand rocks. I can have as many objects per triangle as I damn well please. The only limit is the actual cost of rendering the additional geometry. And populating the positions has effectively zero impact as well, I can't actually detect any spike from it on the profiler, just the expected drop in FPS from when the rocks start rendering. I say drop, but what I mean is it goes from 1800 FPS to 300-400, so... I'm not too worried.

This is gonna be fun.