Design of easily scalable game skill system from multiple perspectives

[[145670]]

A well-expanded skill system can well represent and adjust the relationship between skills, buffs, and props, which undoubtedly reduces a lot of overtime for game development. So how to design an easily expandable game skill system? Youzi.com sorted it out from the three perspectives of game planning, programming, and players:

Planning angle:

Author: Monkey and Flower-Fruit Mountain

I feel like this question hasn't been raised for a long time, but it's still worth discussing. I spent at least 5 years designing and practicing (I've experienced 7 projects, although most of them didn't work in the end for other reasons) such a mechanism and it can be said that it basically solves this problem! I don't want to hide it, I have shared it with many friends, and I also thank them for their many suggestions, including details and optimization. Because of mutual reference and communication, I have summarized this mechanism very well today, and I still want to share it with more people who want to make good games. I hope everyone can further communicate and improve it to form a standard. This mechanism is suitable for any type of game development because it is a great idea.

First, let's analyze scalability: From a designer's perspective, scalability means that you don't know what the next design will be, but you need to implement it without changing the core code as much as possible, and you can modify it without breaking a sweat during debugging (or even when you need to make adjustments after going online). In addition to having good code specifications, you also need to abstract a set of mechanisms to achieve it.

In fact, a good planner has a lot of imagination. You really don't know what kind of skills he will design, but you can't say that some designs should be buried because they can't be realized. (My requirements for planners designing Dota games are open-minded and imaginative.

Therefore, I came up with a mechanism like this: [Design Idea] The cage of game system design ideas is to pursue practicality blindly.

Their core lies in:

1. The three areas of AOE, Buff and skills are clearly distinguished, and planners should think about the problem from this perspective.
2. Since this is a set of mechanisms, you can use it in the framework of any game. For example, if I want to make a Dota legendary card game, I can also use this set of mechanisms, but the key is that your planner must be able to summarize the callback points in the game.

Of course, when we use this mechanism, there is no problem in the logical implementation, but we will still encounter some difficulties in turning logic into animation, especially when our battle is completed in an instant on the server, but the result must be told to the client, and the client must recalculate it. Therefore, I later summarized a set of practices to accomplish this task: Inductive design of mobile game turn-based game battle mechanism

This solves the problem that when you have various interesting buffs but don't want to make major changes to the client, you should build this framework in this way. You can imagine if you are making a MT type game, the battle is a moment on the server, but you want the client to replay it. Let's take an example:

For example, we designed a terrain factor to add to MT type games: there can be a sea of ​​fire, which causes fire damage to all enemy and friendly heroes on the field at the beginning of each round.

Then there is a hero who is a phoenix. The phoenix has 2 passive effects:

1. When taking fire damage, heal yourself for an amount of health equal to the damage dealt.
2. The first death in battle can be resurrected, restoring 50% of the maximum health. If in a sea of ​​fire, it will be restored to 100%.

How do we implement such a hero and terrain? If you have read the above several mechanisms and understand them, it is basically not difficult, and you don't need to hard code them at all. But there is a problem here, how can I make the client reproduce it? This is the key point mentioned above.

Program perspective:

Author: Kill the Darkness

Skills don't have much of a framework, they just have a lot of fields.

For example, CD casting distance, release animation, flying animation, etc. . .

In fact, game skills are not always difficult. After all, you just need to implement the logic according to each attribute.

The really troublesome thing about skills is the so-called "effect".

Because the concept of effects was added into the game design a long time ago.

For the main body of the game's combat object, we will temporarily call it BattleAgent, or BA for short.

There are many data that affect BA, such as movement speed, attack power, basic attributes, etc., and there are also many entry points:

Skill

Buff/Passive Skills

equipment

strengthen

gem

soul

And so on, which actually make no difference in affecting the results.

First, let's talk about the differences. For these numerical effects, the only difference is the entrance or the way they work.

Skills are the instantaneous numerical effects of BA (castor) on BA (target).

Buff is the continuous numerical impact caused by the caster on the BA (target) after installation, which is divided into instant triggering on time and continuous modification of numerical values.

Equipment is a specific container that continuously modifies the value of BA.

So here game developers abstracted the concept of effect.

For effects, there are only 2 behaviors:

1. Numerical impact on BA
2. Impact on BA cancellation value

So the effect is finally defined as:

 interface Effect {
 void cast(BattleAgent target);
 default   void reverse(){
 }
 }

For other functional entities, they can be simplified as containers of effects:

 interface EffectContainer extends Effect{
 List<Effect> getEffects();
 }

In this way, we only need to define different effect containers.

For example, skills:

 class   abstract Skill implements EffectContainer{
 public   void spellTo(BattleAgent target){
      foreach(Effect effect in getEffects()){
 effect.cast(target);
 }
 }
 }

For buffs:

 class   abstract Buff implements EffectContainer{
 public   void update(){
       foreach(Effect effect in getEffects()){
 effect.cast(target);
 }
 }
 }

For passive skills (actually also buffs):

 class   abstract BuffSkill extends Buff {
 public   void install(){
       foreach(Effect effect in getEffects()){
 effect.cast(target);
 }
 } 
 
 public   void unstall(){
       foreach(Effect effect in getEffects()){
         effect.reverse(target);
 }
 }
 }

The same applies to passive skills of equipment.

Is it clear?

As for complex skill effects, we have abstracted the Effect.

So it’s easy to implement!

 class DamageEffect implements Effect{
 private   int damage = 100 ;
 public   void cast(BattleAgent target){
 target.hp -= damage;
 }
 }

Looks simple, doesn't it? Let's write a sheep transformation.

This skill includes 2 effects appearance modification and attributes.

1. Change into sheep

 class ChangSheepEffect implements Effect{ 
    
 public   void cast(BattleAgent target){
     target.gameObject = GameManager.getAnimeObject( "sheep" );
 }
 }

2 Attack and defense become 0 Speed ​​becomes slower

 class PropChangeEffect implements Effect{ 
    
 public   void cast(BattleAgent target){
 target.atk = 0 ;
 target.def = 0 ;
 target.speed = 50 ;
 }
 }

It’s that simple, do you understand, classmate?

If we go deeper, the transformation into a sheep is continuous and will change back in time.

So we want an effect that can trigger the buff:

 class TriggerBuffEffect implements Effect{
  BuffSkill buff = new BuffSkill (){
 public List<>getEffects(){
 return   new List().add( new ChangSheepEffect()).add( new PropChangeEffect());
 }
 }
 public   void cast(BattleAgent target){
 int time = 3000 ; //3 seconds  
     target.addBuff(buff,time);
 }
 }

Then add this TriggerBuffEffect to the skill, and you have completed a skill that can turn you into a sheep for 3 seconds.

Player's perspective:

Author: Wutong

This article aims to express my analysis of some game skill systems that I am interested in as a player, not as an employee of a commercial company, a so-called programmer, artist or planner.

It depends on your pursuit. If you don't pursue configuring hundreds of parameters in an excel sheet, you can always write it out by adding one parameter when you encounter a requirement; if you pursue it, you can even make dota without source code like war3, a game from more than ten years ago (but there are always people who think it's no big deal); or if you fantasize like me, is it possible to design a skill system that integrates GTA (simulated reality) + Smite (moba) + Prototype (hyperreal action) and can be expanded by players?

Skills are such an interesting thing. A sophisticated and expandable skill framework can be said to be the greatest fun of the game. It is far from being able to get rid of the simple sentence "everything is a buff" in some Korean online games. So for a long time I have been enjoying exploring the implementation of skills in various games. Let me share some research clues.

I don’t talk much about the specific coding details, because as I said at the end of this article, after more research, I even began to reflect on whether the concept of skills exists, or whether the skills discussed in different game types are really the same thing? If games are really a reflection of real life, do we humans have skills as characters?

The simplest one is the FPS like Unreal Tournament. I feel like there is nothing much to say about this. Although the modified guns in Unreal Tournament are a fun point, the code level is not complicated.

For more complex Korean online RPGs or MOBAs, you can refer to the Galaxy Editor of StarCraft. Heroes of the Storm was made with this.

If you are familiar with war3 but not familiar with sc, just download ga's war3 mod (Warcraft III 2015). This is a complete reproduction of war3 under the sc system by the forum leader. You can observe how the skills in war3 are implemented one by one. Common ones include blizzard, air chains, sheep transformation, storm hammer, etc. In fact, simple online game skills are nothing more than variations of these skills.

Generally speaking, it decouples skill-related things into the following modules: unit, action, order, ability, behavior, effect, actor, and then expands the game through reflection and connection configuration.

To give a simple description of this system, it is very complicated, and I don't expect people who haven't studied it to understand it: ability is a skill in the popular sense, packaged as an order and called by unit, ability itself is not responsible for skill logic, it is only responsible for processing such as using the resources consumed by ability (such as how much magic is consumed) and the pre-swing and post-swing, it points to an effect, and is forwarded to the effect when ability is called; effect will be discussed later, let's talk about behavior first, a common behavior type is to add a buff, that is, a phased modification of an attribute, behavior is stateful; coming back to effect, effects eventually form an effect tree, common effects include launching projectiles, applying behavior, periodically calling the next effect, searching the area and then calling effect on each searched object, causing damage, creating units, etc., except for periodic effects, all effects are stateless, and they are just a simple function call to the logic. All the above descriptions are purely logical, and the actor is the performance body. All special effects and animations are responded to by the actor by listening to the signals of all the above objects, rather than the common animation-driven logic. In other words, if the actor does not listen to the signals of the logic layer, there will be performance problems, but the core logic of the game will still run, including the unit class, which does not actually include any performance information. It only notifies the actor to create and perform when the unit class is created. The actor is very similar to a completely passively driven client, and other modules are servers. Finally, in the entire asynchronous process, some global blackboard data similar to AI is needed to record, for example, the caster, casting location, target attack location, target attack object, etc. Because the effect behavior spreads downward in a tree-like manner, the blackboard data actually needs to constantly change the context, which is a bit complicated.

In addition, the skill action processing of the actor in the presentation layer is also quite interesting. It adopts the idea of ​​fuzzy matching of action names: it is roughly like this: sample the current status of the character (such as mood, weather, the name of the character's previous status, etc.), and automatically select the most appropriate and existing action according to the priority of the status type. For example, if the resource has both Attack 00 and Attack 01 actions, then a random attack is played. For example, in Heroes of the Storm, different actions are played for ordinary death, explosion death, and sky knock-up death. Of course, the design of the action module is a big problem. The middleware of major engines often makes a major change in a version. His solution also has limitations. The advantage is that it is easy to use. Ruby says: convention is greater than configuration. Imagine that when a player creates a new passerby character, this character automatically performs a specific fun action when seeing a beautiful woman, and all you need to do may be to configure an NPC and give him an action with a specific name, such as love stand. StarCraft currently has 296 keywords that can be combined with each other.

Let me talk about another small detail. Generally, self-developed engines have solved this problem better, but some people may not have noticed it yet: in the action assets of StarCraft art, in addition to skeletal animation, real-time calculation functions such as sound and special effects are also integrated in it, and the editor can preview it directly. In the upper-level skill framework, the performance status of many units (such as replacing models) are abstracted into "actions" (rather than simple skeletal animation). This intuitive design is very comfortable. On the other hand, some solutions (such as Unity's very common practice) directly use fbx as the end point of the art pipeline, which has great limitations. Even adding a simple special effect must be placed in the upper-level skill framework, and it cannot be previewed. It is best to add an intermediate layer related to the engine's real-time calculation function (mainly special effects and sound) that supports editor preview between bare skeletal animation and "skills". The results of this intermediate layer are finally exposed to the business layer as "actions". Unreal has done a better job in this regard. The editor supports preview of fbx's secondary processing, which is much more convenient to use.

After studying it, you will find that the plug-in interface, game recording (you can even join a certain camp from a certain point in the recording), network synchronization, automatic adaptation of performance information to machine configuration and other contents are also solved at the same time. However, when I personally copied it, I finally compromised on some cumbersome details of this solution. The final result is very similar to the skill system of dota2, so I won’t say more about it.

A MOBA skill system that can be expanded at will by all players, can't a professional planner do it well? This is probably the difference in game ideas. Let me add another fun thing. The author of the map "Legion TD" on the war3 platform made an online game dream tower defense, which is in testing.

As for the specific coding details, I have been studying them since the war3 era, and I have also copied them. It is not easy to explain them in a few words, but the core ideas are actually what I have mentioned above. As long as you make all the common skills by hand, you will have a conclusion in your mind. Although it sounds simple, if you have to position yourself as a programmer, artist or planner, rather than a player or mod author, this thing may be too complicated.

Some people say it looks a bit like some AI designs? Of course, whether it is AI or the so-called "skills", from the basic if else to the upper layer, there are layers of abstraction. In the final analysis, it is nothing more than to control the complexity of asynchronous logic. The means are similar. As for the messy theories in game AI, it has nothing to do with this topic, so I will not complain about it. Anyway, it is also a field full of chaos.

I really don't understand it and I'm too lazy to deal with such a complicated thing, so I'll just study the war3 we editor.

The general idea is to prepare some infrastructure such as continuous effects, instant damage, and unit generation, then design skill templates for common skills, and finally send out signals at a reasonable time, using triggers or scripts to expand the skill content.

If you are too lazy to design a skill template, it seems that there is nothing wrong with even writing a state machine for each initial skill. After all, a game as complex as Warcraft actually does not have that many basic skills.

The skills that will be expanded in the future will all be instances of these skill templates. The difference is that the signals or triggers emitted are handled differently at the script level.

This is how the skills for so many custom maps in World of Warcraft came about. Copy the configuration of an existing skill and then make slight modifications, although it may sound a bit silly.

I still remember the first time I saw the Dota butcher's hook, I was amazed by it.

When it comes to studying we, ga is also the main base, but it is discussed less now, after all, it is old, and everyone has turned to sc.

More complex than MOBA skills? Is fighting like Mugen enough?

In the Mugen section of B station, everyone is having a lot of fun. I have read some reverse-engineered fighting games on Unity. The Korean online game Soul Heart is a good one, which uses state machines. Domestic games such as Kingsglaive and Shadow Blade are actually very easy to reverse, written in Unity. There is also a fighting plug-in on the Unity platform that is also well written. I read an early version, which is a bit difficult to read without using state machines, but many details related to fighting business logic are handled quite well, such as skill cancellation, frame advantage (Frame Advantage is translated correctly, the concept of Street Fighter), physics, and the new version should be even better.

Although I have read a lot of fighting-related codes, I have never actually made a fighting game, so it is difficult for me to give more reference opinions.

Some personal reflections, which may be a bit unclear and messy, and may not be useful for real game making, are put here for the time being: no matter how complex the game is, the so-called skills are essentially asynchronous logic that has cancellation requirements on a time line, requires strong expansion design, has extremely complex branches, and supports configuration. There may also be parallel interactions between these asynchronous logics. Looking further, the existence of game units in the game world is itself a state (for example, Yunfeng's skynet game server generates a luastate agent for each unit, and cooperates with coroutine to realize asynchronous pulling to synchronous without blocking). Many skills are sub-states generated by the unit state body. In this way, it will become more interesting to understand the behavior of the unit (such as walk, idle, and not just the skills in the popular sense), as if everything is moving forward in parallel along the time, just like human society, without callbacks and interruptions, and the context of all logic becomes natural (the complexity of asynchronous operation often comes from the loss of context).

If this set of assumptions is true, there are many explorations in various industries to simplify asynchronous programming, and the gaming industry may not be the best. For example, I have practiced a skill framework based on the actor model (coroutine simulation) as an amateur. Although many details have not been resolved so far, it is indeed a very interesting exploration.