Monday, September 12, 2011

HTML5 Part Tres

It's been a few weeks since my last HTML5 post and I've learned even more. I know I seem wishy-washy on the language, but that's not really the case. HTML5 is destined to be a big player in the games space at some point. The problem is that the some-point in question is not today...and that sucks.

Being that it's JavaScript makes it rather accessible, not to mention easy. The fact that it's distributable to many platforms is awesome too. But the fact that it's slow as crap on tablet devices, not fully supported on various browsers, has sound-sync issues, and a few other key bits makes it difficult to embrace fully.

Remember, I'm talking about the CANVAS here, not just the standard HTML5 elements.

Once all of these things (or at least a goodly number of them) are resolved, it will be a highly used platform for development.

But there are some pretty kick-ass games out there using it! How can it be said that it's slow? I mean, have you seen the Aves engine??? I have seen the Aves engine, yes, and it is quite impressive. Clearly there are some developers out there that, as we used to say during our heady development meetups, "are fed raw meet under a locked door" because they were amazingly good at development.

But more than that, it shows that there ARE ways to get HTML5 to power through a lot of its current limitations.

That's not the point though. The point of this ongoing review of the language is to see where the state of affairs is now, for the average developer. Can a person take HTML5, in its current state, and build something as speedy as said person can with Flash or Corona, without having to tweak and hack stuff to get that speed? And that's just the speed question. There are still questions of sound, image rotation/scaling/etc., and so on.

I'm bummed about this because it's much more fun to code in HTML5 than it is in some other languages. I guess I like the nerdy element to the fact that you have to hack in order to get it to do what you really want it to do. But, again, it's not about those of us who enjoy the hack, it's about those who aren't all that good at the hack and therefore must rely on the essentials that come with the language.

Still, I anxiously and optimistically await the day that HTML5's Canvas is a rollicking (and blisteringly fast) solution to games.

Wednesday, July 27, 2011

HTML5 revisited

I was recently tasked at work to dig deeper into HTML5 and I'm starting to see some pretty cool stuff coming out of it. There are a buttload of games out there now using this technology.

There are still a few things that, in my opinion, still make it not-quite-ready-for-prime-time. And they are:
  • Sound synchronicity issues. I know that you can use a Java-to-Flash bridge to get the sounds out, but that kind of cuts into the iOS distribution. If anyone happens to know of a consistent way to handle this (without using Flash), I'd love to see it!
  • Code security. Since it's JavaScript, you can pretty much see anyone's code. Obfuscation is helpful, as is encryption, but any truly interested hacker will eventually skip through that stuff. I suppose one could wrap the code loading section in a .php file or use some other method, but it'd be super if there was a compilable option. To be fair, there are solid SWF decompilers out there too, so it's not like Flash is immune to this issue.
  • Browser support. It works great in Chrome and Safari, and it's decent in Firefox too. But what about IE? "What about it?" You say, and then you add, "Get a real browser!" You're preaching to the choir on that. Sadly, IE still owns a huge amount of users that don't know any better, and those users are going to show up to your HTML5 game and find it doesn't work all that well.
  • Mobile support. It seems to be working splendidly on my iPad, but my iPod Touch just sits there wondering what to do with anything canvas-related.
  • Apple. We already said it seems to be working on the iPad, so what's the problem? Well, somebody smart at Apple has to realize at some point that if developers can just slam together games and make them freely available on the web (or offer some other means of monetizing them)...Apple is bound to wonder how they get their cut. Whether they use the "the HTML5 canvas doesn't run fast enough and so we don't want our users having a poor experience" excuse like they did with Flash, or not, is irrelevant. Developers can just use PhoneGap and have their HTML5 projects compiled into native code (which is what Adobe tried to do with CS5 and CS5.5...and it's still really slow). This is cool, but it does take away from the build-once, distribute everywhere concept.
So what makes me think there is still a strong likelihood that HTML5 has a strong future? I took a look at the market and saw a few interesting things.

Zynga, arguably the largest social game company, purchased the Aves engine. This engine is very cool and sports some awesome Isometric graphics. It also has multiplayer support.


Aves Engine

Google is constantly keeping the Chrome browser up to date to support the latest canvas elements, and Android devices (at least my Droid does) seem to play most games pretty darn well...okay, maybe not super fast, but not bad.

Disney purchased Rocket Pack, who created the HTML5 Facebook game "Warimals." It's a nifty little game that shows a number of neat nuances one can do with the canvas.

Warimals

Adobe is putting HTML5 support in their CS products and they event created a product called "Wallaby" ( http://labs.adobe.com/technologies/wallaby/ )that converts Flash to HTML5. Why would Adobe, the owner of Flash, start pushing for stuff that clearly threatens the future of Flash? My guess is because they're smart enough to recognize that it's better to jump on board and create great tools for non-developers (and developers too, let's be honest) that will help them smoothly create for either platform so that they, the aforementioned designers/developers, don't jump ship and look for other projects. Do note that Wallaby only does simple conversions, nothing game-heavy, but who's to say that may not happen eventually? After all, Adobe did work to make a porting-tool for Flash developers to get onto the iOS platform.

Again, I don't think it's 100% there yet, but I am seeing the light now with HTML5. There is a lot of potential with this platform and I, for one, am hopeful that it will grow and grow and grow.

Please feel free to blast me or whatever. I don't mind. :)

Tuesday, June 21, 2011

About Objects class part 1 - Complete

I finished up part 1 of the About Objects ( http://www.aboutobjects.com ) class on Friday and am hoping to take part 2 in July.

For the most part is was terrific. I learned a ton of stuff about C that I didn't know (or thought I knew, but I was wrong) and the teacher was really good at conveying everything in a clear manner. Plus, he was a pretty cool dude.

The one thing I was a little disappointed in was that all day Thursday was a review of the things we learned Monday through Wednesday. This is because we had a few new people show up on Thursday that were there for the start of the Objective-C course, which follows the ANSI C one. Also, it was because a TON of information was presented through the ANSI C course and was therefore reviewed to the folks in the class that just went through it.

Unfortunately, this only left one day for Objective-C training. I know that the point is to lead the Obj-C into the following week (part 2) of the training course. So I'm sure for everyone that was staying for part 2 it was a great thing to have as a review. For me, though, I would have quite preferred two solid days of Obj-C. That's no fault to the About Objects folks. If I could have stayed the second week I'm sure I'd have a different view on things. :)

Regardless, the day of Obj-C that I did get taught me a number of nifty little bits. For example, one thing I was unaware of was what the NS stood for at the beginning of all the foundation class stuff. So, NSArray, NSObject, NSString, etc. In case you don't know, NS = NeXTStep. This is because OS X is really a descendant of the NeXTStep OS. Now that may not seem like it's all that helpful to know, but when you're coming from a Windows background and you're seeing all this weird Objective-C stuff (NSObject and the like), it's a bit confusing.

Also, the syntax of Obj-C is weird. To me anyway.

NSString *desc = [[NSString alloc] initWithFormat:@"Class: %@, Name: %@", [self class], @"Test"];

That looked really strange to me when I first saw it, but now I'm getting the hang of it.

Anyone interested in learning this stuff should consider About Objects. They were very nice and extremely helpful the entire way.

Other good things that I've picked up since have been a couple of iPad books (that were free!). They are:

  • The Objective-C Programming Language
  • Object-Oriented Programming in Objective-C
Both of them are available on the AppStore, again, for free.

Wednesday, June 15, 2011

Learning iOS Development at About Objects

Since Monday I've been at a training seminar to start getting iOS development under my belt. I've played around with Flash CS5 to make pointless little apps that go through the Adobe porting process and spit out iOS code. I've also tried a few different 3rd-party tools to get a handle on how things work. But it just wasn't enough to really get a grip on things.

I just finished up a lab and we're on a 10 minute break, so here is a quick blip about the class.

So AOL hooked me up with a training course at a company called About Objects ( http://www.aboutobjects.com ). It's in Reston, Virginia, located in the downtown area (called Reston Town Center). The area is very nice and there are a lot of restaurants and shops right here. The point is that you don't have to worry about where you're going to eat lunch or pick up supplies, etc. There's even an Apple store a block away in the event that you need something to support your learning.

Of all the companies out there that I could find doing OS X/iOS development training, About Objects was the only one that had ANSI C. Thus, the first class in the series is ANSI C on OS X. While I've coded numerous apps in C since the late 80's, I haven't done anything in C for about 10 years. Plus, I've not done anything really deep on the Mac or iOS platforms, so starting out with a lower level language like C seemed to be a smart move. As the instructor (Jonathan Lehr, owner of About Objects) points out, it's better to get a solid understand of what's going on under the hood before you start working with the higher Objective-C language. I couldn't agree more. After spending a month banging my head on Objective-C, I finally gave up and just considered it a lesson that I needed to stick with the Windows environment. This is because I couldn't seem to find anything that really helped me get to an area that I was comfortable *before* going into an area I'm not.

Things are moving quickly in this class, but in a good way. As an example, this is supposed to be a "learning C" course. On day 2 we were working with pointers. Today we move into structs, function pointers, etc. But, to me, this is the way to learn. Get a fast dump of relevant information, skip all the crap that you're not really going after, do a number of labs to help the knowledge sink in, sleep on it, and move on to the next section. I've gotten more out of two days on C than I probably did in the years I was coding in C. Jonathan conveys the information clearly and his level of knowledge about the language and OS make for numerous tidbits that have made me say, "Oh...cool" numerous times.

Now keep in mind that the point of this ANSI C class is not so that you walk out knowing all there is about C. The point is that you have a solid understanding of C's strengths, quirks, and weaknesses. This is because day 4 is the start of learning Objective-C and in order to understand why Obj-C does things as it does, understanding its base component (C) is very valuable. I sure hope so because I'm hoping to finally understand Obj-C by the end of this week!