iOS In-App Purchases [Tod Cunningham] - 推酷
iOS In-App Purchases [Tod Cunningham]
This is hopefully a concise getting started with in-app purchases article.
has had a fair&amount&of success with leveraging
, and I wanted to share some of the lessons we have learned along the way and also share some code to help make basic in-app purchases a little easier. &This article focuses on non-consumable purchases with built-in product (app)&delivery.
Setting Up Your Account
In order to use in-app purchases you have to complete several steps. &A good guide to how to do this is &
. & I would recommend taking some time and reading it&thoroughly.
One of the key things you need to do is make sure your app has a specific AppId such com.appleseedinc.MyGreatApp. & If your current AppId is using wildcards (&.*&) you will need to replace it with a fixed AppId and regenerate and reapply the provisioning profiles. &This is because in-app purchases can't be shared across multiple apps.
Creating Test Accounts
You will also need a test account. &These can be created using your iTunes Connect account.
In order to test with the test account, you will need to logout of your current iTunes AppStore account. &You can do that in the &Settings& app under &iTunes & App Stores&.
However, don't try to login with the test account through the Settings app. &The test account is only valid in the sandbox environment. &In order to use it, you enter it from within you app when you initiate the in-app purchase. &It will then ask you to login and then you can use the test account you just created. &Once you do this, you can logout of the test account through the Settings app.
Setting up In-App Purchases
You setup the items you want to be purchasable via
This includes picking the type of in-app purchase, it's product id used to reference the purchase from within you app, pricing, and finally the actual text displayed to the user during the purchase process.
This&article&focuses on Non-consumable In-App Purchases. &These type of purchases only need to be purchased once by users. They do not expire or decrease with use and they can be restored.
Purchasable items need to be approved by apple, and they must include a screenshot. &When you define a new release of an app you can pick which new in-app purchases are available in the app.
It's App Time
Now it's time to start doing work in the app. &At this point, you should have your AppId provision profile set, a test account setup, and one or more non-consumable purchases configured in the App Store through iTunesConnect. &The
is used to communicate between your app and the AppStore.
The&simplest&type of in-app workflow to implement is for built in product delivery. &The workflow looks like:
The other workflow is a server based authentication workflow which is significantly more&complicated&and isn't a focus for this&article.
I have made available a class called FLOStoreManager that helps manage the built in product deliver workflow and is part of the
FLSOpenLibrary
I'm happy to make&FLOStoreManager&available under the MIT license as part of the&
. &The FLOStoreManager class does most of the work to manage the in-app purchase process. & I suggest you download it and at least use it as an example. &
NOTE: The FLOStoreManager makes reference to featureId which is&equivalent&to to the App Store productIdentifier.
There are 3 main parts to the in product delivery process: Download, Present, and Purchase.
Downloading Purchasing Information
The in-app product definitions are stored on the App Store and must be download to the app before presenting or trying to purchase the item. &This is a download of the product information or meta-data such as product price. & Apple enforces this through the App review process so don't try to skip this step even if you think you can just embed all the meta-data in the app. &Apple still&requires&your to download and honor this information as it exists in iTunesConnect.
The product definitions contain information such as product description and price. In order to fetch the product definitions, the app needs to know the product ids in advance. &There is no method to query the product ids from the App Store. &This means the App needs to know the product ids by either hard coding them or by other means such as downloading them from a server.
class is used to fetch the product definitions for a set of feature id's. &The FLOStoreManager wraps this in a handy method called startAsyncFetchOfProductForFeatureList.
- (void)applicationDidBecomeActive:(UIApplication *)application
NSSet *featureSet
= [[NSSet alloc] initWithArray:@[@&ProductId1&, @&ProductId2&]];
[[FLOStoreManager defaultManager] startAsyncFetchOfProductForFeatureList:featureSet];
This implementation also does some handy work for you automatically:
Auto retry on failed attempts
(kFeatureListReady) when the feature list has been&successfully&retrieved.
If the feature list has already been retrieved and matches the given feature then it will only try and update the list once a day. & This is handy since it is called in&
applicationDidBecomeActive&
which may get called multiple times as users enter and leave the app.
Keeps track of the &registered& features and the product information associated with them
I usually request the product information during applicationDidBecomeActive so it will be downloaded and&available&as soon as is possible so the purchasable items can be presented to users.
Present Purchasable Items
It's up to you to decide how to present the in-app purchases to your users. &However, the App Store uses UIAlert messages which you can not control other then through some text&customization. &These customizations are done through iTunesConnect when defining the in-app purchase.
You also shouldn't present&purchases&for items&whose&purchasing information hasn't been downloaded. &Apple can reject your app if you try to do that.
One of the things you are going to want to know from the server is the price of the item. &This can vary based on the country and also can be changed in iTunesConnect. &FLOStoreManager has a handy routine to allow you to retrieve the localized price of the product formatted in a nice string.
NSString *price = [[FLOStoreManager defaultManager] formattedPriceForFeatureId:@&ProductId1&];
You will also want to take into account some other factors in the UI such as:
The act of purchasing an item is done asynchronously so you will probably want something to indicate when a purchasing is in progress,
You will need to handle the notifications when the purchase either completed or failed.&
is used to initiate a purchase. & It's easy to initiate a purchase, but it does require some tricky handling of the payment queue. &FLOStoreManager tries to make this really easy. &You just call startAsyncPurchaseOfFeature to begin the purchase:
[[FLOStoreManager defaultManager] startAsyncPurchaseOfFeature:@&ProductId1&];
Once the request is&completed, one of two NSNotifications will be sent:
kFeaturePurchased is sent if the purchase is successful.&The notification&object with be the featureId NSString
kFeaturePurchasedFailed is sent if the&purchase failed. &The notification&object with be the featureId NSString
FLOStoreManager also keeps track of which product ids (features) are in the process of being purchased. &This is handy when updating or displaying a view and you need to know if something is being purchased.
if( [[FLOStoreManager defaultManager] isFeatureBeingPurchased:@&ProductId1&] )
// The feature is in the process of being purchased
if( [[FLOStoreManager defaultManager] isAnyFeatureBeingPurchased] )
// Some feature is being purchased, we don't care which one
One of the limitations with FLOStoreManager is that it doesn't try to do purchase receipt validation. There is a vulnerability in iOS 5.1 and earlier related to in-app receipt validation. & It is not a simple topic to validate a receipt. &Apple has a handy&article&that talks through the &
&. &If people are willing to go through the hassle to hack my app to save a buck or two then so be it, I don't think they would be willing to pay for it anyway. &Perhaps some day they will change there ways.
You will also need to handle the condition of a purchase request that gets completed after the user has left your app. &In order to handle this case, one of the first things the app should do is setup the &SKPaymentQueue in application:didFinishLaunchingWithOptions by adding an observer. &This needs to be done so the app can receive payment notifications from the AppStore. &This is all taken care of by FLOStoreManager just by getting the defaultManager.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
[FLOStoreManager defaultManager];
// Allows us to receive AppStore notification
Once the user starts purchasing items, how do you track what has been purchased?
Purchase Tracking
It is up to the app to figure out how to store and keep track of purchased items. &The StoreKit does provide a method called restoreCompletedTransactions which is available as part of SKPaymentQueue &to restore non-consumable purchases. &However, it requires that the user provide their authentication to the Apple Store. &So it's usually called in response to an explicit action by the user to restore purchases.
FLOStoreManager exposes the ability to restore purchases through its own restoreCompletedTransactions method. &Using &FLOStoreManager also has the added benefit of sending kFeaturePurchased notifications for items that where&purchased&and needed to be restored. &It will also send a kPurchaseRestoredCompleted notification after all items have been restored.
The other big advantage of FLOStoreManager is it has a built in mechanism to keep track of non-consumable purchases. &It uses the built-in
&to keep track of purchases. &The nice thing about the keychain is that it persists across deletes of the app. &You can also instantly query FLOStoreManager to see what has been purchased.
if( [[FLOStoreManager defaultManager] isPurchased:@&ProductId1&] )
// The feature has been purchased
Conclusion
Wow you made it this far. &This turned out to be a wee bit longer then expected, but I hope you found it useful.
Please feel free to&contribute&to the&
. &I wasn't planning on making this open source so it wasn't designed to be general use, but I think it provides a good start and example. &It also contains a lot more functionality then discussed here including an extension to handle consumable purchases.
Please feel free to follow me on twitter at
. I would love to hear about your in-app purchase&experiences.
Thanks for reading and be sure to visit us at
References
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
I have implemented in app purchases into my app update for the first time, only too wait 3 weeks and have it rejected for the following reason:
We found that your app offers In-App Purchase/s that can be restored
but it does not include a "Restore" feature to allow users to restore
the previously purchased In-App Purchase/s. To restore previously
purchased In-App Purchase products, it would be appropriate to provide
a "Restore" button and initiate the restore process when the "Restore"
button is tapped.
Now I was thinking of adding a navbar button to the right (top) of my table where the app purchases can be seen/tapped and adding the following code that will be linked to the button:
[[SKPaymentQueue defaultQueue]
restoreCompletedTransactions];
Can someone verify that this is correct and most likely all that is needed? Would like this to pass successfully this time. Thanks in advance!
5,36241840
Alex, i've been rejected for the same reason last week, and this is right what Apple wanted - after adding such a Restore button they didn't ask any other question on this subject.
Of course, you need not only to call [[SKPaymentQueue defaultQueue]
restoreCompletedTransactions];, but implement the restoring itself too (i mean, providing the content to user).
15.9k43165
4,00631546
I use a variation of this:
//inside of an IBaction
[[SKPaymentQueue defaultQueue] addTransactionObserver:self];
[[SKPaymentQueue defaultQueue]restoreCompletedTransactions];
// Then this is called
- (void)paymentQueueRestoreCompletedTransactionsFinished:(SKPaymentQueue *)queue {
NSLog(@"%@",queue );
NSLog(@"Restored Transactions are once again in Queue for purchasing %@",[queue transactions]);
NSMutableArray *purchasedItemIDs = [[NSMutableArray alloc] init];
NSLog(@"received restored transactions: %i", queue.transactions.count);
for (SKPaymentTransaction *transaction in queue.transactions) {
NSString *productID = transaction.payment.productI
[purchasedItemIDs addObject:productID];
NSLog (@"product id is %@" , productID);
// here put an if/then statement to write files based on previously purchased items
// example if ([productID isEqualToString: @"youruniqueproductidentifier]){write files} else { nslog sorry}
Sorry, I'm on my iPad if this makes no sense.
Alternative to restore button could be a restore switch in . It does not overwhelm UI and seems like Apple welcomes it (but be sure to mention that you have implemented mechanics this way).
BOOL shouldRestorePurchases = [[NSUserDefaults standardUserDefaults] boolForKey:@"restorePurchasesKey"];
I've been rejected for the same reason. It's due to the fact that you can be signed in with the same Apple ID on different ios devices.
For example, let's say I'm logged into
on an iPad. When I download your application I realize that I would like to remove the ads (let's say you have ads on your app if you don't), so I remove them for 99?. One year later, I decide to buy an iPhone, and sign into
on that account, and I download your app again. The ads are still there, though, even though I already payed for them. Who would like to pay for the same thing twice? With the restore feature, I can restore the purchases that I made on my iPad, and make them work on my iPhone.
To restore the purchase, you could use:
[[SKPaymentQueue defaultQueue] restoreCompletedTransactions];
After that, you need to also provide the content that the user bought.
5,36241840
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Stack Exchange
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
Stack Overflow works best with JavaScript enabledIn app purchase 中的restoreTransaction是怎么回事_百度知道
In app purchase 中的restoreTransaction是怎么回事
提问者采纳
password。流程大概是，就进入恢复的流程。（如果已购买的话　　restoreCompletedTransactions的方法一般用于恢复购买。例如在app中有一个“恢复购买”的按钮，这个流程和直接购买的效果差不多），先调用restoreCompletedTransactions的方法，点击后，然后这个transaction会和购买一样走一此updatedTransactions的方法，并且state是SKPaymentTransactionStateRestored，输入apple id
电子产品技术支持
其他类似问题
app的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁您的位置：>>>>
苹果榜单怎么爬？App Store的10个生存指南
Store的资格获取其实一直以来都不算难，和其它事情一样，需要的只是耐心。现在苹果对申请者的文书手续要求已经比几年前简化多了，我甚至发现网上所有
的申请流程贴多多少少都过时了，比如传真纳税协议那一步已经不需要你真的传一份签了字的文件过去了。你要做的就是看仔细苹果要你提供什么，按规矩一样一样来，材料充分付完年费一般两三天就能搞到资格。
　　1、盈利模式
　　你的游戏是何时收钱的?P2P(Pay-to-play)、F2P+道具IAP、F2P+内容解锁IAP、F2P+P2P双版本、广告?还
是&&纯free公益型?P2P模式在商用或者专业软件领域使用较多，如今大家似乎都对游戏类App达成了要么免费要么死的共识。除非游戏素质非常高，并
且在发布前已经有了足够的曝光度，或者你已经很有名了，否则不要使用单纯的P2P模式。
　　F2P+道具IAP是最常见的方式，请注意游戏中一切鼓励性质的设计都要合理，在IAP中，如果游戏设计两种货币，一种易掉落的(比如说)金币，另一种稀有需购买的宝石，宝石可以兑换金币，在现金购买宝石的过程可以用多购多折扣的方式促销，但宝石兑换金币如果用同样的多换多折扣这就成了鼓励玩
家囤积宝石而不是消耗它们，这显然是不科学的。
　　不存在最好的模式，应选择适合你的游戏的盈利模式。对于以功能区别免费、付费版本的游戏，F2P+内容解锁IAP、F2P+P2P双版本都是可行的方式，如果全功能版本安装包不大，做成F2P+内容解锁IAP好些，因为玩家不用为了完整内容再下载一个新的包;如果包大小成了限制玩家进入的门槛，
分离出一个Lite/Free版更明智。
　　苹果官方提供的广告展示相对文静，很多第三方广告使用非常容易被误点的贱方式，无论出于何种原因，骗取点击都是会让玩家反感的行为，不值得提倡。如想了解更多广告谋生套路，请用&移动游戏作恶指南&自行google。
　　2、规矩就是规矩
　　苹果对App设计的建议和审核的要求有明确的官方描述，请确定你在提交前完全读懂了《iOS人机界面指南》以及《App
Store审核指南》。如遇rejection或者其它难处，可以随时用iTunes
Connect和苹果工作人员联系，他们的回应很及时，在一两天之内你就能得到答案。如果被reject但你认为是苹果的误判，也可以大胆和苹果协商解决。
　　新App的审核周期在7天左右，更新版本一般快一两天(需要5、6天)，reject重新提交更快，2、3天就会有结果。但从几小时到两个月的审核周期都是发生过的，不用催苹果，催了也没用，你需要的是耐心，既然提交前已经充分测试过没有问题了就不用焦虑了。
　　3、元数据
　　一共有三项元数据可以做为搜索索引，除了游戏标题和关键词，发行商名称亦会被当成索引对待。慎重斟酌你App的这些条目，本文的环节都很重要，
不要以主要、次要区别这些工作，而发行商名称、标题、关键词和描述是你开始迈向上架的第一步。这些数据一旦确认就不能修改了，除非你下一次提交新的版本。
标题：一般来说消费者不喜欢过长的标题，这在一定程度上会给玩家造成此产品很山寨的印象，如果玩家不点开App的描述页面过长的标题后半截会被苹果截断用省略号取代显示，自信满满的留下自己的原创名字，
还是走贱名好养的路线，这是个问题。
　　● 关键词：有100字符的限制，关键词之间使用逗号分隔不要用空格。不要忽视关键词的作用，不要想当然的思考它，定义自己的关键词之前多使用
appannie之类的工具分析一下成功作品都在用哪些关键词，有些关键词非常匪夷所思，但大厂商的经验不可忽视，它们就是奏效。然后你需要找出可能有利
于你的游戏的关键词，并在后续的版本更新中不断迭代这一部分。
App描述：是你能写字最多的地方，可惜系统并不会索引它，而且用户点More之前只有描述的前三行会显示出来。多看看火热作品的措辞，那都是专业营销队伍写出来的文字。只有两个原则：把你的游戏中有的东西，重点突出出来，别把你游戏中没有的东西，虚假夸大出来。
　　● 游戏图标和截图：这是最重要的元数据，事实上玩家大多都依据图片而不是文本来决定是否下载你的东西，竭尽所能的把酷炫的画面放出来吧。iPhone
截图有长屏、短屏两种规格，iPad版再加一种规格，每种分辨率最多5张，不要求非是游戏原始截图，加入文本、NPC样的旁白者、主角与敌人间的面对面对
决、多张截图合成一张都是常见的布局，着重构思第一张，也就是App的封面图片，玩家不用点开App页面就可以看到它。
　　如果游戏中有IAP，每个IAP需要提供一张单独的截图(弹出询问是否购买系统对话框的界面)，此截图不会放到商店中，只做审核用;如果含有Non-consumable
IAP，一定要做Restore Purchases按钮才能过审核。
　　4、推广
　　进入App
Store主页或者久居榜单前列是挣大钱仅有的两个途径，你需要的永远是曝光度。预算充足的团队可以花点心思在广告上，除了广告，还有许多廉价有效的营销手段，比如在自家其它App中加入独门广告推广自家新品，这需要你有很多支App。
　　上传YouTube视频能拉动一批下载量，视频比图片更能让玩家了解你
的游戏。单纯的论坛发贴效果不一定好，但是也不能放过在大网站曝光你的游戏的机会，尽量把动态截图、视频都加到贴子里。建议建立你的开发者社交网络账号和
开发博客，时不时的更新一些开发进展，新想法，近期促销活动上去，让玩家觉得你们是一个在持续改进的团队，听他们的声音，甚至让他们觉得自己参与进了游戏
的制作，这同样是个长期经营的事情。卖游戏也是卖服务。一点没错，你需要耐心。
　　5、玩家发现App的途径
　　《愤怒的小鸟》出现之前没人知道为什么要用不会飞的鸟打绿皮猪，这样做有什么乐趣，它上榜了，于是大家都来下载。这类没有明显的现实参照的叫做通用App，你要做的重点在于想法让它挤上榜;另一部分市场细分的App要么是有现实参照(比如网球、足球、篮球游戏)，要么是有现成游戏参照(比如山
寨，或者叫微创新)，市场细分游戏可能受众较小，但针对性更强，玩家忠实度更高，除了向榜单前面挤，应重点突出目标受众用户感兴趣的亮点。
　　6、激励手段
　　玩家想要的是好游戏，好游戏的定义很简单：有趣的游戏。关于更多关于&有趣&的心理学探讨请参考总结部分提供的参考书目。一句话：打铁还需自身硬。设计出有趣的东西是做为一个游戏开发者的基本功。当然玩家都喜欢奖励不喜欢惩罚，关卡后抽奖和日常奖励是很好用的技巧性手段。关于日常奖励的防作弊，不需要开发者自己建立服务器，互联网上有公开校时服务器，具体同步方法搜索Network
Time Protocol。
　　玩家review是新App在榜单上爬升的一个有力指标，炫耀和分享是依靠玩家传播游戏的有效方法。玩家很懒，同时玩家也很喜欢获得实惠，评
价、分享送好礼是简单好用的技巧，大部分App在点了评价、分享后程序并不会(或者没权限)验证用户是否真正完成了这一过程，对此我们完全可以信任用户的这点积极性还是有的，你帮他弹到相应页面了，他不会吝惜花半分钟写几句话的，如果你的游戏很精彩或者很烂，都能获得评价，除非你的游戏很平庸，吐槽都缺乏槽点。评价还是获得反馈信息的主要途径，包括前期调研竞争产品时，对他们产品的review需要重点浏览。
　　7、档期
　　针对特定题材的游戏选对特定档期会对游戏产生积极促进，比如赶在2014年6月前，绝对是足球游戏在今年一整年里最佳的发布时机，因为12号有世界杯。万圣节、圣诞节也是出节庆版本促销的好时机，需要特别注意的是苹果在圣诞节假期会休假，此时有几十天的榜单冻结期，苹果放假前你的App排第几，
这几十天它就在那不会动了，这也就是为什么大公司都抢在圣诞前各种手段齐上阵抢有利位置。
　　8、首发区域，限免促销
　　如果游戏初始版本为先行探路的版本，首发区域要考虑两个因素：
　　英语国家，收入水平接近北美和欧洲，确保与游戏的目标用户群体重合;
　　用户 量小，如果游戏出现问题，不会损失太多潜在玩家。
　　故新游戏一般选择在加拿大或新西兰首发，这两个都是拥有一定量玩家的英语国家，选择前者是因为加拿大市场
和美国最相近，包含玩家的习惯、口味，包括货币都是统一的;选择后者是因为新西兰是国际日期变更线以西的第一个英语国家，也就是能最先玩到你的游戏的英语
国家，新西兰差不多成了约定俗成的IT界小白鼠。
　　给游戏设定较高的首发价格也可以限制用户量，起到避免游戏早期bug、缺陷造成大量玩家流失的作用，现在有一大把的抓限免的平台，千百万玩家会在你降价后知道你的促销活动。P2P游戏适合用降价促销，对于依靠IAP盈利的游戏来说限免不是好策略，因为等待免费的玩家更多是图实惠的心态占主导，不
要指望这波玩家能提高收入。游戏营销应该把最大的力气都使在对目标区域市场发布那一刻，各种手段能用的都用上吧别嫌累，高价首发+限免等于放弃了App发
布时奋力一击的时机。如果游戏跌到榜底了，复活基本上很难。
　　哦对了，除非你是在赶一个很紧的时间节点，否则不要不做充分测试就把有影响体验的缺陷的游戏放上架，那是极不负责的做法，你怎么对待市场，市场就怎么回应你。
　　9、没挣钱怎么办
　　不用怀疑，在面对玩家的检阅前，你就能收到一堆不是来自玩家的人的阻挠，有的人就是乐于给你以及你所做的事情下定义，还忧国忧民的口吻说你这是
堕落啊是不求上进啊，此时你一定要让他们觉得你听了他们的话醍醐灌顶恨不得立地成佛了，总之就是他们的一番话避免了你的失足，他们就爽了，然后就闭嘴了。
我很奇怪为什么会有一个不是你爹妈师长的人在你耳边絮叨这些，我想起了阴谋论。
　　App Annie之类的数据是做前期调研的好帮手，我不知道App
Store掘金对你来说是什么，梦想?对我来说这是现实的不能再现实的目标，对于现实，我不能预测什么，只有不断的尝试，跌倒、爬起来、再跌倒、再爬起来、又跌倒，慢慢磨砺成长，或者再也爬不起来。讽刺的是，那些告诉你你的游戏不可能卖得好的人正是那些会在你的游戏取得成功之后复制它的人。他们并不善于发挥想象力。看到他们过分依赖于数字做预测的时候我们是否该感到惊讶呢?
　　10、多去户外运动
　　Faker前几天说的不错，不要把某一桩生意仅仅看成生意本身，人活一世首先有个要达到什么状态的长期生活愿景，把生意放在你的一生中整体再看
一下，除了金钱得失，它能给你带来快乐让你逼近自己的愿景吗?如果你不喜欢玩游戏，如果你不喜欢做游戏，如果你做的并不快乐，那准是走错了道儿了没跑儿。
　　不要因为有做不完的需求改不完的反馈就成天把屁股钉在椅子上，多去户外运动一下，说自己没时间运动的人并不是认真勤恳工作狂，说这种话的要么是懒惰，要么是时间管理有问题，又懒又不会管时间的上哪儿成功去。除了耐心，你还需要做好打持久战的准备。
　　现在开发手机游戏的人都是鸡血相，在外行人看来，或者对刚涉足这个领域的新人来说，这很正常，因为手机游戏被媒体渲染成了少投入高回报圈钱多的
代名词。如果你经历过发行的坎坷，一定知道生存的艰辛，在我看来，做手机游戏的，非疯即狂。
Store是经济学家曾经心中理想的低库存，直接面对千百万客户的小宗生意模式。但盲目乐观是很危险的，如果你做做简单的基数乘以百分率这样的计算，你就
能了解你的游戏放到了千万人具有看到它的可能性的架子上后多少人能下载多少人会玩过第一关多少人会花钱玩它，嗯还要计入时间因素计算一下它被淹没在App
海洋前能在榜上呆几天。你的游戏有脱颖而出并在显眼位置坚挺一段时间的素质吗?请享受现实的残酷，在现实中你的创意会变得非残即酷。
[编辑：絮雅]
　　《爱情公寓官方手游》推出之……
　　【叶子猪游戏网记者海口现场……
《封神来了》是一款能带给玩家绝……
麒麟游戏的经典作品《成吉思汗3……
近日，记者得知今年最受欢迎的手……
NEPRO JAPAN于2月20日发表公告，称其已经完……
　　中国iPhone榜单　　苹果今天做了大扫除……
中国手游市场在2014年开始步入高速轨道，得……
　　近日，腾讯大数据发布了《2014年第四季……
根据EnfoDesk易观智库发布的《中国网页游戏……