Summary of the design and implementation of the weapon system similar to the paladin of vitality

introduction

This year I made a similar The project of vitality Knight , The poor road is responsible for the weapon system module . Put the weapon module Main organizational structure Here I share with you all . The poor road is still shallow , Please also give me more advice ！ If you don't understand something, you can leave a message for me , Be sure to know everything , can ~~

One . Demand analysis

I believe everyone has played or learned about the vitality knight more or less （ If you don't go out, turn left and play next ）, Need is to be with the vitality Knight 10 Fen is the same Our weapon system .

1. Weapon category

Guns （ pistol , Submachine gun , Shotgun , sniper rifle ）, Cannons （ The rockets , Railgun ）, Laser gun , arch , Close combat （ The knife , The sword , gun ）, Staff of Dharma , Missiles （ Boomerang , Poison Bottle ）…

2. Implementation mechanism

Rate of fire , Offset , combo , laser , Bullets fire bullets , Storing force , summoned , track 、 Bessel curve 、 Simple and harmonic 、 Orbit and other tracks , Switch weapon form …
From the player

3. Trigger mode

Automatic triggering , Single point trigger , Long press and hold to trigger , The accumulated force is automatically released , Release the accumulator , The accumulated force is continuously released …

4. Release （ launch ） The way

Sequential single release , Release all in sequence , Weight individual release , The power storage state is released …

Two . framework design

1. Design principles

a. Unbound relationships do not hold objects to each other , Asynchronous operation will result in object fetching failure , If there is a need, you can save the object id, Check when you use .

b. Member objects should not go to the holder object to get data , But by the holder set. In other words , Does not depend on the holder object , Rely on the data provided by the holder . This ensures that any object holds the member object , Superiors drive subordinates , as long as set data , This member object can run normally .

2. Design thinking

be aware , FireStarter （ I abstract the act of firing bullets as firing ） It is not a unique behavior of weapons , Like skills , equipment （ Some equipment will automatically release lightning around ）, The monster AI Will fire , So take the fire away from the weapon .

Different guns have different trigger methods （FireListener）, Different ways of using the transmitter （FireBehavoir）（ For example, the attack method of the knife is horizontal cutting , Vertical chop , Slash … It is a single point trigger + Sequential single release , The attack method of the magic wand is to slash and release a circle of bullets at the same time, which is a single point + Release all in sequence ）, Their polymorphism is based on combinatorial relationships fire Member objects of . Please note that , The combination relationship does not mean that they can combine freely , And not necessarily FireListener,FireListener The responsibility is to monitor the player's operation setting status and decide to fire , for example AI You can set the state and decide when to fire .

Notice that there is a state dependency between the two （ such as The release of the power storage state depends on the power storage value provided by the power storage trigger ）, How should they communicate with each other ？ There are two ways of thinking ：
1. One is more strict “ Who creates who manages ”, Producers produce products , Consumers take products from producers , And tell the producer that I have consumed . Producers get the news of consumption , Then remove this batch of products from the list . As for whether it was really rowed away , Consumers don't care , Consumers only care about whether they can get products .
2. Another way is to build a warehouse , The producer produces products and sends them to the warehouse , The administrator records how many products are added . Consumers go to the warehouse area to pick up products , And tell the warehouse keeper how many products have been taken .
Each of these two ways has its own advantages , Here choose the second way , Use FireState Management status .

Complete process ：FireListener Monitor the player's operation , Come on set FireState The state of , And decided to fire . When firing ,FireBehavoir Decide which transmitters to create according to the status and configuration （Launcher） And set the status of these transmitters . thus , The internal work of the weapon system is completed . The launcher then decides how to fire bullets according to the status and configuration table .

See class diagram and class responsibility division for specific details .

3. Class diagram

4. Division of responsibilities of classes

a.Weapon： Modification of attribute appearance and action ; Respond to input notifications Fire; Switch mode …

b.Fire： FireStarter ; Input message received , notice FireListener; Fire sound , action , shock …;cd Record , Firing condition judgment …; Attribute snapshot ;

c.FireState: State information

d.FireListener： Polymorphism responds according to the player's firing key ,“ production ” state , Decided to fire .

e.FireBehavoir： Polymorphism determines which emitters are created and sets emitter status based on status and configuration ,“ consumption ” state , notice Fire Firing completed .

So far, the internal responsibilities of the weapon system have been completed

f.Launcher: How to create bullets depends on the status and configuration , And set the bullet status .

g.bullet According to the State 、 Configuration and triggers determine how emitters are created .（ Its trajectory and other behaviors are not discussed here ）