Need a hand with some basic coding ideas for my project (RPG, RTS, Ability System)

Started by
6 comments, last by LorenGDP 1 year, 6 months ago

So, quick overview:

I'm trying to learn basics of game development (actually using Unity with C#, but this won't matter in this case) by taking small steps on a game idea i came up with. I've always been upset with how limited skills and attacks feel in most games (RPG's).

I mean, you're a fire mage, but can't control fire? You can only throw balls and create some fire columns? Come on.

Idk if you know Magicka, but this is the game i'm inspiring mine on. This is a game focused on it's magic system, in wich you have 8 elements. Spells are influenced not only by the amount of an element you charge, but also the order. For example, these are some options with fire:

  • Fire + (Life | Death) → Fire mines.
  • Fire + Shield → Wall of fire
  • Fire + Rock → Throws Rock doing AOE fire damage
  • Fire + Rock + Shield → Summons a line of rocks, each doing AOE fire damage
  • Fire + Lightning → Fire that also does lightning damage
  • Lightning + Fire +→ Bolt that also does fire damage
  • Fire: Cone of fire
  • Fire + Fire: larger cone of fire
  • Fire + Water: Steam cone (melt in one only element)

Also you can have 4 ways to cast them:

  • On Surrounds (AOE)
  • On yourself
  • Use (regular use, depends on the spell)
  • On weapon (changes shape of the spell)

I want a game that “frees” the magician inside, that allows you to cast any spell you can imagine (with no physics involved, thanks) .

So, a RTS with this concept ('cause it can't be just a RPG if we take in count the area parameter)… how?

I mean, i can work on a element relation and how it affects others, the system to actually create the spells and so… but how do i code it? I've been reading through forums, and i've seen that very very often, people have 1 function for 1 spell (as for cards games), but there has to be a better approach. If my game ends up with 3000 possible spells, do i have to code all the possibilities?

Not all spells include damage, some possibilities would be:

  • Applying / healing debuffs
  • Applying / healing Dots
  • Various spell shapes
    • Beam with penetrations
    • Chaining nearby enemies
    • Bombs
    • Charging a spell
  • Physical barrier
  • Teleports
  • Summoning
  • Linking characters stats
  • Reviving
  • Moving around (push and pull)

The idea that came to my mind was, create a Spell class that would contain the Shape, Elements, target (Tile or Char), caster and other data, but… How then i distinguish what it has to do???

Advertisement

Yes Classes.

BaseFire Class + BaseShield Class = FireShield Class

BaseAir Class + BaseShield Class = AirShield Class

And so on.

A BaseSpell Class would have functions such as, cast, drawPower, ect..
And BaseFire would extend BaseSpell. In C# you would be using imports (using).
So a new FireRockShield Class would import BaseSpell, BaseFire BaseRock and BaseShield, and that would be how you build the Classes.

Actually in C# you'd have to use interfaces to achieve multiple inheritance.
Or you can have the separate base Classes and use them as instances inside of others.
For example FireRockShield would extend just BaseShield and internally use an instance of BaseFire and an instance of BaseRock.

None

@Tadstergames Pretty interesting approach, i have thought about inheritance to fulfill this, but didn't manage to take it to a real example as you did. Guess i'll give it a chance and try, thank you!

You could perhaps come up with a modular system, in which the parts of the spell define which from a selection of internal classes are applied in sequence. That is, perhaps the first element defines the “form” of the spell, the second its “locus of effect”, and the third its “damage type”; a “spell object” is then produced by the first of those and modified in turn by the other two, which emits the result.

However, this I fear runs the risk of the magic system feeling rather "mechanical"--and hence rather “unmagical”.

I suspect that--short of some clever heuristic approach, or some other approach that hasn't occurred to me--hand-crafting the spells either as classes or as data-driven definitions of component-compositions is likely to yield preferable results.

MWAHAHAHAHAHAHA!!!

My Twitter Account: @EbornIan

@undefined I've thought about this but, as you said, this makes the system rather mechanical. My first idea was actually, make each “pearl of power” (element, casting, effects) a letter of the alphabet, wich then were used to create Char's names, but this restricted the amount of elements aviable, and left me with the huge problem of working with the strings…

Of course, one way that you might reduce that huge list of potential spells to be implemented might be to introduce some restrictions--perhaps element A doesn't work with element B, or element B only functions in position 1 if it's followed by a specific type of element in position 2, and so on.

It would, I feel, be important for these restrictions to be clear to the player, but if they are then they might even make for a more interesting process of discovering new spells.

MWAHAHAHAHAHAHA!!!

My Twitter Account: @EbornIan

@undefined Exactly, i find it a good way to implement the system and make it “fresh”.

Synergies and contras is something i have to a look at, right now i have some ideas for the debuffs, being the “most clear”:

1 fire element at spell = 1 fire charge

1 fire charge applied to char = 1 mark of heat.

3 marks of heat = 1 mark of Burn → Increased increment/decrement of the damage, and DOT. Each fire charge would now increase Burn on 1.

3 marks of Burn = Scorched → LOT of damage on DOT and the above multiplier.

And to reduce this marks, you have to use opposite elements, so 1 charge of water would neutralice 1 mark of hear, maybe half of Burn and would turn Scorched into 1 burn.

Of course, this right now is debalanced AF.

This topic is closed to new replies.

Advertisement