一、基础知识
不管以哪种方式应用代理服务器,其监控HTTP传输的过程总是如下:
步骤一:内部的浏览器发送请求给代理服务器。请求的第一行包含了目标URL。
步骤二:代理服务器读取该URL,并把请求转发给合适的目标服务器。
步骤三:代理服务器接收来自Internet目标机器的应答,把应答转发给合适的内部浏览器。
例如,假设有一个企业的雇员试图访问www.cn.ibm.com网站。如果没有代理服务器,雇员的浏览器打开的Socket通向运行这个网站的Web服务器,从Web服务器返回的数据也直接传递给雇员的浏览器。如果浏览器被配置成使用代理服务器,则请求首先到达代理服务器;随后,代理服务器从请求的第一行提取目标URL,打开一个通向www.cn.ibm.com的Socket。当www.cn.ibm.com返回应答时,代理服务器把应答转发给雇员的浏览器。
当然,代理服务器并非只适用于企业环境。作为一个开发者,拥有一个自己的代理服务器是一件很不错的事情。例如,我们可以用代理服务器来分析浏览器和Web服务器的交互过程。测试和解决Web应用中存在的问题时,这种功能是很有用的。我们甚至还可以同时使用多个代理服务器(大多数代理服务器允许多个服务器链接在一起使用)。例如,我们可以有一个企业的代理服务器,再加上一个用java编写的代理服务器,用来调试应用程序。但应该注意的是,代理服务器链上的每一个服务器都会对性能产生一定的影响。
二、设计规划
正如其名字所示,代理服务器只不过是一种特殊的服务器。和大多数服务器一样,如果要处理多个请求,代理服务器应该使用线程。下面是一个代理服务器的基本规划:
等待来自客户(Web浏览器)的请求。
启动一个新的线程,以处理客户连接请求。
读取浏览器请求的第一行(该行内容包含了请求的目标URL)。
分析请求的第一行内容,得到目标服务器的名字和端口。
打开一个通向目标服务器(或下一个代理服务器,如合适的话)的Socket。
把请求的第一行发送到输出Socket。
把请求的剩余部分发送到输出Socket。
把目标Web服务器返回的数据发送给发出请求的浏览器。
当然,如果考虑细节的话,情况会更复杂一些。实际上,这里主要有两个问题要考虑:第一,从Socket按行读取数据最适合进一步处理,但这会产生性能瓶颈;第二,两个Socket之间的连接必需高效。有几种方法可以实现这两个目标,但每一种方法都有各自的代价。例如,如果要在数据进入的时候进行过滤,这些数据最好按行读取;然而,大多数时候,当数据到达代理服务器时,立即把它转发出去更适合高效这一要求。另外,数据的发送和接收也可以使用多个独立的线程,但大量地创建和拆除线程也会带来性能问题。因此,对于每一个请求,我们将用一个线程处理数据的接收和发送,同时在数据到达代理服务器时,尽可能快速地把它转发出去。
三、实例
在用java编写这个代理服务器的过程中,注意可重用性是很重要的。因为这样的话,当我们想要在另一个工程中以不同的方式处理浏览器请求时,可以方便地重用该代理服务器。当然,我们必须注意灵活性和效率之间的平衡。
图一显示了本文代理服务器实例(HttpProxy.java)的输出界面,当浏览器访问http://www-900.ibm.com/cn/时,代理服务器向默认日志设备(即标准输出设备屏幕)输出浏览器请求的URL。图二显示了SubHttpProxy的输出。SubHttpProxy是HttpProxy的一个简单扩展。
图一
图二
为了构造代理服务器,我从Thread基类派生出了HttpProxy类(文章正文中出现的代码是该类的一些片断,完整的代码请从本文最后下载)。HttpProxy类包含了一些用来定制代理服务器行为的属性,参见Listing 1和表一。
【Listing 1】
/*************************************
* 一个基础的代理服务器类
*************************************
*/
import java.net.*
import java.io.*
public class HttpProxy extends Thread {
static public int CONNECT_RETRIES=5
static public int CONNECT_PAUSE=5
static public int TIME-OUT=50
static public int BUFSIZ=1024
static public boolean logging = false
static public OutputStream log=null
// 传入数据用的Socket
protected Socket socket
// 上级代理服务器,可选
static private String parent=null
static private int parentPort=-1
static public void setParentProxy(String name, int pport) {
parent=name
parentPort=pport
}
// 在给定Socket上创建一个代理线程。
public HttpProxy(Socket s) { socket=sstart()}
public void writeLog(int c, boolean browser) throws IOException {
log.write(c)
}
public void writeLog(byte[] bytes,int offset,
int len, boolean browser) throws IOException {
for (int i=0i<leni++) writeLog((int)bytes[offset+i],browser)
}
// 默认情况下,日志信息输出到
// 标准输出设备,
// 派生类可以覆盖它
public String processHostName(String url, String host, int port, Socket sock) {
java.text.DateFormat cal=java.text.DateFormat.getDateTimeInstance()
System.out.println(cal.format(new java.util.Date()) + " - " +
url + " " + sock.getInetAddress()+"<BR>")
return host
}
表一
变量/方法 说明
CONNECT_RETRIES 在放弃之前尝试连接远程主机的次数。
CONNECT_PAUSE 在两次连接尝试之间的暂停时间。
TIME-OUT 等待Socket输入的等待时间。
BUFSIZ Socket输入的缓冲大小。
logging 是否要求代理服务器在日志中记录所有已传输的数据(true表示“是”)。
log 一个OutputStream对象,默认日志例程将向该OutputStream对象输出日志信息。
setParentProxy 用来把一个代理服务器链接到另一个代理服务器(需要指定另一个服务器的名称和端口)。
当代理服务器连接到Web服务器之后,我用一个简单的循环在两个Socket之间传递数据。这里可能出现一个问题,即如果没有可操作的数据,调用read方法可能导致程序阻塞,从而挂起程序。为防止出现这个问题,我用setSoTimeout方法设置了Socket的超时时间(参见Listing 2)。这样,如果某个Socket不可用,另一个仍旧有机会进行处理,我不必创建一个新的线程。
【Listing 2】
// 执行操作的线程
public void run() {
String line
String host
int port=80
Socket outbound=null
try {
socket.setSoTimeout(TIMEOUT)
InputStream is=socket.getInputStream()
OutputStream os=null
try {
// 获取请求行的内容
line=""
host=""
int state=0
boolean space
while (true) {
int c=is.read()
if (c==-1) break
if (logging) writeLog(c,true)
space=Character.isWhitespace((char)c)
switch (state) {
case 0:
if (space) continue
state=1
case 1:
if (space) {
state=2
continue
}
line=line+(char)c
break
case 2:
if (space) continue// 跳过多个空白字符
state=3
case 3:
if (space) {
state=4
// 只分析主机名称部分
String host0=host
int n
n=host.indexOf("//")
if (n!=-1) host=host.substring(n+2)
n=host.indexOf('/')
if (n!=-1) host=host.substring(0,n)
// 分析可能存在的端口号
n=host.indexOf(":")
if (n!=-1) {
port=Integer.parseInt(host.substring(n+1))
host=host.substring(0,n)
}
host=processHostName(host0,host,port,socket)
if (parent!=null) {
host=parent
port=parentPort
}
int retry=CONNECT_RETRIES
while (retry--!=0) {
try {
outbound=new Socket(host,port)
break
} catch (Exception e) { }
// 等待
Thread.sleep(CONNECT_PAUSE)
}
if (outbound==null) break
outbound.setSoTimeout(TIMEOUT)
os=outbound.getOutputStream()
os.write(line.getBytes())
os.write(' ')
os.write(host0.getBytes())
os.write(' ')
pipe(is,outbound.getInputStream(),os,socket.getOutputStream())
break
}
host=host+(char)c
break
}
}
}
catch (IOException e) { }
} catch (Exception e) { }
finally {
try { socket.close()} catch (Exception e1) {}
try { outbound.close()} catch (Exception e2) {}
}
}
和所有线程对象一样,HttpProxy类的主要工作在run方法内完成(见Listing 2)。run方法实现了一个简单的状态机,从Web浏览器每次一个读取字符,持续这个过程直至有足够的信息找出目标Web服务器。然后,run打开一个通向该Web服务器的Socket(如果有多个代理服务器被链接在一起,则run方法打开一个通向链里面下一个代理服务器的Socket)。打开Socket之后,run先把部分的请求写入Socket,然后调用pipe方法。pipe方法直接在两个Socket之间以最快的速度执行读写操作。
如果数据规模很大,另外创建一个线程可能具有更高的效率;然而,当数据规模较小时,创建新线程所需要的开销会抵消它带来的好处。
Listing 3显示了一个很简单的main方法,可以用来测试HttpProxy类。大部分的工作由一个静态的startProxy方法完成(见Listing 4)。这个方法用到了一种特殊的技术,允许一个静态成员创建HttpProxy类(或HttpProxy类的子类)的实例。它的基本思想是:把一个Class对象传递给startProxy类;然后,startProxy方法利用映像API(Reflection API)和getDeclaredConstructor方法确定该Class对象的哪一个构造函数接受一个Socket参数;最后,startProxy方法调用newInstance方法创建该Class对象。
【Listing 3】
// 测试用的简单main方法
static public void main(String args[]) {
System.out.println("在端口808启动代理服务器\n")
HttpProxy.log=System.out
HttpProxy.logging=false
HttpProxy.startProxy(808,HttpProxy.class)
}
}
【Listing 4】
static public void startProxy(int port,Class clobj) {
ServerSocket ssock
Socket sock
try {
ssock=new ServerSocket(port)
while (true) {
Class [] sarg = new Class[1]
Object [] arg= new Object[1]
sarg[0]=Socket.class
try {
java.lang.reflect.Constructor cons = clobj.getDeclaredConstructor(sarg)
arg[0]=ssock.accept()
cons.newInstance(arg)// 创建HttpProxy或其派生类的实例
} catch (Exception e) {
Socket esock = (Socket)arg[0]
try { esock.close()} catch (Exception ec) {}
}
}
} catch (IOException e) {
}
}
利用这种技术,我们可以在不创建startProxy方法定制版本的情况下,扩展HttpProxy类。要得到给定类的Class对象,只需在正常的名字后面加上.class(如果有某个对象的一个实例,则代之以调用getClass方法)。由于我们把Class对象传递给了startProxy方法,所以创建HttpProxy的派生类时,就不必再特意去修改startProxy。(下载代码中包含了一个派生得到的简单代理服务器)。
结束语
利用派生类定制或调整代理服务器的行为有两种途径:修改主机的名字,或者捕获所有通过代理服务器的数据。processHostName方法允许代理服务器分析和修改主机名字。如果启用了日志记录,代理服务器为每一个通过服务器的字符调用writeLog方法。如何处理这些信息完全由我们自己决定——可以把它写入日志文件,可以把它输出到控制台,或进行任何其他满足我们要求的处理。writeLog输出中的一个Boolean标记指示出数据是来自浏览器还是Web主机。
和许多工具一样,代理服务器本身并不存在好或者坏的问题,关键在于如何使用它们。代理服务器可能被用于侵犯隐私,但也可以阻隔偷窥者和保护网络。即使代理服务器和浏览器不在同一台机器上,我也乐意把代理服务器看成是一种扩展浏览器功能的途径。例如,在把数据发送给浏览器之前,可以用代理服务器压缩数据;未来的代理服务器甚至还可能把页面从一种语言翻译成另一种语言……可能性永无止境。
作为一名业内资深的游戏开发人员,经常会遇到实习的新同事在工作中会问到这样的问题:
工作中到底有哪些开源游戏服务器框架,该去值得学习呢?
囊括到node.js 、java、C#、golang 、c++、python 等技术栈有各种各样的游戏框架。
本文给大家总结了一些github上star和fork比较常用的且有一定数量的较为完整的框架做了一个说明,大家可以往下看。
地址: https://github.com/cloudwu/skynet
基于此引擎开发的游戏众多,很多棋牌小企业在用,例如简悦的 陌陌争霸 、 食物战争 等等很多产品...
地址: https://github.com/NetEase/pomelo
一花科技等棋牌在用
地址: https://github.com/ketoo/NoahGameFrame
代表作全民无双
地址: https://github.com/kbengine/kbengine
已经被电魂网络收购
地址: https://github.com/egametang/ET
经过产品验证并且教程比较完善
地址: https://github.com/topfreegames/pitaya
zooba appstroe排行很高的moba、吃鸡类游戏
但是,像c++类的框架对新手要求较高。
亦或者node.js类框架性能确实差一些,毕竟它是针对io密集型。
阿博自己的话使用的是pitaya这套框架。毕竟支持分布式使用的技术比较新,也经过各种验证。 其他的就先不做评价,留着给大家发表一下意见。
毕竟,只要适合自己的才是最好的。
是的不......
最近刚跳槽,到新公司已经干了有两周时间了,这两周时间是过得比较充实的,因为这家新公司是个小公司,以前以单机开发为主,服务器方面我一个人,做两个游戏的服务器开发工作,当然,一个很简单,另一个就相对复杂点,简单的那个是个弱联网游戏,服务器只需要做好数据存档和登录支付验证就好了,而另一个,则是相对复杂的slg游戏,我感觉这是又一款cok,而公司目前并不打算再招服务器了,所以估计这个项目我会一个人干到明年吧,等第一款上线赚钱了,可能会再招服务器。老实说,面试的时候,我就觉得这份工作对我而言是一个挑战,而当我清楚的了解了公司状况之后,我依然决定接受这个挑战。说说我之前的经历吧,大四的时候,学校安排来北京培训java(培训没什么丢脸的,出来找工作我也用的真学历真背景,不像某峰互联),之后我去了培训机构推荐的公司实习,那个时候,工资2k,然而工作也干得很开心,跟着前辈学到了不少东西,当时是做微信公众号开发的,我跟着前辈做微信后台开发,当时使用SpringMVC+MyBatis框架,刚接触的时候,我自己学了挺久才弄明白,后来弄明白之后想想,其实挺简单,对于逻辑开发的程序员来说,你只需要弄懂工作流程就好了,页面怎么跳转,跳转怎么传值,数据怎么处理,这些足够了,当然我是个不满足的人,我会去弄明白,为什么用这个框架、为什么不用别的、用这个有什么好处、如果让我自己来做这个后台、我会怎么搭建?带着这些问题,我会试着自己搭建一下后台框架(虽然前期大部分是复制粘贴)。除了框架部分,微信高级接口也是我研究的重点,我会去官方文档看看微信是怎么接入的,然后研究研究前辈的代码是怎么写的,所谓的干一行爱一行大概就是这样吧,当时我觉得,微信开发,是很有前途的,而我们公司用的框架,也是最先进的(后来看来,确实这个框架组合是当前最流行的框架,而当时,微信公众号也确实是当时互联网行业的一个风口,微信后来把h5带起来了,导致现在一个好的h5前端都是供不应求的,薪资很高)。
说了这么多,为什么后来又转行做游戏了呢?其实是这样的,当时在第一家公司,我的上级打算跳槽走了,带走整个下面的技术,而不带实习生,有那么一两个月,实习生就一直闲着没事做,对于我来说,这样过着就太无聊了,我喜欢挑战,于是我投简历,重新找了份实习工作,在一个游戏公司做java服务器开发,公司挺大的,几年前凭借一款slg页游称霸游戏行业(什么游戏我就不说了,说了就知道什么公司了),后来游戏行业往手游发展,这款slg也出了手游版,这一款游戏,几乎支撑了整个公司,再加上后来出的几款手游,公司发展挺好的,我所实习的部门做的是一款mmorpg手游,从实习做到了转正,做了近一年了,然而这款rpg手游的数据却不是太好,第一次封测次日留存23,第二次26(现在这家公司的游戏能达到80多次日留存),七日就更不用说了,而我也能感觉到,作为一款mmo游戏,玩家之间的交互实在太少,从头玩下来,我觉得这是一款单机,失去了mmo的本质,在项目组准备进行第三次封测的时候,我选择了离开,原因很多,不仅仅因为游戏数据不好,也有一些个人原因吧,不过说实话,是这家公司带我走进了游戏行业,我很感谢,我觉得游戏行业是一个非常有前景的行业,甚至比之前我认为最好的微信开发还要好,游戏行业非常暴利,在这家公司工作就能感受到,策划文档中,充满了挖坑预留的计费点,这一块可以正常玩儿,但你如果充钱,你就比别人牛逼。网络游戏,最重要的,就是控制好平民玩家跟普通玩家的占比以及游戏平衡(当意识到公司的游戏如此处心积虑想要坑钱的时候,我突然明白为什么公司的游戏大多被腾讯代理了,为什么腾讯控股,原来如此,没钱玩儿你**,哈哈)。由此也可以看出,游戏的商业化,已经把游戏公司带入了一个固定的模式——无条件坑钱,我觉得已经失去了游戏的本质,我看过一本书,叫《游戏人生》(当时在cocos2014年开发者大会上买的。觉得挺值的),书已经送人了,但内容我看了一大半,从游戏的产生,到玩家的心理,到为什么需要游戏,这本书都诠释的热别好(我觉得游戏策划都应该看看这本书,做良心游戏,拒绝一味坑钱)。啊,突然发现这一段说的有点偏了,说到底,我也只是做游戏服务器开发的,我也改变不了游戏行业,我只要做好我做的。其实大的游戏公司,就应该走这种商业化路线,凭借几款长生命周期的游戏,支撑公司流水。
从转行做游戏之后,我倒是觉得,游戏开发比web开发有趣多了,当然技术上也比web难多了,之前发过一篇讨论,web开发何和游戏开发的区别,http://gad.qq.com/content/wendetail/7082370,我把我的答案再粘贴一遍(实际上是别人要求我上他的号去回答的,于是我就自己回答了我自己的问题):
1.从第三方支持来说,web后台有很多成熟的第三方框架,开发者不需要关心底层控制器跳转的实现,只需要一个或几个配置文件,就能完成核心控制器的部分,而开发者只需要关注web自身的业务逻辑,将逻辑与框架融合即可,使用框架一方面简化控制层代码,一方面很好的实现了业务逻辑的分层。而游戏后台开发中,因为各种游戏的需求差异性很大,从网络层,到业务逻辑层,各方面都必须根据自己游戏需求搭建适合自己的框架,因此很难有一些通用的东西能提炼出来一款成熟的框架,游戏后台开发基本上需要自己搭建适合自己的框架。
2.从业务逻辑层面来说,web后台基本上逻辑都是大同小异的,或许这一套系统,稍微改改,另一套系统就能用,而游戏就不同了,每个游戏都有自己的特色,根据策划的不同需求而实现不同的逻辑,不过也会有一些通用的模块,但整体上差异性还是很大的。
3.从数据持久化来说,web的数据基本上是很规整的,表与表之间关系很明确,并且以后也不会有太大的变化,而游戏中的数据多种多样,随着开服之后,数据的变化也是多种多样,甚至传统的关系型数据库根本无法满足游戏数据持久化的需求,游戏中有很多状态和数据是需要服务器来保存的,我个人认为,在游戏开发中,nosql比关系型数据库更实用。
4.从通信层来说,web中的用户都是一个个独立的个体,而游戏中是多人在线的一个游戏世界,在这个游戏世界中,玩家与玩家之间需要进行交互,这就需要服务器实时的向所有在线玩家进行消息广播,这一点很损耗服务器性能的,在这方面,游戏后台要比web做更多的处理,游戏服务器是一个IO密集的服务器类型。
以上便是我当时的答案,或许我的见解尚浅,毕竟我做游戏不到一年,不过对于后台开发这块,我还是有一点话语权的,从实习游戏开发开始,我便经历了一个转换的过程,几乎又是一个从零开始的学习过程,从mina框架到protobuffer,这些东西,我相信web开发很少接触(mina作为网络通信框架,web中几乎只有http通信,protobuffer作为通信协议,web最多用json,其实二者形式上差别不大,但数据大小千差万别)。而游戏的逻辑,也是比web复杂得多,不得不说,web后台成熟的第三方框架是做的真的很好。
经历了上家公司的洗礼,我想我对游戏后台开发有了足够的了解,于是我找到了我现在这家公司,这家公司目前只有我一个服务器后台,做两款游戏,一款是塔防类,准备由单机改成弱联网,服务器存档,并做登录支付验证,另一款,是比较庞大的slg手游,是准备带领公司走上巅峰的项目,说一款slg带领一个公司走上巅峰一点儿不为过,我上家公司就是这样的,凭借一款《xxxx》(哈哈,名字不透露),走上人生巅峰。我之所以接受这份工作,是因为我接受挑战,从底层写起,从架构写起,这是作为一年工作经验的我想都不敢想的,不过这是一个挑战自我,证明自我的机会,我愿意接受这个挑战,人生总会有很多爬坑的时候,但爬过了坑,就真的是人生巅峰了。我接受这个工作的另一个原因,就是公司发展确实不错,以前做的单机,都是很火的(虽然我认为我自己一个人也能做,我也是学过cocos的),而现在公司也准确的把握了游戏行业的风口——slg,coc和cok的成功案例就能证明一切,mmorpg也不一定能做起来了,moba倒是有可能,但你要跟lol做不到80%的相似,我估计没人愿意在手机玩儿moba,slg或许是性价比最高的了。这么有挑战的工作,还要从架构写起,这样的挑战,我喜欢!
说说互联网业的书吧,我认为这个行业的书,分为两种,理论型的和技术型的,所谓理论型,就是长篇大论互联网发展,行业模式等,而技术型,就是类似技术的工具书,是从技能入手的书,这两种书,我家里都有,但我发现买了之后,我很少有时间看,下班没多少时间,北京上班,大多数时间都浪费在地铁上了,上班时间,看看理论型的吧,觉得啰嗦,浪费时间(后来我发现,做这行,除了会技术,你还是需要去看看牛人眼中的互联网的,你需要透过前辈的眼光看世界,不要做IT民工,要做互联网从业者),看看技术型的吧,让别人看见了感觉你太low,所以我大多数时间还是能在网上down到pdf就在电脑看,down不到百度谷歌我要研究的技术,毕竟从事这行,还是用电脑学技术好点,主要是电脑看久了眼睛会疲惫,偶尔看看纸质的书也不错的。而以前面试的时候,面试官经常问,除了大学课本,你还看什么书啊?(如果是你们,恰巧又没看什么书,你们怎么说?),我一般会说,我会自学其他技术,如cocos2dx,然后买一些技术指南之类的书看。我觉得这已经算最大夸张化了,因为大学我真的很少看书,我记忆中就看过一本C++技术类的,一本C#的,一本Android,还有其他几本是什么都不大记得了,大学毕竟十几层的图书馆,除了英语四六级的时候进去复习,其他时间感觉都浪费了这十几层的图书馆。
说说成长过程中遇到的问题吧,如果遇到我解决不了的,以前是先自己百度谷歌,看看有没有办法解决,不行就问老大,而现在,先百度谷歌,看有没有办法解决,没办法在百度谷歌,实在不行还要看框架源码如何实现,上国外论坛看外国友人如何解决,问题总能解决的,总会有办法的。当我开始学习写架构的时候,我会开始关心游戏的网络层使用什么框架,mina还是netty,数据怎么存储mysql还是mongo,是否需要缓存redis存什么,memcached存什么,缓存什么数据,数据传输用什么协议,json还是protobuffer,怎么写效率高,最高支持多少并发等等,我想这些都是我现在需要考虑的问题,当然这些都需要根据游戏具体的需求来决定的,最终服务器能否高效稳定的运行,都是取决于我的架构是否高效稳定,所以这个过程我要不断学习,不断吸取别人的经验。刚到新公司的时候,我才体会到,自己写代码其实也是一种挑战,整个后端我自己一个人实现,代码是否规范,数据如何存储,都是我说了算,我想我的代码不仅要高效,还要让别人看得懂,后来的人能接着我的代码继续写下去。
最后说说Java的题外话,语言之争,从未停过,为什么有人拥护Java,有人拥护PHP,有人喜欢C#,有人喜欢C++,各个语言各有各的优势,业余时间,我也了解了不少其他语言,go,node.js我都有了解,我觉得go的语言层面支持协程并发以及node.js的异步,都是很适合游戏服务器的,我特别看好node.js,异步io真的是对游戏服务器很好的特性,并且加入对原声js支持的mongo模块也是很方便的(上面我有说到,我相信nosql是很适合存储游戏数据的)。说到游戏行业,我认为h5游戏的发展也是越来越快了,上次白鹭的h5开发者生态大会我去了,白鹭的一整套工作流程,以及web vr,真的很令人兴奋(第一轮抽奖我还抽了一个暴风魔镜,哈哈!),另外,大会的模特挺漂亮,哈哈!2015年,互联网行业也略呈下降趋势了,不少创业公司面临倒闭,泡沫经济破灭,因为很多老板抓不住当前经济形势,以为不管是啥,有个app就是创业了,其实全然不知一款app后面有多少运营模式、盈利模式,就像一句讽刺的话,“我有个绝壁好的idea,可以颠覆bat,什么都不缺,就缺个程序员了,等等,千万别告诉马云!”,哈哈,听到这句话,当时我就笑了,估计好多倒闭的创业公司老板都这么想的吧,他们并不能抓住用户真正的需求,只有抓住用户真正的需求,才会抓住用户的心,真正活下来的,才是用户真正需要的,然而,相对来说,游戏行业更是复杂多变,或许今天玩家喜欢这种游戏,明天玩家就喜欢另一种游戏了,就像我们永远也想不到,flappy bird、围住神经病猫这类的游戏竟然能活起来,愚公移山竟然也能让h5游戏变为付费的可能。就像一句话,“只要站在风口上,猪也能飞起来!”,只要抓住了玩家此时此刻真正想要的,产品就一定能做起来。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)