next »

[nova++]

Why does it have to be conflict in games? And movies? It's always made me wonder. Why can't it just be a piece of art, without conflict?

That's part of what's motivated three of my major game ideas, of five total (good grief I have too many). None of those three have weaponry or combat (well, one sort of does, but you're skillfully avoiding it rather than engaging).

[szczm_]

Aaaand fixed. In a kind of stupid way. I don't really know what was wrong. But in the end, to paraphrase a long and confusing explanation, I just bypassed the usual Unity light stuff entirely and started feeding it some light position and color data directly, and iterate through them, and that works just fine. It bothers me that I don't know why the simpler method wasn't working, but oh well I guess.



I know it's too early to worry about lens flares and such, but having a simple white orb with no glare to it is kinda bugging me.

So that's what you were talking about. Looks nice. The stars are really far in world space I assume?

Why does it have to be conflict in games? And movies? It's always made me wonder. Why can't it just be a piece of art, without conflict?

That's part of what's motivated three of my major game ideas, of five total (good grief I have too many). None of those three have weaponry or combat (well, one sort of does, but you're skillfully avoiding it rather than engaging).

I always thought about it this way: conflict is us vs them, and a win against them is a success. A win is an end, which is necessary for a finite experience like a movie. Also, many people like a sense of pride and accomplishment, especially if they paid for it.

Exploration games, and games like ZSPACE often neither start in a bad situation nor necessarily conclude in a good way. Sometimes, they don't conclude. They require you to take initiative and find things out yourself, and to enjoy yourself, yourself. But different people like different things and that's why we're in this thread

[Schrompf]

Because players want to have something to do in the game, and conflict is arguably the easiest way to add a game mechanic. But yeah, there's lots of other mechanics, and conflict doesn't need to be there at all. You just need to come up with something else to meaningfully waste the player's time.

[edit] Oh, missed another page of posts.

[nova++]

I've been doing some experiments with stars. It's perhaps a bit early since I haven't even re-implemented the interplanetary hyperdrive yet, but it's a nice distraction for a little bit.

After some tinkering I've come up a system I think will work fairly well. In a nutshell, it works very similarly to the terrain system. Each cubic cell can be subdivided down to a given level, and each level will generate different types of stars. At the highest level, only the brightest red and blue supergiant stars which can be seen from a long distance will dominate, with dimmer and dimmer stars on different levels until the subdivision limit is reached. A similar thing is done in Space Engine - because it works.



Cell and star positions are stored as 32-bit integers, mainly because it's the most reliable way to store them and to allow easy hashing of values to generate seeds for both the population of the cells with stars, and the generation of solar systems from these stars. Presently, these units are completely arbitrary and only really govern the resolution at which individual stars can be placed. It's not terribly important that they have multiple decimal places of precision, so at least for now, 1 unit = 1/100 light year, which should be fine.

Originally I had a pre-made grid of cells covering the galaxy, but I recently changed this to have a set of 27 cells arranged in a 3 x 3 x 3 cube that follows the viewpoint around, which is much more flexible.  I'm still working out the values, but at present, the largest cells are 2^18 (262,144) units in diameter, or 2,621 light years with the previously mentioned values. Thus the "top level" cells occupy a cube of 7,864 x 7,864 x 7,864 light years. The vast majority of visible stars are well within this range (although there are a few exceptions), so it should be plenty of space (ha! ha!). With 7 subdivisions, the final cell dimensions are 2048 x 2048, or 20 light years. A population of a few dozen stars per cell should yield a density similar to our own galaxy, but that's mostly going to be trial and error.

The actual population of stars is handled with what is pretty much a list of prefabs, each with only the most basic data - position, mass, and the star's point in its lifetime. The rest of the real properties of the star are filled in with some simple math that nicely butchers the complicated processes of stellar physics.

Previously, the galaxy was populated with a fixed volumetric map, but I am moving it to a more robust system that allows multiple overlapping shapes, be they based on volume maps or simple primitives. That will let me specify things like star clusters, different frequencies of different star types at different regions, etc. I may also leave that open for modding, in the future.

As for rendering, I finally remembered how to make geometry shaders. Each star is converted to a vertex on a mesh (one mesh per depth level, so you only have to update what parts you need), which is then used to render a quad with a sprite texture on it. It's also supplied with a temperature per star and color lookup table to properly map out realistic star colors for given temperatures.



...the actual fading of stars with distance is something of a sinful cheat for purists, however - they are specifically set to fade out to a radius based on how deep in the tree they are, rather than based on any sort of real luminosity calculations. But probably nobody will notice. Nobody who hasn't read this post anyway. Sorry.

And lastly, I made a scale comparison between (a quick and preliminary painting of) the game's galaxy at ~30,000 ly diameter, and the milky way (or rather, UGC-12158, which closely resembles it) at ~150,000 ly diameter:

[amasinton]

Fascinating game and devlog!  Following.

[nova++]

I finished re-implementing the hyperdrive today (that is to say, it's now back to the state it was before the refactor), but then decided to take it one step further than I did before...



And an exterior view that you'd never really get in-game (save for ONE exception... sorta - when your spacecraft's delivery vehicle deploys you and jumps away, you can see what the drive FX look like from outside)

[Schrompf]

Stylish

[nova++]

Also gave the first post a bit of attention. Some new screenshots mixed with some old. Was going to update the description but it's still pretty much applicable...

[nova++]

I started working on a texture generator for gas giants today. Refreshingly simple after how complex the terrain generator is. This ended up being only two noise samplers, which take a low-resolution gradient input (by low resolution I mean the test textures here are 64x1 pixel) and distort it in a few ways.







There are still some more layers I'd like to add. Obviously some kind of storms, for one thing, but also some more distortion and turbulence to better sell the impression of this being a fluid body. Although in our solar system, only Jupiter really shows off this with its many little eddies and swirls.

[jamesprimate]

i love this concept

[nova++]

There's something big out the window...

Fascinating game and devlog!  Following.

Stylish

i love this concept

I never did reply here... all of this means a lot

[nova++]

Well, I've been so deathly afraid of making the atmosphere shader work with ellipsoidal bodies that I've been putting it off until now. And now that I try it, I found out I can just scale the mesh and it works completely fine. 



I fixed some other problems in it as well, the math for the rim fade was screwy in the old one and would go fully solid instead of fading as you got too far away...

I'm still uncertain, though. A Real(tm) atmosphere shader goes through all the rayleigh and mie scattering formulae per pixel to get proper, realistic atmosphere colors and I'm... not sure how much I want to do that? I kind of like the control of having specific, custom colors for both sky and sunset.

[nova++]

The interior part of the atmosphere shader. I would give more pictures, but the upload speed of my connection has basically dropped to ~1000 bytes per second, and I don't really want to make you all look at 240x160 ultra-compressed JPGs...

Edit: Okay, it seems to be back today. Here's the shader with lighting actually applied

[Schrompf]

Gas giants. CooOOooooooOOool stuff. I still dream about populating those with giant jellyfish-like creatures like the Hyperion / Endymion book series decades ago. But judging from your technical description it sounds like the player is not supposed to visit them too closely.

[nova++]

But judging from your technical description it sounds like the player is not supposed to visit them too closely.

Didn't mean to imply that. I intend to let the player fly down to the cloudtops and under, as deep as they like until their ship implodes from the increasing pressure and heat.

I already have some creepy creaking and groaning sounds picked out.

[Schrompf]

But judging from your technical description it sounds like the player is not supposed to visit them too closely.

Didn't mean to imply that. I intend to let the player fly down to the cloudtops and under, as deep as they like until their ship implodes from the increasing pressure and heat.

I already have some creepy creaking and groaning sounds picked out.

Grrrreat with multiple Rs! Do your stuff!

[nova++]

Distant textures for planets have proven to be something of a can of worms, although with any luck I'll have all those worms back in the can before long.

The present system is the most blunt-force of them all. When the game runs, it generates 2048x2048 texture maps for all bodies (in this context, "2048x2048" means for each of six faces of a cubemap, so six textures per object), and keeps them around until the game stops running. Obviously, doing this for 50+ objects upon arriving at a system would be pretty stupid. GPU compute is extremely fast in the right circumstances, but it's not magic.

The next iteration, then, would be to only generate this map when you're close to a body. Or better yet, step up the resolution as you get closer and closer. And while it's true that that will work, it quickly runs into some problems. First of all is just... generating the textures. Generating one 2048x2048 texture, let alone 4096x4096, from sampled noise quickly enough to have no noticeable stutter is already pushing it. Six at once of either size is painful.

Clearly, we have to spread the generation across multiple frames. The most obvious step is to work on the new textures in the background, generate one face per frame, and then hot-swap the new textures for the old. But we can go further than that.

GPU-computed textures (and, well, GPU-computed anythings) work in parallel - that is to say, every pixel is processed simultaneously, and sent through in whatever order it finishes. That necessitates being able to write to a random location in the texture at any time. But there's no reason we need to write to the whole texture at once. We can write smaller blocks of it, stepping across the texture and building as we go, and do the same swap when it's finished.

Here's a very simple of example of that in action. The compute shader has been told to simply output whatever color it's been given, but it's only updating one 256x256 block of a 4096x4096 texture per frame, then the color is changed, and the process re-run:



I know asynchronous compute can do some of what I'm trying to do, by running it in the background and only updating the texture when finished. But that can be a bit tricky for me because it helps to know exactly when the process is complete, something that's not easy when it's all done GPU-side. Also, unity inexplicably only supports async compute on the PS4. So... there's that too.

But anyway, there's still that second problem.

See, it turns out that actually creating and clearing the texture objects themselves was just as much of a performance hit as generating the texture data. Besides, it's pretty inefficient to keep creating and deleting textures like that...

But now we're figuring it out - we can make "pools" of textures of different sizes, initialize them all on runtime, and, for the price of a fixed video memory footprint (and some sanity-checking logic), instantly access the textures with no slowdown from creating/clearing them. The actual number of textures in the pool is configurable, as are the resolutions of those textures, so it can be adjusted to accommodate however much memory is available.

So... combine all these things, and you have what I've been piling together for the last two days. The prototype works great (I'm so screwed by fate for saying that), and now it's just a matter of integrating it with the game itself. Which entails excising the old distant object system and replacing it with this one. Integrating it will also be further complicated by the fact that planets use two types of texture - a data texture, containing normals and height data, and a lower-resolution color texture. But that's not too bad, the underlying logic is still the same.

I guess I shouldn't leave off without some sort of more interesting picture, so here's one of the working prototypes:

[nova++]

I finally dived into making procedural solar systems. It'll be a while before I can really make a coherent write-up on it because everything's still very much in flux. But here are a few pictures of some procedural bodies in the meantime. I also finally put the star renderer into the game proper.

[nova++]

I finally started going back to the interior interaction. Nothing really to show there so far - all it is is the ability to go between cockpit and lounge and walk around in the latter. Until that changes, here's something else the planet generator spat out - an enormous, rapidly-rotating (day length of ~5 hours) gas giant, twice the size of Jupiter on its widest axis, tilted 90 degrees like Uranus.



I'd love to get some supercomputer time and figure out what the cloud patterns on something like this would really look like...

[nova++]

Yesterday, quite spontaneously, I jumped in and implemented interstellar travel. It doesn't yet have any sort of in-game interface; I have to manually specify the stars that you travel between. But that uses the same input data as the real star map, so it's just a matter of putting together some sort of UI.

Probably half of the work went into the effects, admittedly. It doesn't feel right to run it without something happening, so I went ahead and finished off yesterday with starting the effects, and today I think I've mostly finished them for the time being. Usually I have avoided posting videos because I want to wait until there's sound, but I can't resist this time:




(The destination star isn't visible because of what I mentioned earlier about the stars not being part of the star map)

The implementation of the hyperdrive has kind of gone hand in hand with the lore behind it. It has two "levels" - interplanetary and interstellar. Interplanetary is a fairly rough ride, but is kilometer-accurate. Interstellar is very smooth, but not good for fine targeting due to drift and simple difficulty with targeting at such speeds.

So, as can be seen in the video, the ship first activates the interplanetary drive, then charges up a second time and kicks on the interstellar drive, at which point the ride becomes smooth and serene.

I kind of intentionally have made it analogous to supersonic flight. When getting closer and closer to the speed of sound, an aircraft becomes much rougher and harder to control. But once you've fully passed the sound barrier, it smooths out greatly. The physics behind this are complicated, but this phenomena was I deliberately wanted to emulate. In this case, maybe the ship is passing the local propagation velocity of the tachyonic hyperfield and entering a quantum slipstream that requires far fewer control adjustments by the computer. Or something.