# Unity RPG Systems Design - Spells and Items?

This topic is 887 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey there.  I'm getting ready to implement some RPG systems in my Unity game.  I could really use some insight from someone who has developed such systems professionally.  I'm quite fond of MMO spell systems in particular for their sheer flexibility.  Teal deer at the bottom.

Regarding spells first, I've seen all manner of designs.  Some systems have spells as child objects of a character, some as monolithic assets that characters reference and feed data into, some as objects in a database that also have data fed into them.  I've seen uber-spell classes, very inheritance-based spell systems, some that use composition with Spell Effects, and so-on and so-forth.

Personally, I like the idea of having spells be ScriptableObject assets.  It's a simple thing that can be serialized in Unity's inspector, it allows inheritance-based extension, and it's very easy to manage.  This kind of setup would of course be the "monolithic asset" sort of thing, where a Spell asset is like a technique the character is performing.  However, this does come with some significant downsides.  As there is only one instance of any particular Spell, using events would not be feasible, and they couldn't use any per-character variables.  Every single function would require that the character be fed into the spell so it can read and respond.

I can't know for certain, but I suspect this is how WoW and ESO do things, given that they have multiple instances of the same ability.  WoW for example can have as many as a dozen versions of the same spell, as older versions are replaced on a character as they train up the ranks.  The reason I suspect that ESO does the same is that when a toggled ability levels up, it seems to be removed and replaced with an exact duplicate.  Thus I figure that the game's per-spell experience lines are not actually part of the spell itself, but rather held separately in the character's skill progression.

public bool CanCast (Character caster);
public void Cast (Character caster, Character target);
public void Cancel (Character caster);
public int GetManaCost (Character caster);
etc...


This also brings into the question the subject of targeting.  Some spells require a target to cast.  Some have targets optional.  Some merely require a direction or a position in 3D space.  But one thing is for sure; if targets can be fed through to any spells whatsoever, the base system will need such an option.  This is where things get really confusing for me.  I could definitely use some advice.  Right now I'm thinking of simply having a Cast (Character caster) function, and then the spell itself reacts contextually.  What do you think?

The other subject is items.  Initially I had thought a simple ScriptableObject system might be good for this as well, but as opposed to Spells, Items require a lot more optional functionality.  Items can be upgraded, modified, transmogrified, made in multiple styles, have durability and such.  I would probably need a more open-ended system for something like this, and I can tell it's probably going to require a lot of custom editor scripts...

TL;DR:  What exactly goes into designing good Spell and Item systems for RPGs?  How would you design one, and what have your favorite designs been?

Edited by Mysterious Bakemono

##### Share on other sites

I'm working on the design for a small rpg design myself. Only started on the rpg system recently and my notes about magic systems can be found on at http://www.gamedevpensieve.com/design/mechanics/magic. Not much yet :).

For the spell you can create a instance of the FireBall spell each time the player cast a fireball. When it is created give it the target and all others paramters it needs. Send in the players skill level in Elemental magic for example so the ball can get larger.

##### Share on other sites

Scriptable and Unity do not really go together hand in hand unless you add in some other sort of language to prevent unity from getting flooded with instances of inherited classes.

I think Javascript might work if C# and Javascript plays nice on Unity. Then it'd mean that you'd have a single class that gets instanced, and then loads in a script that gets fed data.

RPGs have been known for being notoriously hard however. Especially if you wanted fast iteration times.

Currently for my set up, Spells are defined in Lua, and are very scriptable. Characters do not Own spells, as that would be pretty wasteful.  But they do reference them via container. Besides I don't have control over that. Lua passes tables by reference. When the container is linked to the spell, the Container has direct access (but not ability to modify) the data of the spell. So it can grab the description, cool down, time to cast, and any other details.

When the container's GUI element is clicked, it plays the animation as the cast time goes. At the end of the timer, an Event is fired, and will tick on the next game update. Reason being is... no real good reason. Mostly to prevent small latencies for physically enabled objects

Each spell has a sub component naturally. A fire ball will fly down a path and strike something to explode where it then runs the logic for its hit test after next physics update. A healing spell will lock onto and follow someone, and apply it's healing after a certain animation.

So to break it down.

Spell Container: Player's access. Reads data from a spell's descriptor. On a successful cast, this will also lock the player out till the cooldown is over.
Spell Descriptor: The Spell's descriptor. Provides rudimentary function for selection. Spells always needs at least one item. Lua dynamically types everything. But in C#, you'll probably want to make this a list of args.

Spell Entity: Carries on the logic of the spell in the physical world.

I should note that Spell Descriptor is a parent of the Spell Entity Table. The Spell entity however is kept separate so it can be instanced efficiently.Target data is set to the entity. be it velocity, a point in space, or a person. This variable is kept as the entity updates it's logic.

All Spells' descriptors are stored in a global table.

Items tend to roll a little differently here.

Like spells their bases are stored. But they are entities by default. So they can be dropped into the world with a temporary ID if they are a normal instanciation, or a unique id if randomly generated. When they are in the characters inventory. They too have a general container tied to UI elements. When the item is stored in that containers location, it's just referenced to the entity table.

When the item is used, It's used instantly, or added to the character's qeue (if the character needs to play an animation).

Edited by Tangletail

##### Share on other sites

Ah, this is kind of what I'm going for, I think.  I am likewise trying to avoid too much instantiation where it isn't necessary.  Part of why I want to go for a ScriptableObject Spell and a character that merely contains a list of references to spells, is because instantiation is completely unnecessary and at times detrimental to functionality.  I am curious about how you manage target data.  How do you go about determining targets in code?

I'm thinking of ignoring target information in the initial function, and then allow the Spell itself to get the appropriate data.  Getting the target data may also include putting the character into an "aiming" state or the like.  Then there only needs to be a single Cast function, and I don't have to worry about all the minor details ahead of time.

It sounds like your idea for items is similar to what I've done; to have a monolithic template of some kind, and then item object instances that contain a reference to that template.  My confusion here is with regard to the individual items in a player's inventory.  There has to be some kind of per-object data to items, but items also need a static template.  I have considered using a byte array inside the item container class, but that feels like it could get messy...

##### Share on other sites

Spell Descriptor handles all targeting functions.

When the Container is activated, it calls the function of the spells descriptor  from the global reference. This function will determine if it's an AOE, a skillshot projectile, or a selection.

That collected data is then passed onto a spawned entity, which it acts upon on it's update. Keep in mind that my engine uses a Actor system similar to unreals.

For items... what do you mean per-object data? Do you mean it's a templated object that's unique? If so, you copy it, change data, create an identifier, store it in a -unique- database. You still use a reference to that instantiation if it's in your inventory.

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5

• 10
• 14
• 30
• 13
• 11
• ### Forum Statistics

• Total Topics
631790
• Total Posts
3002365
×