dogfeet 最近的时间轴更新
dogfeet

dogfeet

V2EX 第 41272 号会员,加入于 2013-06-27 09:33:51 +08:00
今日活跃度排名 3591
求个便宜点的办公地点。
武汉  •  dogfeet  •  2014-10-22 14:52:15 PM  •  最后回复来自 moseschou
12
红杏是跪了吗?好像用不了了。
Chamber  •  dogfeet  •  2014-07-04 19:05:55 PM  •  最后回复来自 NEX
8
dogfeet 最近回复了
2021-01-06 11:04:03 +08:00
回复了 ppdudu 创建的主题 Android 求教,手游或者页游渠道商是怎么保证分成数据真实的?
一般按分成合作的渠道方,会要求产品方接入指定的支付通道,也就是所有的流水是先进入到渠道方户,然后按期按比例结算给产品方。这样的话,充值数据双方都是很清晰的。
至于切支付这种骚操作,各家反正都有防。App Store Google Play 这种就是审核+下架+封账号教做人。至于国内的小米华为这种啥的,和前面 2 种有本质区别,这种渠道都是严格的指定量,上这种渠道很不划算,即使有自然量也是产品方的品牌效应。我的理解就是,上这种渠道一般都是因为渠道会保证提供一定的量。如果被发现后期切支付,渠道方只需终止合作不再提供量就行了。
重点产品合作方一般都会定期复查一下的。
个人认为,有流量合作的,不要切支付,坏口碑,以后难找合作。
Google Play App Store 这种,切支付必然夹带马甲包,操作成本也很高,省下来的 28% 左右的利润能否支撑这个操作成本需要自己衡量。
以上有一个例外,就是国内付费游戏,又无版号,这种如果非要违法上,只能切了。
2020-11-06 14:38:24 +08:00
回复了 cuixiao603 创建的主题 程序员 有跳板机情况下如何打洞?
跳板机上没 nc 的话,可以直接先在跳板机上开个隧道
ssh -Nfg -L 3306:127.0.0.1:3306 目标机
然后在本机上执行
ssh -Nfg -L 3306:127.0.0.1:3306 跳板机
这样访问本机的 3306 会先通过隧道到跳板机的 3306 然后再通过隧道至目标机的 3306
2020-09-10 11:05:27 +08:00
回复了 noahsophie 创建的主题 游戏开发 现在游戏后端是怎么做存储的?
C++ 的服务端吗?说个非 C++ 的方式,填业务逻辑的地方是框架预留的地方,都做了异常的检测。服务挂掉的时候框架会提供指定的异常回调处理。一般情况下在这里记录日志加回写数据。半年的研发周期本身就应该让宕机的概率变的很低。挂掉还有机会回写将数据丢失的可能性进一步降低(当然,要保证回调里面不再或几乎不会出现异常)。
但是,这样还是不能解决数据一致性问题,比如修改数据一半挂掉。这种情况下回写的数据是不完整的。这种只能通过业务逻辑中的日志来记录。非极端情况下是能将玩家数据恢复到之前一致的。
以前特别纠结这种问题,总想为什么没有既能完全保证数据一致性,性能又好,心智包袱又小的方案,让写业务逻辑的时候无脑一点。现在想想真的太难,老老实实做好日志记录,关键数据一致性问题能通过日志追踪复原到比较理想的状态也差不多了。

就是 mysql 这种,ACID 不开串行异常级别,一致性也不能支撑完全的无脑的开发。
比如扣减余额,转账这种。默认可重复读级别并不能解决并发的问题。只要允许 2 个事务一起操作该数据,一样余额能成负。最终还是需要额外处理。
接过大量 SDK,也开发过一些。建议所谓测试模式正式模式,都做到生成环境中去。

正规一点的 SDK 常见的做法是:为客户分配参数,然后客户的应用默认是 Test mode.

客户正常接入(接入过程中会有很多垃圾数据脏数据),等到正式接入完成,你们再后台验收,查看关键接口调用与数据是否正常,验收正常,将 Test mode 修改为正式模式。


容易出错的地方,不要吝啬,多打日志,客户多了,什么样的程序员你都会见到的。
2020-09-07 19:04:48 +08:00
回复了 he110comex 创建的主题 iDev 如何申请美区苹果个人开发者账号?
开发者账号有区域之分吗?结算不都是走美元吗?个人的话,提供双币信用卡就行了啊。

直接申请开发者账号。开发者区域和应用发布区域没啥关系啊。
无论怎么申请的开发者,都可以发布全球区吧,只要符合当地规定就行。比如如果发布时要选大陆,付费游戏就需要提供版号。
2020-09-01 23:33:31 +08:00
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
@gantleman
还有,你说 [普通程序员用演员模型加数据库写的缓存服务不可能比 redis 更快]
当然,特指场景服务,多少人同屏本身服务端压力就是场景服务
场景服务一般做法是,状态直接在内存中,这个内存是 Actor 的 state,Actor 可以是一个完整的小场景,亦可以是一个大场景的一个区域,根据实际情况划分。
该区域类的玩家操作直接在该 Actor 中处理,状态就在这个 Actor 内存中,而且就是原生的数据结构。各种技能的计算就像在客户端写顺序代码一样,数据会有策略落地,但是逻辑都是在内存中完成,只有加载场景才有读的动作。

并不是你想的那种 CURD,一个请求过来从数据库或者其他缓存中拿一堆丢失了结构的数据,一顿操作然后再回写数据。
2020-09-01 23:17:43 +08:00
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
@gantleman 前面已经举例了,场景中玩家释放范围技能,技能还分各种类型,与玩家当前的 Buffer 息息相关。想想你状态都放 Redis 逻辑怎么写? PVP 的时候,血量,Buffer,技能类型的触发逻辑还是要非常严谨的。2 人一起释放技能攻击第三方,第一个技能攻击到受击者触发一个被动 Buffer 并进入 CD,第二个技能攻击到受击者,但是被动已经 CD,不会触发。按你上面的状态都丢 Redis,先不说你那个取范围技能的所有受击方靠不靠谱,场景角色上挂的 Buffer 血量等等相关的数据不要太多,2 个技能,你要保证被动只触发一次都麻烦的很。这还只是众多技能中非常常见的一些需求。

前面说的都是场景相关的功能,场景,Scene 。什么九宫格,十字链表,相位啥的,都是应用到场景服务上的。
养成玩法就不说了,谁跟你说场景服务是每个玩家每种功能创建服务?创建 Actor 永远都是把相关的放一起,不怎么相关的分离开来的原则。 [连 Actor 的拆分都是要考虑粒度的]
2020-09-01 19:44:03 +08:00
回复了 windliang 创建的主题 程序员 累计用户 50 万的小程序可以赚多少钱?
太真实了。。。
2020-09-01 19:24:09 +08:00
回复了 mocxe2vwww 创建的主题 Java POJO 对象各种嵌套, 有什么办法通用的处理?
说的是 POJO 麻烦,还是 Dto 与 Vo 转换的麻烦?
POJO 嵌套可以用 lombok 嘛。
至于 Dto Vo 转换这种,MapStruct 了解一下。
https://github.com/mapstruct/mapstruct-examples
这里面的:mapstruct-mapping-with-cycles 、mapstruct-nested-bean-mappings 2 个例子应该是你感兴趣的。
2020-08-31 20:21:22 +08:00
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
在知乎上又看到了这篇文章。
多说几句,超大地图,AOI 这种,跟放不放 Redis 没啥关系。所谓的相位技术也这是场景分割的一种方式。数据不放 Redis 的原因是,场景中的计算本身就需要实时,放到 Redis 中还得要异步的读写,明明用了 Actor 模型将关联逻辑分割到一起降低了并发与同步的心智包袱,又引入一个外部缓存让计算变成异步的,带来的数据一致性的问题完全抵消了 Actor 模型的优势。大量的位置数据,AI,技能延时,技能范围伤害等实时的逻辑都依赖状态,这些状态放外部存储中逻辑写起来有多麻烦尚且不说,拆的这么细,性能风险很高。连 Actor 的拆分都是要考虑粒度的,状态提出去把场景服都搞成无状态实在不觉得收益在哪里(养成等玩法无状态倒是没啥问题)。
Actor 模型在游戏界中往往用 state full 的形式,场景不是简单的状态,而是 状态+计算。
像微软的
Orleans ( https://github.com/dotnet/orleans
与 EA 开源的
Orbit ( https://github.com/orbit/orbit
这种新型的 Virtual Actor 模型的框架,游戏场景的使用都是 state full 的形式。
redis 的优势,
集群,游戏已经场景逻辑上已经通过 Actor 分割了,用不上。Actor 分割出来的逻辑数据单元关联性要强的多了。
各种数据结构,性能有没有优势不说,放外部已经高了不少延时,最主要的是复杂点的数据,没法按场景服务计算式需要的结构,直接扔 Redis,最后必然带来一个转换的开销。
各种过期淘汰策略,这在场景服务中做完全没问题啊,业务逻辑中 timer 相关的东西多了去了,Redis 反而不够用。

示例中场景,交互性太弱了,角色与角色之间的交互太少,跟真实游戏的业务场景相差太大了啊

当然,说了这么多,都只是解决大场景,同场景的一些方式方法。
万人同屏这个不敢想,个人觉得,目前的硬件,最后无论用什么方式(除了 step lock )做到了万人同屏的效果,
我估计实时性肯定无法让玩家能感受到正常的游戏体验。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3951 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 18ms · UTC 09:06 · PVG 17:06 · LAX 01:06 · JFK 04:06
Developed with CodeLauncher
♥ Do have faith in what you're doing.