”我热爱的是做游戏,相对于玩游戏,我知道这两者的差别 …“
这,是我来北京找工作,面试时自我介绍的开头。
不知不觉,已经工作五年,经历了三家公司,做过五六个项目,一步步,算是摸爬滚打的过来了。
聊聊过去,聊聊自己。
启蒙
上大学前,并没有接触过编程。
仅有的经验只是金山打字通的打字练习、做PPT,管管教室电脑(就是开关机);噢,当然还有打游戏。
大一初识C++,经典的谭浩强老师的 《C++程序设计(第二版)》,拿着忘了从哪蹭的100道经典C++练习题,一顿猛敲。
大二,就拉了个团队去做个游戏,学了点C++的皮毛,就准备撸起袖子大干一场,正好有个齐鲁软件大赛,正好有个手机游戏项目,正好就拉了几个人,一个暑假都在学校奋斗,还好,没有半途而废,算是一个完整的游戏吧?。。
后来,加入仰慕已久的ACM实验室,开始撸题。
后来,没有考研,决定就业。
…
感悟
游戏开发
从第一份工作到现在一直是在做手机游戏,一直用的是Cocos2d引擎来开发,有接触了解,也做过一些Creator、Unity的Demo,但真正工业级的项目没有碰过。
在我所经历过的各家公司,也各有特色与偏重,没有同质性的公司。
我目前的理解,做游戏(仅客户端而论),可以先大概分为两部分:
- 游戏;每一行代码都能在游戏中体现,为游戏内容品质服务。
- 基础组件
- 中间件
- 业务功能
- 产品;项目从立项到上线,所额外负责的工作。
- 版本控制
- 打包、SDK接入
- 跨平台扩展
- 更新机制
- 游戏优化
- 统计反馈
- 测试支持
游戏
游戏开发中,所做的每个改动,都可以在游戏中直接表现出来。
我把游戏分为三个部分,各部分所重视的角度不同:
- 基础组件;基础组成部分,一般涉及到自研底层代码及引擎底层代码,相对重视效率与性能。
- 中间件;为业务功能研发做中间转接口,将基础组件拼接组装或封装调整,相对重视通用性及便携性。
- 业务功能;实现各种需求,直面用户,相对重视灵活性。
在开发的时候,明确并了解所开发的模块属于哪个部分,从而知晓它的重点偏向。
比如,开发业务功能,更重视灵活性,多与需求方沟通,了解他们的本意,不要厌恶、恐惧变化,甚至要拥抱变化,以 “任它需求千万变,不如我代码灵活又简便” 为目标。
再比如,如果开发基础组件,理论上,不应该为了使用方便,而去牺牲它的执行效率。
产品
这部分可能跟游戏的实际开发无关,但是却是完整的产品必经之路。
这些部分或许与游戏的品质等无直接相关,但是会直接影响团队的研发效率。就如同产品与包装的关系,包装不代表产品品质,但是好的包装亦能影响用户心中的价值。要不然,月饼、白酒的包装会越来越华丽呢?
这部分的特点是 简单繁琐 、 涉及广度大 、一次就好。
- 简单繁琐;很多简单且繁琐的事情,相对于技术可能更考究细心与耐心。
- 涉及广度大;一般涉及的范围很大,虽不至于天文地理,但也基本和项目的开发截然不同。
- 一次就好;基本实现一次就好,不需要频繁迭代维护,甚至不维护。
这些特点,导致这部分的内容,更像一个苦差事。但随着各种自动化工具、集成工具的发展,完全可以把这些内容脚本化,进而可视化、自动化,慢慢的就会找到这部分的乐趣,能把一堆繁琐的东西理的井井有条,还是很有成就感的。
有一点要谨记,做好文档,做好规范。
软技能
很多行业慢慢由增量时代转入存量时代,做开发亦是如此。
由于模块拆分的越来越细,第三方的服务越来越多广泛且专业,导致开发一个产品的门槛越来越低。
不能再像以前那样,闷头只钻研技术,而忽视软技能的发展。我不否认依旧有很多硬靠技术吃饭的人,但我知道,我不是。
技术&软技能,就像一块木板的长和宽;最终拼的是面积,而不是单纯的长或单纯的宽。但不要因噎废食,过于注重软技能而忽视技术;要做的是以技术为基础核心,同时也注重软技能的发展。
沟通
沟通是一门很大的学问。
小的来说,沟通可以简单分为:
- 向上沟通
- 向上级汇报
- 向下沟通
- 向下级安排任务
- 跨界沟通
- 向其他部门咨询或请求援助
其实,不仅仅是说话,所写的文档、代码等,也都可以算是沟通的一部分。
沟通的目标是让别人理解你的观点,或者是理解别人所表达的内容。无论哪一个方面,都需要换位思考,并且有事直问,不要妄加揣测。
主人翁
全心全意去做当前所做的项目。(我可没说把公司当成自己的家。不一样吗?你品,你细品!)
不要只做自己该做的,剩下的高高挂起。
原因如下:
- 早晚都要自己带团队做产品,与其到时抓破头皮,不如早做准备。
- 看的越多越仔细,会发现一些不曾注意到的细节,都是知识,都是财富。
- 有时候,编程也是门经验学科,有很多坑早晚都要踩过一遍就知道,踩得越晚,坑越深。
- 给上级一个让你晋升的理由。
在开始,大家都是消费者,但可以慢慢成为一名生产者,产出对团队有利,对自己又何尝不是。
一方的利益获得不一定伴随着另一方的利益损失,世界上有很多多赢的事情,只要利益的获得满足自己的预期即可。
体会一句话:你可能血赚,但我绝对不亏。
一个咖啡杯的故事
真人真事,在一个早上,我去便利蜂买杯咖啡,它们就是那种自助咖啡机,排在我前面的人,并没有放置咖啡杯,就开始扫码结算,这时我可以
- 提醒他,让他先放杯子。
- 不提醒他,让他自生自灭。
选择不提醒,最好的结果是,机器检测到没有放咖啡杯,然后提示放咖啡杯;最坏的结果是,机器直接出咖啡,客人手忙脚乱拿咖啡杯去硬放,烫伤自己,然后…。
选择提醒,就一句话的事情,可以避免很多事情;即使对我自己而言,也节省了我的时间,否则按最坏打算,我的这杯咖啡,什么时候能拿到呢。
其实,这个现象就跟团队内的合作沟通一样,很多东西提前通知,做好预备,往往一句话的事情,可以其他人很多的弯路,对整个项目而言,必然有利而无害的。
方向
工作这些年,早期,基本花了很多的时间花在摸索上,更多的关注在如何做一个完整的项目,也就是俗话中的深度和广度中的广度。
现在,对这一行有了大概的认知与理解,更需要的是去进阶一些深一层的东西。就像之前的策略 以技术为主,软技能为辅的发展一样,在技术中也要找到一个专精领域,再以其他领域为辅去进行进一步的发展。
然后,技术上很多东西是相同的,没有必要把自己局限于某个角色,在不同的角度思考问题,会发现不同的内容。
最后,依旧是那句话,屁股决定脑袋。所在的位置,利益诉求,会影响信息、判断与决定,每个人的阅历、想法不尽相同,不需要逼迫着所有人 思想的统一、行为的统一。
准则
专业的事情交给专业的人,简单繁琐的事情交给脚本,留出时间做重要且核心的事。
目标
不做总线,做一个被自己替代的人。
总线,是必不可少的组件;它的阻塞会导致系统无法运行。
但有的时候,有些总线就没必要存在。
一个例子:
之前在生成 Android包及热更的时候,必须由开发来执行。
大概流程是这样的:
- A想要包测试内容
- 告知开发出包
- 开发出包完成,交给A
这样有诸多弊端:
- 出包占用开发电脑资源,影响开发原有功能开发
- 由于出包不便,必然会减少出包测试的请求,整体上讲对项目不利
- 期间有多个交接口,无法查进度,隐性所需时间拉长。(比如A告知开发出包,开发是否立马去出包,或者忘记出包等)
- 在忙碌的时候,手抖导致出包错误,重新出包
- 等等
这个流程中,开发就是总线,但是这个总线是必要的吗?显然不是。
于是,采用一些方法去把总线替换掉:
- 将出包相关脚本化、自动化
- 使用Jenkins实现接口暴露及工作空间共享
这样,出包的流程变为:
- A想要包测试内容,登录内网jenkins地址,根据需求出包
- jenkins出包
- A从jenkins空间中拿包
这样,开发从这个流程脱离出来,并且对于A有更多的配置选项可以配置,更为便捷,同时,出包进度也可视化,更有利于减少隐性时间消耗。
当然,这只是简单的一步,为了让它更加可靠且易用,必然要经历大量测试并且有一些预警机制,每隔一段时间进行使用者的反馈来扩展功能。
这只是简单的关于总线的例子,其实很多东西,都是表面上的总线,就如同那句话:
世界正在变得越来越自动化。因此我认为,并非每个人都需要学习编程,而是每个人都需要学习和理解如何实现自动化。—— 《Don’t Learn to Code — Learn to Automate》
未来
未来,谁都不知道会怎么样。
能做的就是总结过去经验,把握当下。
确定长目标与短目标,以一年或关键时间点为期,进行总结,看是否在既定的路上前进。
重视并珍惜每一个机会,每一个项目,只有在总结的时候才去考虑收益的事,剩下的期间全心全意的去做事。
多想多讨论多实践多总结,步入一个良性的循环。
然后,多读书,保持健康。
引用内容: