P**H
发帖数: 1897 | 1 现在unity3d这些做单机的确糙快猛。但好像做联网联网还是得自己来。
那用什么工具呢？有现成方案还是自己写？
不同游戏可能要求不同。
比如3D网游，棋牌类，动作类？ |
z****e
发帖数: 54598 | 2 real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写
你建模必需把server side考虑进去，尤其是想做大型的mmorpg
c++ or java，很多国内私服都是用java写的，java可以，但是是core java
卡牌，棋牌这种回合制的可以用vert.x，但是还是需要自己启动并管理部分thread
node不合适，process太耗资源，akka又太复杂
vert.x主要问题是会的人少，招来的小弟不一定能顶用
动作类指啥？
游戏server开发难度要大过web很多 |
z****e
发帖数: 54598 | 3 mmorpg用java的话，还必需把gc的停顿时间考虑进去
要控制gc在ms级，最多不宜超过100ms，会影响客户体验
控制在20ms以内问题不大，所以内存最好不要爆超过10g
100g的gc卡死，这就对jvm的tune的能力提出了要求
具体问题具体分析，不同游戏要求是不一样的，设计也不同
另外就是real time的游戏不仅对程序要求很高，对美工要求更高
如果是3d的话，一个美工要你一万块一个月很正常
2d相对要求低很多，所以最好想清楚要做啥再来分析
光说游戏，scope太大，不好一概而论 |
z****e
发帖数: 54598 | 4 东亚人民比较喜欢回合制的东西
比如日本人中国人，都比较喜欢各种棋牌
包括中国的麻将牌，都是回合制的
所以这个real time要求相对低一点
可以不用刻意去怎么着控制gc
但是如果是cs, sc这种，那就要认真对待了
但是一般来说这种成本也高，所以刚开始做，你用不到
一个比较合适的real time游戏的题材是塔防，看zlike最早做的那个就知道了
塔防后来甚至发展出了dota和植物大战僵尸这些流行的游戏
卡牌现在最流行的舰娘，日本和华人圈里都有很多人喜欢
一个比较特殊的就是韩国人不是很喜欢萌文化，而更喜欢那种模特身材
喜欢腿长的，表问我为什么，我也不知道
但是明显感觉7头身甚至更多头身的棒子会比较感兴趣
而卡哇伊那种5头身的比较适合日本人 |
z****e
发帖数: 54598 | 5 卡牌游戏80%市场在日本
puzzle&dragon，舰娘这些都是日本银玩的东西
一个比较容易挖掘的卖点就是这个比较容易跟赌博的部分结合起来
比如给你一个幸运币，然后让你赌一把，有一定概率拿到稀有卡牌
酱紫，据说p&d的主要收益来自这种类赌博式的产品 |
P**H
发帖数: 1897 | 6 想个类似minecraft的点子，就把美工省了。 |
P**H
发帖数: 1897 | |
z****e
发帖数: 54598 | 8 对了，题材有一个经验，可以参考
跟黄赌毒沾边的，都比较容易火
尤其是黄和赌，毒这个不太可能
黄就是指美女，让美女有个大胸，露露裙底啊之类的
就比较容易吸引wsn来
赌上面已经说了
还有暴力，暴力，恐怖和性感经常凑一起出现
gta就是典型的这种垃圾
但是这样很容易就被r18了
apple好像比较抵触这种东西
如果低龄化一点的话，就最好萌一点
肉嘟嘟的圆脸＋大眼 |
z****e
发帖数: 54598 | 9 minecraft也有美工啊
美工是程序员他哥哥做的
【在 P**H 的大作中提到】
: 想个类似minecraft的点子，就把美工省了。
|
P**H
发帖数: 1897 | 10 c++是不是更好点，性能上说。开发维护，java好点。
【在 z****e 的大作中提到】
: real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写
: 你建模必需把server side考虑进去，尤其是想做大型的mmorpg
: c++ or java，很多国内私服都是用java写的，java可以，但是是core java
: 卡牌，棋牌这种回合制的可以用vert.x，但是还是需要自己启动并管理部分thread
: node不合适，process太耗资源，akka又太复杂
: vert.x主要问题是会的人少，招来的小弟不一定能顶用
: 动作类指啥？
: 游戏server开发难度要大过web很多
|
|
|
P**H
发帖数: 1897 | 11 美工体现在哪里？我只看到cube。
【在 z****e 的大作中提到】
: minecraft也有美工啊
: 美工是程序员他哥哥做的
|
z****e
发帖数: 54598 | 12 还有一个就是你可以从旁边周围人玩的游戏中汲取灵感
比如
minecraft是积木，一堆玩家就在建房子
初音未来是洋娃娃，一堆玩家就给未来换上各种衣服，然后让她唱歌，表演
三国杀就是麻将，互相盯来盯去，连横合纵
dota其实就是足球，差异化配合打掉对方的塔楼，射门
钢铁雄心就是围棋，如何把敌人的兵围起来，吃掉
所以这些东西在某些国家火起来不是没有道理的
中国人爱打麻将，所以就爱玩三国杀
minecraft因为欧洲有共济会，石匠文化，所以就喜欢玩这个 |
z****e
发帖数: 54598 | 13 这个纯粹看程序员他自己熟悉什么
因为没有太多现成的轮子好用，都是自己写的
其实维护都是一个大问题
java以前很慢，不适合搞这些
现在基本上gc控制在n*10ms这个级别上，所以其实问题不大
别乱用object就好了，一般游戏的object都要被pooled的
无论客户端还是server side，如果一帧就new一个object
那这种肯定会被自己弄死，所以immutable很不合适用来搞游戏
【在 P**H 的大作中提到】
: c++是不是更好点，性能上说。开发维护，java好点。
|
P**H
发帖数: 1897 | 14 日本奇葩不是一次两次了。现在还流行翻盖手机。
【在 z****e 的大作中提到】
: 东亚人民比较喜欢回合制的东西
: 比如日本人中国人，都比较喜欢各种棋牌
: 包括中国的麻将牌，都是回合制的
: 所以这个real time要求相对低一点
: 可以不用刻意去怎么着控制gc
: 但是如果是cs, sc这种，那就要认真对待了
: 但是一般来说这种成本也高，所以刚开始做，你用不到
: 一个比较合适的real time游戏的题材是塔防，看zlike最早做的那个就知道了
: 塔防后来甚至发展出了dota和植物大战僵尸这些流行的游戏
: 卡牌现在最流行的舰娘，日本和华人圈里都有很多人喜欢
|
z****e
发帖数: 54598 | 15 但是天朝的妹子和宅男更容易接受日本的文化哦
对美国文化反而会有些疏远
【在 P**H 的大作中提到】
: 日本奇葩不是一次两次了。现在还流行翻盖手机。
|
h******b
发帖数: 6055 | 16 糙快猛就用糙快猛的后台吧。
unity论坛很推荐playfab。
https://www.playfab.com
Parse : req/s : requests per second (30 free)
Photon : CCU : concurrent users (20 free)
Playfab : DAU : daily active users (1000 free)
GameSparks : MAU : monthly active users (10.000 free）
we assume 1 CCU to translate into 10 daily active users (DAU) and each of
these into 20 MAU. |
P**H
发帖数: 1897 | 17 这些后台好像多事用户，data的事。逻辑主要还是交给client，server管管交换。
如果在server端计算，游戏逻辑是不是还是要自己手写？
还有，万一用着用着，这些公司垮了，怎么办？
【在 h******b 的大作中提到】
: 糙快猛就用糙快猛的后台吧。
: unity论坛很推荐playfab。
: https://www.playfab.com
: Parse : req/s : requests per second (30 free)
: Photon : CCU : concurrent users (20 free)
: Playfab : DAU : daily active users (1000 free)
: GameSparks : MAU : monthly active users (10.000 free）
: we assume 1 CCU to translate into 10 daily active users (DAU) and each of
: these into 20 MAU.
|
h******b
发帖数: 6055 | 18 parse被脸书收购了。
firebase被谷歌收购了。
这两个比较保险。
游戏逻辑本来就得手写啊。
【在 P**H 的大作中提到】
: 这些后台好像多事用户，data的事。逻辑主要还是交给client，server管管交换。
: 如果在server端计算，游戏逻辑是不是还是要自己手写？
: 还有，万一用着用着，这些公司垮了，怎么办？
|
z****e
发帖数: 54598 | 19 你还是具体说说大概是哪种游戏的server吧
如果是minecraft那种server，一般的paas是不能满足你的需要的
需要在server side建模
iaas的话，注意避开那些iaas平台上独有的产品，比如dynamo之类的
就好了，游戏逻辑当然要自己写，除非你只是用一些简单的io
比如发送一个数据到server，然后存起来，然后读出来
酱紫，大部分paas就只能做这么简单的事，web就这么简单
所以用脚本，还有var这些东西
【在 P**H 的大作中提到】
: 这些后台好像多事用户，data的事。逻辑主要还是交给client，server管管交换。
: 如果在server端计算，游戏逻辑是不是还是要自己手写？
: 还有，万一用着用着，这些公司垮了，怎么办？
|
P**H
发帖数: 1897 | 20 这不是没有什么好的点子嘛。先积累一下技术。
mine craft那种可能投入太大。作坊难得搞。要不先搞个回合或者卡牌的试试水？
【在 z****e 的大作中提到】
: 你还是具体说说大概是哪种游戏的server吧
: 如果是minecraft那种server，一般的paas是不能满足你的需要的
: 需要在server side建模
: iaas的话，注意避开那些iaas平台上独有的产品，比如dynamo之类的
: 就好了，游戏逻辑当然要自己写，除非你只是用一些简单的io
: 比如发送一个数据到server，然后存起来，然后读出来
: 酱紫，大部分paas就只能做这么简单的事，web就这么简单
: 所以用脚本，还有var这些东西
|
|
|
z****e
发帖数: 54598 | 21 然，我也觉得minecraft其实没那么容易做
3d建模很恶心，你可以先做点卡牌试试
卡牌要红火比较难，因为同质化的竞争者比较多
但是很快可以出app，适合你练手
卡牌的话，服务器显然用vert.x管用啊，半控制thread
可以控制也可以不控制，但是卡牌每一局估计需要你启动一个thread
你看v3马上要出来了
【在 P**H 的大作中提到】
: 这不是没有什么好的点子嘛。先积累一下技术。
: mine craft那种可能投入太大。作坊难得搞。要不先搞个回合或者卡牌的试试水？
|
h*******n
发帖数: 82 | |
h*d
发帖数: 214 | 23 单机先搞搞，什么图像，声音，操作都了解了，再发展前后端。啥经验也没有，上来就
搞网络游戏，容易走火入魔 |
d*******r
发帖数: 3299 | 24 正解
另外, zhaoce 说的对, 实在要搞, 可以先搞搞回合的, 其实用现在的 web&http 就能
搞了.
你想搞好 real-time networking for gaming, 那个坑深得很, 你回头且慢慢研究.
【在 h*d 的大作中提到】
: 单机先搞搞，什么图像，声音，操作都了解了，再发展前后端。啥经验也没有，上来就
: 搞网络游戏，容易走火入魔
|
z*******3
发帖数: 13709 | 25
我现在就着手准备real time networking gaming了
一天到晚在udp,uint8,byte这些里面沉浮
不过就我观察，除了游戏，其他大多数应用，比如web，一般的social app这些
多数都是走tcp那条路，http,websocket这些都是tcp的
而只有vert.x这种才比较好地支持了udp，其他的多数都只考虑到了tcp
tcp的三次握手很恶心，属于脱裤子放屁
【在 d*******r 的大作中提到】
: 正解
: 另外, zhaoce 说的对, 实在要搞, 可以先搞搞回合的, 其实用现在的 web&http 就能
: 搞了.
: 你想搞好 real-time networking for gaming, 那个坑深得很, 你回头且慢慢研究.
|
P**H
发帖数: 1897 | 26 啥类的游戏？
[发表自未名空间手机版 - m.mitbbs.com]
【在 z*******3 的大作中提到】
:
: 我现在就着手准备real time networking gaming了
: 一天到晚在udp,uint8,byte这些里面沉浮
: 不过就我观察，除了游戏，其他大多数应用，比如web，一般的social app这些
: 多数都是走tcp那条路，http,websocket这些都是tcp的
: 而只有vert.x这种才比较好地支持了udp，其他的多数都只考虑到了tcp
: tcp的三次握手很恶心，属于脱裤子放屁
|
d*******r
发帖数: 3299 | 27 你步子真大, long time TCP connection, 再设置 TCP_NODELAY to bypass the Nagle
delay, 都不能满足你?
WarCraft3 (and Dota) 和 StarCraft2 都是在 TCP 上跑的, 其实还行.
自己在 UDP 上定制 low latency 协议是最后一步了, 一般是 real-time Action/FPS
(e.g. Call of Duty, Titan Fall) 才需要用到的, 你确定需要搞这个? :)
你现在是什么类型的联网游戏? |
z*******3
发帖数: 13709 | 28 tcp的每个数据包需要三次握手，多此一举
我读书时候做的几个应用，聊天室什么，都是在udp上完成的
研究生时候我们做的一个算法，也是如何保证udp上同步的协议
最后那个project就是这个东西的实现
我记得starcraft联机时候可选择udp还是tcp
我争取做到每一个frame都能够sync起来
这个要求可不低，做得也不是很复杂，2d realtime的pvp
我们当时做到的是两边控制两个角色，互相射，就是一个手机上的2d cs
Nagle
FPS
【在 d*******r 的大作中提到】
: 你步子真大, long time TCP connection, 再设置 TCP_NODELAY to bypass the Nagle
: delay, 都不能满足你?
: WarCraft3 (and Dota) 和 StarCraft2 都是在 TCP 上跑的, 其实还行.
: 自己在 UDP 上定制 low latency 协议是最后一步了, 一般是 real-time Action/FPS
: (e.g. Call of Duty, Titan Fall) 才需要用到的, 你确定需要搞这个? :)
: 你现在是什么类型的联网游戏?
|
z*******3
发帖数: 13709 | 29
real time pvp
现在app上realtime的游戏还少
可以搞的东西比较多
关键还是美工，美工真不好找
【在 P**H 的大作中提到】
: 啥类的游戏？
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
z*******3
发帖数: 13709 | 30
Nagle
FPS
tcp有三次握手，这个我读书时候，期末就有一个考试问题就问
这样能否保证100%不丢包？
答案显然是不行，既然不行的话，那就不需要遵守这个协议
我自己搞一个简单协议就好了，就不受协议的约束
反正只要伺候好我自己的这个app就好了
又不需要跟其他app，server什么share我的协议
其他人看不懂更好，跟web service不一回事
设置来设置去其实本质还是一种妥协，没有必要
理解了网络协议，这些东西都不难做，关键是我希望每一个frame都能够sync
而且每一个frame都能够不依赖之前的数据包，独立生成一个model
所以尽可能压缩网络所带来的latency，这里面时间可不长
30fps的话，一个frame只有33ms的间隔
ping一下来回都要37ms，只发不收的话，可以压缩在33ms以内
然后加上迷雾，压缩每一个pkg的大小，酱紫就有可能实现每一个frame都sync
再在此基础上做点优化，比如尽量不每一个frame都sync
只在关键点上sync，酱紫就差不多，测试时候我可以通过每一frame来sync
【在 d*******r 的大作中提到】
: 你步子真大, long time TCP connection, 再设置 TCP_NODELAY to bypass the Nagle
: delay, 都不能满足你?
: WarCraft3 (and Dota) 和 StarCraft2 都是在 TCP 上跑的, 其实还行.
: 自己在 UDP 上定制 low latency 协议是最后一步了, 一般是 real-time Action/FPS
: (e.g. Call of Duty, Titan Fall) 才需要用到的, 你确定需要搞这个? :)
: 你现在是什么类型的联网游戏?
|
|
|
g*********e
发帖数: 14401 | 31 游戏比一般的网络服务器难做多了 session是persist的 gc 无法避免。所以只能用
cxx
【在 z****e 的大作中提到】
: mmorpg用java的话，还必需把gc的停顿时间考虑进去
: 要控制gc在ms级，最多不宜超过100ms，会影响客户体验
: 控制在20ms以内问题不大，所以内存最好不要爆超过10g
: 100g的gc卡死，这就对jvm的tune的能力提出了要求
: 具体问题具体分析，不同游戏要求是不一样的，设计也不同
: 另外就是real time的游戏不仅对程序要求很高，对美工要求更高
: 如果是3d的话，一个美工要你一万块一个月很正常
: 2d相对要求低很多，所以最好想清楚要做啥再来分析
: 光说游戏，scope太大，不好一概而论
|
z*******3
发帖数: 13709 | 32 gc没问题，pool之后，小gc基本上都在10ms以内搞定
session这个没啥重要的，如果需要persistence的话，用async就可以了
或者上redis etc.
vert.x很多用户就是做realtime gaming的
【在 g*********e 的大作中提到】
: 游戏比一般的网络服务器难做多了 session是persist的 gc 无法避免。所以只能用
: cxx
|
z*******3
发帖数: 13709 | 33
游戏server对我们来说不难
只要理解了概念，这些都不难
内存根本就不是什么问题，gc从来没有困扰过我
内存操作比网络io快不是一倍两倍的问题，那是几十几百倍的差距
很多私服10年前就用java写了
【在 g*********e 的大作中提到】
: 游戏比一般的网络服务器难做多了 session是persist的 gc 无法避免。所以只能用
: cxx
|
z*******3
发帖数: 13709 | 34 关键是用了java，还能够复用android上的model代码
酱紫只需要建两次模，否则java,c++和swift，我靠，三套模型
没吃那么饱，现在只需要对付java&swift，这两个都绕不开
虽然有java->ios，但是为了apple再搞一个，值得，看在钱的份上 |
z*******3
发帖数: 13709 | 35 vert.x的这个用户做的东西就很像real time gaming
http://sketchtogether.com/ |
d*******r
发帖数: 3299 | 36 TCP 只有在建立 connection 时候, 要三次握手, 之后不需要.
所以我前面说, 保持 TCP 长连接, 设置 low latency 参数就能一用了.
你说 frame sync 什么的, frame 是指你自己的 UDP packet 吗?
【在 z*******3 的大作中提到】
: tcp的每个数据包需要三次握手，多此一举
: 我读书时候做的几个应用，聊天室什么，都是在udp上完成的
: 研究生时候我们做的一个算法，也是如何保证udp上同步的协议
: 最后那个project就是这个东西的实现
: 我记得starcraft联机时候可选择udp还是tcp
: 我争取做到每一个frame都能够sync起来
: 这个要求可不低，做得也不是很复杂，2d realtime的pvp
: 我们当时做到的是两边控制两个角色，互相射，就是一个手机上的2d cs
:
: Nagle
|
d*******r
发帖数: 3299 | 37 vert.x 确实还是很有意思的
现在有比较成功的, 大的应用案例了吗?
【在 z*******3 的大作中提到】
: vert.x的这个用户做的东西就很像real time gaming
: http://sketchtogether.com/
|
z*******3
发帖数: 13709 | 38
那你这样搞其实就跟udp没啥太大区别了，又不用tcp这些常见的功能
与其被tcp所限制，还不如干脆自己弄udp得了
tcp和udp的最大差别就是有状态和无状态的区别
自己弄udp就是等于自己要去确认状态
而你改造tcp就是等于不用tcp本身的状态维持机制
怎么搞，其实是差不多的
关键你自己维持状态，是要搞定丢包情况的，tcp怎么搞，不知道
自己搞也不复杂，我们读书时候做过这个的算法project，直接拿来用
frame sync的意思是每一个帧，我都力争让server发送过来
然后visualize掉，所以要完成封装，发送，接收，转换成view，这几步在33ms以内完成
所以我在计算传送时间，网络的io占去了绝大多数时间，内存操作快很多
【在 d*******r 的大作中提到】
: TCP 只有在建立 connection 时候, 要三次握手, 之后不需要.
: 所以我前面说, 保持 TCP 长连接, 设置 low latency 参数就能一用了.
: 你说 frame sync 什么的, frame 是指你自己的 UDP packet 吗?
|
z*******3
发帖数: 13709 | 39
http://vertx.io/whos_using/
每次去看列表都在增加，里面的比如皇家苏格兰银行，这个够大了吧？
不过你给你自己做东西的话，不需要在乎什么大的应用吧？
能做到这个列表里面任何一个的水平，你都发财了
【在 d*******r 的大作中提到】
: vert.x 确实还是很有意思的
: 现在有比较成功的, 大的应用案例了吗?
|
c*********e
发帖数: 16335 | 40 node.js的聊天室是用的socket.io,也是tcp的。 udp的不保证送到，比tcp好在哪？
【在 z*******3 的大作中提到】
: tcp的每个数据包需要三次握手，多此一举
: 我读书时候做的几个应用，聊天室什么，都是在udp上完成的
: 研究生时候我们做的一个算法，也是如何保证udp上同步的协议
: 最后那个project就是这个东西的实现
: 我记得starcraft联机时候可选择udp还是tcp
: 我争取做到每一个frame都能够sync起来
: 这个要求可不低，做得也不是很复杂，2d realtime的pvp
: 我们当时做到的是两边控制两个角色，互相射，就是一个手机上的2d cs
:
: Nagle
|
|
|
d*******r
发帖数: 3299 | 41 用 TCP, 就是折腾它的 options for your QoS,
然后在 reliable byte stream 上 framing 出自己的 frames.
用 UDP, 就是一个个 package 的控制, 当然是最大控制力了,
就是活多了不少, 你做了就知道了, 我以前做过这些.
完成
【在 z*******3 的大作中提到】
:
: http://vertx.io/whos_using/
: 每次去看列表都在增加，里面的比如皇家苏格兰银行，这个够大了吧？
: 不过你给你自己做东西的话，不需要在乎什么大的应用吧？
: 能做到这个列表里面任何一个的水平，你都发财了
|
d*******r
发帖数: 3299 | 42 有 big players, big applications, 就有 community 了,
用的人多了, 就干啥都方便了, 我比较现实
【在 z*******3 的大作中提到】
:
: http://vertx.io/whos_using/
: 每次去看列表都在增加，里面的比如皇家苏格兰银行，这个够大了吧？
: 不过你给你自己做东西的话，不需要在乎什么大的应用吧？
: 能做到这个列表里面任何一个的水平，你都发财了
|
P**H
发帖数: 1897 | 43 realtime都是走udp吧。这种realtime怕啥丢包，反正不停发。tcp反复握手的lag才是
不能接受的。
【在 d*******r 的大作中提到】
: 用 TCP, 就是折腾它的 options for your QoS,
: 然后在 reliable byte stream 上 framing 出自己的 frames.
: 用 UDP, 就是一个个 package 的控制, 当然是最大控制力了,
: 就是活多了不少, 你做了就知道了, 我以前做过这些.
:
: 完成
|
P**H
发帖数: 1897 | 44 膜拜啊。
不过app上的pvp也不少了。山寨diablo，山寨lol很多。
【在 z*******3 的大作中提到】
:
: http://vertx.io/whos_using/
: 每次去看列表都在增加，里面的比如皇家苏格兰银行，这个够大了吧？
: 不过你给你自己做东西的话，不需要在乎什么大的应用吧？
: 能做到这个列表里面任何一个的水平，你都发财了
|
z*******3
发帖数: 13709 | 45 udp是不能保证丢包
你自己需要处理丢包重传这些东西
tcp也不能保证不丢包，tcp自己可以做到一定程度上的丢包重传
但是对于游戏来说，这个还是显得太笨重，还是要自己去改
从本质上说这两个是一样的
要么tcp去掉一点，然后改改，要么直接从udp开始加东西
udp的好处就在于自己设计协议，tcp那一套繁琐的东东就不用了
【在 c*********e 的大作中提到】
: node.js的聊天室是用的socket.io,也是tcp的。 udp的不保证送到，比tcp好在哪？
|
z*******3
发帖数: 13709 | 46
我做过啊，读书时候就在搞这些东东
pkg当然要自己控制，需要自己做一个序列
星际里面，有时候会卡一下，然后恢复之后，就会很快地执行一连串动作
这个就是典型的丢包重传后的效果，我考虑的是直接丢掉中间的所有包
直接跳到最后一frame，然后重现最新的战局，虽然会有跳帧
但是没办法，网络差
【在 d*******r 的大作中提到】
: 用 TCP, 就是折腾它的 options for your QoS,
: 然后在 reliable byte stream 上 framing 出自己的 frames.
: 用 UDP, 就是一个个 package 的控制, 当然是最大控制力了,
: 就是活多了不少, 你做了就知道了, 我以前做过这些.
:
: 完成
|
d*******r
发帖数: 3299 | 47 直接同步最新的状态, 是正确的做法
【在 z*******3 的大作中提到】
:
: 我做过啊，读书时候就在搞这些东东
: pkg当然要自己控制，需要自己做一个序列
: 星际里面，有时候会卡一下，然后恢复之后，就会很快地执行一连串动作
: 这个就是典型的丢包重传后的效果，我考虑的是直接丢掉中间的所有包
: 直接跳到最后一frame，然后重现最新的战局，虽然会有跳帧
: 但是没办法，网络差
|
d*********5
发帖数: 53 | 48 twisted搞定
real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写你建模必
需把server side考虑进去，尤其是想做大型的mmorpgc o........
【在 z****e 的大作中提到】
: real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写
: 你建模必需把server side考虑进去，尤其是想做大型的mmorpg
: c++ or java，很多国内私服都是用java写的，java可以，但是是core java
: 卡牌，棋牌这种回合制的可以用vert.x，但是还是需要自己启动并管理部分thread
: node不合适，process太耗资源，akka又太复杂
: vert.x主要问题是会的人少，招来的小弟不一定能顶用
: 动作类指啥？
: 游戏server开发难度要大过web很多
|
P**H
发帖数: 1897 | |
z*******3
发帖数: 13709 | 50
自己来，2d的话不需要多复杂的opengl啥的
我都已经写好了
swift用sprite kit
android的基础框架网络上到处是教程，用surfaceview
唯一一个麻烦点的就是swift的udp连接
这个用
http://github.com/swiftsocket/SwiftSocket
一个老中写的swiftsocket，支持udp&tcp
加5个文件到你project中去便可
【在 P**H 的大作中提到】
: 前端呢？unity3d上还是自己来？
|
|
|
z*******3
发帖数: 13709 | 51
python建模未必比java容易多少
也是class什么满天飞，而且最关键的
没有办法重用代码，java可以保证android和server重用同样的代码
【在 d*********5 的大作中提到】
: twisted搞定
:
: real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写你建模必
: 需把server side考虑进去，尤其是想做大型的mmorpgc o........
|
P**H
发帖数: 1897 | 52 2d的话，cocos2d就可以了吧。不用自己来。
【在 z*******3 的大作中提到】
:
: python建模未必比java容易多少
: 也是class什么满天飞，而且最关键的
: 没有办法重用代码，java可以保证android和server重用同样的代码
|
z*******3
发帖数: 13709 | 53
ide这种东西，还是官方的比较爽啊
而且到了服务器端，你怎样也都要自己动手了
【在 P**H 的大作中提到】
: 2d的话，cocos2d就可以了吧。不用自己来。
|
P**H
发帖数: 1897 | 54 刚追了下Cocos2dx 开始加3D了。号称已经可以开始用。
Android studio 1.3 rc 也出了ndk preview
[发表自未名空间手机版 - m.mitbbs.com]
【在 z*******3 的大作中提到】
:
: ide这种东西，还是官方的比较爽啊
: 而且到了服务器端，你怎样也都要自己动手了
|
z*******3
发帖数: 13709 | 55
这些不是关键，关键是要做3d的话，美工异常难找而且贵
没有美工的帮忙，游戏无法搞掂
【在 P**H 的大作中提到】
: 刚追了下Cocos2dx 开始加3D了。号称已经可以开始用。
: Android studio 1.3 rc 也出了ndk preview
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
P**H
发帖数: 1897 | 56 那我不如转行美工算了。自学行不？
目前会用blender，照着tutorial画车子。 |
z*******3
发帖数: 13709 | 57
没那么容易，3d美工是技术活，你可以看看水仙等软件
做一个模型非常麻烦，骨骼什么尤其多，需要有极大的兴趣和献身精神才行
2d是另外一条路，这个要从素描开始，也没那么容易
都需要大概7000-8000个小时的投入，才能学有所成
【在 P**H 的大作中提到】
: 那我不如转行美工算了。自学行不？
: 目前会用blender，照着tutorial画车子。
|
P**H
发帖数: 1897 | 58 现在开始玩cocos2d-x。看上去很美。社区活跃，跨平台。还开始正式支持3d了。
android和ios上跑了个hello world。然后自己改改几行，加几个sprite，再用手戳戳
画画，so far so good。目前最友好hello world了。
android studio那几个simple，完全看不懂啊。
【在 z*******3 的大作中提到】
:
: 没那么容易，3d美工是技术活，你可以看看水仙等软件
: 做一个模型非常麻烦，骨骼什么尤其多，需要有极大的兴趣和献身精神才行
: 2d是另外一条路，这个要从素描开始，也没那么容易
: 都需要大概7000-8000个小时的投入，才能学有所成
|
z*******3
发帖数: 13709 | 59
android studio的app samples是用来搞form的
那不是游戏，所以你看不懂，直接全部丢掉就看懂了
等你做backend的时候，你就开始痛苦了
cocos2d是不管backend的，我知道很多人还在用http
用php和node都有，那这种顶多也就是crud一把
真正的real time是不太可能走http那些的
但是总体而言我觉得android挺麻烦的，sprite kit要快很多
但是到了网络部分，需要跟server打交道的地方
ios也开始蛋疼起来
【在 P**H 的大作中提到】
: 现在开始玩cocos2d-x。看上去很美。社区活跃，跨平台。还开始正式支持3d了。
: android和ios上跑了个hello world。然后自己改改几行，加几个sprite，再用手戳戳
: 画画，so far so good。目前最友好hello world了。
: android studio那几个simple，完全看不懂啊。
|
