ToxicSlurpee posted:

You don't actually need to attach things to a GameObject to use them. You can create classes that do not inherit from MonoBehaviour and then just use them like you would normally in non-Unity C# projects. You need to do that to interact directly with Unity but that's it. You can, for example, have an object somewhere in the ether that does those things but never directly interacts with Unity itself.

The file full of enums just needs to exist somewhere in the project. Same with any static classes, singletons, and non-MonoBehaviours; they can't interact directly with Unity but stuff that inherits from MonoBehaviour can interact with them. There isn't any special trick; if it's in the C# project you can use it.

xgalaxy posted:

Yep this. I think people new to Unity who are eager to work in the 'Unity way' get confused and start thinking they need to make everything MonoBehaviours. You do not, and most likely should not, do that. In fact try and make as few MonoBehaviours as possible, IMO.

HaB posted:

Right I get all that - what I don't get is how do I get that stuff into Unity itself?

Like, say I create some sort of class that's a UnitSelectionManager. Where do I attach that so Unity can get at it? Same thing with a file full of enums. Is there some directory or something Unity will just parse all scripts in that directory? I understand how to write the code, I'm just not sure how to get it to play with Unity.

Do I create something like an empty GameObject for Player and attach scripts to it? Since I know that object will always be there?

leper khan posted:

Unity is c# (3.5 subset). A bunch of the stuff I do is written in DLLs without using any unity classes or notions. Some object will hold a reference to that stuff somewhere, but it's largely unimportant. It's built and tested (nunit) independently.

Similarly, games aren't really that different from other programming projects. Beyond purposefully being contorted into an infinite loop. Or having pretty pictures. Many non-games applications are similarly contorted though.

If you know how to solve a problem outside of the unity context (and it isn't reliant on unity's graphics or physics pipelines, etc) you know how to solve the same problem in the unity context.

Mechanically, at some point you'll need some MonoBehaviour that either implements or holds a reference to whatever functionality you're trying to present. Anything you want to use in the editor (and not in the game) should be in a folder named Editor. I usually keep all code in Assets/Scripts and DLLs in Assets/Plugins, but I don't remember offhand if those directory names are magical (some, like aforementioned Editor or StreamingAssets, are).

Sorry if any of that comes off as being short. I'm supposed to give a related presentation at work, but the concept of understanding c# but being absolutely blank on how to approach a problem in unity is foreign to the way I think about the platform. From my perspective it's just writing archaic c# (all the good stuff came in .net4 ) to frobnicate some state or call some API or w/e. I've probably just internalized enough of the weird things though. Eg, don't create/use constructors for MonoBehaviours.


What unity actually does under the hood is a little weird with the way their introspection works. It's probably not very important to dive into that stuff right off the bat, but remember that Update/Awake/OnStart/etc can be private and will still be called by the engine the way you would want them to. And don't declare them if they're empty.

Lork posted:

Edit: I reread your post and saw that SelectionCircle isn't the name of one of your scripts. If you want to get anywhere you'll need to answer the following questions: 1. What do you intend to do with your reference to "SelectionCircle". and 2. Which gameobject is your Selectable script attached to?

HaB posted:

1: I intend to call .SetActive on it, as needed

2: Selectable is attached to UnitPrefab. SelectionCircle is a child object of UnitPrefab

Lork posted:

Ok, so to clarify things, GameObjects are not components, rather they are the things that house components. Components are scripts that inherit from MonoBehaviour, such as your Selectable. GetComponent won't help you find SelectionCircle because it's just a name you gave one of your GameObjects, not the name of a component.

There are a number of ways to get a reference to a GameObject and which one is most appropriate depends on context and personal preference. One way to do it would be to use Transform.Find(), like so:

code:

Transform circleTrans = transform.Find("SelectionCircle"); //Note the lower case "transform".  This is a cached reference to the Transform component on the same GameObject as your script.
GameObject circleGO = circleTrans.gameObject //Also note that it returned a Transform component.  Luckily all components also have a reference to the GameObject housing them in .gameObject

Since the thing you need a reference to is contained within your prefab, another way to do it would be to make your selectionCircle variable public or put the [SerializeField] attribute over it. This will expose it to the Unity inspector (the right side panel in the Unity editor by default) and you can then drag the child object into it, saving the reference as part of the prefab.

HaB posted:

Kaaaaaay....got another question.

I have created a prefab to render a circle on the ground around selected units. It's a projector and a material. it is a child object of my unit prefab.

My objects are laid out like this:

code:

UnitPrefab
    UnitHead
    UnitBody
    SelectionCircle

(all of the above are GameObjects )
    Selectable
    Unit

(these are both scripts)

Inside of Selectable.cs I am trying to get a reference to the SelectionCircle, but I can't seem to figure out how. The error is that the type or namespace can't be found.

I have tried every combo of the following so far:

code:

private gameObject selectionCircle;
// OR
private SelectionCircle selectionCircle;

void Start() {
	selectionCircle = gameObject.GetComponent<SelectionCircle> ();
	// OR
	selectionCircle = gameObject.GetComponentInParent<SelectionCircle> ();
}

What am I missing?

Tiler Kiwi posted:

ah man, I completed the C# tutorial on pluralsight and was feeling pretty stoked about trying to implement some of what id "learned", then I check out a simple message bus sort of system just to see if I could implement it for good practice for my super simple first prototype thing and man I have only half a clue what it is doing.

whenever i step away from some regimented tutorial i feel like im stepping into some terrible void. got a ways to go still.

leper khan posted:

Selectable is probably a bad name for a class, as it's the unity type for buttons/toggles/etc. since you have this as a prefab, you don't even need to use GetComponent. Just declare the thing like:

code:

[SerializeField]
private SelectionCircle selectionCircle;

Then drag your selection circle onto that in the editor and you can use it as if the reference has been set up correctly (because it has).

leper khan posted:

Try breaking the problem down into parts. Recurse on the process until you feel like everything listed is already too easy to have bothered splitting up. Do this on paper. Then code it up.

If you're unsure what it's supposed to do, you'll neither be able to break it down or implement it, so maybe read more docs on the concept you're trying to implement.

Tiler Kiwi posted:

HaB posted:

Ah. Didn't know that about the class name. Will rename to SelectableUnit.

Thanks. I ended up using SerializeField. Didn't like the idea of transform.find - which seems like a weird way to do it. Mostly in the sense that I'm not dealing at all with transforms right now, so it seems odd to use them to try and find an object. SerializeField makes way more sense in my use case.

Thanks again.

Pollyanna posted:

Do managers, services, god objects, etc. just get added to the top actor level in a scene? Or do they have/need a special place?

Explosive Tampons posted:

Someone please tell me of an easy, reliable way of debugging OpenGL applications please

nSight keeps telling me "Non-generated name detected. Using names that aren't generated with glGen* blablablabl" but I have exactly 4 textures, both generated with glGenTextures(2, arrayname). It says that the offending thing is "Type: Texture. Name: 4". WTF. Am I screwing something up here? It works normally without nSight messing with it. (My videocard isn't really compatible with nSight (it's just a meager 950m) but I'm not sure if I should disregard the message or not.)

gDebugger is very unreliable and I cannot do breakpoints (both because my video adapter is not AMD, I guess). Texture view never has the right textures and I was sure it was a problem on my end until I decided to draw all of them in an easy to view way in my app's viewport. (my textures are all for post-processing purposes and only a composite framebuffer is displayed).

goddammit

Explosive Tampons posted:

Someone please tell me of an easy, reliable way of debugging OpenGL applications please

Suspicious Dish posted:

opengl and opengl debugging sucks

Pollyanna posted:

Do managers, services, god objects, etc. just get added to the top actor level in a scene? Or do they have/need a special place?

leper khan posted:

Friendly reminder that you should carefully evaluate whether you actually want global state/singleton. In nearly every case you do not.

FuzzySlippers posted:

Isn't this where indie game dev and big software development truisms collide?

Large projects with many developers with years of expected maintenance: global state and singletons not so good.

1 programmer (or a couple) with little maintenance: global state and singletons good.

Unormal posted:

Counterpoint: Global state and singletons are great.

leper khan posted:

Countercounterpoint: until they aren't.

I'm not saying they don't have valid use cases, but I've also spent weeks tearing poo poo apart to put it back together because some idiot didn't know how to not use a singleton.

You can, and probably should, have control of your application split among several classes, each responsible generally for some (single) thing. Most of those should probably not be singletons. These aren't earth shattering ideas.

You probably don't want your popups to be singletons. Or your menus. Or the type that you've implemented for some type of drop down menu. Or your game screens. Or...

Unormal posted:

Those things are all true and there are still a vast amount of cases where global state and singletons are the right design choice for any particular scope and project. If you want to be the best engineer you can be, learn to love every pattern out there. They all find a place. Telling people to never or always do something is usually just flat wrong.

The only really important maxim is to ask yourself why you're doing something, if it helps you reach your goal, and if there's something that does a better job meeting your particular requirements. Engineering driven requirements are nice, but if you're making games you're not shipping engineering you're shipping games.

Bongo Bill posted:

Globals are bad.

A correctly-implemented singleton incorporates all of the possible benefits of a global, while avoiding the unnecessary drawbacks. The necessary ones are still present, of course.

Singletons make sense to represent resources that correspond one-to-one with the number of processes that you are running. Games, especially small games, have many such resources.

Try it a little something like this. Use it responsibly. I recommend that you not access the singleton at all inside of constructors. Have the singleton instantiate dependencies, but inject those dependencies as arguments to constructors as normal.

code:

// src/Interface/IMySingleton.cs
public interface IMySingleton
{
    void SomeGlobalBehavior();
    int SomeGlobalProperty { get; set; }
    // ...
}

// src/Implementation/MySingleton.cs
public class MySingleton : IMySingleton
{
    public static IMySingleton Singleton
    {
        get { return GetInstance(); }
        set { _Instance = value; }
    }
    
    private static IMySingleton _Instance;

    private static IMySingleton Instance()
    {
        if (_Instance == null)
        {
            _Instance = new MySingleton();
        }

        return _Instance;
    }

    public MySingleton()
    {
        // ...
    }

    public void SomeGlobalBehavior()
    {
        // ...
    }

    // ...
}

// test/Mocks/MyMockSingleton.cs
public class MyMockSingleton : IMySingleton
{
    // ...
}

// test/TestInitializer.cs

// ...
void InitializeTests()
{
    MySingleton.Singleton = new MyMockSingleton();
}

leper khan posted:

You missed the incredibly important test that instantiation of two of the things returns the same thing instead of two disparate ones. You'd also want to take care in implementation of a singleton that it's thread safe. Basically you should probably avoid writing your own singleton wrapper, as carefully built ones should be available. And if you do need to write one for some reason, use real references not half-put-together fragments from a comedy forum.

leper khan posted:

Countercounterpoint: until they aren't.

I'm not saying they don't have valid use cases, but I've also spent weeks tearing poo poo apart to put it back together because some idiot didn't know how to not use a singleton.

You can, and probably should, have control of your application split among several classes, each responsible generally for some (single) thing. Most of those should probably not be singletons. These aren't earth shattering ideas.

You probably don't want your popups to be singletons. Or your menus. Or the type that you've implemented for some type of drop down menu. Or your game screens. Or...

Slurps Mad Rips posted:

I'm having flashbacks to Hellfucker ruining the UI state and loving up my singletons for events on that defunct mobile game we both worked on, thanks.

leper khan posted:

I legit got mad because dude was a senior developer. I'll let you figure out which the applies to (it's both). But I guess in games that just means you either have experience, or that you've been around awhile but are too incompetent to get a job in a more lucrative industry. If the dude couldn't find or coerce working code to what he needed to do out of SO, he reported back that it was impossible or took like a month per 100 LOC.

quote:

If the dude couldn't find or coerce working code to what he needed to do out of SO, he reported back that it was impossible or took like a month per 100 LOC.

quote:

Stay in school. It's safe there, and research is rad.

Pollyanna posted:

Counterpoint: grad and postgrad work is a hellscape of slave labor, stupid drama, and awful pay. Please don't do a grad school.

Pollyanna posted:

Okay okay wait. The use case I'm thinking of is creating object Managers/Systems that associate object update code with the objects that they are meant to operate upon, and registering certain objects/prefabs with particular tags that allow them to be picked up by the Managers/Systems. Kind of a hacky lovely version of the Entity-Component Systems architecture. There has to be a place for those Managers/Systems to live.

I hate global state as much as anyone else, lord knows I've beat my head against the wall trying to get a fully FP-functional, immutable data structure-driven game working, but since Unity is based on C# which is a heavily OOP-oriented language then constructs like these become the alternative. Until comes the day that a game engine backed by functional programming comes into existence (and if it ever does it will be written by John Carmack), this is the best option I can think of.

edit: Singletons are good for encapsulating behavior, but you don't want to use them to encapsulate state. Having global state is where poo poo goes wrong, but having an object that does nothing but query for and operate upon a list of other objects isn't that bad.

That said, I am piss-awful at OOP (and FP to be honest) so maybe don't take my advice