5 ms·
We recently had to change our plans for a HTML5 game for smartphones because it performed like crap on Android. Now we're rebuilding it in Unity (with the recen
by primigenus 13y ago
We recently had to change our plans for a HTML5 game for smartphones because it performed like crap on Android. Now we're rebuilding it in Unity (with the recent 2d features they added) and it performs great. That's too bad, because we really believe in the idea of HTML5 as a cross-platform development environment.
So I'm really happy with the obsessive pursuit of speed, responsiveness and user experience by the Chrome team. It's probably a good idea to seek feedback on this for accessibility reasons, but it feels like this change would be for the better when applying the 80/20 rule.
This along with the numerous improvements to Chrome's developer tools and remote debugging features (https://developers.google.com/chrome-developer-tools/docs/remote-debugging https://developers.google.com/chrome-developer-tools/docs/re...) coming soon really show an increased focus on making high performance web apps on mobile a realistic option.
Hopefully the next game we make will be able to launch on iOS and Android thanks to these speed improvements. :)
- kayoone 13y agoFor multiplatform games you are still better off with Unity imo. Sure, from a developer standpoint, building on open tech is cool, but gamers don't care at all and when Unity gives you the best possible performance and development workflow i would stick with it. They will also probably soon have a HTML5 export (they already have PNaCL)
- austinhallock 13y agoFor performance you're better of with Unity. For distribution you're better off with HTML5. You can get in the app stores & have distribution on the mobile web, have the game instantly playable in webviews, etc...
- kayoone 13y agoSounds great in theory, in practice mobile web views are pretty slow for games, as op already stated. Besides Unity will have a HTML5 export soon which will make it the most efficient tool for creating web games anyway.
- timsayshey 13y agoToo bad android chrome is not the same as the AOSP browser that is built in to android which is what the webview uses...
- martinml 13y agoThat's starting to change! Android 4.4 (KitKat) includes a new WebView component based on the Chromium open source project Will the new WebView auto-update? (...) There are large engineering and logistical challenges. We're not quite there yet, but we're working on it. https://developers.google.com/chrome/mobile/docs/webview/overview https://developers.google.com/chrome/mobile/docs/webview/ove...
- timsayshey 13y agoWow that's awesome news! I had no idea :)
- njs12345 13y agoLooks like someone's trying to make it possible to bundle Chromium with your app: https://github.com/pwnall/chromeview https://github.com/pwnall/chromeview
- pornel 13y agoThere never was any delay for touchstart/touchend events. If you're using onclick/mousedown in your game, then change them to touch events (touchstart and whatever Windows Phone does). These work without delay regardless of viewport settings. If you have existing codebase that can't be easily changed to use touch events, you can use FT Labs' fastclick to emulate onclick with no delay (the library is aware of latest Chrome's change): https://github.com/ftlabs/fastclick https://github.com/ftlabs/fastclick