我和游戏开发

游戏一直伴随着我的成长，小时候的红白机的年代，为了一张心仪的游戏卡带省吃俭用，那些交换卡带交流经验的玩伴，还有那些烙印在大脑中的游戏技巧，都是回不去的童年。大概是因为这些经历，促使现在的我成为了一名游戏开发者。

陌生的开始

22年下半年的时候，因为一个契机我转行到了游戏开发工作，最开始还是非常的不适应，好在同事和领导都很关心我，让我顺利的渡过的不适期。

unity的首选编程语言是c#，一开始我还是很担心是否能适应，写一段时间发现切换的还是很顺利，可能跟我有一些java编程经验有关。游戏开发跟web前端开发有很多相似的地方，都是把数据展示给玩家（用户），不一样的地方在于，游戏的侧重点是让玩家玩的开心，而web产品大多数时候是为了展示或完成某一件事情。

虽然编程方面没太大的阻力，但我后来才发现，对游戏开发而言，编程的工作应该只占到了整体工作内容的1/3左右。我在unity的官网上找到了一些学习资料，在这里过渡了入门阶段，然后就匆匆忙忙的进入了工作阶段。

小试牛刀

工作后我的第一个项目是一个多人协作的回合制游戏开发，是基于一套成熟的架构开发，和我在官网学习的教程相比最大的区别在于UI层，官网教的是Unity最基础的UGUI，而项目中使用的FairyGUI，它是一个UI编辑器，能编译出Unity所需的UGUI。

可能是因为前端开发经验，上手FairyGUI还是挺快的，在熟悉了一段时间后就能开始做一些简单的界面了。然后就开始正式步入正式的游戏开发工作，从需求分析、配表设计、接口对接、美术资源对接、一步步深入学习游戏开发中的点点滴滴。

这个过程持续到了23年9月，这个过程中我主要从事上层系统的开发，就是一些和玩家交互的系统，比如邮件、背包、任务等，大大小小加起来应该20多个系统，虽然这些系统都不是很难，但整个过程还是很辛苦，也出现了很多bug，给领导和同事增加了很多不必要的工作，还是挺不好意思的。

工作内容调整

我从23年第三季度开始做小游戏开发。跟之前主游戏开发相比，最大的区别是不用协作开发了。小游戏开发只有一个程序、一个策划，开发节奏也快很多，比喻起来的话就像主游戏开发是在开一辆很大的车，车的前进需要很多人的努力，而小游戏开发就像是骑摩托车，自由自在无拘无束，只需要按需求和时间节点完成任务就好。

最开始还是很不适应的，小游戏这边用回了官方的UGUI，很多之前用FairyGUI很简单的事情现在变得很麻烦，比如最基础的游戏对象获取、列表的渲染等等。我差不多在完成第二个小游戏后才找到一些开发节奏。

小游戏这边是走的快速试错的道路，一个游戏会分为几个阶段，每个阶段都会进行市场用户测试，根据测试结果决定是进行下一阶段的开发还是及时止损停止。所以节奏很快，到写这边blog的时间节点，我已经完成了7款小游戏cpa版本的开发。

第一个小游戏

我的第一款小游戏是关于经营一个小店，大概玩法就是通过完成顾客的需求升级店铺装修，更新菜谱，然后赚更多的钱。

可能是考虑到第一次做小游戏，给我安排的一个比较简单的游戏案。虽然需求不难，但因为UGUI对我来说很陌生，我整个游戏做起来很吃力，从最基本的UI元素的交互，到一些场景切换，到比较复杂的做菜逻辑，我都做的很辛苦，好在最终做出了策划想要的效果。

第一个游戏给我带来最大的收获是对Unity整体的理解，包括使用UGUI完成游戏表现层的逻辑，基于ET架构的界面、场景管理，Unity的碰撞系统等，这些都是做主游戏的时候没接触到的东西。

第二个小游戏

我做的第二个游戏是一个末日生存游戏，它的内容很多，涉及到种植系统、建筑升级、人物培养、战斗系统，还有两个找茬事件玩法，这个体量对我而言无疑是很大的，而且小游戏开发时间都是固定的两个周，所以给到我这边的压力是非常大。

时间短任务重，那就只能提高工作效率了，我首先列出了所有的功能点并通过脑图的方式呈现了出来，然后找出了其中的难点内容，通过询问和查询资料的方式解决这些内容，然后基于两个周的时间制定开发计划，最终按期交付了该项目。

这个项目对我而言最大的难点是寻路系统，主场景的楼顶和战斗场景里都需要用到寻路系统，这块内容是我之前没接触过的，也是此次内容中耗时最久的，然后就是各种物品拖拽相关的逻辑，比如把种子拖拽到种植区域去种植，把相同等级的雇佣兵拖拽到一起升级等。

然后就是战斗系统，战斗系统在游戏领域是一个大山一样的存在，它可以做的很深，好在我这次的战斗系统比较简陋，只需要相互砍杀就行，不用考虑技能、道具、加成等游戏元素，由于没有这方面的经验，我自己写了一套很简陋的战斗系统， 应该是这个游戏的侧重点不在战斗，策划对这块要求不是很高，最后算是达到了策划的预期效果。

更多的游戏

后来我又做了挺多小游戏，主要是经营各种场所，然后加上一些小玩法，经营场所主要是配表设计比较难，小玩法就天马行空的各种玩法实现，这些都很有意思。

在这个过程中，我对unity的理解越来越深刻，技术在不知不觉的又近了一大步，这些游戏基本也没找任何人帮助过，都是自己实现，虽然还是经常碰壁，但却乐此不疲。

写在最后

一年多的游戏开发经历让我学到了很多东西，也让我的思维变得更开阔，原来可能对编程范式实现方式都有很多执念，现在看待这些问题都有了更深刻的理解。

其实游戏开发和前端开发有太多的相似之处，早期的前端项目需求比较简单，大家随便写点JS，就可以搞定，随着业务的复杂，代码量随之增加，伴随而来的就是混乱， 要处理这些混乱，前端工程开始借鉴后端思想，加入各种设计模式，引入组件化概念，解耦不必要的关联，至此前端开始了工程化的道路。

游戏开发也是这样，早期的游戏很简单，比如俄罗斯方块，蜘蛛纸牌，逻辑和体验需求都比较简单，但现在的游戏体量越来越大，把各种玩法都集中在一起的缝合怪式游戏层出不穷并且玩家似乎还很愿意为此买单， 游戏里的系统越来越多，玩法也越来越复杂，所以游戏开发必然也需要做好工程化。

环境的差异，之前做互联网开发，整个生态都很积极向上，大家都在努力的开发和贡献更多更好用的组件，因为有这些人用爱发电，社区也充满了活力。但游戏这边有些不一样， 不管是围绕Unity的公共组件还是单纯说Unity本身的商业属性，好像都注定了Unity的生态不会那么活跃，虽然围绕Unity也有很多用爱发电的人，但更多的是收费的内容，去年Unity还因为修改用户协议遭到了众多开发者抵制。

互联网的产品一般是围绕一个或者多个现实生活的业务场景而产生，它的存在是为了解决业务问题，不管是独自解决还是配合其它系统一起解决，所以互联网产品的重点是解决问题，一个产品不管它的界面多难看，多么难使用， 只要最终帮使用者解决了问题，大多数使用者还是会认可它，最多只会有一些抱怨，抱怨它不好用，不好看，不稳定等。所以对互联网产品而言，最重要的是能让使用者顺利的完成他们的业务诉求，然后才是易用性、美观、响应速度等。 但游戏这边不是这样的，大多数游戏的目的是为了让用户消费，让用户在游戏上停留的更久，让用户每天都要打开这个游戏，所以目的不一样，出发点也就不一样，侧重点也不一样。这应该是我觉得游戏和互联网开发最大的区别。

做为一个打工人，不管在什么行业，好像都无法跳出发现问题、解决问题、再发现问题、再解决问题的循环，我们能做的只是找到更科学，更高效的解决办法的方式，让自己能短暂的从这个循环跳出来， 休息的同时从不同的角度去审视当前的所做的事情是否正确，积极的沟通和调整自己，找到最适合当前现状的道路。

现在的我虽然还无法制作高质量或者大型的游戏，但应该可以循序渐进的实现自己的游戏创意了，不管是游戏难点如何攻克，游戏资源应该如何获取，甚至游戏的整个生命周期，都已经有了比较深刻的理解，我相信自己会做出自己满意的游戏，加油吧。