It's been a long while since my last update, and there's quite a bit of information I have to share!
Desolation | Code Progress and The Magic of Azun
First, the progress on Desolation: at the time of the previous post, I was in the process of working on writing code for some of the systems in the game, and refining the code I'd already written. The main issue I had was trying to figure out a way to tie different system components together through inheritance (i.e. Player Health derives from Character Health which derives from Health) while grouping their variables together in a neat and organized way in the Unity editor. I initially wrote generic base classes that would accept different "groups" of variables, like so:
public abstract class BaseStats<H> : MonoBehaviour where H : HealthStats { [Header("Entity Stats: General")] [Tooltip("The name of this entity, if it has one.")] public string entityName; [Tooltip("The type of entity this is.")] public EntityType entityType = EntityType.None; [Space] public H healthStats; } public abstract class BaseCharStats<R, M, D> : BaseStats<EntityHealthStats> where R : ResistanceStats where M : MovementStats where D : DamageStats { public R resistanceStats; public M moveStats; public D damageStats; } public abstract class BasePlayerStats<E> : BaseCharStats<CharacterResistanceStats, PlayerMovementStats, CharacterDamageStats> where E : EnergyResourceStats { public E energyStats; [Header("Debug Stuff")] [Tooltip("The speed of this player when in godmode.")] public float godModeSpeed; }Unfortunately, this gave me a new problem: the base class for all Stats classes would be a generic class. If I wanted to refer to a Stats class in general (i.e. check to see if an object has a Stats class of any type), I would need to refer to the generic class, which would also require specifying the type parameters for the class.
I decided on one of two solutions to this problem: either keep this system and specify the base type parameters for the generic Stats class anytime I referenced it, or use a new component-based approach which would encapsulate each class and its derivatives as their own separate components (i.e. Health, Character Health, and Player Health all as three separate scripts that do not tie into each other). I decided to experiment with the component-based method, especially considering Unity's script design pushes for component-based design anyway. The new problem I face is figuring out how I would be able to refer to a class in general (i.e. refer to Health, where both Character Health and Player Health would also be accepted). In my previous projects, I used this same component-based architecture, but included inheritance so more specific classes would derive from a base class. The issue with this design, as I used it, was that variables were harder to organize; I couldn't figure out a way to include new variables in derived classes under a header in the base class, which led me to the generic class design.
Aside from code, I've also been hard at work at designing an elemental magic system that would become one of the game's core systems. I wanted a system that used elements as a type of "characteristic" or attribute for different things, like abilities, items, and even creatures. Different elements could be combined to form new elements, and these intermediate elements would have certain traits inherited from its component elements.
A very rough example diagram of some elements that might be seen in the world of Azun.
However, I was stuck between two implementation options.
Option 1: Inherent Elemental System. The elements are present in all things, and every interactable object, creature, item, etc. would have an element or multiple elements associated with it. A skeleton warrior, for example, would be comprised of Mortus, the death element, and Animus, the moving/animation element. This system could have great potential; there could be simple element-counters-element interactions (a spell with a divine element may deal additional damage to this skeleton), or broader, unique interactions (such as a spell that removes the Animus element from all objects in an area, essentially wiping out the movement capabilities of any creature in the area). The issue with this implementation is, realistically, scope and complexity. Going this route would turn Desolation into a much more complex game than I had initially envisioned, and while I would love to take the game in this direction, I have concerns for how this complexity level would be received by players.
Option 2: Elemental Spell System. The elements are present only in Actions such as spells and abilities. Different elements give different bonuses to Actions (an Arcane Bolt spell with the Vitus element applied may give it healing properties, while the same spell with the Ignus element may deal fire damage, instead). This is a much simpler system than the Inherent Elemental System, but it does mean that the potential for unique interactions like the Animus one described would be gone.
There is the option of combining both systems and potentially giving the game an even higher level of complexity than the Inherent Elemental System alone. Alternatively - and this is the approach I am currently taking - I could find a compromise between both options and design a system that could allow for the potential of the Inherent Elemental System while keeping the simplicity of the Elemental Spell System.
A New Project and a New Vision
However, Desolation is a project that will temporarily be put on the backburner as I have taken up a new project alongside some friends. We've been in the process of designing an interesting story-focused space RPG series of games, a series that would follow a unique order of release in terms of content and gameplay style. This project is a unique opportunity for us, as it 1) gives us all a common goal to strive for, 2) allows us to experiment with tools we may not have used before, and 3) gives us the opportunity to work together as a team to develop something creative. Furthermore, if we decide to commit fully to working on this project in the future, the games we produce will likely be published under Azurus Creative label, the development label I've been establishing.
This is an exciting opportunity and a potential stepping-stone for our careers. This may just be the birth of Azurus Creative as a team, and the birth of a striking new game series. Look forward to more updates on this project in the future!
Comentários