Shulou(Shulou.com)11/24 Report--

Warboard SLG is a type of game with a long history in the game field. The famous games include "Emblem of Fire", "Dream Simulation", "Robot Wars", "Royal Knights", "Yan long Knights", "Advanced War", "Wind Fantasy" and so on. I believe that one of the dreams of many game developers when they enter the industry is to develop a fun chess game. So how to design and develop a chess game? What do game planners and game programmers do when developing a chess game? Is there a better framework for chess games?

This article will introduce to you a set of development and design ideas of chess games, based on the design of a flexible and easy-to-use framework of chess games, and explain in detail the contents of the core game development process of chess games.

First of all, we have to define the data structure in the game, as I often say, "when the data structure is designed, the game is half done", because the data structure comes from all the elements of the game. Of course, we know that different chess games are different in many details. For example, in the Fire stripe series, the support of adjacent units is emphasized in later works, while in the Dream Simulation Battle (non-domestic mobile games) series, it emphasizes the feeling that each unit has only 10 drops of blood and the feeling that the commander leads the soldiers. But in fact, the difference between them only lies in the planning of the design in many details.

The core data of chess games

In the core of chess games, that is, the chess mode is supported by four categories of data, namely, level data, map data, character data and animation data.

Animation information will put animation information in the first place, because the performance of the game is also a very important link, and any design in the game should eventually return a section of animation for the performance of the game. For example, at the beginning of each round, we will calculate that if this round needs to start raining, then there should be an animation that starts to rain, which produces an animation message. with this message, the animation playback system starts to play the rain, and then enters the real start state of the round after playing the rain.

The essence of animation information in turn games, animation information is essentially a Timeline, that is, a timeline, this Timeline is composed of several nodes on the timeline, when the Timeline starts to play, time advances, and when the time advances to the point in time of a node, the event of this node is triggered. If the node is an end node, then the Timeline is completed and goes on to the next step.

No matter what turn-based game, the necessary data for the Timeline node are:

Time: the unit is usually Tick, that is, the number of Update (the number of fixedUpdate in Unity). Game development is different from the real world, in which Tick is the minimum unit of time, while in reality we usually use seconds as the minimum unit of time.

Events: that is, what this node is going to do, which usually includes several categories:

Create a visual unit, such as characters, special effects, pop-up numbers, etc., and create this somewhere on the screen.

Delete a visual unit: stop an existing visual unit.

Move a visual unit: let a visual unit move, for example, we create a fireball to fly from the launcher to the target, this is just a fireball visual effect that passes through a track and reaches the target position. It is then removed, while creating an exploding (hit) visual effect unit.

Change the action of a visual unit: such as changing a character to an animated sequence.

In the process of running the game program, many of the calculation results should eventually produce a Timeline, and then play the animation according to Timeline to show the results to the players. As we said above, what the player sees with the naked eye is that a fireball is launched and hits the target, and the player will think that the fireball is an actual unit, and he is sent out by a character and finally hits the target to produce an effect. but in fact, this fireball and the fireball running in the logic layer are not the same thing, it's just the most basic visual deception in the game, before the animation is played. Fireball has already hit the target, otherwise there would not be this animation-this is the way the round game works.

Map animation and war animation distinguish between map animation and war animation, in fact, it is only because the event values and processing objects of Timeline are different. Because in some games, fighting has a special performance mode, it is more like the automatic combat system in our domestic mobile games, just showing a series of pictures and presenting the results to the players. but this presentation mode is completely different from the core mode of chess. Of course, there are also some classic chess games that support direct combat on maps, such as Fire stripe series, Robot Wars series, the Tale of Seven Heroes, and so on. If there is no special performance module for the character of a chess game, there is no need to draw on the war.

(in Fantasy Simulator 2, you will enter another "Mini Game" state after the war.) the core of the level data chess game usually describes the process of a battle, and the complete process of a battle. It is also usually a level for many chess games. While the game is running, we need some data to use as information about this battle:

Round number We know that chess games must be round-based, so there will be a concept of round number, but the concept of turn number is not commonly used in chess games. In traditional chess games, it is usually the turn of one camp to act after the other, such as Fire, High Battle, Robot Wars, and Fantasy Simulator series. This is the case-the end of the round after all the characters of the player are done. it's the enemy's turn, and there may be allied action after the enemy's action is over. When it's the player's turn to move again in this lap, it's the number of rounds + 1.

But there are also some other chess games, such as "OL of Jinyong Group", the battle mode of the track series, and "Fantasy Simulation 4" all adopt the ATB mode, that is, the traditional round concept is abolished, and the action order is determined according to the agility of the characters. Some fast characters may act three times, while slow characters only act twice, thus breaking the traditional round concept. So the attribute "number of turns" no longer exists here. Replaced by the ATB (Action Time Bar) value, the ATB value is also equivalent to a "number of turns", but this value will be much larger than the number of rounds, and the advance rule may not be + 1 per round.

The target conditions are victory conditions and defeat conditions, although most of the victory conditions of most chess games are "total destruction of the enemy" and failure conditions are "our total annihilation" or "the protagonist is dead". However, there will still be other conditions, such as moving everyone to a certain cell, holding on to how many rounds is victory, and so on. The winning or losing condition of a level is a decisive data. Because we have to check whether the battle is over (the player wins or loses) after each character has completed the action and at the end of each turn (which can also be the beginning), that is, the target condition has been achieved.

(each level of the chess game has its own unique winning or losing conditions.) the current action camp is popularly called "whose turn to go now". Board games are usually played on a single machine. There are also similar "Hero Invincible" series and "Civilization" series have more players to play, this time is to take turns to act. So we need a current action camp, such as Player1,Player2, to identify the current actors.

Level script is a relatively easy to ignore existence, but in fact, the vast majority of game games with plots are about card scripts. The level script is that when the game meets certain conditions, some events will be triggered, which is usually related to the data of the whole game, such as "in the 20th round, if Master Lu has not been defeated, the enemy cavalry will all retreat." it's all about the level script. The necessary data for the level script mainly include:

Trigger turn (ATB): triggers the script in which turn, or from round to round. In our example above, the trigger round is = 20.

Trigger conditions: only when these conditions are met will the event start. In the example we cited above, the condition is "Master Lu survived", while in actual game production, multiple conditions should be supported.

Trigger events: when the conditions are met, some events will be triggered. The triggered events mainly do two kinds of things for the program-one is to do some data processing, such as adding some characters to the court or deleting some characters, and the other is to generate animation information. As we said above, after the logic of the game is executed, it should generate a Timeline, and then play the animation to the players according to the Timeline.

(every certain round of the chess game triggers some scripts. Of course, the scripts include not only scenarios such as dialogue, but also increase, remove troops, generate AoE and other events.) Weather and other game-specific data in addition to the above main information, different games can also expand some other information to the level in the game. For example, there is a weather system in the Biography of Yingjie of the three Kingdoms, Kong Ming of the Chronicles of the three Kingdoms, and Cao Cao of the three Kingdoms, so we need a weather attribute to support this design.

(in the Chronicles of the three Kingdoms 11, the effect of the fire meter will be affected by the weather and wind.) Map data is a very core existence relative to chess games, just as the chessboard is relative to Chinese Chess. Usually in a chess game, the map is made up of a two-dimensional array, that is, what the map block is corresponding to the map's (xPowery) coordinates. the advantage of this is that the corresponding cells can be found through the array subscript. Although some games are visually three-dimensional, such as the Royal Knights series "final Fantasy Strategy" and other works that mimic the Royal Knights, their maps are actually two-dimensional, so they don't need a three-dimensional array. They simply add a "height" value to the plot data, which will be concerned by systems such as pathfinding.

Map block data each element of a two-dimensional array of a map is a map block (Tile) data, which is contained in a typical chess game:

Mapping information: the graphic information of this map block, such as muddy ground, forest, etc., is visible to players with the naked eye, and does not even have to have text messages such as names.

Mobile consumption: this is usually a key value structure, because in chess games, one of the basic elements we use to distinguish a unit is the mode of action of the unit, such as walking, tires or tracks, or horseback riding, flying or swimming, etc., according to different game designs, there will be different modes of action, each mode of action when passing through this map block, the movement force that needs to be consumed is mobile consumption. This will be used to find the way.

Attribute change: in most flag games, different terrain will bring different attribute changes to characters on terrain units, such as increased defense.

Other information: according to the actual needs of the game, there will be some other information, such as the name, if you need to display it, and in some games, there is the concept of a portal. For example, the staircase of level 11 in IF Night of Flame is a portal that the character can transfer to another non-adjacent map block.

Map block data is data that planners need to fill in the form and design in detail, just like map data, but in fact, the map data is not always constant when the game is running, depending on the progress of the game, it may trigger some changes-such as the village was destroyed by mountain thieves (from a good village topographic block to a destroyed village topographic block) The treasure chest has been taken away by the player (from a closed treasure box terrain block to an open treasure box terrain block), etc., this information should not be placed in the map block, but in the map information, the result is to change the terrain block data.

(the "flat ground" in the lower left corner is the UI of the current cursor location.) AoEAoE, short for Area of Effect, derives its concept from the player name of World of Warcraft. It means that an event within a certain range, such as a meteorite hitting the ground, will produce a sea of fire with a cross cell (center grid + up and down a total of 5 squares). First, the map block will become the smashed ground, and then the flames of the fire will be AoE, causing damage to all characters in the AoE range. Therefore, in a chess game, the existence of AoE is necessary, not only because of skills, but also because of the level design, such as volcanic eruptions, etc., will need to generate AoE to enrich the content of the game. The attributes necessary for AoE in chess games include:

Visual representation: usually we will understand that an aoe always has a performance, such as the fire we just exemplified, and the rocks erupted by volcanoes, etc. But in fact, the vast majority of aoe do not need visual effects. For example, a character exerts the skill of "inspiring the army" to increase the attack power of all friends in the 8-grid range around him. He may not need any visual expression of this aoe at all. He only needs to play some special effects on the character to show that he is inspired, and the "person in charge" of this special effect should be the buff that the character is added. Instead of aoe (it's not that you can't do it with aoe, of course, the approach is flexible).

Scope: [runtime data], the scope is a run-time data, not planning to fill in the table data. Many people may not understand when they see this, why can't I define the scope of aoe in the first place? In fact, the reason is very simple, such as the effect of the blizzard, it is an aoe, but how big is the snowstorm? It is possible that low-level wizards and senior wizards are different, while senior wizards equipped with a secret book will have a wider range, so the scope of AoE is actually determined when the AoE is created, rather than by the planner filling in the form data, so the planner does not have to fill in 16 pieces of data because a skill may type 1-16 boxes. And there is another "amazing" concept of range-that range is not a map cell, and that aoe range is not just a shape in diablolike games, such as "all female characters in the game" is also a range. Because the essence of AoE is to capture qualified characters, the location of these characters (what we usually understand as "scope") is just one of the conditions.

Location: corresponds to the range to form the actual range. Not all aoe need a location, but the aoe pointing to the map area should have a coordinate. The position can be moved, for example, in the Chronicles of the three Kingdoms 11, the flame will be blown away by the wind, which is a position change.

Work items per round: aoe is allowed to run once in each round, so there will be this trigger point of OnTurn, which points to a script written by the planner (aoeObj, targets, turnId) = > Timeline, that is, the parameters passed to the planner script are the aoe entity, all roles within the aoe scope and the current round. The script executes the content based on this information and returns a Timeline for performance. For example, pricking terrain deals 5 damage to all targets in range per turn. Write this logic here.

Character entry event: when a character falls within the scope of this aoe (or here, depending on the game design, so this is also a detail of the planner to design), it will trigger the aoe role to enter the event, execute (aoeObj, character, targets) = > Timeline, that is, give the script the parameter to this aoe, enter the aoe role and the role already in the aoe (excluding character). For example, if this is a landmine and the character goes up and explodes, then the script is executed to cause damage to character; for example, this is a pair of agencies, with a total of two aoe with id, each entry event is to check whether the character in the aoe range of the id in the map is up to the standard (for example, if at least one unit is targets.length > 0), the activation mechanism will be activated, such as turning a topographic block into a treasure chest.

Event when a role leaves: triggers (aoeObj, character, targets) = > Timeline when a role leaves the scope of the aoe, where character refers to the departing role, and this character is not included in the targets.

AoE is a very core design content, if used properly, the content of the game will be greatly enriched. Of course, it's not impossible not to use AoE at all. There are a lot of classic chess games that don't use AoE.

Role data characters are relative to chess games, just as chess pieces are to Chinese chess. The character is a very core element, whether it is the enemy or the player's character or npc, but all the elements of character rules that can participate in the game, such as battles, are characters.

(the role is one of the core elements of chess games) the camp is often a design that is ignored by planners, but in fact, it is another element that has to be designed at every level of the flag game, even though it is very simple. The so-called camp, to put it bluntly, is "who is a group of people", for example, the player is in a camp, and the enemy is also in a camp. However, in a chess game, there are often not only two sides, but there may also be similar "our reinforcements", thus creating the possibility of at least three sides fighting each other, but as our reinforcements, why not attack the player but only the enemy? This is determined by camp relationships, which determine some permissions between cross-camp characters, such as whether they can attack or not. Common camp relationships include:

Right to attack: whether Camp A can attack the characters of Camp B, such as a group of villagers who are persecuted by the Empire at some point in the game, and then the player army will destroy the Imperial Army. So here the villager camp will not attack the Imperial camp and the player camp, which is to show the weakness of the villagers; while the player camp cannot attack the villager camp, it can only attack the Imperial camp, which is to show that the player is here to save the villagers. but the Imperial camp can attack both villagers and players.

The right to cure: whether camp A can treat camp B. In many classic chess games, there will be some special reinforcements that help players and join the player team if they survive after winning the battle, but what makes players very urgent is that these characters cannot be healed, which makes it more difficult to save their life and death, which is one of the interesting points of this kind of level.

Leapfrogging right: whether the character of camp A will regard the role of camp B as an obstacle. This is usually a problem when the character moves. If the character of the B camp is not regarded as an obstacle, the grid of the B character will be regarded as a passable cell when finding the way, although it cannot end up on this grid. In some classic chess games, there are enemies that affect the movement power of the units around you, that is, when a character tries to bypass a "hostile" unit, it consumes more movement power.

The camp relationship is two-way, that is, when camp A can attack camp B, camp B may not have the right to attack camp A. When the camp relationship is determined, the relationship between the roles can be determined through the "camp" value of the role attribute.

(using different colors to express different camps is already a familiar expression for players.) the data of characters vary from game to game, but basically as long as it is a chess game, it should have the following types of attributes:

Modeling: the information of the elves used by the characters on the map, some games use the unique modeling of the characters, some use the image that represents the profession, in short, modeling is needed, after all, it is a "chess piece".

Role attributes: this should be a struct, such as attack power, defense, etc. are all attributes of this struct. When planners need to add attributes, you only need to modify them in struct. Role attributes are subdivided into several attributes on the character, including:

Character-based attributes: that is, the character's "naked" attribute at the current level. There are many chess games, such as the Gaozhan series, where the character is always "naked" because it is not equipped with a system.

Attributes from equipment: in some chess games, the character still has equipment, which comes from the sum of the attributes of the equipment.

Attributes from Buff: character attributes from the buff on the character, there can be several, such as those for addition and multiplication, which are related to the numerical design of the specific game.

Finally, we pass these attributes to a script function, which returns a character attribute struct as the "current attribute value" used by the character in the game, and this script function is exactly the character attribute relationship that the numerical planner wants to design.

Movement force: includes a movement type and a number, corresponding to the movement type consumption in the map block. A character can only have one type of movement, and even if it is similar to Gaeta in the Robot Wars series, it can deform and cause a different type of movement, which is also because the type of movement of the character has changed after the transformation.

Camp: the camp to which the character belongs, combined with camp design, has some permissions for the character in this game.

Buff: it depends on the complexity of the game, but in modern games, there should be buff. For example, the character's Passive Skill, the character's temporary state (bloodshed, poisoning, attack enhancement, wind anger, etc.) are all buff.

Health: the current health will die if it is lower than 0. It is believed that most characters in chess games will need this attribute.

End of this turn / current ATB: for traditional chess games, that is, games in which the next camp acts after each camp has finished, the character should have a mark (at runtime) as to whether the turn is over, and the finished character cannot continue to act unless there are conditions to set this flag to false again. For ATB games, it is the ATB value of a character (or the remaining ATB value). When the ATB value reaches the standard, you can act, otherwise the character cannot act.

According to the specific design of the game, should also expand a lot of properties, here will not be listed one by one.

(of course, in addition to the attributes mentioned above, a lot of character attributes can be added according to the details of different games.) in the player's understanding, Buff refers to the gain or decrease of a character, even as simple as the change of character attributes. But for the game logic itself, buff is more like a special symbol, and these special symbols stored in the characters will play a logical role in some processes. For example, the simplest poisoning state is a damage value calculated by a formula for the role of the buff carrier at the beginning of each turn. Usually junior game planners and players "design" some skills, often with a "Blizzard update document" style description, such as "50 damage per turn to the character", but as professional designers, our concept should not be the same thing as "Blizzard update documentation", but should be transformed into a "buff mechanism" that can be implemented. For example, "the scorching sun does double damage to burning characters", this is the standard "Blizzard update document" paradigm, but what should we designers' minds look like? There is a buff, and this buff is a sign that doubles the damage if the source of the trigger (see damage information) is a scorching sun in the trigger of the BeHurt.

In chess games, the attributes commonly required by buff include:

Buff freer: run-time data, a role message, can of course be null. That is, who is the caster who caused the buff, because some buff comes from the script creation of the scene and other factors, they do not have a "responsible person" to say, or plan to deliberately make some buff do not need to be released at the time of design, then the release of buff should be null.

Remaining round / remaining ATB: runtime data, that is, the buff life cycle (duration), minus 1 per round (1 per ATB in ATB). When the life cycle of a buff ends (when 0), the removal event of the buff will be entered first, and if the removal event returns true, the buff will be removed.

Tag: string array, what is expressed here is what the buff is, which is entirely determined by the game design, just as the content on many websites has a tag, such as "footwear", such as "Capcom" and so on. Although the content of Tag is "free", but the purpose is serious, for example, when we want to design "remove all poisoned states of the character", what is the poisoned state? We may have a lot of buff (their id must be different) that are considered "poisoned" at design time, so how do we remove them? That is, they all have a "poison" in their Tag. What I want to remove is the return content of GetBuffsByTag (character): Array.

Custom recording parameters: this is an open Object, which is used to record some data needed by buff, such as how much more damage can be absorbed by shield buff. For example, we give the character a "purgatory shield" that absorbs 100 fire damage and 100 physical damage. We don't need to do 2 shield buff to achieve this, just need {"Physics": 100, "Flame": 100} to record it.

Run interval, run event and number of runs: these three attributes work together. The run interval refers to how many rounds (per ATB) to execute the run event, and the run event is a script function (buffObj) = > Timeline, that is, the buff entity is thrown to the script, and the script performs the corresponding function. After each execution, the number of runs will naturally be + 1. The number of runs is a run-time data, while the run interval and run events are the data generated when planning to fill in the form. When creating buff, it is Clone to the buff entity, because we can have other factors to change. For example, the original searing effect deals 50 damage to the character every 2 turns, when we use catalytic magic on him. It has become 25 damage per turn, when the interval and number of runs have changed. The reason for the number of runs is that the planner may design an effect similar to the pain curse spell in World of Warcraft-deals damage to the character each turn, and the damage value increases gradually.

When launching an attack (OnHit): the event that occurs when an attack is initiated, (buffObj, damageInfo) = > Timeline, passing buff and injury information to the script, which rewrites the damageInfo and creates the Timeline to execute. The most common usage is "have a 30% chance of causing double damage," that is, random numbers.

< 0.3 时伤害信息的对应伤害值翻倍；"对于有燃烧效果的敌人造成额外 40% 伤害"，即目标如带有含"燃烧"Tag 的 buff，伤害值乘以 1.4；"攻击不会落空"，即伤害信息中的是否命中设置为 true。通过攻击发起时，可以给角色赋予很多特性，比如攻击女性角色时伤害降低 20% 等。 被击时（BeHurt）：在角色受到攻击的时候触发的事件，(buffObj, damageInfo)=>

Timeline, which is similar to when launching an attack, except in the process (see the damage process below). The most common ones are "damage reduced by 50%", "rebound damage when damaged" and so on.

Here, I list the three most commonly used trigger points, which does not mean that buff has only these three trigger points. According to the specific needs of the game design, the designer should clearly define the trigger points in the process. For example, if I want to avoid death, I have to have the trigger points before the character is defeated (BeDefeated), and if I want to double the experience of defeating the enemy, I need to have (OnDefeat) and so on. But it is worth noting that do not define too much, think carefully before you want it (for example, if you need a trigger point, think of three uses to increase), because the more trigger points, the more flexible the design, the less efficient the game will be. Designing a good trigger point is one of the core tasks in the early stage of game design.

Injury information injury information is the details of an upcoming injury (usually from an attack). Through this information, the injury processing system goes through an injury process to produce injuries and results. This is usually a completely ignored existence, even many old classic games, will directly calculate the damage without the need for such a "redundant structure". However, with the accumulation of game development experience, this harm information will become more and more necessary. Its necessity is that there are so many variables (generated by planners and designers) in the game, and when these variables are combined to form a "build", it will be very scary. For example, when a planner designs "Wind Wrath" for a character, he has a 30% chance of generating an additional 2 attacks, and the target of his attack is also added a buff, when it is damaged. The damage will be spread over the "Soul Link" character, and his "Soul Link" character has a buff, and when the attack initiator takes damage, the attack initiator will also receive 30% of the damage. A design like this is fun to play, so the idea of planning should be supported, so we need a good management mechanism.

The main attributes in the injury information (DamageInfo) include:

Attacker: that is, the maker of the damage, this can be the null, because it is very likely that the damage is triggered by some plot or event, and we expect the damage to go through a buff process, rather than directly writing how much blood is deducted, then the attacker should be the null, not the victim himself.

Victim: the recipient of the final damage, which must exist, otherwise a DamageInfo will be meaningless, and in the actual operation process, if the recipient has been defeated and other factors make it unnecessary to damage him, then you can "optimize" the victim is most of the character's damage information.

Hit or not: get the hit result through the script function (attacker, defender, source) = > boolean, and throw it to the script attacker, victim, and damage source (source, such as "normal attack", "Buff bounce", etc.). If a hit is returned by the script, it is worth mentioning that even if the hit is false, we must also obtain data such as damage value and critical strike, because "hit" is only a reference here, not the end of the process, and it has nothing to do with the injury. It is also because this value may be changed in the buff process (see the injury process later), so it is discussed one by one. Hit is hit, damage is injury, critical strike is critical strike (and one of the classic arguments about "critical strike because of hit" or "hit because of critical strike" is decided by the planner according to damage information and game design rules, and it is nothing more than an if problem). Of course, it is not necessarily a boolean here. If many buff in planning and design will conditionally increase the hit rate, such as "20% increase in hit rate for targets whose health is higher than their own," here can be a number, that is, the hit rate, which can be calculated at the final settlement.

Damage value: a damage value obtained through the script function (attacker, defender, source) = > Object, thrown to script attackers, victims, and damage sources. The return value is an Object, because there may be a variety of damage types in a game, such as {"Physics": 30, "Flame": 20}, and there may be some buff in buff that "increases Fire damage by 50%". The result is to change the damage value of this damage message from 20 to 30. This damage value is the basis for the final "blood deduction", rather than directly withholding blood from this damage value.

Critical strike: get the critical strike result through the script function (attacker, defender, source) = > boolean, the principle is the same as "hit or not", it can also be a number, depending on the specific game content design.

In addition to the necessary information, some other required information can be expanded according to the specific design of the game, which will not be explained here.

It is worth mentioning that any "normal" injury request in the game should produce a "harm message" rather than a direct injury, because this can avoid a wrong recursion. Let's take an example: a target has 6 buff, of which the third "hit" effect is likely to be subjected to an additional attack, with a damage of 40% of this time. At this time, what this "hit" needs to do is not to directly "buckle blood", let alone directly increase the damage value of the damage information by 40%. This is not what the planner thought, and there is another damage when the planner wants it. This damage also goes through all buff procedures, and more importantly, this damage should occur after the other 3 buff perform "hit", and after other registered damage information, this is a process problem, so a new damage message should be generated at this time.

(each attack of the character can generate a damage message, whether hit or not.) the state and flow of the game when we have defined the data of the game, all the elements of the game are in place, and the train of thought is clear. next we have to connect them together. From here, it is time to enter the program to realize the process of this game, but this does not mean that there is no need for planning to design the part, so the planner should clearly understand how the game is implemented, although there is no need to go to coding. Next, we will explain the development details of the war chess game from the state to the process.

Here, we focus on the traditional battle chess game, which is alternately played by the camp, and the ATB class will not make a full description.

The main state of chess games

The state at the beginning of each turn, in which there are several main tasks:

Broadcast the number of rounds and which camp action: of course, this is more of a UI design problem, if you do not need to broadcast, you can completely ignore this step, depending on the needs of game design, but most classic chess games are based on this step, from the rationality of UI, at least tell the player whose turn it is.

Turn increase: increase the number of turns according to the turn increase rule, not every turn will increase the number of turns, usually only the first camp (generally speaking, the player camp, that is, the player's turn to act) turn + 1. However, the "round" in the "number of rounds" is often not the same thing as the "(logical) round" mentioned here. Please pay attention to the distinction (most of the "rounds" mentioned below are logical rounds).

Execute the level script: if the relevant card script reaches the conditions that need to be executed, the level script is executed and a Timeline is generated.

Execute all AoE's "work per turn" events on the map.

Traversing and executing the Buff run intervals of all roles (if they match the run round) are generally executed only for all roles in the current action camp (that is, role camp = current action camp). How this is implemented ultimately depends on the rules of the game designed by the planner.

Perform things specific to the game, such as weather changes, that need to be done at the beginning of the round.

We can see that the above things are to be done at the beginning of each round, and the order of these things is fastidious, and the planner should design the sequence of things to be carried out, because different priorities will bring different execution effects. The most common example is a poisoned character at a "recovery point" who needs treatment and loss of life, then loss first and loss later depends on this order. " The essence of "recovery point" is that there is an AoE with a range of 1 grid in this grid coordinate, he heals the character in scope every turn, and poisoning is the buff on the character, causing damage to the character in each turn, so whether to execute AoE first or Buff first will bring completely different results. Similarly, if the character has a fire Buff, and each turn will be damaged by fire, and the game has a weather system, if a rainstorm will extinguish the fire Buff on all characters, then whether the fire in this turn will hurt the character depends on the order of execution of the planner and design, whether the weather will be executed first (will not hurt) or the Buff will be executed first (will hurt).

When all the things at the beginning of the round are completed, there will be several Timeline (possibly many). At this time, a merge of Timeline is needed, that is, there must be a rule to concatenate these Timeline, one after another, in parallel, or in series that meets some conditions, or parallel in parallel with other conditions-- these are also carefully designed by planners and art.

Finally, the program will play the merged Timeline here, and after the playback is finished, go to the next state-- select the role state.

There are actually two situations when choosing a character state: first, when the player acts, the player starts to play chess and watch the map to select the character state, which is a state waiting for the player to issue orders. The other is non-player action, so here you will traverse the character on the map, find the first character that matches the camp that has not yet acted, execute AI, and then switch to the follow-up state. If you cannot find a character with such a condition, you will enter the end of the turn.

What needs to be further explained here is that the display of player action status (display) is not immutable, and according to the design requirements of the game, there will be a lot of details that need to be modified, such as "showing the range of movement of the currently selected character", such as "showing the range of all enemy attacks", etc., these are just different things that are displayed and do not need a special state.

If it is a player's action, when the player clicks on a specific character, it will enter the UI of the character details, and at this time you need to switch to the "character details status", which is only the role of an "operation lock". Whether or not you need a "character details status" can be decided according to the actual UI design.

When the player acts and clicks on a character of his or her own, if the character has not yet acted, it will enter the "select mobile range state". If it is an AI script, it does not need to "choose mobile state" this state, you can directly cut into the character mobile state.

(select character status in Fire if) Select moving range State when selecting a character's moving range, we need to rely on map, character, and camp 3 chunks of data to get a range that the character can move (in fact, this is also used in "selecting character state" in most UI designs, this is just a specific introduction to this method). The range of movement of a character is a standard Dijkstra algorithm, but there are some differences from the common Dijkstra algorithms described in articles used in games:

First of all, the selection of "next grid" is not only adjacent to 4 squares, but also to the basic rules. If you are designing a large strategic honeycomb, it is also divided into horizontal hexagonal and vertical hexagonal, that is, whether the other two squares are [xmur1] [y] or [x] [ymur1] and so on. In addition, because there may be a portal in the map block, the destination also meets the "next grid" and should also be added to the algorithm.

In chess, generally speaking, "hostile target" (defined by the planner as "hostile target" in the "camp" design, or "penetration rule" here) is "impenetrable", and other cells can penetrate but not fall, that is, whether the pathfinder will regard this cell as "next", but will not be added to the "next" array.

During the operation, according to the movement type of the character, the movement type and consumption of the map block, and the location of the enemy (look at the influence of the enemy on the movement force of the surrounding grid in the specific settings of the game, there is usually no additional effect, and it is enough to block. This still depends on the needs of the planning design) to generate a temporary map to calculate the movement range.

Choosing the range of movement is not only a problem of showing the range of movement, but also determining whether it can be moved or not, there is also a problem of trajectory. There may be some "mines", so the path taken by the character is very important. If you touch "mines", such as fire lines, high warfare and other series, the enemy units can not be seen on cloudy and rainy days, and if the next step is to reach the location of the enemy units, the blocks will be forced to stop. Therefore, if there is such a design requirement, it is necessary to record the walking process entered by the player. If there are no special needs, you can use AStar pathfinding to act, just like AI.

AI chooses the route by generating mobile data based on an AI script similar to a behavior tree. It is called "similar behavior tree" because it just looks like a behavior tree, which is completely different in essence. An AI script is made up of several fragments, each of which contains:

Condition: if the condition is completed, the event is executed and the result (return) is calculated.

Event: the calculation method obtains the result data.

Otherwise: hang to another AI script fragment.

Eventually there will be an AI script snippet at the end, which is "unconditional standby or standby". And what on earth is "standby" all about? From a data point of view, the returned mobile data (in fact, the player's operation also obtains this information) contains the following data:

Move target cell coordinates: where you want to move. This is a place where planning needs to be designed in detail, because players and junior planners usually have the illusion that "I" is designed to "run away without much enemy blood", which is very clear-but in fact, there is no design at all. because this sentence "Blizzard update document" uses two generalizations "not much blood" and "escape", what is not much blood? It is HP / MaxHP in the condition.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.