Unfortunately one of the first things you see in many Unity game tutorials is a mistake.
Wrong:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Wrong : MonoBehaviour
{
void Start()
{
}
void Update()
{
// x, y are set somewhere else
Vector3 movement = new Vector3(x, 0, y);
}
}
Correct:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Correct : MonoBehaviour
{
Vector3 movement;
void Start()
{
movement = new Vector3(0, 0, 0);
}
void Update()
{
// x, y are set somewhere else
movement.x = x;
movement.y = y;
}
}
Always create a new object instance in Start()
and update its attributes in Update()
.
If you need a variable amount of objects that are spawned depending on some event that happens during the game then use an object pool. An object pool is based the same principle: create the objects in advance and re-use them in the game loop.
Note: While the Unity compiler might be able to optimise away the object creation in the particular case above, imagine what happens when you instatiate complex objects that have multiple components and assets and instatiate other objects in turn. Therefore I like to think of avoiding object creation in the game loop as a habit to practice.
TL;DR You should never see the new
keyword inside Update()
. Your garbage collector will thank you.
More information about object pools in Unity: https://learn.unity.com/project/c-survival-guide-object-pools?uv=2018.4&courseId=5cf06bd1edbc2a58d7fc3209
If you declare a property public
in order to access it from another script, it will automatically show up in the Inspector. To prevent that, use the [HideInInspector]
attribute:
[HideInInspector]
public float life;
Note: In other object-oriented programming languages, "attribute" means the same as "property". In C#/Unity it denotes a code annotation in square brackets.
Starting point to learn about attributes in Unity3D: https://docs.unity3d.com/Manual/Attributes.html
GitHub for Unity is a plugin available on the Unity Asset Store that simplifies working with Git, Github and Git Large File Storage: https://assetstore.unity.com/packages/tools/version-control/github-for-unity-118069.
To make it work, set:
Edit > Project Settings > Editor > Version Control > Mode > Visible Meta Files
Unity's built in audio system is quite flexible and powerful. If your audio sources are files or mod trackers you might not need even need addiitional audio midleware.
Instead of attaching audio processing components to GameObjects, you can manage your game audio from a central mixing desk. This setup features Audio Mixers, Audio Groups of filters and effects, Snapshots to remember and transition between parameter setups, Views to toggle the visibilty of elements, Sends and Receives for audio sidechains and parameters that ca be exposed to scripts. You can even write your own DSP effects and add them to the stack (Native Audio Plugin SDK).
Surprisingly however, Unity (currently) does not allow to copy or move Audio Groups between Mixers (confirmed for 2019 LTS: https://twitter.com/unity3d/status/1285162528226582528). Say, you started out with one central Audio Mixer but later decided that you want to have one Mixer per Scene. You cannot move your existing Audio Groups to other Mixers and therefore you would have to start from scratch 🙀.
TL;DR If you use Unity's built in audio system, plan your Audio Mixer setup carefully beforehand.
More information about audio in Unity:
https://docs.unity3d.com/Manual/Audio.html
https://gamedevbeginner.com/10-unity-audio-tips-that-you-wont-find-in-the-tutorials/
https://www.gamasutra.com/blogs/ZanderHulme/20190107/333794/Unity_Audio_Import_Optimisation__getting_more_BAM_for_your_RAM.php
In particular beginners learn a development philosophy in Unity that revolves around attaching scripts to GameObjects. In order to communicate with other components, these script have address components and other GameObjects through attributes and method calls such as .gameObject
, GetComponent<ComponentType>()
and variants thereof. This is plausible for a small number of objects in a game scene. With growing complexity these constructions get less and less manageable.
(tbd.)
(tbd.)
https://docs.unity3d.com/Manual/index.html
https://docs.unity3d.com/ScriptReference/index.html
https://docs.microsoft.com/en-us/dotnet/csharp/
https://jacksondunstan.com/