"Your game doesn’t need to be in the iOS App Store or Google Play to be played on mobile devices. That is a huge benefit. Sure, it’s good to have it in both of those stores (and is easy enough to achieve), but the fact that it can be played without requiring an install and the extra bulk of the stores is a big opportunity."
I don't know if this is true though. Consumers expect the games to be in the appstores. I don't know anyone who even knows they can play games on the phone browser.
The point I'm trying to make there is consumers can still find your game through those apps like WeChat, and through shared links on Facebook, Twitter, etc... The same way people typically find and consume other forms of content.
What needs some work is making those games stickier in the sense that the person will play it again. That requires saving it to the home screen which probably not enough people are familiar with - and is a bit of a pain on Android.
I like the approach Firefox OS has taken with saving/installing apps and hopefully Apple and Google follow suit. As is, I think iOS's "Add to Home Screen" is fine. Android's like I said, could be improved.
The other thing that needs a bit of work is HTML5 performance in the webview. On iOS at least, game's don't perform as well as when they are played in Safari (since the webview doesn't use the Nitro JS engine) - hopefully that changes soon.
The nice thing about HTML5/JS games is that if someone hears about your game on a website or through word-of-mouth, they can immediately start playing it just by clicking a link. Not much additional thinking is required other than "go to this site on your phone to play."
The type of consumers who wouldn't be able to figure this out are more geared toward casual games. If you are catering to casual gamers then I somewhat agree that you are forced to be complicit with the app store publishing model.
However, more serious gamers are more understanding and are willing to go through minor hurdles, such as using their phone's web browser, as long as you are offering them a more serious game experience.
I completely agree with this. Building HTML5 games - and you can get competitive levels of graphics and so on - is a great way to be able to target the Apple, Android and even the Chrome store. You can easily make a shim that launches a WebView window.
It also allows for playing online as said.
WebWorkers, however annoying to debug, raise an interesting speed-bump to cheating too. Here's a WebWorker wrapper script that lets you run (a single) WebWorker in-process instead, for debuggability: https://github.com/williame/ludum_dare_27_snowden/blob/gh-pa...
With the new Audio API and webRTC, plus the WebSockets, things are bright.
Browsers run web workers in sandboxes and even normal debuggers built into browsers have no visibility into them; this means fiddling around at the JavaScript console is blind of any state you have in them e.g. a procedurally generated world.
A determined attacker can debug the browser itself, or try and rewrite your app to not use web workers, of course... Its just a speedbump. Its still client side.
I use them - and try and work out how to debug them - for performance smoothness reasons though. They are worth more for that imo and anti cheating is very much a secondary thing.
Where's the pricing information. I hate it when a site hides it's pricing. My immediate reaction is that it's too high. Then contact with the company to find out is going to be fraught with listening to justification before I can get prices and immediately rule them out as too high a percentage of expected revenue.
This comment is a bit off topic as the post isn't about Clay.io, rather games in general.
However, to answer your question, we take a 20% cut on any transactions made through selling games or our in-game payments API. If you're using our Advertising API we take 10-30% (depending on where the game is being played). Everything else (leaderboards, achievements, etc...) is free to use. This info is displayed here: http://clay.io/docs
"Why write an iOS version of a game in Objective C, and the PC version in C? Performance would be the only reason, but that’s becoming more and more of a moot point."
Why indeed, when there is a multi-paradigm C# and MonoGame that give you a combination of an actual modern language, decent performance and multi-platform access.
17 comments
[ 0.23 ms ] story [ 48.4 ms ] threadI don't know if this is true though. Consumers expect the games to be in the appstores. I don't know anyone who even knows they can play games on the phone browser.
What needs some work is making those games stickier in the sense that the person will play it again. That requires saving it to the home screen which probably not enough people are familiar with - and is a bit of a pain on Android.
I like the approach Firefox OS has taken with saving/installing apps and hopefully Apple and Google follow suit. As is, I think iOS's "Add to Home Screen" is fine. Android's like I said, could be improved.
The other thing that needs a bit of work is HTML5 performance in the webview. On iOS at least, game's don't perform as well as when they are played in Safari (since the webview doesn't use the Nitro JS engine) - hopefully that changes soon.
Do you think that would be a good idea for someone who wanted to evangelize HTML as a games dev platform?
I'm not sure if it exists or if it would Apple's terms of service.
(it's probably not)
The type of consumers who wouldn't be able to figure this out are more geared toward casual games. If you are catering to casual gamers then I somewhat agree that you are forced to be complicit with the app store publishing model.
However, more serious gamers are more understanding and are willing to go through minor hurdles, such as using their phone's web browser, as long as you are offering them a more serious game experience.
It also allows for playing online as said.
WebWorkers, however annoying to debug, raise an interesting speed-bump to cheating too. Here's a WebWorker wrapper script that lets you run (a single) WebWorker in-process instead, for debuggability: https://github.com/williame/ludum_dare_27_snowden/blob/gh-pa...
With the new Audio API and webRTC, plus the WebSockets, things are bright.
A determined attacker can debug the browser itself, or try and rewrite your app to not use web workers, of course... Its just a speedbump. Its still client side.
I use them - and try and work out how to debug them - for performance smoothness reasons though. They are worth more for that imo and anti cheating is very much a secondary thing.
Me getting down voted elsewhere for this opinion this week: http://www.reddit.com/r/programming/comments/1lnnvm/making_a...
http://en.wikipedia.org/wiki/Cheat_Engine
I wish I hadn't said it noe; it was on the top of my mind, was all.
The much maligned web sockets are actually useful for keeping the game loop light; I even generate meshes in them.
However, to answer your question, we take a 20% cut on any transactions made through selling games or our in-game payments API. If you're using our Advertising API we take 10-30% (depending on where the game is being played). Everything else (leaderboards, achievements, etc...) is free to use. This info is displayed here: http://clay.io/docs
https://github.com/superjoe30/chem/
Why indeed, when there is a multi-paradigm C# and MonoGame that give you a combination of an actual modern language, decent performance and multi-platform access.