从游戏开发到应用开发的转变

从2011年大学毕业到2014年年底,这段时间我的软件开发生涯是在游戏圈子里渡过的,虽然终究并没有做出什么名堂来,但是至少也是混到了服务器主程的位置;游戏开发的那些日子,大概也是进步最快的日子,回忆起来自己的博客里面比较有质量的文章都是那段时间写的,尤其是面对上线和大并发的时候,对于软件和代码的理解有了不同于刚毕业那会的理解,我想大概也是项目推动成长吧!

       时间来到了2014年年底,随着自己对于游戏开发的兴趣骤减和于策划方案冲突的急剧加深,慢慢产生了离开这个行业的想法,于是就在那个契机,自己放下了一切切入到了应用的开发!

       记得第一个应用是一个手机端的应用,大概是一个类似于微博那样的应用,当然功能要弱化的多;简单被带着入门app端之后,发现服务器端的逻辑完全无法入手;最后也是在网上抄了一个redis的微博的例子;在这个例子的基础之上开做起来了。那个应用的数据库没有使用mysql,而是直接使用的redis,现在无论如何我也不会这样了吧。没有用mysql也主要是因为自己对于mysql的不熟悉,做游戏的时候对于数据库的使用处于全部nosql或者简单mysql的状态。比如我们只会设计一个玩家表,可能很多人要说玩家不是很多属性吗?一个表怎么够用,其实我们是把很多玩家的数据全部封装成json,base64转换,zip压缩,已text形式保存到mysql的表中。这样几乎mysql中两三个表就能保存游戏中所有的数据;可是到了应用层则就不一样了,一个微商城都几乎使用近一百个表,还要处理个个表之间的关系,试图等等。

       做游戏服务器的时候,写逻辑几乎不与数据库打交道,而现在写应用却几乎很难离开数据库。写游戏的时候,比如做一个帮战系统,进入到帮战里面所有的人,都是登录玩家,玩家数据已经全部加载到内存中,和他交互或者的其他玩家都是这个场景内的其他的玩家,数据也早已经加载到内存中,任何一个打斗,交互,移动等逻辑处理,都是处理内存中数据和逻辑。做应用就不一样了,应用中用户之间交互的载体变成了数据库,而不再是内存,如果用户A想要得到用户B的行为,那么用户B的行为首要要被存储到数据库中。这一点是在从游戏服务器转向webapp的过程中最痛苦的也是最难理解的,至少我个人是这个情况。记得自己第一个php小应用,把MySQL的连接做成了全局变量;以为这样每个连接都能共享;知道后来发生了mysql连接不够用的情况。

       对于游戏来讲,数据库只是一个玩家下线暂存玩家数据的地方;也就是说并不是重中之重;而对于应用来讲则不一样了;数据库除了保存着应用所有的数据,还可以用来驱动逻辑,比如触发器,游标,等等。比如排行使用order等。所以这造就了游戏程序员看到一个业务或者模块,首先想到使用怎么样的数据结构。而对于应用程序员看到了一个业务和模块首先想到了是如何设计数据库;我现在看到了很多应用开发者再处理一个逻辑的时候,首先想到的并不是从数据结构上做文章;而是首先改变数据表设计。

       在做游戏开发的时候,是把nosql作为主数据库设计的,在我开发游戏的前两年,都是用mongo作为主要的数据库;但是到了应用上,nosql还是用来作为一些特定模块的解决方案,或者是为了缓存一些常用数据。比如商城系统,对于经常游览的商品,我们就把它保存到redis中,对于首页,我们也直接将首页的html+css数据保存到redis中;但是在应用中把nosql作为主数据库,遇到复杂的逻辑,比如商品销量统计或者订单统计之类的需求,用redis就勉为其难了。

       软件开发是一个行业,可是这个行业内不同应用层之间也似乎像是隔山似的,有着不同的开发原则和准绳;我们从一个应用层到另一个应用层,也应该抱着谦卑的姿态,首先做到融入,再熟悉,然后再想着发挥自己的才能才好!

       

       

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值