`
shuiyan
  • 浏览: 34035 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

【推荐】我的FLASH情结2010——浅谈FLASH WEB GAME与创业(3)

阅读更多

前端与后端的配合
FLASH与后端通讯的手段多种多样,网上相关教程太多了,这里不再例举。但很多时候,创业团队由于受制于各种现实条件,可选择的方案并不多。像我们公司,刚开始基本上只能选择FMS+PHP+MYSQL。其实,对于我们前端来说,后端选择什么解决方案对我们的影响并不大,我们无非就是用的API不一样而已。多看看教程,用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢?我觉得关键是逻辑的划分。

前后端合理划分逻辑,这句话咋看上去貌似简单,其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性:记得我们的游戏同时在线超过3000的时候,就已经有人开始攻击我们的后端了,篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家,如果是恶意的商业攻击,后果不堪设想。经过这次后,老板开始缠着我们追问怎么防止别人攻击,提高安全性。这个问题又一次把我们难住了,我们都知道,基于HTTP的请求不被截取是不可能的,而SWF文件又不存在绝对的安全。就算你防得了恶意进攻,你也防不了良性的外挂,想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了?不是!如果前、后端在合作的时候,数据逻辑与合法性检查都是做在后端的,就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端,比如用户在玩小游戏的时候,我们不要只是在用户结束小游戏后,简单的把数据传回后端,后端记录进数据库完事,一旦攻击者发现了你这个传数据的后台接口,完全可以避开SWF,做外挂直接呼叫你这个接口刷分,就算你验证用户也没用,因为他可以先注册一个合法的用户,然后在外挂中登录再刷分。当然,你还可以对游戏分数先加密在传给后端,提高攻击难度,但这也是不保险的,因为加密算法就在你的SWF文件中,别人可以很容易获得。所以正确的做法应该是:游戏开始的时候只告知后端游戏ID后端标识ID对应的游戏已经开始并记录开始时间用户每次获得一个分数时,前端传回来的不是分数,而是一个动作ID,后端根据动作ID给用户加分游戏结束时,前端告知后端游戏已经结束后端得知游戏结束,记录结束时间,计算时间差,根据时间差和最后得分是否符合标准做出相应处理,如果符合标准就把最后得分入库,并返回前端显示给用户,如果不符合标准,就启动 处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析,你可能头痛了,本来一个很简单的小游戏计分,怎么搞得这么复杂?前后端工作量都增加了不说,对后端性能也提出了更高的要求,服务器可能要增加了,后端人手可能要增加了,开发周期也要延长了,值得么?这个问题问的很好,这正是我下面要说的:后端性能、工作量、人事分工:一旦我们每一步进行安全性与合法性验证后,整个项目的工作量都会大大膨胀,开发周期也会大大延长;一旦我们把数据处理、业务逻辑和安全验证都移到后端时,后端的压力就会增加,服务器要增多,对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力,软件硬件都不足,可能顾不上那么多,一心想着早点让项目上线。在这种情况下,我觉得安全性可以暂时放一下,众所周知的安全漏洞补上就可以了。但数据处理和业务逻辑这个,宁可开发的慢一点,宁可再招个后端高手,宁可多几台服务器成本,也要把它们尽量都放在后端。因为这个没分清的话,会影响到整个系统的清晰度,严重影响项目中后期的发展,为日后的重构增加难度和超多的工作量,我们还指望着在重构时加强安全性呢,到时候数据处理和业务逻辑还是要放后端!所以综合考虑,该出手时就出手,能省的不浪费,不能省的不要抠!

前面一节谈了前后端合作的难点。这里再简单的谈两个要点:
        1
,前端人员不要以前端的角度看后端:前端和后端有个本质的区别,就是前端的负荷是分担在每个客户端的,而服务端的负荷是集中在服务器上的。对于我们前端来说,一个功能多占了几K内存,SWF文件大了几K根本不是什么问题,可对后端来说就是很严重的问题了,一个人大几K,上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点,一旦这个平衡点被打破,随便再多哪怕一点点资源占用,整个服务器的性能都会严重下降,影响用户体验,当然,如果你有几十上百台冗余服务器供你负载平衡,你可以当我没说,可如果你像我们公司一样,一开始就35台服务器的话,就请前端人员一定要多多配合后端人员,帮他们省出每一个字节,每一次请求。比如像道具属性会有很多文字说明,这些说明应该以类似XML文件的方式储存为静态文件,后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品IDXML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K,对后端来说意义重大。还是那句话,只要不是架构性问题,前端不要怕麻烦,要尽量配合后端提高性能。

        2
,前端后端要有很明显的BUG分界点。当一个BUG出现时,后端应当很快的用一种统一的方案证明数据没有问题!这个方案必须让前端知道,并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser,这个东西就很好,它能罗列出所有PHP的接口,我们输入参数,它就返回结果,我们可以根据结果直接查看数据是否正确。——确定数据的正确性,对前端DEBUG非常重要,而一个BUG的解决,一般都是由前端人员入手并进行定位的。

其实相对于前端和美术的合作,前端与后端的合作还是简单清晰的,前后端在开发的过程中,应该是非常独立的,后端开发完全可以先启动,把数据接口提前写好,等着与前端整合,而当整合过程发生问题时,又可以很快的界定是谁的问题。

公司文化与产品定位
前面谈了那么多,无论是策划、美术、前端还是后端,大家通力合作,共同奋斗的目标无非就是希望开发出来一个好产品,而开发出一个好产品的目标无非就是成就一个好公司,这就涉及到产品定位公司文化的问题,公司文化和产品定位没做好,其它人再努力都是枉然。可正是这两个问题,从我们公司成立到现在一直困扰着我,我抓破脑袋苦思冥想,总结出我们公司的公司文化就是老板说了算,而我们的产品文化就是与时俱进,不断重新定位。下面我先谈公司文化再谈产品文化,因为产品文化是包含在公司文化中的。

公司文化:一个公司的文化在很大程度上是由初创团队建立的,而初创团队一般分两种,一种是权利分散型,初创团队在各个领域都有领头人,虽然也有形式上的CEO,但产品、研发、市场相互干涉的并不多,领导层内部三权分立,民主平等,对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补,让懂行的人完全负责相关领域,负责人成就感大,责任心强。缺点是,权利分散就要求领导层必须非常团结,配合默契,如果他们之间出现矛盾,对公司影响会很大。我们的竞争对手淘米网络就是这种模式,到目前为止,他们公司发展的还是最好的。另外一种模式就是老板专政模式,专政到什么程度,跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了,就连买一个几百块钱的路由器都要再三跟老板请示,美术、策划、开发所有的日程安排、人事任用都要由老板点头。专政模式在创业初期也未必就是坏事,因为创业初期,困难重重,大家又都有自己的想法,每个人的信心都比较脆弱,如果没有一个强势的人主掌大事,所有人容易形成一盘散沙的尴尬局面。专政模式下,公司文化其实就是老板的个人文化。专政的人一定要有专政的资本,有专政的能力,掌握着公司最大的权利,就必须承担最大的责任。如果公司成功了,就算你再说成功是大家的,最大的成功者还是你,但如果公司失败了,就算你找一千个理由推脱责任,最大的失败者也是你!在这种情况下,专政者要努力提高自己的全面素质,公司管理、产品、开发、策划、美术、市场都必须有所了解,你的任何一个错误的决定都会把公司推向深渊,并引起相关部门人员的不满。我们公司就是典型,老板以前是做销售的,对策划、开发和美术,甚至是互联网都没什么概念,做海底世界前连QQ都没用过!虽然他在资历和财力方面当之无愧,但其短板也是无法否认的事实。初创很长一段时间内,他都敢拍板说一个社区一个AS一个月搞定之类的话,而且还要非常强势的让你接受,并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定,我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来,而我们又没有取得他的信任吧,所以他就只能尽量往少的时间说,等到我们没完成工作,大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了,这种根本不可能达成的目标如何拿出执行方案呢?开发规划如何做呢?最后开发不出来谁承担责任呢?于是一个怪圈形成了:老板不信任开发制定不合理的开发目标制定不合理的开发规划开发规划没完成或者大打折扣老板认为开发者能力不行更不信任开发老板要求开发者提升自身能力满足他的要求开发者依旧满足不了老板老板在工作能力和员工素质上全面怀疑开着者制定更加不合理的开发目标甚至是惩罚制度项目更加完不成……额,这真是一个装满了苦水,倒又倒不出的杯具!当然,只要不是傻子,在这个悲剧的循环过程中,不管是老板还是开发者都会变得越来越聪明,老板一天天成熟了,程序员一天天世故了。只是曾经浪费的时间,错过的时机不再有,曾经不合理制度下积累的问题,明天需要继续补救!如果上天能给大家一次重来的机会,我相信,老板会说:下次我一定要在项目刚开始就找一个靠谱的,值得信任的CTO,而程序员会说:我下次再也不会跟着不懂技术还自以为是,横加干涉的老板了!

        
虽然民主平等高度专政两种模式都有其优缺点,但最终玩的都是一个字,相同项目,一个模式,不同的人玩出来的结果肯定不一样。同是专政模式,奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话,我个人更偏向于民主平等模式,这种模式下的公司领导层为了保证公司能长久健康发展,肯定会不得不想尽一切办法制定出平衡权利的法制规则,只要法制规则适应时代,领导层人事变动影响是可控的。而专政模式的专政者,为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌,肯定不得不想尽一切办法寻找接班人,帝国的命运系于接班人的选择。相对于人治,我觉得法制更靠谱。看到这里也许你又该搬出中国特色来反驳了,说什么中国的企业不合适。但纵观天下,历史的潮流是不可逆转的,中国作为历史发展的组成部分,脚步可以慢,但方向不会错。80后已经开始觉醒,90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题:你是只想做一个成功的企业家,还是想真正做一个成功的企业,让这个企业能长久发展,代代相传。一个成功的企业家的成功是个人的,而一个成功的企业的成功是大家的,是社会的!

产品文化:产品文化包含于公司文化,民主平等的公司,产品的文化就是管理层相同价值观的文化,而高度专政的公司,产品文化就是老板个人的文化。不管是什么类型的公司,什么产品文化,这个文化一定要简明而清晰,要深入人心,最好能浓缩成简单的一个词或者句子,妈妈放心,孩子喜欢就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了,到现在没有变过。我相信他们的用户,他们用户的家长,他们公司从管理层到员工每一个人,就连他们的竞争对手都对他们公司的价值观,对他们的产品文化有一个清晰的认识。而我们公司呢?反观我们公司,在这方面做的非常差,公司从成立到现在产品定位一直在变,刚开始要做一个针对初高中生和女孩子的休闲社区,搞了几个月后,又发现企鹅,一股脑的投入到儿童这块儿蓝海市场,说要做一个中国版的企鹅俱乐部,再后来可能觉得儿童市场有点小,收费比较困难了,又想把产品目标用户群再提高一下,提高到初高中生也能玩,游戏复杂度也要随之提高,这样还没做多长时间,又看到人家淘米推出赛尔号这种PK游戏了,又觉得纯绿色游戏的可玩性不高,对用户尤其是男孩子的吸引力不够,又要在我们的游戏里也加入PK和打怪了。直到现在,公司里上上下下,除了老板之外,没几个人能弄清公司的产品定位是什么,我们的产品文化是什么!这种情况导致一个很严重的问题,就是策划在策划游戏的时候,没有核心价值观,也就更没什么游戏世界观了,最终导致游戏形散神也散!

        
游戏一直在改版,功能一直在开发,BUG一直都存在,性能一直上不去,目标用户群一直在改变,老用户一直在流失,我只能用一个词形容我的心情:痛心疾首!

2010年:我的梦想扬帆起航
从毕业就一直在酷噜,一直做FLASH WEB GAME,当时的想法很简单,就是想体验一下顶尖的FLASH应用开发。转眼即将三年了,回眸探望,几多感慨,但终究还是能淡然处之。毕竟大家都不容易,大家都在摸索,也都在摸索中前进和成长,公司现在其实已经比刚开始好多了。

如今再打开4年前那篇《我的FLASH情结2006》,激扬的文字震撼我心。而现在的我,在海底世界的前端开发中已经找不到往日的激情,每日重复的机械劳动。而自己的理想,更是逐渐飘渺远去,一种温水煮青蛙的危机感油然而生。于是2010年,我向公司递交辞呈,结束我毕业后的第一份工作;再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。

那么2010年,我要做什么呢?没错,我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说:火山啊,你现在自己做项目有两个最大的问题,一是你没在大公司呆过,对一些正规的公司流程不了解;二是你原始资本积累还严重不足,很难支撑项目长久下去。其实我自己又何尝不明白呢,我知道自己这次单干也是九死一生,但我实在等不了了,7年的技术积累,3年的工作积累,为的就是今天,我也是奔三的人了,都讲男人30而立,马上要面对结婚生孩子,上有老下有小的艰难局面,我再不趁机把握最后这两年相对轻松自由的机会,以后会更难。我的梦想可能很天真,但我会做的很认真。

其实冷静下来想想,也没什么好怕的,想当年我敢带着一千块钱闯上海,今天我就敢拿着几万块钱自己干,大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒,虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少,虽然我自己得把策划、开发、美术和运营全做了这听上去有点假,虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦,但这都是外人看我的观点,我自己是乐在其中,浑然不觉,哈哈。不管怎么样,2010年,我的梦想必须扬帆起航,不以成败论英雄,只为人生少留遗憾!


(
原文)寂寞火山:http://www.huoshan.org/#BoKe_143

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics