Tuesday, April 17, 2012

Blogosphere exit; stage right

I accepted one of the positions I was offered last week. So I'm starting at SGN on Monday. My duties will include figuring out the  technology to bridge Flash and mobile game development. A topic near and dear to me, considering my distaste for having to work in ObjectiveC or Java. 

My next stop is mammoth mountain. I've got 4 or 5 days remaining in my down time, and taking a drive up there to spend some quality time sliding down the slopes seems like a dream. Even if I have to go alone. It's so hard to schedule stuff like that with anyone anymore, I barely even try. I'm sure it'll be great, maybe even worth the zillion hours driving to get there and back. 

I'd like to thank the universe for all the luck I've received. For the most part, it feels like my luck is bad and worse, but that's an immediate mode view. In reality, nothing terrible has yet happened to me, I don't have money/family/health problems, and I have no reason not to be jumping for joy every day. It seems like we over accentuate the negative on a daily basis, all of the bad things that could happen but don't are always taken for granted. But they're out there, pulling other people down and ruining lives. Just thankfully not to us. 

Obama 2012

Saturday, March 17, 2012

HTML5 vs. Adobe Air 3.2


I know HTML5 backwards and forwards, and so I get to talk about it pretty often. I’m not really an HTML5 partisan like some, it’s just a convenient way to create some forms of content, and games can fall into that bin. The promises of HTML5 are somewhat predicated upon the decline of Flash, which has been a given in Jobs’ iOS era. (Speaking of those promises, they tend to be “write-once, run everywhere”; ironic as that was Java’s brand marketing, and probably C’s at some point) But as Flash falls out of popular opinion and HTML5, Dart, NaCl come onto the stage, it’s important to ask the question, is Flash no longer viable from a game development platform standpoint?

The factor behind Flash’s decline has been the rise of mobile and mobile gaming. Flash is not good for resource-constrained devices. It was designed for PCs, it has PC-like memory requirements, and it makes enormous demands on the CPU while virtually ignoring the GPU. This made sense in the desktop world of 199x. Well, actually it didn’t, Flash has never been architected optimally for game development, it has always had these problems. We just didn’t care so much because it worked well enough, and the oh so critical to adoption video codecs gave it an install base that became every online computer in the world. And once it was there, might as well leverage it for the interactive 2d content experience it could provide and the cross platform compatibility ever so lacking in the browsers themselves.

Adobe hasn’t shown much leadership, either. They’ve never prioritized the features, release schedule, or platform commitments necessary to please traditional game developers, much less mobile game developers. Prior to this week’s research, I’d have said that more then anything technical, this lack of communication and vision on Adobe’s part is the reason why I would predict the decline of Flash content online.

But Adobe hasn’t actually surrendered the playing field. They gave up on the mobile player, and that seemed to be an endgame for Flash, but they did allocate resources to the mobile Air client team. Now that group’s efforts are viewable in the form of Adobe Air 3.2 RC1 posted Feb 27th, 2012, and it’s time to discuss the topic of this note, HTML5 versus Adobe Air for game development.

The criteria for comparison is: “which technology is the better choice for mobile, web, and mobile-web development?” Straight away, HTML5 gets a nice lead in the mobile-web category, because Adobe cannot field a Flash contender. They tried on Android only, but that didn’t work, and iOS Safari will forever be barred to them, rest in peace Steve Jobs. But HTML5 doesn’t receive a max score on mobile web by any means. Turns out, HTML5 support on Android browsers is in shambles. The default browser is so bad, the user experience on Android cannot help but be diminished. The good news is that google fixed the problem in the Chrome for Android browser. The bad news is that there’s only one phone that runs it since it requires Android 4, and there’s no upgrade path to 4 for pretty much any existing Android devices. Eventually some will come online, and the channel will ship more 4.0s, but this situation continues to get worse, the Android fragmentation and poor upgradeability hurt the HTML5 platform in terms of crap performance and API compatibility. Advantage: HTML5.

Next up, what about best technology for desktop browser game development? While HTML5 (especially WebGL) is stronger on the desktop browser compared to other browsers, Flash is also particularly good on the desktop. When it comes to browser compatibility, Flash wins hands down. Windows XP machines running IE8 are a big demographic that HTML5 can’t reach, but Flash works fine. Un-updated browsers tend to work with Flash. Older machines are broken for both Flash/stage3d and HTML5/webGL. Windows version 8 with the metro UI does not work with the Flash plugin, but it does work with HTML5 and may have some fallback outside metro for Flash content. Ultimately, IE8 users will outnumber IE10 metro users for the foreseeable future, and the advantage goes to Flash.

The tiebreaker now becomes: which technology is better for mobile / app store? HTML5 requires a packaging tech to execute in this fashion (spaceport.io, appMobi, ludei, or PhoneGap) Adobe Air is an analogous technology. Adobe Air has both 2d and 3d modes (stage3d), and library extensibility with native extensions. Those items are possible in the 3rd party packagers, but the 3rd party stuff primarily focuses on rudimentary 2d operations; Flash offers broader access to the GPU functionality. That’s a significant advantage to me. The downside is the runtime minimum install for Air is a whopping 8+ megabytes. So app store content won’t update as easily as it might have; if you need to redownload 8+ megabytes per content update. (Not necessarily true, but possible) So it’s a tradeoff, and if the packagers had a webGL operating mode I’d call it a push, but since they don’t I go with Adobe Air.

That gives us a conclusion as to the winner between HTML5 and Adobe Air. Air is better because it works on windows XP/IE8 and can enable 3d game development on the mobile devices as well as its traditional strengths in 2d vectors and artist accessibility. HTML5 can only win when your requirements include running under iOS Safari, small downloads starting quickly, or Windows 8 IE10 Metro interface compatibility.

Will this always be true? Probably not. Do Dart and NaCl come into the picture? Kind of unlikely. Is Unity or Unreal better than both? Certainly, but those are non-viable in browser, so it’s not the playing field that matters.






Wednesday, February 22, 2012

I want an iOS HTML5 application development environment


As a developer, I have a distinct disinterest in mastering the arcane details of android-java or iOS-ObjectiveC. Not that they have intrinsic faults, they are just different from what I already know, and my interest is in making my application more than dealing with a platform. Being able to write it once and compile it to other devices would be ideal. Java had this promise, and succeeded in servers, of all places. Flash succeeded on desktop, then faceplanted on mobile. If Flash hadn’t lost its mojo, I think Adobe Air would be a very interesting application development environment.

If HTML5 is to replace Flash as a development tool, then having a cross-platform runtime (like Air) would be the best way to facilitate application development. Excluding iOS, that cross-platform is represented by the web browser, but on iOS the closed ecosystem disallows any other browser but Apples. The key to me is to not discount the iOS platform, but instead prioritize decisions that would work within Apple’s established guidelines. Those guidelines including: no executing writable memory (no JIT), no browser other than UIWebView/Safari, and no downloaded code or metacode, all behavior is driven by native compiled executable. And content does not appear differently from the time the application was reviewed by Apple

There’s a number of middleware today that meet Apple guidelines. For example, Unity, which even includes a javascript runtime. But very few of them are HTML5, and they all have some drawbacks of one kind or another. Most HTML5 middleware follow the phonegap model of Safari dependence via UIWebView. But UIWebView/Safari is not good for games (slow and no WebGL) The only alternative to UIWebView to date has been dropping the DOM model and packaging JavaScriptCore as a runtime interpreter, which definitely works, but isn’t the optimal performance or api accessibility. ARM compiled javascript would crush JavaScriptCore interpreter.

Mozilla should be capable of creating my ideal HTML5 development environment: applications that are coded using javascript, html, and importantly, WebGL. Some hypothetical Mozilla tool could create a package that is a compiled executable, including javascript as assembly, not bytecode and text-based. The ahead of time javascript compilation step is the magic that would make this solution better than any other. The compiled application is signed with XCode and is submitted to the app store. IOS support would be my priority #1, amazon/android #2, and mozilla marketplace #3.

I think this idea would also be highly consistent with Mozilla’s goals of making the web free and of the people. The web universe and the application development universe are not the same, but they do seem to be converging. Runtimes that support applications as web pages are proposed and Mozilla has boot-to-gecko, XULRunner and WebRT technologies, that are similar to my description. But really what is missing is acknowledging that desktop has become secondary to mobile for application development, and iOS is the key to mobile success.

iOS is a walled garden, and the wall is a barrier that will prevent Chrome or Firefox from successfully supplanting the device operating system. As long as WebRT, WebGL, WebRTC, etc are not included by Web Safari; they have no utility for iOS, and Apple prevents these new technologies from being widely adopted. This impedes the evolution of the open web and preserves App Store revenue. Apple’s App Store is responsible for billions of dollars of revenue. (4b in 2011 received by third party developers) Developers won’t use technologies that iOS does not support since that would shut them off from participating in the revenue steams Apple is responsible for.

If there was a tech to make App Store and Amazon market compatible applications using HTML5, developers would flock to it. In fact they have flocked to PhoneGap, which is a facsimile of web application development that's store compatible, but it is too slow for games; and has recently come under fire for how easily one's content may be repackaged. Making application development as easy as making a web site gets people's attention, but being on iOS creates revenue to fullfill application developers' goals and ambitions. 



Tuesday, February 21, 2012

Is HTML5 ready yet to be the future of mobile social game development?


By Michael Scholz Jan17th 2012.
Michael Scholz was the CTO of Gamzee, a startup whose mission is to create cutting-edge HTML5 mobile social games. 


HTML5 game development is a popular topic for discussion amongst startups, investors, and game developers. The question: “Is it ready yet?” invariably comes up; and it’s a hard one to answer. In this post, I will provide notes from the development of Skyscraper City that might help answer the question.

What is HTML5?
One challenge in answering the question ‘is HTML5 is ready yet’ comes down to definition, what is HTML5? The terminology means different things to different people. On Wikipedia’s page, it references the variety of new APIs and web standards and sums it up as “(tech) ….  intended to subsume not only HTML 4, but  XHTML and DOM Level 2 HTML as well.” In conversations with game developers the emphasis tends to be on new display APIs: canvas for 2d and webGL for 3d. Since our game Skyscraper City makes minimal use of WebGL and canvas, we occasionally get asked ‘how is it that we are considered to be using HTML5? [without doing canvas]’ The long answer to that question lists all the various browser improvements we rely on that were not present a few short years ago. The short answer is that we are HTML5 game developers because of our decision to make pluginless browser games that won’t work in Internet Explorer 8 or earlier browsers.  That’s the choice that frees a developer from needing Flash and enables one to consider what HTML5 era application interfaces have to offer.

Why reduce your targeted market size?
IE8 is the default Windows XP browser, so giving up support for it may not appear to be a good idea. Why give up a sizeable segment of browser marketshare? The reason is simple: the growth of mobile. Mobile and tablet web browsing are clearly the direction the worldwide web is headed, and as readers of this note are likely aware, IE8 era technologies range from not very good to does not exist on the millions of new mobile devices that are entering the market every month. So HTML5 is a way to make games for desktops and mobile devices with minimal effort to go between one and the other (for both the players and the developers).

Which HTML5 APIs are actually available for mobile devices?
The answer to this one evolves over time, it’s best answered with links to third party references. One of my favorites is the page caniuse.com. I direct the reader there for an in-depth list of what the evolving situations looks like regarding browser API support. For example; the question ‘When can I use typed arrays’ is answered http://caniuse.com/#feat=typedarrays where it shows typed arrays are almost supported enough to be used. But an untyped fallback path is still required.

Is HTML5 Ready: Yes! J
· Device Portability
One of HTML5s biggest promises is that it will eventually become the common client development language of web and mobile applications. Future application developers will be able to code HTML instead of today’s mix of java, Flash, C++, Objective C, and so on.

Skyscraper City was intended to leverage HTML5’s potential portability and deliver a game with a single codebase running on all devices. And HTML5 delivered on this promise in full. Our game runs successfully on mobile Opera, Dolphin, Android, and Safari; as well as desktop versions IE9, Safari, Chrome, Firefox, and Opera. The primary extent of our portability layer is delivered in the CSS; where we have different layouts for desktops, phones, and tablets. Other than those screen dimensional differences, the game is identical from one platform to the next.

The only difference worth mentioning was in our input handling. When playing from touch devices, we use handlers for ‘touch’ and ‘touch-and-hold’ mapping to desktop ‘click’ and ‘hover’, respectfully. That was done as an optimization since mouse events on mobile devices have greater latency than the touch events.

· Common Codebase (Node.js)
Browser specific code is less than 1% of our codebase, and so choosing HTML5 is a big success on the benchmark of code coverage and reuse. We also found that since our game was a javascript application, we could write our server in node.js and it could efficiently simulate on the server everything that happens on the client. We have previous experience with Flash clients in combination with Java or .NET backends. But by using node instead, we could hire specifically for javascript skills and move developers between the client side and the server side interchangeably. This reduced our development overhead, and while perhaps not directly related to HTML5, it is our strong recommendation for javascript as our development platform of the present and future.

· Libraries
HTML5/Javascript gets a new library every day, and that speaks volumes regarding its popularity, and says something about the readiness of a community that helps transitioning developers pick up this craft. Skyscraper City uses a few libraries, and we have learned from even more than the ones we chose to deploy. JQuery is an omnipresent choice for DOM manipulation and utility functionality. Q has been very handy for dealing with asynchronicity on the client. The twilio github repo allowed us to implement SMS text messaging in an afternoon. Lastly I should mention that pdf.js is quite clever, and we have benefited from its image loading code.

Is HTML5 Ready: No? L
·        Facebook mobile platform
We began development of Skyscraper City months before Facebook's mobile HTML5 support plans were known. This required some speculation on our part of what the platform would look like. Would it be a native app? Would it be a website? Would our game be running in a frame or would it launch with a redirect? Today the answers to all those questions is 'yes', and the Facebook Javascript SDK is a key component to implementing the Facebook integration. But with our early adopter status of the platform, we get the dubious pleasure of discovering which components are fully functional and which should be considered 'beta' still. For example, at Skyscraper City launch time, iOS devices didn't support requests [since fixed], launching the game from the native app did not authenticate, and a few inexplicable error states will break the integration, requiring a browser refresh. We do our best to log these sort of problems to http://developers.facebook.com/bugs and it's our experience and expectation that all of these types of problem will be resolved in short order.

·        Remote debugging
The biggest problem we encounter developing mobile social games in HTML5 is debugging the mobile client. Some notable tools are weinre, alogcat, and iwebinspector. But they are pale versions of what is really needed, which is a mobile remote debugger along the lines of node-inspector. Node-inspector is such a useful tool for node.js, it makes the absence of a mobile equivalent all the more painful. Fortunately, because HTML5 is reasonably platform neutral, we don’t have too many mobile-only bugs. Those we end up diagnosing with console.log() debugging. But that’s definitely a caveat for HTML5 developers, needing to rely on print statement debugging rather than have a fully integrated inspection and trace tool. Hopefully the mobile browser guy solve this problem in 2012 and we’ll be able to celebrate mobile remote debugging this year.

·        Mobile audio
The issues with Facebook being minor and resolvable, they present no strong argument against HTML5's readiness. By far the most significant issue we encountered making Skyscraper City is mobile browser <audio> tag support. iOS does not allow programmatic play() invocation (all play()s have to callstack back to an input event type) nor will it allow more than a single clip to be played at one time. These are extremely limiting considerations that only Apple enforces on us. Android suffers from some <audio> tag immaturity issues, but should work reasonably well as the Android browsers mature. The best advice I can offer on this topic is to log bugs against Mobile Safari and research sound sprite implementations. Zynga has generously open-sourced their HTML5 sound sprite implementation, check it out here: https://github.com/zynga/jukebox

Is HTML5 Ready: Maybe… >#:/
·        Javascript vs. Ecma4
The programming language of HTML5 is ECMAScript 5 as described in ECMA-262, edition 5. It’s commonly referred to as javascript and the readiness of the language is a topic of some debate. Personally I’m disappointed that proposed the ECMAScript 4 standard was implemented by Macromedia Flash as its Actionscript 3 language; but it never received support from browser vendors.

Recently Google invented the Dart language for the web, with its optional strong types, class inheritance, library import structure and more. Javascript actually was a better language in its 4th edition with the inclusion of those features (back in 2005). Now that Dart is reintroducing those concepts, javascript receives some criticism for the missing pieces. But what is different today from the past is the existence of compensating tools and runtimes on the javascript side. Googles’ closure compiler has the ability to typecheck annotated code and inline optimize function calls. The execution time of javascript has improved dramatically. A quick profile on my pc shows Skyscraper City is 94.5% time spent in Chrome and 5.5% executing game code. During development of the game we worked on trying to update and display DOM elements faster; the time spent in game code more often than not negligible by comparison. (Except when there's a perf bug) The answer regarding readiness is inconclusive at this point. The execution environment is good enough and reasonable speedwise, but it’s not optimal, and visibly less than perfect. Depending on what environment a prospective HTML5 developer is coming from, it could be better, or it could be worse. But for Skyscraper City, good enough was enough.

·        Content delivery
The optimization of content delivery is topic enough for a separate article. It’s a challenge to minimize HTTP requests, filesizes, load times, and display a traditional loading progress bar with any degree of accuracy.

Some HTML5 games make a separate request per asset, especially DOM engines like ours where assets are loaded into IMG elements. This is a dire situation at first launch load time, where ~60 small assets are requested from the CDN simultaneously for display, hammering a mobile browsers download queue and spending more time creating and closing connections than actually downloading content.

A technique I came up with to mitigate this circumstance was to base64 encode the initial image assets into strings. Then we deliver a gzip compressed js file listing of those strings, thereby eliminating the overhead of the requests in exchange for decode/decompress on delivery change. It’s unfortunate that the HTML5 platform does not offer more help to solve this sort of problem, but it is interesting that there are viable implementation solutions to most delivery problems. The argument that it should not be necessary to jump through such encoding hoops is true; but it is what it is. Since there are solutions, I’d save HTML5 is ready enough today.

·        DOM vs Canvas vs WebGL
As previously mentioned, our renderer is a browser driven manipulator of DOM elements. Ones other options include canvas as well as WebGL. We can eliminate WebGL from consideration for lack of mobile support. Although there’s no reason not to expect WebGL on future phones, certainly the hardware specs are improving fast enough.

Canvas is kind of slow compared to both WebGL and DOM renderers. It can be fast, especially on desktop PCs, but the corresponding performance on mobile is such a drop-off, it is hard to recommend, unless you can get very creative with minimizing your game’s fillrate.

For Skyscraper City, DOM element rendering won by default. It was faster than canvas on mobile devices, and it exists in the same shape everywhere, unlike canvas and WebGL.

Summary:
In conclusion, Skyscraper City is living proof that HTML5 is ready as a mainstream platform for building games that are social and available on a multitude of devices. There are issues to deal with, like with any platform, but the browser vendors are increasingly responsive to the issues developers face, and it is likely that this will be the year that HTML5 is acknowledged as viable way to reach game players where they play. 

Or simply check out Skyscraper City and draw your conclusions from what we accomplished.

First

The first blog post I'd written for this here personal page was an unoriginal commentary regarding the evolution of the blogger.com interface and how much things have changed since I first signed up, some many years back. I might not have submitted the post; the content value was pretty negligible.

That's what I should have named this blog, "negligible content". Really rolls of the tongue doesn't it? And appropriate too. I don't think of myself as a blogger type of person, because I often feel like my role in the blogosphere is a content-consumer, not a content-producer. I don't think I could write a blog so well that I'd subscribe to it personally.

When I read what I've written, I feel like I'm looking at mostly inane, insipid, uninspired drivel. {Except that sentence, I'm proud of that one. ;-) } Mostly because I don't learn anything, I don't have anything interesting to say, and I'm self conscious regarding the craftsmanship of the work. Some people think I write well (myself among them); but then that creates a standard I have to live up to, and presents an impediment to the under-edted stream-of-consciousness crap that is most easily spewed forth upon these hallowed word transmitter things.

And yet some people have so many words bottled up inside them that they have to write whole books to get them out! I'm looking at you Andy Gavin and Jake Simpson. I promise I'll read them sometime, too, just as soon as my printer finishes the batch.

So the question is, do I really have nothing to say? That seems a bit of a stretch, I'm classified a full-on Type Alpha Opinion Over-sharer, (TAOO?) and I really do take advantage of every opportunity to discourse on a plethora of topics, in a various levels of depth. But mostly the shallow end. So I should be able to write stuff out like this. And the ridiculous run on sentences, maybe if I stick with this thing for awhile I'll get a handle on those.

It's interesting sometimes how thoughts and language intermingle, but are not the same. When I listen to the things I say, sometimes I'm flabbergasted by awkwardness of it all; bizarre word choices, run on sentence soup, and gaps where I have to search for the word best matching the concept so simple in my mind's eye, but hesitant and stumbling to the tongue. When I'm speaking in that gear, it's not always fun for the counter party. Although my high school friends were very dear to me, because I when I did happen to wax non sequitur they kept up admirably. Props to them, wherever they are now.

Really spell checking interface? non sequitur is too hard for you? I admit I had to look it up too, since you flagged, but I'm pretty sure at present we are legit in this usage. I interpret your red squiggliness as tacit disapproval, which by the way I thrive upon, and so there..

Being so introspective on this first post, I guess that gives my a blogging purpose, to up my written language skills, keep involved with things I'm interested in, and spend some time productively. Actually, there are few things I can imagine less productive than writing blog entries; playing video games and Facebook spring to mind, that's about it. And of course, a Facebook game is the double whammy of unproductivity, but that's a topic worth exploring in subsequent post.

Speaking of future posts, I will need to sheath this, my diary voice. It's wholly unprofessional and not indicative of what I'm about. Which is pure professionalism, yeah baby, that's my thign. I have some other thoughts to share, prepared not inline, but offline, well, technically online, but not in this editor. Sideline? Okay sold, we'll take it, prepared sideline. In a more appropos voice to be sure.

Oh for crying out loud, spell checker. Now I blew your mind with appropos? How many bytes did they give you to work with, I thought you had the whole internet at your disposal??

I'm sad for you
Michael out.