Discussion What's the best way to find (SCRIPT ONLY) answers in Unity?

Unity is awesome for non-coders and light coders - it's one of the best things about Unity. But as a code-oriented developer, I find it difficult to find code-only answers (no drag-and-drop or editor tweaking).

Are there any others who prefer to do everything in script? (the reasons are a whole subject in itself). This is mostly a call out into the void - out of curiosity.

It would be too much to ask Unity to make a script-only (or script-heavy) supplement to documentation (with simple but complete code examples). It might help developers who are not averse to code, as a way to combat tutorial-rabbit-hole-fatigue.

Thanks!
-j

 

Code is great, I'd rather do everything in code.

Trouble is, it only works to a point, and then it gets ridiculous.

I do WAY more than most in code. Been at it for four decades plus.

But I still use the editor dragging when it adds value.

Try hitting this forum up with pointed questions about what you contemplate doing. Use this pattern:

How to report your problem productively in the Unity3D forums:

http://plbm.com/?p=220

This is the bare minimum of information to report:

- what you want
- what you tried
- what you expected to happen
- what actually happened, log output, variable values, and especially any errors you see
- links to documentation you used to cross-check your work (CRITICAL!!!)

The purpose of YOU providing links is to make our job easier, while simultaneously showing us that you actually put effort into the process. If you haven't put effort into finding the documentation, why should we bother putting effort into replying?

I highlight the documentation part because if you WANT to do something in code, then YOU need to find the appropriate API, or at least find the correct terminology to search for it. Nobody else can do that except YOU.

 

Well to be fair, Unity does it's best with making everything as simple as it can. So I can agree to a point, with only wanting code only, but as Kurt mentioned, it can get really ridiculous(and extremely time consuming).

But do you have a particular asking? Off hand I can think of several ways to do basically everything with code, ex: load assets from file path, etc...

 

I mean if you wanted to do everything via code, then you might consider why you're using Unity at all.

Nonetheless a majority of Unity has some API to do what you could via the inspector via code. Really just a case of looking through the documentation and seeing what suits your needs.

 

Some good keywords to use in your searches:

• programmatically
• create at runtime
  
• dynamically
  
• procedurally
  
• in code
• via script

You could use the builder pattern to build complex game objects instead of instantiating from a prefab. Internally the builder would be using new GameObject and AddComponent to construct the game objects. You might find some inspiration by searching for "unity builder pattern github" and going through other people's implementations of the pattern.

You can use the RuntimeInitializeOnLoadMethodAttribute to specify the entry point of your application where you can start procedurally creating your game objects.

 

Exactly. It's a bit like different programming paradigms. You can program in almost every paradigm regarless of the language. There are languages which enforce or favour a certain paradigm, but the paradigm itself is just about self-discipline. I think this video actually explains the differences quite well.

As it was already mentioned, you can do almost everything in code, however, why would you? The concept of prefabs is one of the great things about Unity. You can import and compile assets in the editor and just use them as a cloning source. Scenes, prefabs and ScriptableObjects can setup references and kinda act like a dependency injector.

What you can not do just in code is importing assets at runtime. Unity can load a very small set of assets at runtime, but most of the loading code is part of the editor and not shipped with the engine.

 

I've worked on one project, a bit of a minecraft—esque game, where the world and entities were generated at runtime based on data that was sent from the backend.

The root game object of each entity was pieced together wholly in code, with the backend being entirely in control of which components were attached to each entity's root game object.

The visual sides of each entity were still put together at edit time in prefabs containing the mesh filters, renderers, animators and such. These visuals were then instantiated as a child of the root game object based on the visuals id that was sent from the backend. The artists in the project would be responsible for creating these prefabs for the visuals, while the programmers would do pretty much everything else (except for the UI layer, which was a mixed bag).


I totally agree that scenes and prefabs are an awesome tool, and it's well worth it to spend the time to learn them in my opinion But different kinds of hybrid solutions, where some aspects of game objects are generated at runtime, can also make sense in certain kinds of projects.