Man... Magic SUCKS

ID:51940
 
Dec 17 2008, 1:22 pm
Seriously, it does!

Basically, I am now translating... A lot of D&D spells into BYOND... And unless I find a decent system to do this, it is going to take a chuffing long time.
There is a good 300-400 spells to add, and some of them are fairly generic and have similar effects to others. An example is a typical projectile spell, they are all most of less the same, a projectile is shot out, and it deals damage. The only things that are different between them is what the spell looks like, damage it deals and possibly what type of damage it deals. Spells like this can be quickly and easily added by making a "projectile spell" proc, and just calling it with the arguments each spell needs.
A fair few spells can be easily categorized in a similar way to this. Spells that inflict status effects, spells that summon something and so on.

But, the problem with D&D is that a lot of spells that are similar also have major differences, that are not easy to code in.

Every spell in D&D has the following.
Components, this could be an item, magic words, magic gestures, experience or concentration, or any mixture of those. Some more unique spells have special components that depend on what happens when the spell is cast.
Casting Time.
Range
Target, this is another complex one. The spell can be a projectile, centered on the target, or require you to touch the target. And a valid target can be very specific sometimes, it could be a specific type of monster, a monster with a specific class, alignment, age or something else unique to a monster. The target could even be an item, object or location.
Duration
Saving throw, this is basically, can the spell be resisted? If so what is needed to resist it, how difficult is it to resist, and what happens to it when it is resisted?
Spell Resistance, basically can the spell be defended against (is different to resistance, if a spell is defended against the caster fails to cast it).

There is also spells with unique effects that cannot really be put under any category.
An example would be a spell that points in the direction of the exit to a dungeon, or possibly even maps out the route to the exit.
Another spell simply makes a status effect permenant.
Some spells, despite being similar also have other, additional effects. Each effect also has a chance of being resisted and so on.

Anyway, you get the basic idea. A lot of the magic is very difficult to categorize in any sort of easy way. It is even harder to think up of a system that can make adding each magic spells effect quick and easy.

So the question is. Does anyone have any ideas on a way I can add magic spells, without the need to code each individual effect?
Dec 17 2008, 1:36 pm
Use external files to do it, with a dynamic-enough system to allow it. XML would be good for this sort of thing.
Dec 17 2008, 1:43 pm
Popisfizzy wrote:
Use external files to do it, with a dynamic-enough system to allow it. XML would be good for this sort of thing.

I thought about it, but to be honest, I fail to see the point in using XML.
I mean, if I put the data of each spell into an XML file, that data is loaded, then turned into a usable format and then used.
Why not just... Put the data straight into the source code? Instead of using an XML file, which adds extra steps to the process.


Anyway, what I am looking for is not a method of storing the data of each spell. That is fairly easy to do.
What I am looking for is a method of turning all this useless information into a magic spell effect. A method that is preferably flexible.
Dec 17 2008, 1:55 pm
The Magic Man wrote:
I thought about it, but to be honest, I fail to see the point in using XML.

It's useful because people can add the spells on their own, without requiring it to be in the source code.
Dec 17 2008, 2:00 pm
Popisfizzy wrote:
It's useful because people can add the spells on their own, without requiring it to be in the source code.

But at the moment I am not particularly sure if I want people doing that or not.
No doubt it is a cool feature to have in a game provided it is done correctly. But at the moment I am not entirely sure that I want people to be able to edit any part of the game or not yet.
Dec 17 2008, 2:06 pm
If you were really willing to put in the extra work you could make it so that each spell object has a script variable which is read though spell object's casting proc.
It's a LOT of work, requires you to do a lot of planning and really get your head around the entire magic system but when you're talking about having spells in the hundreds it's probably worth it.

You've really got to put a lot of work into the structure though.
Dec 17 2008, 2:23 pm
DarkView wrote:
If you were really willing to put in the extra work you could make it so that each spell object has a script variable which is read though spell object's casting proc.
It's a LOT of work, requires you to do a lot of planning and really get your head around the entire magic system but when you're talking about having spells in the hundreds it's probably worth it.

You've really got to put a lot of work into the structure though.

I was considering doing something like this basically. But the problem is still, it's a LOT of work.

What I was planning on doing was giving each spell a proc for each step of it.
Obviously, the proc would be overwritten for each type of spell (if needed), and each proc would have several generic forms to make things quicker and easier.

In a simple form, when a spell is cast 2 procs would be called. First would be the graphical effect proc.
This would by default simply either show a missile between x and y mob, or show an animation on all the turfs specified. (Or both, if the arguments are provided)
For more unique spells, you could overwrite this proc only for that unique spell. (The spell might display something dropping out of the sky for example) But otherwise that default proc is called.

Once the graphical proc is done with, the effect proc would be called.
This would by default deal damage if an argument is passed, and if an argument is passed add a status effect.
This again could be overwritten for more specific spells. Maybe the spell deals more damage to specific types of enemies, or only inflicts the status effect when certain conditions are met, or so on.

That would be a simplified version of what I plan to do. The actual version would do the following.

Check that the spell can be cast.
Get a valid list of enemies (could be a single one, all enemies around the caster, or the enemy, in a cone shape or so on).
If the spell has a range (projectile spell for example) then check that the enemy is in the valid range.
Wait for the spells casting time to finish.
Check that the spell was successfully cast.
Play a graphical effect.
Check to see if the enemy defended against the spell.
If not then check to see if the enemy resisted the spell.
If so do the resisted effect.
If not then do the full effect.

Each spell would have 10 procs, all would call a default action, and only spells with unique effects would need these procs altering.

It is probably not the best method of doing things. But for the moment it looks like the most viable option for such a large number of spells (which could grow at a later date).
Dec 17 2008, 2:47 pm
The Magic Man wrote:
But the problem is still, it's a LOT of work.

But it's work that will pay off. If you do your 400 spells, then wake up and decide to add another 400 the ground work is all taken care of. It's just a matter of translating spells to the scripting language.


It is probably not the best method of doing things. But for the moment it looks like the most viable option for such a large number of spells (which could grow at a later date).

That's roughly what I'd do if I couldn't do the other method, everything broken down and isolated to the point where variations are either small and covered by variables or large and covered by converting a few procs.
Ultimately though I think you're setting yourself up for just as much work. Things get very messy very fast with a system like this. You do still end up in situations where spell 399 requires you to go back and alter the base and every customised spell before it.
As far as workload goes, you've still got to do all the structural assessments, figuring out the precises order of operations, etc. In a sense you've got to work even harder with them because they are even harder to change. Granted if you haven't done much work with scripting this may still be less work than learning the ins and outs.
You can still have the custom procs on the spell objects, you just make it so that when it encounters 'callCustom=1' it calls spellObj.customProc(1). In the case of graphics it also runs a little easier. You just do the same thing, but you can add a potentially limitless amount of animations to single spells.
You can do graphic(1), graphic(2), graphic(1), graphic(3), damage(), graphic(3), effect(), graphic(2), graphic(1) (obviously with a bunch more in between to check targets and junk).

Anyway, if for what ever reason you don't want to go with a script based system then the way you described is your best bet.
Dec 17 2008, 3:03 pm
DarkView wrote:
That's roughly what I'd do if I couldn't do the other method, everything broken down and isolated to the point where variations are either small and covered by variables or large and covered by converting a few procs.
Ultimately though I think you're setting yourself up for just as much work. Things get very messy very fast with a system like this. You do still end up in situations where spell 399 requires you to go back and alter the base and every customised spell before it.
As far as workload goes, you've still got to do all the structural assessments, figuring out the precises order of operations, etc. In a sense you've got to work even harder with them because they are even harder to change. Granted if you haven't done much work with scripting this may still be less work than learning the ins and outs.
You can still have the custom procs on the spell objects, you just make it so that when it encounters 'callCustom=1' it calls spellObj.customProc(1). In the case of graphics it also runs a little easier. You just do the same thing, but you can add a potentially limitless amount of animations to single spells.
You can do graphic(1), graphic(2), graphic(1), graphic(3), damage(), graphic(3), effect(), graphic(2), graphic(1) (obviously with a bunch more in between to check targets and junk).

Anyway, if for what ever reason you don't want to go with a script based system then the way you described is your best bet.

The point is. With the system I am proposing to use, ONLY spells with unique effects need editing.

If I put it into code format, it might look like...



Spells
  proc/Damage(mob/M,dam)
    M.Hp-=dam
  var/damage
  Fireball
    damage=30
  Iceball
    damage=20
  Lightning_Bolt
    damage=50
  Acid_Ball
    damage=30
    Damage(mob/M,dam)
      for(var/obj/E in M.Equipment)
         del E //destroy equipment as well as deal damage
      ..()


As you can see, in this case only the Acid Ball spell needs changes made to it. All other spells simply deal damage, and call the default damage dealing proc.

With this type of system, the groundwork already exists. I can add 1000 damage dealing spells and I don't need to add anything, change anything or translate anything into a script, the effects are already there (from the spells parent).
The only time I ever need to add/edit/change something is when a spell like Acid Ball is added, when it has a different effect from the default deal damage.

This is basically the exact same thing I do with enemy AIs. Enemies loop from an AI proc, and call different procs for specific actions, each of these procs can be customized for any enemy in the game (only if they need be).
It has so far proved a highly flexible system to use, is very easy to use, and I only need to add what needs to be added.
Dec 17 2008, 3:37 pm
If the spell variations don't get much more complicated than that, then you shouldn't have too many problems working with that sort of system.

If there are a lot of unique variations that interfere with the order of operations and junk things will get out of control fast. You'll find yourself stuck in corners where you can keep plugging away with complicated patches or you can re-write the core of the system.

Like I said before your choice will get it done, and if you're more comfortable with it go for it. I just think, even for a less complicated system, scripting is the A+++ method.
Dec 17 2008, 3:51 pm
DarkView wrote:
If the spell variations don't get much more complicated than that, then you shouldn't have too many problems working with that sort of system.

If there are a lot of unique variations that interfere with the order of operations and junk things will get out of control fast. You'll find yourself stuck in corners where you can keep plugging away with complicated patches or you can re-write the core of the system.

Like I said before your choice will get it done, and if you're more comfortable with it go for it. I just think, even for a less complicated system, scripting is the A+++ method.

By using a while loop and having each proc return a value (which determines the next proc to execute), I could pretty much have the procs executed in any order I wanted.

But, in most cases this wont be needed. The order procs are executed should in theory never need changing.
Afterall, it would return some pretty whacky results if I tried to deal damage to an enemy... Before even checking to see if the enemy exists and it is within the range of the spell.

The only thing that might ever need altering in terms of when procs are executed, is the proc that applies the spells effect (dealing damage, healing and so on). Because that proc cannot be executed (without it returning an error) before any of the other procs are executed (as I said, a fireball spell should not attempt to deal damage to an enemy before making sure that enemy is a valid enemy).

I am still not seeing any good reason at the moment to use a scripting system :[ It'd basically achieve the same results (but most likely more inefficiently, since the script needs to be translated into a set of instructions), but with more effort. Which is the exact opposite of what I am trying to do.

Unless you can show me some sort of exampe as to how it would save time?
Sep 1 2009, 1:25 pm
You could use a generic spell class, which contains all the commonalities amongst the spells, such as range, components, and requirements. Then, in each object, you could define what happens in the Cast() proc. Granted, with the hundreds of spells in D&D (expansions notwithstanding), this would take a while, but it would alleviate some of the stress.

Of course, that's not to say you couldn't clip some spells out that you feel would be unnecessary or have the potential for abuse re Wish/Miracle.