Better object referencing than drag and dropping GameObjects to components?

Since you invoked a great quote, I'll share my favorite... "If you don't have time to do it right, when will you have time to do it over?"
I fully agree with what you guys are saying. Dealing in absolutes and fixed approaches is contrary to what engineering is. It's about finding an optimal solution for the situation. Abstracting a pattern to create a generic, reusable system can ultimately end up being more simple than bashing something together and rewriting it 5 times in 10 places. We call them "freebies" when something was built well enough that it can serve a purpose that it wasn't directly planned for it. It's all about balance. Holding up an extreme unrelated example like "astronaut architect" sounds more like a way to justify not thinking things through and planning. "Why did you refactor that same thing a dozen times?" ... "Astronaut architects!" You can easily over complicate or over simplify, its all about finding the sweet spot.

---

As far as the main topic goes, our approach is a bit different. Our games are fairly large in scope and very dynamic, and possibly because most us are used to working on games of that nature on other platforms, we approach it same way in unity.

Our main/only scene is empty apart from one gameObject that has one script attached to it. That script starts the engine and everything from that point forward is loaded dynamically. Because everything is invoked by some part of the engine, There is no need to "find" things in the game, no editor hookups to be broken (well, it is possible at the asset level, but rare because they validated in a sandbox before they get that far). Everything, generally speaking, knows only about the things it needs to know about, or if it conditionally may need to know about something, we have a sort of directory service that keeps track of transient elements.

The devs that built this framework have been working on it for a couple of years, and it is pretty elegant. It's a bit different from the typical way one would build in Unity (I still love to slap things together on the stage and wire them up), but it works really well. One of the biggest benefits is that a large team can all work on the same project easily. There are times where it does feel a little constrained, but it is well worth it.

That is one of the things that I have really grown to love about Unity, it is flexible enough for quick prototypes, a variety of game types, one dev projects up to large studios.

 

I think I'd really enjoy working with you.

As for the way your team does stuff, how do you feel that fits with regards to using Unity as opposed to other toolsets?

To me Unity's strengths are a) cross-platform deployment and b) generic bare-bones Editor that handles all the basics and allows straightforward customisation for a project. In other words, they're both about out-of-the-box productivity.

It sounds kind of like you're re-rolling most of b for yourselves, and if they're mobile only titles (are they?) a might noir be such a big deal in that I'm sure there's plenty of options around. So what are the major benefits you guys are getting from Unity, if you're able to share?

 

For one.. use [SerializeField] private when you don't have to access the property from another class.