本篇文章主要是针对GE的一些细节进行深化的解读，需求具有GAS的相关根底，我也会尽量减少贴代码，有需求的读者可以去看源码，结合着本文可以有更深化的了解，本文许多当地都会相对简述。我以为一个好的学习办法是从问问题开端的，从一个问题开端，答复，然后继续提问，答复，直到结尾中止，当绝大多数问题得到回答今后，对相关的知识也就可以把握了。
本篇文章由四个部分组成：解析Duration Effect，解析GE的猜测，Stack Effect的原理，扩展GE功用。本篇文章也将从一个问题开端，首要便是
Duration Effect是怎样收效的？
对GAS有一个根底的了解后，咱们会知道，Effect本身并不会实例化，当ApplyEffect后，会生成一个实例，即FActiveGameplayEffect，它会贮存在ASC的ActiveContainer中。游戏内一切的GE作用都会贮存在这儿，一起模仿端的GE也是经过它进行网络同步的（在默许形式下，只要主控端的ActiveEffect会同步）
对这个流程感爱好的可以自己去看函数UAbilitySystemComponent::ApplyGameplayEffectSpecToSelf，会调用ActiveGameplayEffects.ApplyGameplayEffectSpec(Spec, PredictionKey, bFoundExistingStackableGE)生成实例化GE，具体的进程我就不赘述了，有一个概念就行。
咱们现已有了实例化的GE——ActiveEffect了，它可以被以为是Duration Effect本身，它现已被Add进ActiveEffectContainer中了，但此刻它并没有任何实践的作用，很天然地就会需求提问，Duration Effect是在什么当地开端收效的，这相关了以下两个的问题：
GE又是怎样激活并收效的，它的激活与封闭是怎样完结的的？
这两个问题是彼此相关的，当ActiveEffectContainer创立GE时，会调用函数InternalOnActiveGameplayEffectAdded，在这儿激活GE让其收效，这边函数实践意思为，封闭AcitiveGE，输入为true封闭GE，false激活GE，便利了解我就直接把这儿的行为称作激活了GE。
需求留意的是，这儿的Inhibit指的是让GE激活和封闭作用，并不会将GE移除，和Add和Remove的概念是不一样的。可以了解为GE首要生成ActiveEffect实例，被增加Add到ActiveEffectContainer中，然后经过激活（!Inhibit）GE发生实践的作用，包含增加tag，修正特点等。
有了激活，咱们很容易就会想到一个问题，GE里可以经过装备，让ActiveGE在某些tag下收效，没有这些tag的时分无效，是怎样完结的呢？没错，同样是经过调用InhibitGE这个函数。
假如看过我之前解析GAS在5.3改动的那篇文章，就会知道GE在5.3之后，功用是经过EffectComponent去完结的，而TargetTagRequirementGameplayEffectComponent的作用是，在满意特定Tag条件后，会增加移除，或者激活封闭GE。
它的完结办法为，在GE被增加时，监听ASC中tag改变的音讯，当tag发生改变时，会触发函数UTargetTagRequirementsGameplayEffectComponent::OnTagChanged，然后判别是否满意GE激活的条件，假如不满意，则调用Inhibit函数去封闭GE。
有了这个比如作为参阅，咱们可以很衍生出去，是否可以对GE地功用进行扩展，能不能在特定特点的条件下增加移除GE，或者激活封闭GE呢？
答案是YES，我会在文章的终究，完结这个功用扩展。感谢UE5.3的更新，让相似的功用可以比以前愈加便利高雅地完结了。
到了这儿，咱们了解到GE在被Add到Container中后，会被激活（!Inhibit），GE的作用是在这儿收效的，接下来的问题是：
GE激活后，会影响哪些特点呢？
GE收效的函数为AddActiveGameplayEffectGrantedTagsAndModifiers
在这儿只考虑非Period的Duration GE，Period GE的完结是经过设置一个Timer，周期性地调用ExecutePeriodicEffect去收效，可以简略的了解为周期性履行的Instant GE，这儿就不具体讨论了。
GE的作用大致有以下几个部分组成：Attribute，Tag，Ability，Cue
Attribute
首要从Attribute开端，Duration GE首要影响的天然便是特点，GE会修正人物的Attribute的Current值，信任读这篇文章的应该都对Attribute的base值和current值有所了解，两者可以大致了解为根底值，和遭到各种GE影响后的实践值。base值比较好了解，由于修正后和GE本身就无关了，可是current值是怎样完结的呢？这个问题等下会深化的解说，现在暂时放下不表，咱们继续看GE还有什么作用。
Tag
Tag的修正比较简略，获取GE Def和Spec中的Grant Tags，然后调用ASC的UpdateTagMap对CountTagContainer进行修正，比较简略，不赘述了。
然后经过ASC对Tag进行网络的特点同步
这儿需求留意的是，在模仿端，默许状况下ActiveEffect并不会同步，可以了解为在模仿端，GE是不存在的，GE作用是经过服务器上Tag, Attribute，Cue等作用的同步，在模仿端产收作用的。
Ability
给予Ability，此功用在此函数里现已被抛弃，5.3今后是经过GE Component去给予Ability的。
读者可以经过在GE中装备UAbilitiesGameplayEffectComponent让GE具有Give Ability的功用。
GE对Ability的影响还有一个，可以block ability，依据Ability中装备的BlockTags条件，中止当时正在激活的技术。
Cue
终究一个GE的作用是触发Gameplay Cue，逻辑大致为，遍历装备需求触发的GameplayCues，然后修正人物的Tags，让其增加对应的Cue Tag，然后调用InvokeGameplayCueEvent让Cue在本地收效，终究让Cue经过同步在模仿端收效。
从这儿可以看出，Cue Tag尽管增加到ASC上，但它实践并没有被网络同步，是一个Local Tag。
扩展
除了以上这些根底的功用，咱们还可以经过GE Component，很简略的让GE发生更多的作用，与其它的功用模块进行互动。假定，我是说假定咱们要做一个高达游戏（笑 ），有的高达可以形状改变，在人形和飞机形状进行切换，其它的程序完结并供给了变身的功用模块，它会切换高达的Mesh，状况机等，并向咱们供给了接口。咱们怎样接入呢？
咱们可以将变身视为一种Buff状况，用GE进行办理。然后派生一个UGameplayEffectComponent为UTransformGameplayEffectComponent，用于办理变身状况。这方面可以参阅UAbilitiesGameplayEffectComponent，我这儿大致说一下完结的思路。
首要重写OnActiveGameplayEffectAdded函数，然后绑定OnInhibitionChanged的播送，它会在GE激活和封闭时触发
然后在OnInhibitionChanged中，调用其它程序小伙伴给咱们供给的接口，去开启和封闭变身。参阅AbilityEffectComponent，则是增加和移除Ability。
OK，咱们知道了GE在激活后，会影响哪些特点，并且咱们可以扩展让他有更多的作用了。那么咱们继续提出新的问题，在知道GE在激活时可以影响特点后，这个影响是怎样办理的？比方多个GE一起影响同一个特点，这个特点的终究的实践值是怎样确认的？比方GE被移除后，被它影响的特点又是怎样还原为原有状况的？这些问题的第一层答复是，Duration GE影响的是特点的current值，不会影响base值，那么咱们继续提问：
Attribute的current value是怎样完结的？
这个问题最简略的答复是，特点的结构体FGameplayAttributeData中有两个特点，BaseValue和CurrentValue，一个是根底值，一个是受外界影响的值。这也是绝大多数教程回答的，但它却解说不了GE对特点的影响是怎样被办理的，接下来我会叙述我个人的了解。
首要从头开端缕，Attribute都具有Base值，它可以被了解为一种固有的特点，一旦修正便会永久改变。然后Current值可以了解为Base值被各种”暂时“作用润饰后的值。这种润饰便是一种Mod，GAS中的Mod有Add, Multiply, Divide, Override四种。终究的current值便是由多个Mod一起影响后决议的。
这儿需求留意的是，Multiply和Divide并不是多次相乘或者相除，比方有两个 Multiply1.2的作用，实践的乘数不是1.44，而是1+0.2+0.2=1.4，divide也是相似的。
我把这样一次核算Current值的进程称为实践特点核算，核算次序如下：
- 假如有Override的Mod，则直接运用override value作为输出
- 累计相同符号的mod，比方多个add mod：10，20会集成为30，多个multiply mod：1.2，1.5会集成为1.7
- 对特点的base值，先加，后乘，再除终究输出作为成果
接下来看看代码，一个根底的Mod如下，包含三个参数，第一个是Channel，这个咱们先暂时不管，第二个是Mod符号，第三个为Mod数据，这个数据中最核心的是EvaluatedMagnitude，即Mod润饰的巨细。
ModInfo则被存储在FAggregatorModChannel中。先不要管Channel的定义，可以把它了解为用于存储某一个特点一切的Mod。
可以看到一切的Mod都存储在ModChannel中的Mods处
核算Current值的办法便是上图阐明的办法，假定Health特点base=100，additive mod: 20, 30，multiply mod: 1.2, 1.5，divide mod: 1.2，1.2
- 假如有Override Mod，直接回来Mod值
- 将不同运算符的Mod累加，additive mod sum=20+30=50，multiply mod sum=1+(1.2-1)+(1.5-1)=1.7，divide mod sum=1+(1.2-1)+(1.2-1)=1.4
- 实践成果 result=(100+50)*1.7/1.4=182
代码贴在下面了，有爱好可以自己去看看。
上面ModInfo和ModChannel现已可以完结base和current值区别的，关于GE来说，只需求在激活的时分创立ModInfo并增加到特点对应的ModChannel中，然后依据base value核算出current value。但这个时分咱们再提出一个新的问题，假如策划期望支撑乘区的概念，咱们怎样支撑呢？比方期望对攻击力的增加，一部分遭到乘法的影响，另一部分则不会，怎样完结？
当时的这个结构毫无疑问，并不能经过一个单一的攻击特点完结这个功用，当然可以经过增加AttackPercent，AttackExtra等额定的特点来解决这个问题，甚至我以为这可能是更好的解决方案，但这儿我要隆重的说到GAS里Attribute Mod Channel的概念，现在我好像没有看到国内的文章说到过。
没错，GAS里现已给实践特点核算划分了Channel，咱们可以依据需求将GE增加的Mod增加到期望对应的Channel中，然后按照不同的Channel去分别核算，实践current的核算就不是上面说到的只进行了一次核算，而是下方的姿态。
在多个Channel的状况下，会将上一个Channel的实践特点核算的终究成果result，作为下一个Channel的实践特点核算的输入，直到一切的Channel都核算完毕，终究输出的result为特点当时的current value。
接下来看实践的代码，可以看到结构体ModChannelContainer中，贮存了Channels的Map，当时枚举ModEvaluationChannel最多支撑10个Channel，默许状况下只要Channel 0收效，咱们假如去修正GAS代码，也可以支撑更多，但感觉就没有必要了。
查看代码，核算便是按照上图所示，遍历一切的Channel，将上一个Channel的输出作为下一个Channel的base输入，直到核算出终究的成果作为current值。
有了多条Channel，上述那个”讨厌“的策划的需求就可以得到解决了，需求遭到乘法影响的攻击力加值，放到Channel 0中，不需求遭到乘法影响的攻击力放到Channel 1中，那么实践的攻击力为：
Attack = ((Attack Base + Attack_Add_0)*Attack_Multiply_0) + Attack_Add_1
Perfect！可是需求留意，默许状况下，GAS只支撑Channel0，那么怎样打开多Channel的功用呢？ 我也放在文章的结尾进行回答。
有了ModChannelContainer后，咱们介绍终究一个结构体——Aggregator，ModChannelContainer存储在Aggregator中
读者可能会有一个疑问，分明ModChannelContainer现已支撑核算实践特点值了，只需求在GE激活和封闭时，增加和移除Container内的Mod即可，为什么还要增加一个aggregator呢？
关键在于GE修正某个特点，是可以依据另外的特点的，比方说，狂兵士的有一个暴烈Buff，他的攻击力会依据血量百分比的减少而增加，那么当狂兵士的生命值减少时，暴烈buff增加的攻击力也应该发生改变。在GE中挑选MagnitudeCalculationType为AttributeBased后，假如不挑选SnapShot，就可以完结上述的功用，GAS中又是怎样完结特点依靠的功用呢？
首要，在填写GE时，假如设置了Backing Attribute后，那么程序就可以知道这个GE需求依靠哪些Attribute，比方上面那个比如里，暴烈buff需求依靠的特点是生命值。那么咱们只需求把暴烈buff的Effect Handle存储在生命特点的Aggregator中，在生命值发生改变时，先找到对应的Effect Handle，找到暴烈buff，然后知道这个buff会依据生命值去修正攻击力，接下来就可以依据新的生命值从头更新攻击力加成即可。
咱们来看看Aggregator中，是怎样完结的。可以看到FAggregator中，ModChannels即上面说到的ChannelContainer，用于核算实践特点值，这儿的Depedents就代表了依靠于此特点的Active Effects，以上面的比如来说，生命值特点的的Aggrator中，依靠于生命值的GE就包含了暴烈buff。
这个依靠会在ActiveEffectContainer的函数ApplyGameplayEffectSpec中注册，感爱好的可以自己去看看，这边就不细心说了。
有了依靠关系后，假定特点发生改变后，会调用BroadcastOnDirty去通知依靠于此特点的特点更新。
打开这个函数可以看到，里边最多的代码便是解决无限循环的问题，比方攻击力依靠于生命，生命又依靠于攻击力，那么攻击力发生改变后，这个链就会一直继续下去，官方的做法是增加了一个计数器，BroadcastingDirtyCount，当它大于10的时分会中止更新依靠特点。我个人以为仍是从设计层面上防止循环依靠为好，在可能发生循环依靠的当地，运用SnapShot快照进行替代。
核心代码就比较简略了，循环一切依靠的于此特点的ActiveEffect，然后经过函数OnMagnitudeDependencyChange更新特点。大致的办法便是遍历改Effect悉数的Modifiers，然后依据依靠特点新的值从头核算出新的ModInfos，先移除老的ModInfos，再把更新后的Add到所修正特点的Aggregator中去。
这儿又会调用BroadcastOnDirty去更新依靠于更新的特点的特点，无限循环的问题便是在这儿发生的。
至此，Duration Effect是怎样收效的，应该就可以得到一个相对完结的回答了，它首要会生成一个实例Active Effect，并被增加到Active Effect Container中，然后被激活，在这儿会生成GE特点作用的一系列Mod，存储到GE所要修正的特点的Aggregator中，然后Aggregator会依据存储的Channel里的一切Mod，从头核算出特点的current value，更新后的特点值则会经过特点同步，从服务端发送到客户端。
当GE被移除时，也是相似的流程，首要Active Effect会被封闭，它所修正的特点的Aggregator会依据Active Effect Handle找到此GE生成的一切Mod，将其从Aggregator中移除，然后Aggregator会从头核算current value并同步到客户端。接着GE会被从Active Effect Container中移除，然后此音讯也会经过FastArrayItem的特点同步，在客户端将对应的Active Effect给移除去。
至此，Duration Effect产收作用的链条就很清晰了。这儿只以Attribute作用作为研讨的目标，其它包含Cue其实也有许多的技巧和可研讨的当地，但碍于篇幅，这期我就不赘述了。
勇者面临BOSS
GE是怎样完结猜测的？
这一部分我会剖析一下GE的猜测机制，关于具体解说GAS中猜测的完结机制的文章，市面上现已有许多了，都写得很好，所以我这边就大致解说一下，并不会细心的剖析源码，想要深化学习的可以去搜一下别人的文章。
GE的猜测实践上很简略，在玩家的主控端可以生成PredictionKey，然后主控端需求开释GE时，可以在调用ApplyGameplayEffect时将有用的PredictionKey作为参数输入
在FActiveGameplayEffectsContainer::ApplyGameplayEffectSpec函数中，在本地生成了一个猜测的ActiveEffect，将代码拉到函数的最下面，可以看到在主控端，会将函数RemoveActiveGameplayEffect_NoReturn绑定到PredictionKey的Reject和CaughtUp回调上。回调函数做的工作很简略，便是将猜测GE给移除去。
这意味着不管服务器判定这次ApplyGameplayEffect的成果是有用的仍是无效的，当PredictionKey触发RPC回调后，客户端的本地猜测GE都会被移除，本地猜测GE仅仅作为一个暂时的数据存在，不管成功或是失败，终究都会被销毁
接下来讲讲服务器上的行为，首要要清晰的是，ApplyGameplayEffect的函数并没有RPC，也便是客户点调用并不会让服务器也触发ApplyGameplayEffect，不管在客户端和服务器上，开释GE都是独立的行为，他们之间的相关仅仅经过PredictionKey，服务器会将本地的猜测GE给移除去。
那么咱们在技术发动的时分，假如调用ApplyGameplayEffect，服务端和客户端都会触发呀，这是怎样做到的呢？很简略，发动技术这个行为是在玩家客户端发起的，ActivateAbility有RPC调用会触发Server_ActivateAbility，将客户端生成的PredictionKey传给服务器。因此服务器和客户端的ApplyEffect行为是在ActivateAbility函数中彼此独立的调用的，他们之间的相关是经过客户端上传的PredictionKey来树立的。
关于服务端，在创立ActiveEffect后，会走到上面代码的if分支，调用ActiveEffectContainer的MarkItemDirty函数，经过FastArray的特点同步，将ActiveEffect的数据从服务器同步到客户端。
关于这儿具体的事例来说，在MarkItemDirty后，会触发函数FActiveGameplayEffect::PostReplicatedAdd，这儿涉及到虚幻TArray快速网络同步的概念。在这儿，会将同步到客户端的ActiveEffect增加进ActiveEffectContainer中。
由此可以看出，本地GE猜测的回滚和服务端的GE同步是两个独立的行为。
测验事例
尽管我的解说现已是极度简化阐明的GE猜测了，可是信任仍是会有许多读者觉得不够直观，因此我在这儿会经过几个比如来阐明GE开释的不同状况。为了测验，我会将网络推迟调整到500ms以上。
事例 1
在本地猜测发动技术，在客户端技术ActivateAbility时，直接给自己ApplyEffect，作用为本地马上增加GE_Test，然后推迟往后，服务器也调用了ActivateAbility→ApplyEffect，增加了GE_Test，接着客户端本地的GE_Test会被移除，服务器的GE_Test被同步下来。
事例 2
在原有的根底上进行如下修正，服务器上此技术不能发动，客户端则可以。那么GE_Test会怎样样呢？
实践的状况会是，玩家的客户端成功发动技术增加上了猜测的GE_Test，然后推迟往后，服务端的技术发动失败，没有增加上GE_Test，然后PredictionKey回调后，客户端的猜测GE被移除。两头都不存在GE_Test了。
事例 3
再进行一个小修正，技术推迟之后，咱们推迟一帧再ApplyEffect，此刻GE_Test是否会被增加到玩家客户端呢？
答案是不会，此刻玩家的本地客户端将不会生成猜测的GE_Test，实践的状况是，玩家本地猜测发动了技术，可是GE_Test则不会被猜测，服务端判别技术无法发动，然后调用Client Fail的函数，将玩家端的技术给End掉。
为什么这种状况GE_Test不会被猜测呢？由于本地的猜测都依靠于有用的PredictionKey，它被包裹在ScopeWindow中，而ScopeWindow的有用生命周期是在发动技术的函数闭包内，当函数履行完将会被析构，尔后的PredictionKey都将会无效。简略了解来说，新生成的PredictionKey只在当时帧收效。由于没有有用的PredictionKey，本地无法猜测GE。
直面惊骇，发明未来
Stack是怎样完结的？
接下来需求解决的问题是，GE的堆叠是怎样完结的。首要仍是回到一切的起点，查看函数FActiveGameplayEffectsContainer::ApplyGameplayEffectSpec，在一开端依据Spec找到堆叠GE现已存在的ExistingStackableGE，找的办法大致是遍历Container中一切的ActiveGE，条件为：Def和输入的Effect相同，且StackingTypr不等于None，Duration不等于instant等，找到后将ActiveEffect回来
Overflow
假如当时ActiveEffect的stack count等于def的StackLimitCount，表明新的GE现已无法继续堆叠了，处理overflow。
第一种状况是当OverFlow发生后，会Apply Overflow Effects，这个作用的比如为：当当地身上的焚烧buff达到五层后，会触发爆炸。
第二种状况是overflow后移除effect，即buff叠满后，移除当时的buff。
更新StackCount
处理完overflow的可能后，开端核算新的堆叠数量
更新Duration
假如GE的DurationRefreshPolicy为NeverFresh，设置bSetDuration为false，假如bSetDuration为true，此参数会在后边从头改写GE的继续时间
RestartActiveGameplayEffectDuration函数中，会更新Effect的StartServerWorldTime，StartWorldTime
注册Timer，这儿会在堆叠GE首次创立，或者改写时调用，时长为GE的继续时间。当然这儿设置的是GE的继续时间，是针对一切的Duration Effect，而不仅仅是Stack Effect
在终究通知StackCountChange，更新AggregatorModMagnitudes，更新tag，播送EventSet里的OnStackChanged
DurationExpired
当Stack Effect继续时间到后触发，FActiveGameplayEffectsContainer::CheckDuration
依据不同的状况处理StackEffect， 处理的办法分别为，悉数移除，移除一个StackCount然后改写继续时间，不移除StackCount然后改写继续时间
终幕
GE功用拓宽
这个部分介绍一些扩展GE功用的办法
依据特点增加移除GE
在这儿完结一个扩展GE的功用，经过GE Component完结：当指定特点条件满意后，移除当时GE。举个比如，还用之前说到的狂兵士Buff，当人物生命值大于80%时，自动移除暴烈buff。
完结这个功用后，读者可以很轻松的举一反三，完结依据特点条件激活封闭GE；或者只要满意指定特点，GE才干被开释；又或者满意特定特点条件后，开释额定的GE等功用。
这儿解说一下思路：
首要创立一个结构体AttributeCondition，里边的数据是：特点，特点条件，还有一个函数，当特定的特点满意条件时，回来true。这个代码我不就不贴了，应该比较简略。
然后创立GameplayEffectComponent的派生类。其中有成员变量RemovalAttributeCondition，作用是阐明当特定的特点满意条件后，应将此Component的GE给移除。
创立函数RegisterAttributeListener，作用是绑定指定特点的AttributeChange回调。留意还需求一个配套的UnregisterAttributeListener去解除回调绑定，这儿就不贴代码了。
核心代码其实就终究这一句话，监听指定特点的改变，然后触发OnAttributeChange函数，在这儿判别特点条件，决议是否应该将GE移除。这儿需求将DelegateHandle的引证回来
接下来重写函数OnActiveGameplayEffectAdded，此函数会在GE实例化并被增加到ActiveEffectContainer中时调用
这儿要做的是两件事，第一件是调用前面完结的RegisterAttributeListener，监听指定特点的改变，然后将对应的特点和委托存在AllBoundEvents中，由于Gameplay Effect Component并没有被实例化，所以里边并不能存储数据，咱们需求将数据经过绑定OnEffectRemove的回调，触发OnActiveGameplayEffectRemoved函数，并将AllBoundEvents数据传进去。
然后完结函数OnAttributeChange，它的作用是判别监听的特点改变后，是否满意了移除条件，假如满意则移除此ActiveEffect
终究完结函数OnActiveGameplayEffectRemoved，它会在GE从ActiveEffectContainer中移除时触发，这儿要做的工作便是，将增加的特点回调给移除去。
大功完结，终究作用如下图所示，当生命值大于等于80%时，GE会被移除。
怎样运用CustomChannel
这儿介绍怎样在项目中启用多个Channels
首要打开DefaultGame.ini，在AbilitySystemGlobals下填写红框里的代码，最多可以支撑10个Channels
然后打开编辑器，创立一个GE，在Modifier处就可以看到支撑挑选Channel了
然后测验一下，在默许状况下HealthMax=500，完结一个GE的作用为Add 100，Multiply 1.2，开释GE后，HealthMax = (500+100)*1.2=720
假如咱们额定开释一个GE，再加上100的生命值，那终究实践的生命值为
HealthMax = (500+100+100)*1.2=840
当咱们运用新增加的Channel1 TestChannel去增加这100的生命值，Channel0和Channel1的数值是分别核算的，现在生命值为820而不是840
其中核算的次序是这样的：
- 首要核算Channel0 = (500+100)*1.2=720
- 然后Channel1会依据Channel0核算，HealthMax=(720+100)=820
如此就完结了一个特点的乘区
不过我个人以为这种做法并不好，至少不应该乱用，会让对Attribute的运用变得愈加的杂乱，也会让准确的获取数值加成麻烦一点，我以为更好的办法是创立多个乘区的特点，而不是直接运用channel，至少是不应该乱用，我想这也是官方没有提及这儿的原因。
飞吧，用破碎的翅膀
OK，本篇文章到这儿就完毕了，期望可以帮助读到这儿的读者。
写下这篇文章后，有些工作大概就现已定好了，即将脱离广州了，我会想念这儿的猪脚饭，生蚝还有早茶，还有从前一起工作过的人。结业投入游戏职业后，尽管只要短短的三年，但也算是阅历了许多。从一开端的充满热情，有些天真，到现在意识到许多工作并不能以个人的片面意愿为搬运，努力并不能会有一个好的成果，尽管它是最重要的，但有时分赛道和环境，乃至运气才是通向成功的加速器。
但做游戏毕竟是快乐的，每次功用完结后所能得到的正反馈是极其强烈的，我觉得做游戏本身甚至比玩游戏还有意思。我个人仍是始终信任，游戏职业在当下仍然是一条值得去走的路，作为一个内容职业，高低险阻但永远充满机会。职业寒冬，所能做的便是努力提高自己，让自己有更强的实力去面临冰雪消融的时间，信任会有万物复苏的时间，与我们共勉。
