next »

[karlin]

Ah, some news ! Good to see that you are still developping it.

Thanks, glad to see you're still around.  

Oh man, this looks interesting. Space-themed RTS that is not focused on war? Count me in!

I like how empty space looks... but have you thought of making it even emptier?

Great find, really makes you appreciate the vastness of space. I might have a play with scale once I get the main game down as things start to look a little squished when you zoom right out.

I love the graphical style, well done

Thanks, I just saw your game sOlar, looks great did you ever do any more work on it?


Did lots of work on the ship interface this week. It took quite a lot of time as I couldn't quite decide how it would work. I managed to get it all working this evening, the ui is still a wip.

I still need to do a small amount of work on the ship code, the bulk of it's there. I just need to add the ability to load cargo & passengers, as well as the code for the mining ships, probes etc. I also have a bit more ui work to do , mostly getting scrollbars working for the ship and building list.

[barley]

Thanks, I just saw your game sOlar, looks great did you ever do any more work on it?

Nah, with Cloudface and other stuff I didn't really get a chance to do more actual work on it. I've got some ideas for it, though, so it'll probably be the next thing I work on!

Good luck with Icarus, I'm looking forward to trying it out.

[JobLeonard]

Oh man, this looks interesting. Space-themed RTS that is not focused on war? Count me in!

I like how empty space looks... but have you thought of making it even emptier?

Great find, really makes you appreciate the vastness of space. I might have a play with scale once I get the main game down as things start to look a little squished when you zoom right out.

If you make the game to scale (while designing the UI in such a way that this is not a problem) then every astronomer everywhere will love you forever.

[karlin]

I've been a little slow with the updates again but I'm still making steady progress . In my last post I was working on the UI and it's turned out to be a tad more complicated than I'd hoped. I've now got the main elements down - buttons, windows and dialogue windows. Just need to add textboxes and dropdowns and then all the UI work should be done.

Performance is a lot better now as offscreen drawing is now properly managed, gives a 2-3x performance boost which meant the star map could be added back in. I still need to add in more stars and populate their systems.

I did some more work on the asteroids. These can be mined by ships and their resources can then be sent back to colonised planets. Rogue asteroids may also spawn here and collide with planets.

Made some changed to how planets look:

A few smaller things which are now in the game:

• Ships now move between planets in a smooth curve instead of going directly to a planet (they no longer fly directly into stars)
• Ships now display their arrival time.
• Planets now orbit at the correct speed following Kepler's Laws.
• Stars now change colour as they expand - still need to add stellar classes.
• A few other stuff I've forgotten .

Oh man, this looks interesting. Space-themed RTS that is not focused on war? Count me in!

I like how empty space looks... but have you thought of making it even emptier?

Great find, really makes you appreciate the vastness of space. I might have a play with scale once I get the main game down as things start to look a little squished when you zoom right out.

If you make the game to scale (while designing the UI in such a way that this is not a problem) then every astronomer everywhere will love you forever.

Sorry for taking so long to respond. I get weird distortions like this when using too large a scale, but it should be possible to have a small star system to scale. I'll release it as a "map" when the game is done .

[JobLeonard]

Woah, how does that happen? Rounding errors?

[flap]

Woah, how does that happen? Rounding errors?

Karlin explained that it was for large maps. So I guess that some numbers somwhere in unity engine get too big : For example, if your number is stored in 1 byte, the max value is 255. If you add 1, then it goes back to 0. So, the steps you see in the picture probably are caused by similar errors of numbers hitting the roof.

[dirak]

Woah, how does that happen? Rounding errors?

Karlin explained that it was for large maps. So I guess that some numbers somwhere in unity engine get too big : For example, if your number is stored in 1 byte, the max value is 255. If you add 1, then it goes back to 0. So, the steps you see in the picture probably are caused by similar errors of numbers hitting the roof.

Couldn't this be fixed by using long integers or some sort of scaling factor? (i.e. how long of a distance one pixel is, which would change based on how far out you've zoomed.)

[JobLeonard]

When it comes to the universe's scales, learn to love the log function.

[karlin]

Woah, how does that happen? Rounding errors?

Karlin explained that it was for large maps. So I guess that some numbers somwhere in unity engine get too big : For example, if your number is stored in 1 byte, the max value is 255. If you add 1, then it goes back to 0. So, the steps you see in the picture probably are caused by similar errors of numbers hitting the roof.

Couldn't this be fixed by using long integers or some sort of scaling factor? (i.e. how long of a distance one pixel is, which would change based on how far out you've zoomed.)

Its being written in GameMaker where I think all variables are stored in the double-precision floating point format but when passed to the graphics card the single precision floating point format is used. From what I understand this causes a loss of precision and the weird bugs I'm seeing.

I'm not sure how I could fix this in GameMaker without resorting to translating every instances' coordinates relative to the center of the screen.

[JobLeonard]

What about, like I suggested, using a log scale (and inverse log on the graphics card to pull out actual scale)?

[karlin]

What about, like I suggested, using a log scale (and inverse log on the graphics card to pull out actual scale)?

I'm kind of new to any sort of graphics programming, so I'm not really sure how to do it. I know there are some transform functions I could use which might actually make the whole game a lot simpler and probably faster.

Currently every orbiting body in the game has 6 position variables - there's:

• oTime - the time of the orbit in degrees
• oRadius - the radius of the orbit in pixels
• x - an instances real x value without scaling (calculated by using parent.x + oRadius * cos(oTime)
• y - an instances real y value without scaling (calculated by using parent.y + oRadius * sin(oTime)
• zX - the zoomed x value (calculated with (parent.zX + oRadius * cos(oTime) * zoomLevel)
• zY - the zoomed y value (calculated with (parent.zX + oRadius * sin(oTime) * zoomLevel)

I'm guessing if I can use the transform functions I could just get rid of the zX and zY variables hopefully getting a speed boost.
Anyone who uses GameMaker know if it's possible to apply the d3d_transform functions to every instance without having to have d3d_transform_set_identity() in every draw event (which I've read is very slow)?

[JobLeonard]

Wait, you're using CIRCULAR ORBITS?!

Nah, just kidding, it's fine. This isn't trying to be a Universal Sandbox-style simulation. But if you do want to give gravity simulation a go: Leapfrog Integration is the way to go. Relatively simple to code, conserves energy, and long-term errors average out to zero. Here's a 2006 super-old school javascript demo

Could you give a summary of how you implement the "simulationy" aspects right now? You probably want to minimise conversion of data between CPU/GPU. I'm sure people here (maybe even me - not that good a programmer but I have some experience with physics simulations) can help with suggesting the optimal way to code what you're aiming for, from a high-level perspective.

[JobLeonard]

Ok, this is just a little math history lesson, and also demonstrates why log functions aren't the solution here

Log functions are kinda funny, and almost nobody these days seems to know what their original purpose was, and therefore people don't realise when they can be used. The main thing is that you can do this with log functions:

log(A * B) = log(A) + log(B)

Ok, so? Big deal. Well, back before we had calculators, if A and B were very big, calculating a lot of them that by hand was a really slow, tedious and error-prone process. But let's say you have a quick way to calculate the logarithm and inverse logarithm. Watch this. We want to calculate C:

A * B = C

So we take the log of A, log of B, add them together:

log(A) + log(B) = log(A*B) = log(C)

So... inverse the last log, and you have C!

log^-1(log(A) + log(B)) = C

This is how logarithms were originally used: in mathematical tables, which were the paper versions of lookup tables, to quickly compute large multiplications. You had one table which told you the logarithmic value of a number, and one which told you the inverse logarithmic value. So you look up two logarithmic values in the first, add them, then look up the original value in the second. Done!

Anyway, how could this be used in games? Answer: not really. You see, floating point arithmetic has this funny property that multiplication introduces only a tiny error, but addition can introduce a big one. Looking at this part of you code:

parent.zX + oRadius * cos(oTime) * zoomLevel

It stands to reason to assume that for big values of oRadius * zoomLevel the addition might break down (note: if it's all calculated in doubles and then converted to GPU floats it should be less of an issue, since it is much less of a problem with doubles). Log functions don't help here.

[JobLeonard]

(sorry for the triple post)

... so, with that in mind, perhaps a "proper" gravity simulation is the way to go. It also has the added bonus that you can get elliptical orbits that change velocity depending on how close they are to the Sun!

I wrote "proper" in quotes because it looks you only care about how the Sun's gravity affects everything around it, since you're currently using sine/cosine for orbits. Again, perfectly fine - keeps things relatively simple and fast. Here's a gamedev.stackexhange explanation of the leapfrog method, probably easier to wrap your head around than the other links I shared.

[karlin]

Wait, you're using CIRCULAR ORBITS?!

Nah, just kidding, it's fine. This isn't trying to be a Universal Sandbox-style simulation. But if you do want to give gravity simulation a go: Leapfrog Integration is the way to go. Relatively simple to code, conserves energy, and long-term errors average out to zero. Here's a 2006 super-old school javascript demo

Could you give a summary of how you implement the "simulationy" aspects right now? You probably want to minimise conversion of data between CPU/GPU. I'm sure people here (maybe even me - not that good a programmer but I have some experience with physics simulations) can help with suggesting the optimal way to code what you're aiming for, from a high-level perspective.

There's not really a whole lot being simulated besides the orbits. I would love to simulate the star system using real gravity but I'm a little worried about a couple of things - namely performance, ensuring orbits remain relatively stable and I suppose the thought of potentially having to rewrite a lot of my code.
One of my original prototypes had a very simple gravitational simulation (still on-rails) where moons would switch to another planet if it was closer or if it's parent planet was destroyed. Sadly I didn't have time to get it working particularly well within the 1 week deadline so I had to scrap it.

I suppose it would be possible to keep the planets / stars / moons using the sin / cosine method while asteroids & comets use the leapfrog method you posted? Might make for some interesting gameplay mechanics.

Ok, this is just a little math history lesson, and also demonstrates why log functions aren't the solution here

Log functions are kinda funny, and almost nobody these days seems to know what their original purpose was, and therefore people don't realise when they can be used. The main thing is that you can do this with log functions:

log(A * B) = log(A) + log(B)

Ok, so? Big deal. Well, back before we had calculators, if A and B were very big, calculating a lot of them that by hand was a really slow, tedious and error-prone process. But let's say you have a quick way to calculate the logarithm and inverse logarithm. Watch this. We want to calculate C:

A * B = C

So we take the log of A, log of B, add them together:

log(A) + log(B) = log(A*B) = log(C)

So... inverse the last log, and you have C!

log^-1(log(A) + log(B)) = C

This is how logarithms were originally used: in mathematical tables, which were the paper versions of lookup tables, to quickly compute large multiplications. You had one table which told you the logarithmic value of a number, and one which told you the inverse logarithmic value. So you look up two logarithmic values in the first, add them, then look up the original value in the second. Done!

Anyway, how could this be used in games? Answer: not really. You see, floating point arithmetic has this funny property that multiplication introduces only a tiny error, but addition can introduce a big one. Looking at this part of you code:

parent.zX + oRadius * cos(oTime) * zoomLevel

It stands to reason to assume that for big values of oRadius * zoomLevel the addition might break down (note: if it's all calculated in doubles and then converted to GPU floats it should be less of an issue, since it is much less of a problem with doubles). Log functions don't help here.

I watched an interesting talk by David Braben yesterday where he was discussing some of the tech used to get the original Elite running on the BBC Micro. Quite astounding to see what they managed to do on early 1980s hardware. In Elite a 256 byte lookup table containing logarithms was used in order to increase mutiply and divide performance by around 10x. He's an incredibly talented programmer and it's well worth a watch if you have any interest in programming http://www.gdcvault.com/play/1014628/Classic-Game-Postmortem.

(sorry for the triple post)

... so, with that in mind, perhaps a "proper" gravity simulation is the way to go. It also has the added bonus that you can get elliptical orbits that change velocity depending on how close they are to the Sun!

I wrote "proper" in quotes because it looks you only care about how the Sun's gravity affects everything around it, since you're currently using sine/cosine for orbits. Again, perfectly fine - keeps things relatively simple and fast. Here's a gamedev.stackexhange explanation of the leapfrog method, probably easier to wrap your head around than the other links I shared.

Thanks for the link, I'll try to get something running tomorrow and report back .

[JobLeonard]

One of my original prototypes had a very simple gravitational simulation (still on-rails) where moons would switch to another planet if it was closer or if it's parent planet was destroyed.

Well, the problem there is that everything attracts everything. Also, that's still an issue with cosine/sine orbits, because if a moon orbits empty space that looks ridiculous, no?

An alternative solution that I hinted at would be that you only calculate gravity for the planet. That's also way faster - scales linearly with number of heavenly bodies, not n² or n*log(n).

So, main issue: what if a planet is destroyed? Here's an idea: you could handwave the realism a bit and say "now the moon is in the orbit of the Sun". In fact, you could generalise this: if x orbits y, and y orbits z, and y gets destroyed, x orbits y.

So to do that you could simply make a tree of what orbits what, and when something gets destroyed promote the leaves from the destroyed node to its parent node. So at the root would be the Sun, then planets and asteroids, then moons and other satelites around the planets. That covers most of it, no?

[flap]

That software is doing that kind of gravity simulation (with orbits stable enough to be watched over thousands of years).

I am sure that its author would be glad to give all required info. However, I am not sure that it would be that important to implement more reallistic gravity interactions...

[flap]

hey, maybe the falling sun could be a mini game idea for Icarus, or an intro : http://kingdaro.itch.io/the-falling-sun

[Fillipuster]

Is this project still active?