Game Development Reference
In-Depth Information
Tip
As a rule of thumb, you should always keep flags, settings, or properties for a thing with
another thing. If you start having variables to track the state of a thing elsewhere, it can
get very messy. The only time this is not true is when a thing is meant to be shared across
multiple objects.
Also note that the ScriptableObject entities are a fickle beast. They let us attach
them to the game objects, and they can be automatically serialized and saved as part of the
project. However, they are fixed assets that should only be edited in the editor. If you need
to alter them as part of the game, you will need to save and store that change of state sep-
arately.
This is just a simple note to remember when architecting such things.
So, create another C# class in Scripts\Classes named Conversation and popu-
late it with the following code:
using UnityEngine;
public class Conversation : ScriptableObject {
public ConversationEntry[] ConversationLines;
}
Now the first thing you will note is that this class is derived from a scriptable object class.
As described earlier, this is what enables us to use Unity's serialization methods and store
them as a .asset file.
We are not done yet as we need that final hook to enable us to create these (at least ini-
tially) in the editor.
Earlier, I showed you all of the code needed to create the asset for serialization, but this is
rather a lot of code to be generated all the time. So, it's better to place that logic in a separ-
ate helper class that we can reuse rather than repeat ourselves all the time.
Earlier, with the PositionManager example, we created assets in the editor and re-
used them. You can reuse that code if you wish, but to simplify things, I added a little
helper script to the example project in Assets\Scripts\Classes . The Cus-
tomAssetUtility class does all the work that the preceding code does. It also uses
Search WWH ::




Custom Search