Shrugger! Unity!

[Draco18s]

Yea, my tendency towards "private" was in the context of writing code that's entirely internal to Arcen.

If I ever write library code again, many things will need to be different   Though there I would probably expose it through getter/setter stuff.

Well yeah.  The way you're doing stuff is completely reasonable.  Mojang wrote their code in a perfectly reasonable fashion.  I was just complainging about the Forge guys who are supposed to be making an API...and finalizing a method of the API for no reason other than "because it was final in Mojang's code."

I.e. "made the field private because they weren't creative enough to envision my use case."

[keith.lamothe]

I.e. "made the field private because they weren't creative enough to envision my use case."

Sounds like it's time for Velociraptor Creativity Camp: where Velociraptors teach you to be creative... or lunch.

[Draco18s]

I.e. "made the field private because they weren't creative enough to envision my use case."

Sounds like it's time for Velociraptor Creativity Camp: where Velociraptors teach you to be creative... or lunch.

You haven't been seeing the comments on the project about delivery, have you? >..>

OMG SO COMPLICATED WHY DO WE HAVE TO DO IT THIS WAY!?!?!?!!!!1
1 minute later:
Oh, I should have read the whole thing.  That was really easy.

[Shrugging Khan]

So I've been playing around with celestial bodies. I got the sun to be visible from 1 AU away, but trying to make the spaceships and planets do a little gravitational dance just made unity choke and die on floats by the power of eleven. Apparently, Unity is really, really, really really really bad at distances greater than about a thousand kilometres or so, with physical forces going haywire and the camera throwing errors all over the place.

Can anyone tell me some tricks to keep distances and scales realistic? I tried to just shrink everything by a factor of one million, but that gave me the opposite problem of meshes not rendering correctly anymore and the camera being unable to zoom in close enough without producing clipping errors or just not displaying things anymore. Even shrinking things by 1000 caused these problems, and dividing all sizes and distances by 100 just seemed insufficient.

By now my most promising solution is to scrap the solar system and go for something more manageable - a dwarf planet or a modest asteroid perhaps. But that's really not a solution so much as surrender, so I'd be rather happy if there were some way to make things work.

Any ideas?

PS: I've also considered making the sun and planets rotate around the centre of the game area in such a way as to simulate proper movement, but I don't really know how one would do that.

[keith.lamothe]

If you want to model realistic astrophysics, even for a single star system and even in simplified form, you're probably going to have to do that yourself rather than relying on the Unity physics model.  Unity's model is meant for game environments, not, well, _real_ environments   It would similarly choke on simulating a single room if you actually got down to the molecular level.  Or even substantially coarser than that.

So once your model is telling you where things should be, you then hand the "executive summary" (that is, the minimum "what should I show the player?") of the info to Unity via rendering calls.  So it remains blissfully unaware of the utter insanity you're actually doing, and doesn't throw errors

[Shrugging Khan]

Well, if I'm going to have to trick Unity, then why use it in the first place? xP

Kidding, of course...I was hoping it might be possible to bludgeon Unity into doing what I want without too much trouble; but given that I'm just trying to make something fun for my little brother at the moment, I'll put homemade astrophysics simulations off for some later date.

I'll keep your suggested approach in mind for later, though. I DO want my pretty little orbits, some day!

PS: Just for curiosity's sake; do you mean that the way to go about the simulation would be to do everything according to proper mathematical formulas without involving Unity physics in the first place, or something else?

[Draco18s]

http://www.youtube.com/watch?v=8Z1fhClypjg

[keith.lamothe]

Well, if I'm going to have to trick Unity, then why use it in the first place? xP

You. Have. No. Idea.

A sizeable portion of my last 2-3 years is bound up in that question.

PS: Just for curiosity's sake; do you mean that the way to go about the simulation would be to do everything according to proper mathematical formulas without involving Unity physics in the first place, or something else?

Basically just do the math yourself, yea.  You'll probably want to use a lot of simplifications and approximations even there.  Even just the bare metal of the processor (no engine-based, or OS-based, or whatever tomfoolery at all) isn't going to do millions of square-root operations per second (iirc).

[Draco18s]

Well, if I'm going to have to trick Unity, then why use it in the first place? xP

You. Have. No. Idea.

A sizeable portion of my last 2-3 years is bound up in that question.

And that, dear friends, is how new engines are born.

[keith.lamothe]

And that, dear friends, is how new engines are born.

When Unity got to the point where we could produce a viable linux port from an existing game in less than 24 hours (on the first try) I softened a bit.

And in general it's getting better over time.

But we definitely do "our own thing" and forget the engine at least 90% of the time.


You can generally count on the engine to do well those things which the engine developers had in mind.  The rest you have to pull out of a hat.  And you have to bring your own hat.

[Shrugging Khan]

Well, you might remember that three months ago I didn't even know that hats were a viable option for headwear. Those hat-making skills are something I've yet to acquire 

But now I really have to ask; what parts of Unity, other than drawmesh, are you actually using?


Edit: With the planet scaled down to 1km in diameter and weighing in around 8000 tons, as well as the gravitational constant multiplied by 10^13, I've been able to get something resembling reasonable orbits. The frame rate goes down the loo whenever one of the spaceships orbits too far from the planet, though (around 60 fps when everyone is within 10 kilometres, 30 when someone approaches 25km, under 10 FPS when a single ship goes beyond 80km).

Now, I've scripted it so that anyone more than 25km from gets deleted from the scene, and everyone draws TrailRenderers. Well, surprisingly enough, all the ships were gone within 20 minutes, with their trails presenting spiral patterns. Seems like they spiralled further and further out as they orbited!

If anyone here has some knowledge of orbital physics, or perhaps a few more hours of Kerbal Space experience than me, could you explain to me WTF is happening there? Is this some quirk of Unity's physics, or have I actually messed this one up myself?

[Draco18s]

If anyone here has some knowledge of orbital physics, or perhaps a few more hours of Kerbal Space experience than me, could you explain to me WTF is happening there? Is this some quirk of Unity's physics, or have I actually messed this one up myself?

http://what-if.xkcd.com/68/

[keith.lamothe]

But now I really have to ask; what parts of Unity, other than drawmesh, are you actually using?

Er, well, not much really. 

Input for keyboard and mouse (sometimes Event for the mouse; there are times when one is more accurate than the other). 

We still use OnGUI for the Textbox (until we get around to making our own textbox, anyhow) but we replaced all our other GUI calls with our own stuff (using normal rendering and input handling, because Unity's GUI stuff is loony in a few respects, especially with more than 2 "layers" on the screen at once). 

The primitives for sound playback.

File I/O for getting the textures and music off disk.  Most of the sounds themselves we actually use Unity's baked-in-asset approach to avoid having to load those sounds off disk every single time we want to play them.

Can't think of anything else off the top of my head, actually.  Though Chris did more of the engine-level interactions.

as well as the gravitational constant multiplied by 10^13

What could go wrong?

[Draco18s]

We still use OnGUI for the Textbox (until we get around to making our own textbox, anyhow) but we replaced all our other GUI calls with our own stuff (using normal rendering and input handling, because Unity's GUI stuff is loony in a few respects, especially with more than 2 "layers" on the screen at once). 

The primitives for sound playback.

File I/O for getting the textures and music off disk.  Most of the sounds themselves we actually use Unity's baked-in-asset approach to avoid having to load those sounds off disk every single time we want to play them.

Start releasing those as plugins the rest of us can have
At like $5-20 there will be a lot of small time developers that would jump at it.  Most GUI systems available that aren't Unity's native are like $100+  (even iGUI Basic--which is just a WYSIWYG editor for the native GUI system--is $35!)

File I/O is something that a lot of developers don't even realize Unity can do.  Actually directed someone your way just the other week about this (they hadn't even realized AI War was built in Unity )

[keith.lamothe]

As I mentioned elsewhere, we really _don't_ follow even the basic-sanity rules for library coding, because we aren't coding libraries   Much of it is reasonably modular, but documentation is extremely rare (aside from very clear symbol names, which are largely self-documenting) and much of the code relies on programmer knowledge and self-discipline to not cause massive problems.

It's a lot like a lumber mill built by two guys with nearly 0% concern for safety.  5-foot-radius sawblades spinning at maximum speed hanging from minimum-strength supports in the middle of an empty room with no safety shields and raw wood being thrown at them by various devices.  You could call it "efficient", you could call it "horrifying".

So we'd never really be able to sell it, in good conscience, unless we took the time to really rewrite a lot of it.  And frankly that time is more profitably spent writing more games

That said, we're quite happy to share our techniques and such for getting Unity to cooperate.  No need for others to suffer the same way

THAT said, often someone else's needs will differ so much from ours that looking at our approach may actually slow them down, particularly if they try to run with it until they hit a wall.