Vimer的程序世界

届时还请大家多多支持~

游戏内小红点算是一个极其常用的功能了，之前在德州里面也有过实现。
然而之前的实现实在是乱七八糟，所以这次也是将其做了彻底的重写，并把方案跟大家分享一下。

我们将游戏内小红点可以分为三类：

1. 服务器小红点-服务器自动清除

   比如，我们常见的每日任务，成长任务，活动等。
   以每日任务举例：
   当有任务奖励可以领取时，在每日任务按钮上就显示小红点。
   当任务奖励全部领取完毕后，小红点消失。

2. 服务器小红点-客户端告知服务器清除

   比如，信箱功能，新好友通知，好友申请通知。
   以信箱举例：
   有新邮件，则信箱按钮就显示小红点。
   打开信箱后，如果信箱内分标签页，则判断标签页下的邮件列表，如果有新邮件，则在标签上显示小红点。
   当标签页打开之后，标签页上小红点消失。 当所有标签页的小红点都消失后，信箱按钮上的小红点消失

3. 客户端小红点-客户端自己维护

   比如聊天功能。

   登录时，拉取所有未读消息，如果有消息的话，大厅聊天按钮需要显示小红点。
   之后，当收到新的好友消息的时候，大厅聊天按钮需要显示小红点。
   当点击聊天按钮进入具体的聊天页面时，每个有新消息的好友页签，需要显示小红点。
   当点击该页签时，小红点消失。
   当所有页签的小红点消失后，大厅聊天按钮的小红点消失。

接下里我们说一下具体的实现。

首先，所有服务器小红点的状态，在用户登录的时候，就应该返回。
所以我们在登录协议里面增加了一个red_points字段 ...

其实第一次创业在技术上还是有不少历史问题的，所以在第二次创业就趁机做了很多弥补，下面详细说一下。

一.运行环境升级

直接列在这里

centos 6.5 x64  -> centos 7.5 x64
mysql 5.5       -> mysql 5.7
redis 2         -> redis 4
python 2.7      -> python 3.7
django 1.6      -> django 2.1
protobuf 2      -> protobuf 3

老版本有很多的问题，比如mysql5.5的性能问题，redis的dump性能问题，python2的中文处理问题，django1.x系列无法自动migrate，protobuf 2的default混乱问题 ...

三周目82.1个小时，《只狼》白金达成！

《只狼》是我玩的第三个魂类游戏，上一款白金的是《黑魂3》，而说来惭愧，自己的第一款魂类游戏居然是《仁王》，因为自己很喜欢和风，所以当时也是冲着这点开的《仁王》的坑。
我记得当时玩《仁王》一周目的时候，不停的死死死，结果后来耐不住性子开着修改器过关了。
但是等通关之后，我突然觉得这样子玩游戏有什么意思呢？于是关了修改器，重新开始打二周目，虽然艰难，但也开始享受到了魂类游戏的乐趣。
然而玩到三周目之后发现这怎么越来越像《暗黑》刷刷刷？

因为自己本身也做游戏研发，所以很仔细的分析过《仁王》的优缺点。
往小了说，《仁王》是把后期数值做崩了。
往大了说，《仁王》没有找清楚自己的定位。
比如同一把武器有多种品质，同一种品质居然还有多种属性。就算起着绝世神兵的名字，什么《雷切》，《妖刀村正》，背包里有十几把的话也实在是感觉不到稀有。
其实说白了，《仁王》不懂得什么叫克制，什么都想要，反而很容易迷失。
而深入来说，是《仁王》团队极度的不自信 ...

转眼间已经接近半年了。

18年12月份开始筹备二次创业的事，光组团队就折腾了4个多月，才终于把团队成型。
美术同学的招聘比较顺利，刚好是之前专门做像素画，也刚好想要跳出舒适区，挑战一下自己。可以说是一拍即合。
客户端主程的招聘就没那么顺利了。前前后后换了几个，中间甚至还遇到过薪资都已经谈好了，入职当天有临时要求加薪导致离职的。
不过好在最终还是找到了合适的人，才得以保证近几个月项目终于开始有条不紊的进行。

服务器端当然就是我自己写了，由于游戏的特点，服务器端其实是相对比较简单的。
但同时我还有一个重要的职责，就是策划。

你问我为什么不单独招一个策划？
说实话，我们在另外一个项目里尝试过这种方法，但是发现当产品的基调都没有定下来的时候，底下的策划很难去真正理解并细化你的想法。
所以，我宁可自己多辛苦一点，也要把这个游戏做成自己真正想要的样子。

值得庆幸的是，正因为如此，我才真正有机会能在和研发/美术一次次的交流中，完善自己的思路，并且碰撞出新的火花。

当然，做策划远比我要想的复杂，尤其是这种创业团队的策划。

一开始，我发现自己很难去确定哪种特性是好的。
具体的粒子就是，两个美术效果，我很难确定哪一个更合适，即使确定下来，也很难给出原因。
因为这是一个很综合的评估标准，而且有很大的主观因素，它并不像程序代码一样，有绝对的正确结果。
而对于我自己来说，我分析了下原因：

1. 在产品策划上的经验太少
2. 就是源于不自信
3. 之前做CTO留下的坏毛病，对自己权威的保护过强

第一个和第二个原因其实是相关联的 ...

第二次创业比第一次做的事情要更加繁琐一些，毕竟之前只要负责技术就好，现在几乎所有的事情都要和我对接，自己还要负责策划+项目管理的工作。
又要画原型图，又要画思维导图，还要画甘特图，有时候还得处理个音效，录个视频，修个图。。

也正是因为如此，所以自己前段时间找了很多工具软件来辅助自己，出于版权和成本的考虑，所以这里推荐的软件基本都是开源/免费的。

一. 原型图

名字: Pencil
价格: 开源免费
平台: Win/Mac/Linux
简介: 不仅仅支持原型图，也支持流程图等功能。
截图:

二. 思维导图

名字: Freeplane
价格: 开源免费
平台: Win/Mac/Linux
简介: 很方便的思维导图工具，而且有键盘快捷键可以使用，很适合键盘党。缺点是比较丑，而且在4K分辨率下很模糊
截图:

三. 甘特图

名字: GanttProject
价格: 免费
平台: Win ...

上一篇文章已经提到过，自己最近在做第二次创业。
至于再次创业的原因，等下次有机会跟大家聊，这次先整理一些和创业相关的工具。
这是自己以前整理的第一次创业时使用的工具: 给创业者整理的工具
时过境迁，很多工具都可以替换或者升级了，所以通过这边文章更新一下。

一. 代码托管

代码托管的选择其实蛮多的:

• github: 使用最广的代码托管网站了。上次创业的时候还只有开源项目免费，现在私有项目也可以免费使用了。但缺点是国内速度太慢。
• bitbucket: 免费支持私有项目托管，在上次创业中使用。缺点和github一样，也是太慢。
• gitee: oschina出品的代码托管网站，速度不错，国内用的人也比较多。但是私有项目有很多限制。
• coding: 与腾讯多次合作与拆分，搞得比较麻烦，但是后来还是独立回来，只是对于项目容量大小有限制。

经过了深入比较后，最终选择了 coding 来做代码托管，速度很不错。就是功能上少了点，比如分支保护等都没有。

当然，等项目做起来之后，可以通过 gitlab 搭建自己的代码托管服务器。

二. 任务管理

这几年一直想把wordpress换掉，因为明明最讨厌的语言就是php，自己还用php搭的博客。

之前之所以一直不做，也是因为python下的博客一直不成熟。

直到前段时间发现了这个：django-blog-zinnia。

支持python3，支持django2，最关键的居然是支持wordpress导入。

当然，实际操作起来才发现坑不少，好在python比较简单，改起来也很快。

折腾了两天总算搞定了，所有数据完美迁移，另外还把很久之前博客改短url导致链接失效的问题给解决了，美滋滋。

这次之所以花了这么久折腾博客，也是因为自己最近二次创业，感受上和第一次创业有了很多不同，所以也是想找时间分享给大家。

既然内容要更新了，门面当然也得跟着装修一下了，哈哈。

今天先写到这，等过几天开始正式写分享。

前段时间有朋友问我：创业这几年对你改变最大的是什么？
我想了半天，说道：应该是思考的角度。

一. 关于离职

只要涉及到团队，员工离职就是一个永远逃避不了的问题。

创业这几年，不停的有人入职、离职，人与人之间的关系可以多快的建立起来，有可以多快的消失掉。

而作为团队的leader要做的，就是通过 感情、成长、利益、希望 各种方面，将这段关系维持的尽量长一点。

之前，我一直在想，中小型的公司，即使能够一直还不错的活着，最终影响员工选择离开的是什么？
当时我得出的结论是：生活

在深圳，即使以腾讯这个规模的体量，也无法确保员工的薪水能够在深圳买的起房子，而仅仅只是能够提供部分无息贷款的方式。
那么小公司呢？

我想到最后，只有一个方法，那就是小公司要自己成长到足够的体量，足以让核心的老员工们，最终能够达到足够的财务自由。

然而，现实远要比想象精彩。

我忘记了还有理想这回事。

最难挽留的离职，不是太累，也不是没前景，也不是薪水低，而是理想。

就像我当年离职创业一样，并不是任何加薪之类的方式可以挽留的了的。

其实慢慢的，当公司足够强壮的时候，即时是leader级别的人离职也渐渐不会对公司产生多大的影响了。

而我一直相信并且也一直在被验证的事情就是：

每一个离开的人，都在让这家公司变得更好 ...

一. 前言

2016年6月17日凌晨5点钟，我们完成了服务器端V3版本的重构，切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着，我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日，现在看看，时间过的真快啊。

而熟悉我的人应该知道，我特意为上一次重构写过一篇《游戏服务器端架构升级之路》，其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构，我将其定义为第二次工业革命。也许它没有那么的强大和完美，但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过，V2版本的服务器的几个优点：

1. 支持服务器代码热更新而不影响外网服务
2. 架构模式足够简单：push-pull

但是，其简单的架构也存在一些缺点：

1. 业务模块之间容易互相影响

   比如两个游戏玩法 A 和 B，内部使用的逻辑、存储服务器都完全不同，但是在worker层却是共用的。

   所以一旦玩法A的服务器出现问题导致处理变慢，那么worker就会被堵住，而玩法B也会跟着遭殃。

   同时，即时在一个业务模块内，也存在请求处理优先级的问题，比如拉取牌局记录和跟注，要尽量避免跟注这种核心逻辑受到影响。

2. 限制了游戏逻辑的实现方式

   V2的多worker的模式，导致worker必须限制为无状态的，因为worker可能处理任何一个请求，而一个请求也可能被分配到任何一个worker上。

   这一点是之前解决服务器热重启的关键，但同时也限制了我们代码逻辑多样性的实现。

   比如我们的游戏桌子数据是存储在redis中，所有人对桌子的写操作可能同时分配到多个worker上，而为了避免写冲突，我们不得不通过redis来实现分布式锁 ...