Unity3D workflow

Hi everyone,

since I am new, not only to the community but also Unity3D, this might be a stupid question but how do you keep up with organizing your gameprojects?
I am used to creating games from scratch and organizing everything from a central "main" script file which handles the initialization of the game environment, kicks off the gameloop, loads levels etc..
As I have read here Unity does not work that way and only allows to add to the gameloop through methods like FixedUpdate() but not to rewrite it.

Eventhough I think this is totaly fine because I don`t have to take care of the most basic things like e.g. threading this way, it just feels dirty to me to basically add scripts to gameobjects by hand which contains their own additions to the gameloop.

My first thought was to add an invisible gameobject to each scene which would contain an main script file that takes care of loading, creating, initializing and updating the scene but is this realy the best way to approach this problem?

I would be very thankful for any kind of insight into your own workflow!

Greetings,
Bob

 

If you're trying to fight what Unity does by default every step of the way, you start to lose the benefit the engine provides to you. That said, you're under no obligation to use things straight out of the box, and Unity allows easy customization to suit your own style. It's not uncommon to write traditional classes and instantiate and manage them as needed yourself, without using the built-in Update functions.

There are, understandably, less tutorials out there showing how to work in this manner, since the assumption would be that if you're going against the standard features intentionally, you know what you're doing enough to figure it out.

And while it may feel dirty to just tap into Update as needed across random objects, I don't believe it's any worse than some of the make-it-work things programmers do when trying to brute force their own custom code into existence sometimes, and for your average game I don't think the performance hit would be significant.

 

That's a pretty common approach for more abstract tasks that aren't specific to visible objects in the scene. For example, at work we have one invisible "controller" in every one of our scenes. But as schneider notes, you generally want to do things in the intended way as much as possible, so as often as possible treat objects in the scene as self-contained little robots that have their own brains (ie. an "entity").

 

I meant to mention Singletons, too, and forgot.

 

huh, I'd never heard the term "Toolbox" before (it's in the Warning at the top of that page). That sounds a lot like what we do at work (and I explained in my book Unity in Action), basically a simple variation on the Service Locator pattern. thanks!

That said, I very much agree with that warning message, that Singletons are heavily abused and should probably be avoided. Also their implementation of a Singleton (actually, also their implementation of Toolbox) is pretty overwrought and more complicated than it needs to be.

 

I've referenced that article a dozen times and never noticed the mention of Toolbox at the top. I'm intrigued by them and will investigate further today, time allowing.

I think Singletons get a bad rap because of how badly they can be misused, but I don't think they're inherently any worse than any other practice. But then, I've never had to optimize a program to the point of millisecond efficiency, either.

 

Thank you guys this actually helped a lot.
I understand that using an engine against it`s purpose will do more harm than good and I actually begin to like the way Unity simplifys things ( I come from an unhealthy love/hate relationship with Monogames Content Manager ).
Keeping everything in it`s own little self contained package for example can make debugging a breeze (compared to digging through hundreds of files just to narrow down the source of failure ).

It`s still a lot to get used to but I think I can live with that! Thanks for the link about Singeltons by the way that will definitely be useful.

 

Not necessarily. We have professionals on these forums who do it all the time. They set up an empty scene, throw in one GameObject and attach a script to it and then control everything through code and don't use the actual editor much.

 

Right, that's what I failed to mention. It's one thing to try to write your own Update function, but that doesn't mean you can't just take advantage of Unity's rendering and asset handling and roll your own code other than that. I'm positive the developers of games like Hitman Go and Hearthstone barely make use of the Scene view at all.

I did a nice hybrid for my game. The UI and background were all built with the Scene view, but each scene (Menu and Gameplay) contained an initializing script that handled everything else. The BoardManager handled creation of the board and pieces, movement, and game logic, and my AppManager handled things with setting options, navigation between scenes, music, etc.

So never feel like you should be locking yourself into the way Unity "wants" to do things. It's just a toolset presenting you with options. Use them however you wish!

 

I agree with everything I'm reading above I've been using Unity for about a few years for personal apps and games (just made the move to Sony and Nintendo actually) and in the day time I've been developing using Unity for a medical company as a web-chart style plugin. That said, the way I do it still probably isn't the 'right" way.

... Workflow, for me, depends on the application. But generally speaking for games - I'll have one central GameManager GameObject with a GameManager class. That guy exists as a singleton, and contains references to any other classes I want to use (such as GameSettings).

I then create any helper classes as their own static class in a family.

Code (CodeStructure):

1. GameSettings.cs
2. - Misc
3. | - StringUtils.cs
4. - Elements
5. | - Cars
6. | | - CarManager.cs
7. | | - CarController.cs
8. | | - CarPlayer.cs
9. | | - CarEnemy.cs

Code (Hiearchy):

1. CameraRig
2. - CameraLight
3. GameManager
4. GUIManager
5. - MenuPanel
6. | - Title...
7.  

The rest of the flow then depends on the game. They typically have a GUIManager, for well the GUI which sits on the base Canvas. He registers to events inside GameSettings. And registers to all GUIElement scripts in all the child classes. This lets him "automagically" listen to all input events on things I care about.

From there, I follow the inverse of what some do (in terms of how I name Managers vs Controllers). I follow a Manager > Controller > Element system... Where groups of Managers control groups of Controllers, which control groups of Elements, all accessible through GameManager. And if you connect it all using events, its really easy to raise a text message from a car class with minimal effort (for example).

That said, utilizing what Unity does well, I often have tiny scripts using FixedUpdate() { } that will go off and check on child elements. For example, if (transform.ChildCount > 0) { // change colour }. But you are absolutely right, you want to maintain strict control over Updates. And know when it makes sense to to use Update vs LateUpdate vs FixedUpdate vs a Coroutine.

A friendly tip: The biggest slow downs I usually find are caused not by pooling, but colliders. So quite often I disable colliders on an object by default. And on Start() { } it triggers a Coroutine to enable the attached MeshCollider (when it gets around to it). This makes the object appear on the screen faster and when coupled with a pooling system can really give you a nice performance boost in some cases.

 

Your workflow actually sounds very solid. I like to put my mind around the game architecture and the relations between the different elements before starting to write a single line of code.
Keeping everything neat and tidy when programming can turn out useful when dealing with thousands of lines of code!
That`s probably why I just don`t want to rely on some gameobjects jumping into the update cycle and doing their thing whenever they feel like it.

Still, I think it`s pretty interesting to learn about other peoples approach to game programming! There is nothing worse for a creative mind than stagnation and I will try to adapt a bit of everything.

After all, it can`t hurt to try something new!

 

I love to see other setups too I'm finally starting to include multithreaded and serialization into my workflows and coding schema. But I'd absolutely love to see how others structure their code (its one of the reasons I've bought a few kits off th asset store too!)

It sounds like we have a very similar approach to learning

 

Yes it does look like we have something in common !
Since I made the step from being a freelance coder to working in corporate - IT it`s getting kind of hard to find people that are willing to show their own creations at work. It`s almost as if they are ashamed of what they have done!
I do have a name for them: Coding Gollum !

 

Haha, I have a coworker that would absolutely love that term! We have been trying to get another local Unity developer for quite a while now. It's surprising how hard it is to get a Unity dev that's interested in corporate here. It's been quite an interesting year

 

Well for most people corporate IT sounds like sitting in the basement and waiting for phonecalls to reset passwords for idiots that can barely boot a pc.
I wouldn`t blame them ! I have been working in a dead-end job for way too long. So having a regular monthly income, spending more time with my wife as well as being able to do what I love feels like non-stop holidays to me !