MMORPG Tycoon 2

MMORPG Tycoon 2

View Stats:
Possible add-ons for ability-creation?
I have two ideas for possible additions to the custom abilites you can create for monsters and characters.
Maybe you could include checkboxes in the ability creation to specify, if the ability is used by the game against enemies or friendlies of the user?
For example a spell that aims at a friendly to syphon 10 rage and slowing them down but giving them the "protect" charm in return.
I know that the AI makes this choice itself, but it would allow for more "creative" spells and abilities by overriding the included way of chosing the default target.
And you could also add a third area for the mechanics to specify what effects are added to the caster outside of the costs.
For example a spell, that gives the enemy target rage and slows it down, but adds "protect" to the caster and.
Those additions could be useful in Parties, especially in Dungeons!
< >
Showing 1-10 of 10 comments
VectorStorm  [developer] Apr 18 @ 7:23am 
We currently have a rule which says that the topmost ability effect determines the ability "type" for the AI. That is, abilities which start with a "damage" or "drain" effect are attacks, ones that start with a "stun" effect are debuffs, etc. Subscribers then use those ability 'types' to determine who they want to target with the ability and when to use them. It seems to me like maybe the simplest way to get what you're asking for is to let you reorder the effects so that you can change which effect is on top and setting the 'type'?

So like.. if I'm understanding your desire correctly, in your example where you want an ability with a siphon, a slow, and a protect to get used on somebody's own party members.. the game right now would pick the 'siphon' as the primary effect and make it be used as an "attack", and so would never use the ability on their party members. But if you could reorder the effects within the ability, you could theoretically put the 'protect' first, which would make it a 'buff', and the AI would then use the ability on friends who needed a protection buff. Would that accomplish what you were thinking about?

I guess my worry is really about a similar ability to the one you describe, but which siphons health instead of rage; I'm not sure we can just let the AI simply treat the ability like a 'buff' in that case, or else they'd sometimes accidentally kill their own party members by draining all their health away while thinking they were applying buffs. These more complicated abilities probably require a lot more AI to use in ways that look reasonable.
Last edited by VectorStorm; Apr 18 @ 7:27am
Dragon1 Apr 18 @ 8:53am 
Originally posted by VectorStorm:
We currently have a rule which says that the topmost ability effect determines the ability "type" for the AI. That is, abilities which start with a "damage" or "drain" effect are attacks, ones that start with a "stun" effect are debuffs, etc. Subscribers then use those ability 'types' to determine who they want to target with the ability and when to use them. It seems to me like maybe the simplest way to get what you're asking for is to let you reorder the effects so that you can change which effect is on top and setting the 'type'?

So like.. if I'm understanding your desire correctly, in your example where you want an ability with a siphon, a slow, and a protect to get used on somebody's own party members.. the game right now would pick the 'siphon' as the primary effect and make it be used as an "attack", and so would never use the ability on their party members. But if you could reorder the effects within the ability, you could theoretically put the 'protect' first, which would make it a 'buff', and the AI would then use the ability on friends who needed a protection buff. Would that accomplish what you were thinking about?

I guess my worry is really about a similar ability to the one you describe, but which siphons health instead of rage; I'm not sure we can just let the AI simply treat the ability like a 'buff' in that case, or else they'd sometimes accidentally kill their own party members by draining all their health away while thinking they were applying buffs. These more complicated abilities probably require a lot more AI to use in ways that look reasonable.

Ah, I didn't realize that the game looks at the first effect! That would make my "checkbox" idea redundant, you are right.
What about my idea about more "Cost" options for the caster? For example a caster inflicts an enemy with "Slow", but instead of Health, Rage or Mana as a cost you could go and give the caster "Weaken" or any of the other spell effects.
Or would that be to much thinking for the AI to use the spells without commiting seppuku on a regular basis? XD
VectorStorm  [developer] Apr 18 @ 6:51pm 
Originally posted by Dragon1:
What about my idea about more "Cost" options for the caster? For example a caster inflicts an enemy with "Slow", but instead of Health, Rage or Mana as a cost you could go and give the caster "Weaken" or any of the other spell effects.

Those could absolutely be done! The question though is whether the caster could use the ability when they were already under the influence of "Weaken", or whether the cost would require a *new* "Weaken" effect.
Dragon1 Apr 19 @ 3:03am 
Originally posted by VectorStorm:
Originally posted by Dragon1:
What about my idea about more "Cost" options for the caster? For example a caster inflicts an enemy with "Slow", but instead of Health, Rage or Mana as a cost you could go and give the caster "Weaken" or any of the other spell effects.

Those could absolutely be done! The question though is whether the caster could use the ability when they were already under the influence of "Weaken", or whether the cost would require a *new* "Weaken" effect.

Maybe the easiest way would be to let the new instance of an Effect deal with the former one the same way as it is right now, if spells from the same caster overlap same Effects. At least for a first Concept-Update. If it is liked by the players, you can always make more changes regarding the "how" later and look, how well they are recieved!
But I wouldn't know how easy it is, to implement it though, as I don't know a thing about programming.
VectorStorm  [developer] Apr 19 @ 6:38am 
Originally posted by Dragon1:
Maybe the easiest way would be to let the new instance of an Effect deal with the former one the same way as it is right now, if spells from the same caster overlap same Effects. At least for a first Concept-Update. If it is liked by the players, you can always make more changes regarding the "how" later and look, how well they are recieved!

Oh, it definitely would work the way you describe!

My question really was.. if we (for example) give a healer a "at the cost of snaring myself, I can cast an amazing heal on a teammate" ability, should they be allowed to cast that amazing heal repeatedly (refreshing the snare every time), or does the first snare have to completely wear off before they can trigger it again? I guess I worry that if we do the former, it leads to absurdly powerful abilities that can just be spammed forever.

On the other hand, though, I guess that just becomes something that people making the abilities have to design around. If you want to stop somebody from spamming the 'heal' ability and to wait for the five-second snare to expire, you make the ability have a five second cooldown, and that'd work great.

Okay, I'm writing this stuff down in my list for future work on combat abilities! :)
Dragon1 Apr 19 @ 7:16am 
Originally posted by VectorStorm:
Originally posted by Dragon1:
Maybe the easiest way would be to let the new instance of an Effect deal with the former one the same way as it is right now, if spells from the same caster overlap same Effects. At least for a first Concept-Update. If it is liked by the players, you can always make more changes regarding the "how" later and look, how well they are recieved!

Oh, it definitely would work the way you describe!

My question really was.. if we (for example) give a healer a "at the cost of snaring myself, I can cast an amazing heal on a teammate" ability, should they be allowed to cast that amazing heal repeatedly (refreshing the snare every time), or does the first snare have to completely wear off before they can trigger it again? I guess I worry that if we do the former, it leads to absurdly powerful abilities that can just be spammed forever.

On the other hand, though, I guess that just becomes something that people making the abilities have to design around. If you want to stop somebody from spamming the 'heal' ability and to wait for the five-second snare to expire, you make the ability have a five second cooldown, and that'd work great.

Okay, I'm writing this stuff down in my list for future work on combat abilities! :)

I am looking forward to it! I am running out of interesting combinations that make sense lorewise for my classes! XD
This option would help us players to create some unique and interesting abilities to hammer down our own style of classes.
At some point it just becomes a gray mass that feels the same, you know. You can only create so many abilities that make a Tank a Tank before it becomes repetetive.
Dragon1 Apr 19 @ 7:20am 
Then again... I guess that is exactly the same problem, big Companies have to deal with, when they design MMOs with 60 or more Abilities for every of the 6 Classes for every of the 10 Races. XD
It's just not the same scope for you ... yet? ;-)
This game definitely has amazing potential and I am looking forward for what the next months and years have in store for it! Keep up the great work!
VectorStorm  [developer] Apr 21 @ 5:18pm 
And the other worry is that I'm trying to make the game mechanics interesting for the actual human player who is designing everything, and ideally I don't want to make things too complicated for the AI subscribers who are picking which ability to use.

Like.. if they have an ability which drains rage from a teammate in order to give them a buff, that's *super* complicated for them to think about; whether extra survivability from the buff outweighs the loss of rage for that teammate; it almost requires the buffing character to know how to play *both* classes in order to decide whether that can do something better with that rage than the buff we were going to give them! And worse, there's nothing visually happening on screen to even let the human player know that we're spending CPU time figuring that out every time we have the opportunity to use that attack; it's just throwing CPU time away on something that the human player probably won't even appreciate.

So.. it's complicated, yeah! Always a balancing act trying to figure out which bits will actually help the real game the *human* player is playing, and which only improve the invisible game the *AI* is playing. :D
Last edited by VectorStorm; Apr 21 @ 5:20pm
Dragon1 Apr 22 @ 6:43am 
One way of implementing this could be to give the AI a way of recognizing, whether it is in a Party or solo. If it is in a Party it would track the stats of 4 instances: itself and the other members.
That might be done by creating some sort of "Sub Subscriber" that works with 4 sets of stats internally.
This "Sub Subscriber" would replace the four primary members and use a more complicated way of thinking and choice making to keep track of stats and the way all abilities would function with them.
Outside of a group, during solo traveling, the game could then ignore additional effects for non-Party-Subscribers and default to the "old" way with only a normal "Cost". That way the full worth of those Abilities would be unlocked in Parties, but they would still be good for Solo.
I am just throwing this into the discussion here! I have no actual Idea about programming or if it would be possible for YOU with YOUR way of coding! I am aware, that is is a small passion project (I believe you are doing this on your own?), so you might not have the resources to get this implemented...

Or you could try to get some framework set up and let the community figure out, what crazy stunts can be done with it. You are planning to give us workshop-access one day, right? I believe I saw it on the Roadmap.
< >
Showing 1-10 of 10 comments
Per page: 1530 50