4

Scourge Healing: Hex Spell. (30 seconds.) Whenever target foe is healed, the healer takes 15...67...80 holy damage.

The above is one of Guild Wars 1's monk class skills.

My question is about what would be a good way of implementing abilities like this. In a realtime game, should I be implementing them in my game's backend language(golang) directly, interpreting them from a scripting language at runtime, or something else? How do most RPGs(online or otherwise) do this?

RJones
  • 43
  • 2
  • 1
    What you ~should~ do is subjective, and it's based on a lot of variables. How critical is performance? How expensive is the game logic? How safe is your main language? Are you creating a modding API, while keeping the game engine closed source? Etc... (these questions are rhetorical). It's an interesting question, but maybe not fit for this site. Asking what is common for games to do, may be a good question for this site, but i'm not entirely sure. You could ask on meta if you want. You might have better luck asking on, say, Quora, to be honest. – Phoenix Apr 16 '18 at 03:55
  • 1
    Related (possible duplicate): https://gamedev.stackexchange.com/questions/29982/whats-a-way-to-implement-a-flexible-buff-debuff-system –  Apr 16 '18 at 20:33
  • I appreciate the comment and the link! That modding use case I think is an excellent example of why I'd want to implement these external to the main game. But at the same time, with the game being real time, I'd want the performance to be as high as possible. I'll take your advice and try Quora. Thank you! – RJones Apr 18 '18 at 06:12

1 Answers1

2

My experience is limited to two "AAA MMORPGs". I was a "gameplay engineer" in both, writing C++... SOE's "Everquest Next", and ZOS's "Elder Scrolls Online".

Both used abilities defined in data in such a way that dedicated designers could create and modify them with (ideally) little or no direct programmer involvement. The more complex things got, the more likely a designer might need an engineer to debug something, to say nothing of feature requests.

Both supported a fixed variety of kinds of things they could do, conditions they could test for, events they could hook into, and so on. A vast array of them, but a fixed set that could only be expanded by engineering.

In one case this data became so baroque/complex that it became Turing Complete. It was a painful obtuse/user unfriendly scripting language... accidentally.

I think an ideal system would use a visual scripting language (scribble, blockly, etc,) and expose a variety of objects/methods to it. This system would need to enforce execution time limits(and possibly other resources), and flag potential troublemakers for engineering review, native reimplementation, or deletion.

It would support a debugger! People writing these scripts are programming. Give them some tools to do it right. Ideally you wouldn't have to restart your game to load a new version of a script. Iteration time is important, particularly when you might have to close down your client and multiple servers, then restart them all. With debug builds this can easily take > 10 minutes.

If players were allowed to customize their GUI with this same language/objects, you would further need different layers of access. General Public, internal GUI only, and abilities-n-such.

Given a working C++ (or whatever) class, it should be trivial to expose that object and some or all of its public methods to the scripting language. "Tweak an XML file and rebuild", or perhaps add code annotations as in Java or C++.

But this all stems from my experience on big teams of developers working on MMORPGS. A smaller game with fingers-of-one-hand people working on it can probably get by with something much simpler.

Mark Storer
  • 237
  • 1
  • 8