Beef posted:

A good excuse for programmer art if I ever heard one.

"A sphere is obviously the best design, so that's why everything are just circles! Realism!"

OneEightHundred posted:

There is no air, lift, drag, or gravity, you have 6 DOF and can maintain a dead stop with no power, surely that means you can do more than strap a single thruster to the rear end-end and stick some useless fins out of the side!

Shalinor posted:

I kind of liked the Wing Commander explanation: "we designed the jets to mimic atmospheric flight, because the pilots couldn't handle it otherwise,"

yaoi prophet posted:

Doesn't excuse battleships that only have guns on the 'sides' and not the top or bottom.

Beef posted:

Shalinor posted:

I could park an x-wing off the bow of that thing and light you up for hours, and you'd never draw a bead on me

EDIT: Wait, stern. The back part. Stupid nautical words.

... though I guess they probably explain that via shields, which prevent ships from closing to sufficient range as to make shots impossible.

Shalinor posted:

I could park an x-wing off the bow of that thing and light you up for hours, and you'd never draw a bead on me

EDIT: Wait, stern. The back part. Stupid nautical words.

... though I guess they probably explain that via shields, which prevent ships from closing to sufficient range as to make shots impossible.

Above Our Own posted:

Although I also think that in EVE even the smallest craft is much much larger than an X-Wing, because small fighter-class aircraft make little sense in space.

xzzy posted:

Programmers would still find a way to screw it up, give it a low resolution bump map or something.

"What? 128x128 is plenty of pixels."

Shalinor posted:

... instead, I would highly recommend building static singletons that bake out to PlayerPrefs on destruction, and reload from PlayerPrefs on load. All the convenience of a global always-there singleton, but they can actually respond to scene change events in a sane fashion via their usual Awake() method.

Myopic posted:

I always thought the best design for an interplanetary spaceship was a blob on the end of big long stick, with your engine on the other end of said stick (think 2001). Since it's probably nuclear and pumping out fun radiation, you can minimise the size of the shielding by having it only partially cover the reactor and hide the important stuff in the 'shadow' (hence the big long stick). Bonus, it's something even a programmer could model! Plus when you add radiators into the equation it could look like a dragonfly

roomforthetuna posted:

From the point of view of "practical from the outside" that's good thinking, but for "practical from the inside" a ring is good, because you can just spin it to have artificial gravity for the people inside. A disc comprised of multiple rings is even better, because you can have variable artificial gravity - if you want a lot of gravity you go 'down' to the outer rings, if you want no gravity you go to the center. From the outside perspective this is horrible because steering a thing that's spinning would be a huge pain.

A dragonfly with a long body would probably be an annoying place to live and work, a long boring walk from the cockpit to the engine maintenance room.

Pfhreak posted:

So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating?

roomforthetuna posted:

And of course, for a space game context where the ships are almost certainly best designed around combat, both our ideas are stupid because a dragonfly has a huge profile to shoot at and a spinning disc is about as maneuverable as a falling turd. Which brings us back to the sphere!

Pfhreak posted:

So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating?

Shalinor posted:

Just be sure you prefab them out.

Pfhreak posted:

So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating?

Myopic posted:

If I combine your approach with something like this:

code:

public class AdvancedSingleton : MonoBehaviour {

    private static AdvancedSingleton instance = null;
    public static AdvancedSingleton Instance { 
        get {
            if (instance == null)
            {
                Debug.Log("instantiate");
                GameObject go = new GameObject();
                instance = go.AddComponent<AdvancedSingleton>();
                go.name = "singleton";
            }

            return instance; 
        } 
    }
}

(stolen from http://answers.unity3d.com/questions/17916/singletons-with-coroutines.html)

I can avoid even putting a manager object into every scene via the editor, but I still get to use Awake() and the like. Is there a reason this is a bad idea?

Tres Burritos posted:

1) The use of the sine and cosine functions means that the Vector3 class uses radians, correct?

The Cheshire Cat posted:

Well it's not a space game, but since relativity as a game concept was being discussed earlier, here's one that's all about relativity.

Shalinor posted:

Shalinor posted:

If you do that, you're (in effect) encapsulating the singleton in question's Awake() method within whatever first calls to it. You have no idea what that will be (literally - Unity's execution order for Awake()'s on an object can shift each time you save a scene), and it could result in some pretty nasty situations.

What you want to do is use Awake() as a purely internal-to-component setup pass, and only call into other objects - even Singletons - within Start(). This guarantees that everything has the state you expect before you call into it. Given your above approach, you obviously couldn't do that.

Shalinor posted:

I would argue that you do not want GameObjects to persist across scene loads. In practice, it is almost impossible to get such an object to respond to a scene load, which means if it was tracking ANYTHING in-scene, you've now got a lot of pointers in a very weird stare. They don't even invalidate immediately - there's seemingly a window before it realizes the GameObject pointer it had is now bad.

... instead, I would highly recommend building static singletons that bake out to PlayerPrefs on destruction, and reload from PlayerPrefs on load. All the convenience of a global always-there singleton, but they can actually respond to scene change events in a sane fashion via their usual Awake() method.

Just be sure you prefab them out. Nothing sucks more than needing to tweak such a global manager, only to realize each scene has its own version.

Paniolo posted:

So I'm not quite sure I understand how this works. I've seen multiple people suggest having a singleton class that is derived from MonoBehavior and attached to a gameobject, which doesn't make a lot of since since my understanding is that Unity will instantiate that class as part of constructing the game object, and that will be a different instance than the singleton instance constructed within getInstance(). Does Unity have some sort of special case handling for classes with a static getInstance() method, or are these suggestions just insane?

Pfhreak posted:

So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating?

xzzy posted:

It should be the directory you're sitting in when you run the script.

xzzy posted:

It should be the directory you're sitting in when you run the script.

You can add search directories by setting the 'path' variable if that's not convenient for you:

http://www.pyglet.org/doc/api/pyglet.resource-module.html

The Gripper posted:

I'm sure this has been asked and answered a dozen times, but I skimmed the last ~20 or so pages I didn't see anything relevant.

All my previous game development has been either Windows-only (plus Windows Mobile/Xbox, which are basically Windows at their core) so almost all of what I know is deeply rooted in Managed DirectX and related frameworks, and my code isn't particularly portable because of it.

I'm looking to switch to OpenGL or at least dip my feet in the water, but can't find any resources modern enough to commit to reading. I know the fixed function pipeline is deprecated as of 3.3 or thereabouts, and is unavailable in OGL ES 2.0, yet most of the suggested reading material from people saying "OpenGL hasn't changed since 2.1, retard!!!!" (every stackoverflow thread) is strongly based on it, to the point where it's hard to pick out what is required as part of the fixed function pipeline and what is considered more general opengl use.

Given all that, is there any particular resource for documentation that isn't just going to require going through each previous OGL version, or is that a necessity? Popular opinion seems to be "for every version of OpenGL after 2.1 you need to know the fundamentals of the previous version, so we're not going to bother explaining anything".

Browsing through GLSL examples looks useful enough for filtering out ffp-based resources, but honestly I just need a push in the right direction to make sure I don't get too deep into obsoleted tech. I suppose just outright knowing what features/techniques to avoid because they're obsoleted/superseded would be enough to get me on track.