315可信应用白名单
更新内容：
同一开发者
微信公众账号：应用宝是时候拿出这张图了（转自朋友圈）：&br&&img src=&/303b2f2cd28eb8a931cde7_b.jpg& data-rawwidth=&852& data-rawheight=&1136& class=&origin_image zh-lightbox-thumb& width=&852& data-original=&/303b2f2cd28eb8a931cde7_r.jpg&&
是时候拿出这张图了（转自朋友圈）：
唉，不说高大上的理论、执行效率和开发人员学习成本什么的，我用Erlang做游戏服务端开发，最大的感受就是：&br&&br&&blockquote&&b&策划案的不确定性和函数式语言的数学式抽象要求是矛盾的&/b&&/blockquote&&br&游戏开发过程大家最苦恼的就是程序反复跟着策划案调整，作为有经验的开发人员，一定不会抵触这种行业现状，也不可能要求策划案想好后就不做任何调整，而是应当尽量帮助策划早点明确思路，同时尽量想办法降低调整的成本，并减少调整后出现BUG的可能性。&br&&br&但是函数式语言的本质是要把逻辑和行为极度抽象，直到用一个个简单公式一个个严谨的模式就可以表达业务逻辑。&br&&br&当一个业务需求还没定型的时候就要做高度的抽象是非常有难度的，而且过早的抽象也导致调整起来很麻烦。&br&&br&以上是个人愚见，还望指正。
唉，不说高大上的理论、执行效率和开发人员学习成本什么的，我用Erlang做游戏服务端开发，最大的感受就是：策划案的不确定性和函数式语言的数学式抽象要求是矛盾的游戏开发过程大家最苦恼的就是程序反复跟着策划案调整，作为有经验的开发人员，一定不会抵触…
这不是早上skynet群里讨论的问题嘛。&br&&br&我就复述一下早上我提出的观点吧：&br&&br&首先技术是为解决问题而生的，技术就是解决问题的工具。当所要解决的问题不断变化的时候，工具就需要跟着不断变化，所以会有技术不断演进和改变的情况发生。&br&&br&最直观的例子是前端开发相关的技术，因为随着硬件性能的不断提升以及人们对体验的需求不断提高，这方面的技术相比于后端技术来说更迭得更快，因为所要解决的问题一直在不断变化。&br&&br&你再回头看看后端，十几年前大家在研究同步算法、怎样避免数据拷贝、怎样减少IO，这些问题到现在依旧如故，所以相关的技术变化比较少，当然现在增加了大数据和分布式的需求。&br&&br&问题的变化包含以下几种情况：&br&&br&1. 需求的提升，比如低分辨率升到高分辨率、2D升3D、3D不断提升表现精细度等&br&2. 需求的废除，假设有一天物理机之间通讯跟本机内存访问一样速度，很多分布式算法也得跟着变的&br&3. 问题域扩张，比如我原本做了个面向消息包处理的网络框架，现在想让这个框架同时支持流协议，API修改在所难免&br&4. 效率的提升，即便需求不变的情况下，人们总是在尽量提升解决问题的效率，直到有一天追求工作效率提升所花费的代价高于效率提升所换来的回报（投产比问题）&br&&br&你所说的makefile、linux和WPF、iOS、Android、Win32不是面向同一个问题域的技术，其实不具备可比性。&br&&br&makefile就是解决文件编译问题，这个问题域的变化显然是非常缓慢的，它长期不变是必然的。&br&&br&而linux作为一个操作系统，解决的问题就是资源管理，当资源管理上有新要求时它就变化了，比如select、poll、epoll这些东西都是同一种问题的不同解，显然是经过更迭的。&br&&br&iOS、Android这些技术所处的正是硬件和需求变化快的领域，它们变化最为频繁是必然。&br&&br&但是不管技术怎么变化，程序员长期积累的其实是在&b&如何用技术解决问题&/b&的经验上，而不是在具体工具使用上。
这不是早上skynet群里讨论的问题嘛。我就复述一下早上我提出的观点吧：首先技术是为解决问题而生的，技术就是解决问题的工具。当所要解决的问题不断变化的时候，工具就需要跟着不断变化，所以会有技术不断演进和改变的情况发生。最直观的例子是前端开发相关…
哈哈，如果没有充分理解Slice的原理，这会是一个深坑。&br&&br&实际过程如图：&br&&br&&img src=&/3ced1eb3dea09f35d7edae_b.jpg& data-rawwidth=&4208& data-rawheight=&3120& class=&origin_image zh-lightbox-thumb& width=&4208& data-original=&/3ced1eb3dea09f35d7edae_r.jpg&&&br&1. 创建s时，cap(s) == 1，内存中数据[5]&br&2. append(s, 7) 时，按Slice扩容机制，cap(s)翻倍 == 2，内存中数据[5,7]&br&3. append(s, 9) 时，按Slice扩容机制，cap(s)再翻倍 == 4，内存中数据[5,7,9]，但是实际内存块容量4&br&4. x := append(s, 11) 时，容量足够不需要扩容，内存中数据[5,7,9,11]&br&5. y := append(s, 12) 时，容量足够不需要扩容，内存中数据[5,7,9,12]&br&&br&这就是后一次操作覆盖了前一次操作数据的原因。&br&&br&参考实验：&br&&br&&div class=&highlight&&&pre&&code class=&language-go&&&span class=&kn&&package&/span& &span class=&nx&&main&/span&
&span class=&kn&&import&/span& &span class=&s&&&fmt&&/span&
&span class=&kd&&func&/span& &span class=&nx&&main&/span&&span class=&p&&(){&/span&
&span class=&nx&&s&/span& &span class=&o&&:=&/span& &span class=&p&&[]&/span&&span class=&kt&&int&/span&&span class=&p&&{&/span&&span class=&mi&&5&/span&&span class=&p&&}&/span&
&span class=&nx&&s&/span& &span class=&p&&=&/span& &span class=&nb&&append&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&,&/span&&span class=&mi&&7&/span&&span class=&p&&)&/span&
&span class=&nx&&fmt&/span&&span class=&p&&.&/span&&span class=&nx&&Println&/span&&span class=&p&&(&/span&&span class=&s&&&cap(s) =&&/span&&span class=&p&&,&/span& &span class=&nb&&cap&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&),&/span& &span class=&s&&&ptr(s) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&s&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&])&/span&
&span class=&nx&&s&/span& &span class=&p&&=&/span& &span class=&nb&&append&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&,&/span&&span class=&mi&&9&/span&&span class=&p&&)&/span&
&span class=&nx&&fmt&/span&&span class=&p&&.&/span&&span class=&nx&&Println&/span&&span class=&p&&(&/span&&span class=&s&&&cap(s) =&&/span&&span class=&p&&,&/span& &span class=&nb&&cap&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&),&/span& &span class=&s&&&ptr(s) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&s&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&])&/span&
&span class=&nx&&x&/span& &span class=&o&&:=&/span& &span class=&nb&&append&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&,&/span& &span class=&mi&&11&/span&&span class=&p&&)&/span&
&span class=&nx&&fmt&/span&&span class=&p&&.&/span&&span class=&nx&&Println&/span&&span class=&p&&(&/span&&span class=&s&&&cap(s) =&&/span&&span class=&p&&,&/span& &span class=&nb&&cap&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&),&/span& &span class=&s&&&ptr(s) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&s&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&],&/span& &span class=&s&&&ptr(x) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&x&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&])&/span&
&span class=&nx&&y&/span& &span class=&o&&:=&/span& &span class=&nb&&append&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&,&/span& &span class=&mi&&12&/span&&span class=&p&&)&/span&
&span class=&nx&&fmt&/span&&span class=&p&&.&/span&&span class=&nx&&Println&/span&&span class=&p&&(&/span&&span class=&s&&&cap(s) =&&/span&&span class=&p&&,&/span& &span class=&nb&&cap&/span&&span class=&p&&(&/span&&span class=&nx&&s&/span&&span class=&p&&),&/span& &span class=&s&&&ptr(s) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&s&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&],&/span& &span class=&s&&&ptr(y) =&&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&nx&&y&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&])&/span&
&span class=&p&&}&/span&
&/code&&/pre&&/div&&br&输出：&br&&div class=&highlight&&&pre&&code class=&language-text&&cap(s) = 2 ptr(s) = 0x
cap(s) = 4 ptr(s) = 0x
cap(s) = 4 ptr(s) = 0x ptr(x) = 0x
cap(s) = 4 ptr(s) = 0x ptr(y) = 0x
&/code&&/pre&&/div&&br&可以看出，s、x和y都指向同一个内存地址。
哈哈，如果没有充分理解Slice的原理，这会是一个深坑。实际过程如图：1. 创建s时，cap(s) == 1，内存中数据[5]2. append(s, 7) 时，按Slice扩容机制，cap(s)翻倍 == 2，内存中数据[5,7]3. append(s, 9) 时，按Slice扩容机制，cap(s)再翻倍 == 4，内存中数据…
这问题会被说是广告帖的。。。不过我最近看了好多问IT行业加班游戏公司加班的帖子，而我们公司属于加班特别凶的，对这个情况我若有所思，就借题发挥吧。&br&&br&要说我们公司情况，得从加班说起，为什么？因为团队节奏是我们四个创始人平时讨论最多的话题，关系着公司的未来走向和开发模式的转变。&br&&br&从最初做魔法之城，到神仙道项目，再到仙侠道项目，我们几个人的年纪在变化，身份在变化，生活环境在变化，对加班看法、团队节奏的看法也一直在改变。&br&&br&最初做魔法之城只有叶斌、阿贤两人加班，我是后面加入做魔法之城的，一开始阿贤一个人抗客户端和服务端，当时完全没经验，叶斌也没做过游戏，两个人各种熬夜苦撑，我来了就变成三个人熬夜苦撑，再后来项目还是因为拖太久挂了。&br&&br&之后叶斌去了一趟广州，参观了4399的团队，回来跟我们同步了他的感触：别人团队这么有经验还以那样的强度在开发，我们没经验不拼怎么存活？总结失败经验，迟则生变，新项目一定要快。&br&&br&于是神仙道项目开始拼了。神仙道项目能成当然不完全是因为加班加出来的，但是假设开发节奏没有转变，神仙道也没办法抓住市场的时机，也不一定能达到那样的高度。后来外面传说神仙道团队加班非常恐怖，这是事实。&br&&br&神仙道跑起来之后，我们回头看我们的开发节奏和加班强度，看团队成员的成长，我们当时的总结是：值得。虽然加班让大家付出了很多，但是只要愿意承担更多责任，长经验的速度也是惊人的。&br&&br&之后大家该成家的成家了，该生子的生子了。进入另一个人生阶段的同时我们开始了仙侠道项目。&br&&br&仙侠道的特殊性在于它是真有趣的第一款产品，决定团队的生死，所以还是不能悠着来啊，继续努力吧。&br&&br&网页版刚跑稳定，手机版接着来了，本来一个团队加班，现在变成 &a data-hash=&d512f99001bd9efe92e55a8b9a8d2170& href=&///people/d512f99001bd9efe92e55a8b9a8d2170& class=&member_mention& data-editable=&true& data-title=&@沈晟& data-tip=&p$b$d512f99001bd9efe92e55a8b9a8d2170&&@沈晟&/a&他们团队也跟着加班了，网页版一周一版本在跑，手机版每天拼到一两点。&br&&br&接下去怎么走？我不清楚最终会怎么样，我只能说从我的角度看，虽然团队还是在加班，但是很多细节在变化，观念在变化。&br&&br&团队不再是大部分单身了，有好几个兄弟有孩子的了，大家除了工作还要兼顾生活，我们希望真有趣是一个可以让大家扎根的公司，所以各种情况都要能照顾到。所以我们在尝试让一些有家室的兄弟当师傅带人，来分担他们的工作同时平衡他们的加班时间，另外让那些想通过自身努力来获得更多经验的兄弟也尽量让他们有拼搏的机会。所以团队节奏的把控不再是很粗狂的加班，而是很细颗粒度的按每个人的情况来把控。&br&&br&当然，能让整个团队不需要加班不需要那么累就可以做出很值得骄傲的作品同时又能过得不错，应该是真有趣的终极目标吧。&br&&br&怎么实现呢？目前打算做一次尝试，做一款一次性消费的游戏，想做一款能积累粉丝的游戏，试试看这样的模式能不能养活开发团队，希望这条路能走得通吧。引用叶斌的话就是：做了这么久的赚钱游戏，得奖励自己一次做不赚钱游戏的机会。&br&&br&在我们观念里，公司是人类社会多人协作的产物，它的存在目的不是赚钱，想象一下我们的祖先怎么猎杀巨象的，一群人分工合作达成一个人达成不了的目标，所以共同实现目标才是公司的本质。&br&&br&有的人想要做出好玩的游戏，有的人想要练就能支撑几万人在线互动的服务端技术，有的人想要让更多人认可自己的美术作品，有的人想要实现财务自由，公司就是这些理想的载体，只要能稳定维持下去，让大家一起实现一个又一个目标就可以了。&br&&br&另外从我负责的技术领域，我打算尽量多的分享我们的开发经验和技术，我的观点是技术要分享流通才能不断进步，行业内互相良性竞争才能不断提升，有兴趣的朋友请关注我们团队的github：&a href=&///?target=http%3A///funny& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/funny&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&P.S：本人加班经验丰富，从大学还没毕业就开始加班到现在成了公司合伙人还在加班，已有近10年历史，尝试过各种姿势的加班，比如连续通宵、封闭式开发等等，各种加班问题或心理咨询欢迎私聊。
这问题会被说是广告帖的。。。不过我最近看了好多问IT行业加班游戏公司加班的帖子，而我们公司属于加班特别凶的，对这个情况我若有所思，就借题发挥吧。要说我们公司情况，得从加班说起，为什么？因为团队节奏是我们四个创始人平时讨论最多的话题，关系着公…
当初从erlang切换到go，最难适应的就是没热更新。紧急修复BUG，在线修数据，等等，都是很救命的。&br&&br&再加上我们的服务端设计是整个数据库加载进内存的，重启需要较长时间，所以就特别担心频繁重启对游戏会很伤。&br&&br&后来产品上线了感觉还好，没有热更新的确没那么方便，但是也没那么可怕。&br&&br&原因：&br&&br&1. 需要临时重启更新就运营公告，如果实际较长就适当发放补偿。&br&2. Go加载数据到内存的速度也比之前快很多，重启压力也没想象的那么大。&br&3. 强类型语法在编译器提前排除了很多之前要到线上运行时才能发现的问题，所以BUG率低了。&br&&br&所以没有热更新也顺利跑下来了。&br&&br&不过以上只能做为参考，不同项目需求不一样，还是得结合实际情况来判断。&br&&br&热更新肯定是可以做的，方案挺多，数据驱动、内嵌脚本或者无状态进程都可行，只是花多大代价换多少回报的问题。&br&&br&如果评估下来觉得热更新必做不可，那么用再大代价也得做，这是项目存亡问题。&br&&br&&br&如果不是必须的，那就需要评估性价比了。&br&&br&做热更新、换编程语言或者换服务端架构所花的代价，换来的产品在运营、运维或开发各方面的效率提升，是否划算。
当初从erlang切换到go，最难适应的就是没热更新。紧急修复BUG，在线修数据，等等，都是很救命的。再加上我们的服务端设计是整个数据库加载进内存的，重启需要较长时间，所以就特别担心频繁重启对游戏会很伤。后来产品上线了感觉还好，没有热更新的确没那么…
乔布斯不在的日子。。。
乔布斯不在的日子。。。
吉野家的牛肉饭一点都不好吃，就是白米饭加几块火锅料的牛肉片，菜是开水烫熟的样子，一点味道都没有，这几样摆到一起就叫牛肉饭了，完全看不到诚意啊。就包装做得比其他家好而已。&br&&br&即便是吉野家的鸡肉也是让人感觉完全没诚意的食物，那些鸡肉明显都是流水线上下来的，吃起来一样没任何味道。&br&&br&同样是“肉+菜+米饭摆到一起”的海南鸡饭，为什么就可以做得很好吃？我不懂烹饪，但是至少吃能吃出做的人是不是有下功夫去做啊。&br&&br&其实我有点怀疑这是营销帖！
吉野家的牛肉饭一点都不好吃，就是白米饭加几块火锅料的牛肉片，菜是开水烫熟的样子，一点味道都没有，这几样摆到一起就叫牛肉饭了，完全看不到诚意啊。就包装做得比其他家好而已。即便是吉野家的鸡肉也是让人感觉完全没诚意的食物，那些鸡肉明显都是流水线…
我又来了。。。&br&&br&前一个问题里面分享了不会写tokenizer和parser的黑暗历史，这里继续分析一下后来会了只好是怎样一种体验。&br&&br&后来我在负责《神仙道》项目的时候，设计了一个描述通讯协议用的DSL，像这样：&br&&br&&img src=&/22ad5da782fb180d3674_b.jpg& data-rawwidth=&422& data-rawheight=&264& class=&origin_image zh-lightbox-thumb& width=&422& data-original=&/22ad5da782fb180d3674_r.jpg&&&br&有了这个DSL，程序就有了通讯协议的结构数据和描述，于是我又撸了一个协议调试工具：&br&&br&&img src=&/118df774_b.jpg& data-rawwidth=&643& data-rawheight=&656& class=&origin_image zh-lightbox-thumb& width=&643& data-original=&/118df774_r.jpg&&&br&这工具的原理就是一个socket代理，然后把经过的包都可视化显示出来，左手边的调试脚本也是一个DSL。。。。&br&&br&那时候的感觉就是什么自动化工具我都可以撸出来了，好爽。&br&&br&至于学习，我的起点很低，经历应该有些参考价值。&br&&br&前面撸正则的黑历史大家已经看过了，后来会了些皮毛主要还是因为有了之前的经验并且一直坚持研究，其实我中间还重新用正规做法做过一版模板引擎，但是那时候已经离开bbsmax项目了，再后来做DSL就驾轻就熟了。&br&&br&我一直对编程语言挺感兴趣，后来还做了一些玩具，比如这个PHP做的计算器，支持函数，但是没做闭包就停滞了：&a href=&///?target=https%3A///idada/CalcPHP& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&idada/CalcPHP · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&不过现在回头看，当时撸通讯协议DSL，我不如用JSON描述通讯协议，然后用网页做一个可视化编辑器，这样协议描述信息我都不用自己做解析就可以被各种语言使用，省事又高效。&br&&br&所以嘛，我觉得会不会是一回事，能不能用合理的方式解决问题又是另一回事。&br&&br&但是，机会是给有准备的人的，多学习没坏处，说不定那天就真的用上了。
我又来了。。。前一个问题里面分享了不会写tokenizer和parser的黑暗历史，这里继续分析一下后来会了只好是怎样一种体验。后来我在负责《神仙道》项目的时候，设计了一个描述通讯协议用的DSL，像这样：有了这个DSL，程序就有了通讯协议的结构数据和描述，于…
人肉语法树
人肉语法树
我们这边用法：&br&&br&&div class=&highlight&&&pre&&code class=&language-bash&&nohup ./bin/game_server 1& game_server.out 2& game_server.err
&/code&&/pre&&/div&&br&nohup这个命令可以把程序放后台运行，顺便通过1&和2&把标准输出和标准错误重定向到文件，这样程序崩溃时才会有记录可查，这两者和程序的日志最好是分开，混在一起没办法判断轻重缓急。&br&&br&进程启动时候记录下自己的pid：&br&&br&&div class=&highlight&&&pre&&code class=&language-go&&&span class=&k&&if&/span& &span class=&nx&&pid&/span& &span class=&o&&:=&/span& &span class=&nx&&syscall&/span&&span class=&p&&.&/span&&span class=&nx&&Getpid&/span&&span class=&p&&();&/span& &span class=&nx&&pid&/span& &span class=&o&&!=&/span& &span class=&mi&&1&/span& &span class=&p&&{&/span&
&span class=&nx&&ioutil&/span&&span class=&p&&.&/span&&span class=&nx&&WriteFile&/span&&span class=&p&&(&/span&&span class=&s&&&game_server.pid&&/span&&span class=&p&&,&/span& &span class=&p&&[]&/span&&span class=&nb&&byte&/span&&span class=&p&&(&/span&&span class=&nx&&strconv&/span&&span class=&p&&.&/span&&span class=&nx&&Itoa&/span&&span class=&p&&(&/span&&span class=&nx&&pid&/span&&span class=&p&&)),&/span& &span class=&mo&&0777&/span&&span class=&p&&)&/span&
&span class=&k&&defer&/span& &span class=&nx&&os&/span&&span class=&p&&.&/span&&span class=&nx&&Remove&/span&&span class=&p&&(&/span&&span class=&s&&&game_server.pid&&/span&&span class=&p&&)&/span&
&span class=&p&&}&/span&
&/code&&/pre&&/div&&br&同时监听系统发来的kill信号，在收到kill信号时做些收尾工作：&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&signal.Notify(sigTERM, syscall.SIGTERM)
&/code&&/pre&&/div&&br&这样就可以用kill命令关闭服务进程了：&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&kill `cat game_server.pid`
&/code&&/pre&&/div&&br&最初试过自己用系统调用实现daemon进程，但是发现和pprof模块有冲突，一pprof就死锁，不知道是姿势不对还是早期Go的BUG，反正那时候起就换成nohup形式了，简单好用。
我们这边用法：nohup ./bin/game_server 1& game_server.out 2& game_server.err
nohup这个命令可以把程序放后台运行，顺便通过1&和2&把标准输出和标准错误重定向到文件，这样程序崩溃时才会有记录可查，这两者和程序的日志最好是分开，混在一起没办法判断…
&img src=&/948bca3d98dfa55ea6b4b50_b.jpg& data-rawwidth=&263& data-rawheight=&260& class=&content_image& width=&263&&&br&没办法。。。忍不住。。。折叠我吧
没办法。。。忍不住。。。折叠我吧
Go的确更适合你这个情况，用Go做服务端开发很省心，只要不乱搞，按着套路来，做出来的东西就不会太差，我是指开发效率、可维护性和运行效率三个方面。&br&&br&你别看Go性能比不上Java的JIT，比不上C/C++，实际生产环境下，Go的执行效率完全是一流的，内存消耗控制还比Java好得多，绝对值得那一点性能差异了，你又懂C/C++，很多经验是可以延续到Go来用的，比如指针优化、防止数据复制，实在不行还有CGO可以让你用C/C++做些更底层得事情。&br&&br&框架方面，推荐beego， &a data-hash=&5ca33aadc924ddcf1f7814& href=&///people/5ca33aadc924ddcf1f7814& class=&member_mention& data-tip=&p$b$5ca33aadc924ddcf1f7814&&@asta谢&/a& 一直很努力在更新，用的人很多，群里有很多乐于分享的人，国内人开发国内人在用，遇到困难也比较容易获得帮助。
Go的确更适合你这个情况，用Go做服务端开发很省心，只要不乱搞，按着套路来，做出来的东西就不会太差，我是指开发效率、可维护性和运行效率三个方面。你别看Go性能比不上Java的JIT，比不上C/C++，实际生产环境下，Go的执行效率完全是一流的，内存消耗控制还…
老妈打扫房间扫走了啊
老妈打扫房间扫走了啊
客户端大多数是flash，小部分unity3d和自己开发浏览器插件或者html5。&br&&br&服务端有C/C++、Java、C#、PHP、erlang、nodejs等等，只要你想得到的基本上都有人在用。&br&&br&页游前后端一般使用TCP/IP协议，SNS游戏用HTTP协议的挺多，页游和SNS游戏在应用场景上有所不同，所以架构也会有所不同，所以SNS游戏用PHP的多，页游新兴时也是PHP的多，但是随着游戏类型多样化，需求提高，应该已经逐步没人再用PHP了。&br&&br&你说的释放技能这样一个流程：&br&1. 客户端告诉服务端释放什么技能&br&2. 服务端验证技是否能释放，比如玩家是否装配了这个技能，蓝够不够等等&br&3. 服务端按技能配置找到周围的命中对象（可能是群攻），进行扣血等操作，更新敌人和玩家的状态&br&4. 服务端发送广播给周围的客户端，告诉这些客户端发生了什么事情&br&&br&可以阅读Mozilla开源的Browser Quest这个项目，一个html5 + nodejs的游戏，完整演示了客户端服务端怎么通讯的，逻辑怎么做的，通讯怎么做的，很值得参考。&br&&br&游戏demo: &a href=&///?target=http%3A//browserquest.mozilla.org& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&browserquest.mozilla.org&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&项目代码: &a href=&///?target=https%3A///mozilla/BrowserQuest& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/mozilla/Brow&/span&&span class=&invisible&&serQuest&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
客户端大多数是flash，小部分unity3d和自己开发浏览器插件或者html5。服务端有C/C++、Java、C#、PHP、erlang、nodejs等等，只要你想得到的基本上都有人在用。页游前后端一般使用TCP/IP协议，SNS游戏用HTTP协议的挺多，页游和SNS游戏在应用场景上有所不同，…
谢邀。&br&&br&我目前用的就是类似你说的这个方式。&br&&br&请求到达 -& 解包 -& 启动内存数据库事务 -& 请求路由给对应功能模块 -& 执行业务逻辑 -& （接下来，两种可能）：&br&&br&1. 正常处理完请求 -& 提交内存数据库事务-& 内存数据库事务写入事务日志 -& 内存数据库事务转成数据库事务执行&br&2. 非法请求或程序BUG -& 抛出异常 -& 内存数据库事务回滚&br&&br&内存数据库事务转数据库事务我试过两种方式：&br&&br&1. 动态组装SQL并执行&br&2. 用预先prepare好的语句绑定参数执行&br&&br&两种都可以，prepare好处就是不需要动态拼接SQL，游戏端这边省内存又省CPU，MySQL那边也省CPU，但是update语句不是动态拼接SQL，要预先prepare语句只能全量更新，之前有担心效率不行，还好实际运行起来感觉没啥问题。不过prepare语句有一个数量限制，小心别被坑了就是。&br&&br&我使用MySQL，所以事先要将MySQL的自动事务提交禁用，改用手工提交事务，否则可能出现同步一半的时候同步程序自身异常导致内存数据库事务只提交一半到MySQL得情况。&br&&br&内存数据库的事务日志是非常重要的，写入MySQL之前需要先写同步日志，这样可以在MySQL通信故障时有数据可以还原，不用担心写日志的IO，顺序写入的效率是很好的，绝对没大负担。&br&&br&另外我在同步日志里记录了完整新旧数据和请求的类型、玩家ID、事务执行时间，记录的格式是自定义的二进制文件格式，每个文件头部有完整的表结构信息，可以用一个对应的分析工具结合lua脚本来分析玩家行为，回查漏洞或者BUG。&br&&br&也可以从同步日志截取生成完整的同步用的SQL或者回滚某段时间数据变化的SQL。&br&&br&生成SQL逻辑很简单，UPDATE和DELETE不需要特殊处理，INSERT用REPLACE语法替代就可以让SQL反复执行，不需要人工精确对比。&br&&br&内存数据库因为是自己实现的，所以要实现事务机制没有多复杂，插入的反操作就是删除、删除的反操作就是插入、修改的反操作还是修改。只要把新旧数据记录下来，要做事务回滚很容易。&br&&br&内存数据库的代码是按MySQL数据库结构自动映射生成的，所以只需要设计好底层结构，开发人员不需要管这些底层的机制，只需要按功能设计数据库结构就可以了。
谢邀。我目前用的就是类似你说的这个方式。请求到达 -& 解包 -& 启动内存数据库事务 -& 请求路由给对应功能模块 -& 执行业务逻辑 -& （接下来，两种可能）：1. 正常处理完请求 -& 提交内存数据库事务-& 内存数据库事务写入事务日志 -& 内存数据库事务转成数…
电影里最绝望的死法当然是“导演让你死”。
电影里最绝望的死法当然是“导演让你死”。
比如在OpenGL里，贴图单元数量是有限的，假设最坏情况只支持1个贴图单元，这时候你有一个2D角色的两个对象实例，分别正处于不同的动作帧，你如果没有用贴图合并技术把同一角色所有帧都合到一张贴图，那么要绘制这两个对象就会提交两次贴图，如果是合并贴图就只需要提交一次，然后通过在shader里面取不同的坐标来获得对应动作的贴图。&br&&br&同理，推广到一个游戏场景，有各种特效和角色，尽可能合并贴图带来的好处就是执行效率的提升。&br&&br&比如显卡支持10个贴图单元，那么你可以尽量把当前场景用到的各种贴图提交上去，然后把对象的顶点信息一次性提交上去，最好情况是只要一次贴图提交和一次draw call。&br&&br&更极端点，你的场景对象没有变化的情况下，之后的所有帧，你都不用重新提交贴图了，只需要每帧提交对象的顶点信息就可以了。
比如在OpenGL里，贴图单元数量是有限的，假设最坏情况只支持1个贴图单元，这时候你有一个2D角色的两个对象实例，分别正处于不同的动作帧，你如果没有用贴图合并技术把同一角色所有帧都合到一张贴图，那么要绘制这两个对象就会提交两次贴图，如果是合并贴图…}