Porter's Everyday--turn-based combat skill implementation

Turn-based combat skill implementation

The logical part of our game is placed on the server side of the processing, in fact, the front end is only a performance effect, can be said to be just a player. But you can actually add a logical module locally and put all the logic on the local processing.

In general, after the logic module processes the skill, the display module will get the following data

1. Skill ID

2. Active role: Which role in the battlefield releases the skill (in fact, this has multiple roles to achieve the same effect as a fit technique, but our project does not have this kind of demand, so we only deal with one)

3. Passive role groups: which roles in the battlefield are affected by the active character's skill (is it hurt?) or the treatment? Or did you add a buff? ）

Let's take a look at our first version of the combat skills implementation, the most original version, where melee and ranged attacks for example

1. The type of this skill (melee or remote, or all) is obtained by reading the table with the skill ID.

2. Move the card to the front of the target

3. Card Play Attack action

4. Card play action at the same time, play the effect before the card

5. Effects of damage frame play hit card injury animation

6. Card return, next round

Remote attack

1. Card Playing and fluctuation

2. Special effects fly from our card to the target card (there may be multiple)

3. After the effect keyframe is triggered, the hit card plays the injured animation

4. Card action homing, next round

All attacks Ibid, just take the enemy array is playing a whole special effect

......

This original version has a few drawbacks

1. Each type of skill requires a single set of implementations, similar to flight time such details can be achieved by increasing the skill parameters, but the implementation is similar to the Tasikmalaya row, the vertical row and so on need to add a new skill type, big class bang!

2. Even the same kind of attack requires a lot of small details to be dealt with.

For example:

A remote skill needs to play a special effect before releasing the missile when it is released.

A melee skill needs to play a power-up animation before the target card to launch an attack.

A total skill requires the release to go first to the center of the screen, then the skill effect, while another skill is to go to the center of the enemy camp

......

3. What about the changes? If some of the skills need to change, the planners will come running on the fart, very happy to point out your details, and then all kinds of unrelated people come to blah .... It's a pain we all know to get people to die.

These major flaws eventually forced me to abandon the first version of the battle to achieve, although the level of combat complexity has been and the target game "let go of the Three Kingdoms" almost, but it is very poor scalability, forced to overturn the original design into the second edition.

Design goals for the second edition

Experienced the first version of the tragic experience, I set the second edition of the following design goals

1. Planning can be through the table, independent realization of skill rights (no, no, don't bother me!) ）

2. High abstraction, abstract all implementations into several classes to avoid continuing the first class explosion (functional cohesion)

3. For the characteristics of programming, not for the implementation of programming, do not engage in specialized skills of the code implementation (give you tools, self-implementation)

In fact, the goal of these requirements is exactly the same, that is, the implementation of a skill toolkit, planning the independent combination of cards and effects of the dynamic effects, to independently configure skills. First re-analysis of the first version of the battle.

Melee battles

1. Get the type of this skill (...) through the Skill ID reading table. ）

2. The card moves to the front of the target (the card moves)

3. Card Play Attack action (the card plays an action)

4. Card play action at the same time, play the effect before the card (the card plays an action, produces a special effect)

5. The damage frame of the special effect plays the injured animation of the hit card (produces a special effect)

6. Card homing, next round (card moved, skill ended)

Abstract semantic analysis, there are so few simple processes:

1. The card has moved.

2. Card Play action

3. Create a skill effect

4. The skill is over.

Further analysis will find: Card movement and card play action can be combined into the same, card action

We can view

Card play in situ do action is a special case of card action

Card movement but not play action is also a special case of card action

This process is abstracted as

1. Card Action

2. Result in skill effect

3. End of skill

These three processes

Then analyze the remote

Remote attack

1. Card Play and put fluctuation (card action)

2. Special effects fly from our card to the target card (resulting in skill effects, skill effects moved)

3. When the effect keyframe is triggered, the hit card plays the injured animation (card action, resulting in a skill effect)

4. Card action homing, next round (card action, skill end)

With the above analysis, we will find that the production and movement of skill effects can also be combined into one, that is, the skill effect, static skill is a special case of mobile skills

So in the end, only three abstract tools are left in our skill kit.

1. Card Action (Movement and action)

2. Skill effects (creation and action)

3. Skill end (skill end)

In other words, melee attacks and ranged attacks are made up of these three processes, and all the skills not previously mentioned can be analyzed.

1. Card Play cast action--card action

2. The Schfart effect is played above the card.

3. Play all effects---skill effects on the target card deck

4. Play the effects of the injury effect on the target card group

5. end of skill, skill end

Using three of the descriptions in the Toolbox is completely possible!

Here we are faking a relatively complex skill:

The active card releases a set of missiles, hits all enemies, moves to the center of the enemy camp, releases a full-screen effect, and finally, from the last side of the screen, summons an eagle (special effect), flies behind the enemy and attacks all enemies.

The analysis is as follows:

1. Active Card casting action, card action

2. Release a group of missiles------skill effects

3. The active card moves to the enemy camp is in the middle of the card action

4. The enemy is playing the whole skill effect

5. Effect trigger frame, enemy all cards play injured animation, card action

6. Create an eagle effect, move from the rear of our screen to the rear of the enemy--skill effects

7. Eagle effect trigger frame play injury effect, card action

8. Active card------card action

9. End of skill, skill end

We can see that basically satisfies the requirements, so we can semantically describe most of the skills of turn-based games in a completely abstract

Next, the implementation of the following three tools is described

Table structure

According to the above, the card action is mainly divided into two parts, one is the card animation action, the other is the card execution of the displacement.

Card Animation action

We are using the Cocostudio implementation of the animation, each card animation is packaged well, to perform an action plan only need to fill in the action name of the current card execution can be

The displacement of the card

The displacement is more troublesome, because we can not let the planner fill in the coordinates? But in fact, the starting position where the card displacement may appear is a finite set, which can be fully predefined, as follows

1. Active Card Location

2. Destination card location (the target card is usually a card group, this return is the first one)

3. Destination Card Group column position (take first card, then calculate current column position based on location)

4. Target Card group row position (IBID.)

5. The screen is in the center

6. Our rear

7. Rear of enemy

8. The enemy is central

....

The above list some possible card location, the specific implementation, you can add flexibly.

To give a practical example, a card action is to move from the active card position to the center of the screen (0.5 seconds), and play the Mobile Action (walk), planning the Card action table as follows, move represents the starting position

Cardmove.xlsx

ID |  Act | Move | Time | Other ...

---------------------------

1 | Walk | [1,5] | 0.5 | Other ...

* The act of the card here is filled with the name of the action tag.

So when the skill's state machine executes here, it knows how to move.

Similarly, an eagle special effect from the rear of the screen to fly the Enemy Center (0.5), planning the form of the effect table as follows

Effect.xlsx

ID |  File | Move | Time | Other ...

---------------------------

1 | eagle| [6,8] | 0.5 | Other ...

* Here the file is filled in using the name of the animated files

The skill state machine reads the corresponding structure in turn and then plays it ....

Wait a minute! Not yet spoken call!

Oh, yes!

The invocation is also very simple

cardmove.xlsx

ID |  Act | Move | Time | Callback | ...

--------------------------------------------

1 | Walk | [1,5] | 0.5 | [effect,1] |

ID |  Act | Move | Time | Callback | ...

--------------------------------------------

2 | Walk | [5,1] | 0.5 | [over,1] |

Effect.xlsx

ID |  File | Move | Time | Callback |

--------------------------------------------

1 | eagle| [6,8] | 0.5 | [cardmove,2] |

The simple process is:

Cardmove[1], effect[1, cardmove[2]

This implementation is somewhat similar to a linked list, callback specifies the next function of the skill state machine to execute until over, and the skill state machine begins to perform the next skill.

The actual Cardmove table and the effect table are far more complicated than this, and in a real project our callback is an array with a delay time as follows:

[[1.5,[cardmove,2]],[1.5,[effect,2]],[1.0,[effect,3]]

This callback delay calls three functions, implements a card move and two skill effects, and the previous value is the time of the delay call, which can produce the effect of the Tiannvsanhua class.

You can consider how the following skill effect is achieved by using a table

The active card launches a missile, hits the center of the screen, triggers an explosion effect, and then launches six missiles from the explosion effect to hit the enemy's six targets.

Later, there is time to send out the sample code, based on the quick cocos2dx LUA implementation.

At the request of a friend, the next attempt will be to use this similar mechanism to try to achieve some of the skill effects in lol, allowing the planner to freely configure the desired skill effect.

This article is from the "Porter's Game blog" blog, please be sure to keep this source http://jyzgo.blog.51cto.com/1390359/1590223

Porter's Everyday--turn-based combat skill implementation