I am working with the FPS Microgame and I can’t access scripts I created from within the FPS Microgame Scripts.
I created this script:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Unity.FPS.Game;
public abstract class XPTranslation : ScriptableObject
{
public int CurrentXP { get; protected set; } = 0;
public int CurrentLevel { get; protected set; } = 1;
public int XPRequiredForNextLevel => GetXPRequiredForNextLevel();
public bool AtLevelCap { get; protected set; } = false;
public abstract bool AddXP(int amount);
public abstract void SetLevel(int level);
protected abstract int GetXPRequiredForNextLevel();
}
FPS Microgame created this script:
using UnityEngine;
using UnityEngine.Events;
namespace Unity.FPS.Game
{
public class Health : MonoBehaviour
{
XPTranslation XPTranslation; // I created this line, which does not access my script.
[Tooltip("Maximum amount of health")] public float MaxHealth = 10f;
[Tooltip("Health ratio at which the critical health vignette starts appearing")]
public float CriticalHealthRatio = 0.3f;
public UnityAction<float, GameObject> OnDamaged;
public UnityAction<float> OnHealed;
public UnityAction OnDie;
public float CurrentHealth { get; set; }
public bool Invincible { get; set; }
public bool CanPickup() => CurrentHealth < MaxHealth;
public float GetRatio() => CurrentHealth / MaxHealth;
public bool IsCritical() => GetRatio() <= CriticalHealthRatio;
bool m_IsDead;
/// Lines Continue...
I even tried creating a namespace around my script:
Besides the potential use of assembly definition files, it would be interesting to know where in the assets folder the two scripts are located. There are still magic folder names which can get in the way.
The scripts I am trying to access in the Health script.
Right now, I have a working system to gain experience and increase levels. What I am trying to do is increase stats with every level increase. One of the stats would be health. I am trying to increase the player health when leveling up.
An assembly definition file essentially separates the subfolder it is in and all nested folder into a separate assembly. So the code in that folder (and subfolders) are compiled to a completely separate standalone DLL / assembly file.
Unity, by default, when not using any assembly definition files will compile all your code into a single assembly which is called Assembly-CSharp.dll. This is somewhat your main assembly. This will automatically reference your other assemblies. However it can not be referenced by your standalone assemblies as you can not have circular dependencies between assemblies. So it’s not possible to have assembly A reference / depend on assembly B and at the same time have B depend on A.
There are several ways how things like that can be resolved. One way is to get rid of the assembly definition file so all your code is again compiled to the same assembly. When all code is in the same assembly, every class can see and interact with any other class within the same assembly.
If the mini game should be a separate unit that runs on its own, you could define interfaces that the main code uses / supplies to the minigame in order to have the minigame interact with your main code in an abstracted way. This of course requires a careful planning and to keep the cross dependency to a minimum…
It’s up to you how you plan to design your codebase.
Thanks for the clarification. I don’t see any reason why the microgame would have to run separate from anything else, so I should just delete the Assembly definitions then? Everything I’m working on will be built upon this microgame rather than separate entities.
Just curious though, what purpose would assembly definitions serve? Let’s say the code is compiled separately. What does that accomplish? Is there an actual game you can use for an example? It sounds like something I might want to look into further.
In general, it helps with script recompilation. A lot of folks also find it helps with organising code. Personally I find it’s good for keeping my code dependencies one-way. I also just like a well-organised project myself.
It’s all behind the scenes stuff, though. And most Unity games I poke around in the files of aren’t using them. Even really big Unity games like the Pathfinder games.