Resources isn’t actually a Key Word, it’s a Namespace within UnityEngine. The qualification is required because the class is in the RPG namespace, and the way that C# manages Namespaces and class names causes the compiler to want clarification when it sees a potential name conflict. This sort of thing can happen all the time in a language like C# where numerous 3rd parties create libraries to extend the code base. That’s why we have namespaces in the first place, so we don’t have to worry about class name conflicts. (For example: In System, there is a class Random which behaves more like the traditional Random classes from our earlier programming days, just returning a number between zero and 1, and in Unity there is a Random class that provides Range functionality. If you have using System; and using UnityEngine; in your usings clauses, the compiler will want you to disambiguate the conflict. Visual Studio usually solves this for you by adding a line to the using clauses using Random = System.Random; or using Random=UnityEngine.Random;, or you can disambiguate it directly in your code by saying UnityEngine.Random.Range(min, max); so the compiler knows it’s UnityEngine’s random right in the code.
We do actually change the namespace to Attributes later in the course because it was pointed out that anything stored in a Resources folder is packaged with the final build of the game (a feature of the build system). Now that the full series has finished it’s recording, I’ll put a reminder in for Sam to consider a re-record of this portion of the lecture.
I terms of the complexity of the Lookup… yep, it’s ugly, no doubt about it. Think of it as pre-caching a complex SQL statement. That ugly turducken of a data structure lets you look up levels hundreds of times faster than if we crawled through all of the Class/Stat/Level lists and arrays every time we needed to look up a stat (which could be many many times per frame)
You can have a formula (in fact, I use formulas, I did from the very first time I took the course). Formulas can be tricky, especially when it comes to game balance (It’s easy to edit the attack value at level 10 without breaking the game balance at level 1, not quite as easy when it’s a formula, and the tweak to make level 10 right makes level 5 impossible). The decision was made when the course was designed to go with a spreadsheet like approach to the Progression. Not necessarily the way I would have gone, but it’s what we have to work with.
There are a number of ways you can implement formulas. These would replace the levels portion of our progression.
You only want the ScriptableObjects that are dynamically loaded at runtime… In this course, that’s just the WeaponConfigs. In the next course (Inventory), it’s all Inventory Items. In Dialogues and Quests, Quests will also go in the Resources folder. Ideally, you only want things that have to be loaded dynamically.
