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.
Monday, September 12, 2011
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:
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.
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.
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. :)
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.
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!
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!
Wednesday, December 1, 2010
Which language to learn for web game dev?
There are a number of different options these days when making casual games. Here is my take on the order of usefulness today:
The majority of casual games right now are being developed in Flash. If you look at sites like Games.com, Mochi, Mindjolt, and so on...you'll see that 90% (or more) of the content is Flash. Does this mean that Flash is better than the others? Nope. It just means that it's the most common use-case for developing casual games right now.
The question really is how long that's going to be. HTML5 is hot on Flash's heels, and it's really shaping up to be a powerful ally to casual game developers. I just don't think it's ready to usurp Flash's position just yet. The progress is substantial, though, so give it a year or two and it'll be a formidable contender. Adobe knows this too. They have been working on Flash->HTML5 conversion systems, and I wouldn't be surprised if they created a Flash-like IDE for the HTML5 (focusing primarily on the canvas support). As John Nack put it in his article regarding the conversion tool, "Adobe lives or dies by its ability to help customers solve real problems." This does seem the case and I would argue that Adobe's doing a pretty decent job of it. If they did create a full HTML5-IDE (ala Flash), I'd buy it.
Java is a great language for developing games. It's been around forever and has had a lot of push. I'm not a Java game developer, but I've tinkered lightly in the past and I had to do a few projects in college (non-game) using the language. The power afforded by the Java gives the developer a lot of options. The issue I see is that when Oracle took over the company they seemed to have put games off to the side. This doesn't mean that Java no longer offers gaming as a possibility. Far from it. It just means that the company-backing to grow that area of the language is no longer in the forefront...unless something has changed that I'm unaware of.
Unity is a nifty language with a robust graphics engine. It's powerful, 3D, supports builds on various platforms and distribution channels, etc. I've dabbled only lightly in it and I can say it is a very nifty world. Issue: the documentation is less than awesome. There are a lot of things that you just have to figure out. Now, if you're the tinkering type, this may be cool to you; if you're part of a team that is taking Unity and extending it to fit your particular game, then it's a very smart path to go. But if you're a hobbyist or a developer working on time-constrained projects, the learning curve may just be too great until they get their docs in order.
Silverlight is interesting, but I wonder how far it's going to go. With Microsoft behind it, one would imagine it has decent longevity. I wonder why they'd bother pushing money in its direction when HTML5 seems to be heading swiftly toward front-runner position. Personally, I've not developed in Silverlight, so I can't talk to its particular strengths. Still, as time permits, I will create a least a little something so I can see how it all comes together. I just don't see it as an area to spend too much of my time since Flash already has the lead and since I'm guess that HTML5 will soon take the #1 spot.
There are others out there that are available to learn as well, but I think the ones listed are the primary contenders at the moment. Of course I may have completely spaced on one of the other big players. If so, smack me. I'm not proud. :)
The bottom line is that any of the above languages (and more) have their advantages and disadvantages, but if you're looking to pick one or two to learn at this point, I feel that picking the more relevant one makes the most sense. This isn't a case of me saying (or thinking) that Flash/ActionScript is the best and everything else is crap. I don't believe that at all. Actually, there are parts of AS3 that drive me nuts. The point is that I see little value in spending my time deeply learning Unity and Silverlight for web-game development at this time, unless, again, there is a particular need (or job-opening) that requires that expertise.
Playing devil's advocate: There are a load of Flash and Java devs out there already. Companies that are invested in Silverlight, WildTangent, ActiveX, Unity, Torque, etc. are on the lookout for developers that know those technologies.
It's a catch-22. You either focus your time on being a know-it-all about one or two technologies, or you play the jack-of-all-trades card and just be decent in various technologies. I've always gone the second route. The way I see it is that I'm a developer regardless of the language I use. If I am tasked with developing an application in Java, I'll focus my efforts on learning it for that purpose. Same with Silverlight, etc. So I purposefully do not try to be an expert at any single language. To do so, for me, is limiting. ...but that's really a different discussion.
- Flash/Flex
- HTML5
- Java
- Unity
- Silverlight
- etc..
The majority of casual games right now are being developed in Flash. If you look at sites like Games.com, Mochi, Mindjolt, and so on...you'll see that 90% (or more) of the content is Flash. Does this mean that Flash is better than the others? Nope. It just means that it's the most common use-case for developing casual games right now.
The question really is how long that's going to be. HTML5 is hot on Flash's heels, and it's really shaping up to be a powerful ally to casual game developers. I just don't think it's ready to usurp Flash's position just yet. The progress is substantial, though, so give it a year or two and it'll be a formidable contender. Adobe knows this too. They have been working on Flash->HTML5 conversion systems, and I wouldn't be surprised if they created a Flash-like IDE for the HTML5 (focusing primarily on the canvas support). As John Nack put it in his article regarding the conversion tool, "Adobe lives or dies by its ability to help customers solve real problems." This does seem the case and I would argue that Adobe's doing a pretty decent job of it. If they did create a full HTML5-IDE (ala Flash), I'd buy it.
Java is a great language for developing games. It's been around forever and has had a lot of push. I'm not a Java game developer, but I've tinkered lightly in the past and I had to do a few projects in college (non-game) using the language. The power afforded by the Java gives the developer a lot of options. The issue I see is that when Oracle took over the company they seemed to have put games off to the side. This doesn't mean that Java no longer offers gaming as a possibility. Far from it. It just means that the company-backing to grow that area of the language is no longer in the forefront...unless something has changed that I'm unaware of.
Unity is a nifty language with a robust graphics engine. It's powerful, 3D, supports builds on various platforms and distribution channels, etc. I've dabbled only lightly in it and I can say it is a very nifty world. Issue: the documentation is less than awesome. There are a lot of things that you just have to figure out. Now, if you're the tinkering type, this may be cool to you; if you're part of a team that is taking Unity and extending it to fit your particular game, then it's a very smart path to go. But if you're a hobbyist or a developer working on time-constrained projects, the learning curve may just be too great until they get their docs in order.
Silverlight is interesting, but I wonder how far it's going to go. With Microsoft behind it, one would imagine it has decent longevity. I wonder why they'd bother pushing money in its direction when HTML5 seems to be heading swiftly toward front-runner position. Personally, I've not developed in Silverlight, so I can't talk to its particular strengths. Still, as time permits, I will create a least a little something so I can see how it all comes together. I just don't see it as an area to spend too much of my time since Flash already has the lead and since I'm guess that HTML5 will soon take the #1 spot.
There are others out there that are available to learn as well, but I think the ones listed are the primary contenders at the moment. Of course I may have completely spaced on one of the other big players. If so, smack me. I'm not proud. :)
The bottom line is that any of the above languages (and more) have their advantages and disadvantages, but if you're looking to pick one or two to learn at this point, I feel that picking the more relevant one makes the most sense. This isn't a case of me saying (or thinking) that Flash/ActionScript is the best and everything else is crap. I don't believe that at all. Actually, there are parts of AS3 that drive me nuts. The point is that I see little value in spending my time deeply learning Unity and Silverlight for web-game development at this time, unless, again, there is a particular need (or job-opening) that requires that expertise.
Playing devil's advocate: There are a load of Flash and Java devs out there already. Companies that are invested in Silverlight, WildTangent, ActiveX, Unity, Torque, etc. are on the lookout for developers that know those technologies.
It's a catch-22. You either focus your time on being a know-it-all about one or two technologies, or you play the jack-of-all-trades card and just be decent in various technologies. I've always gone the second route. The way I see it is that I'm a developer regardless of the language I use. If I am tasked with developing an application in Java, I'll focus my efforts on learning it for that purpose. Same with Silverlight, etc. So I purposefully do not try to be an expert at any single language. To do so, for me, is limiting. ...but that's really a different discussion.
Thursday, November 11, 2010
Mochi ZIP integration issue resolved
It took a couple of weeks working back and forth with the tech folks at Mochi, but we finally uncovered an interesting ooopsie.
There are three ways (that I'm aware of) to build a game for Mochi distribution:
1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.
2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.
3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.
The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.
The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:
The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.
The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.
If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.
Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.
There are three ways (that I'm aware of) to build a game for Mochi distribution:
1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.
2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.
3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.
The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.
The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:
var loader:Loader;
var resourceURL:String;
var request:URLRequest;
loader = new Loader();
resourceURL = loader.contentLoaderInfo.loaderURL;
resourceURL = resourceURL.substring(0,resourceURL.lastIndexOf("/") + 1);
resourceURL = resourceURL + "tempflashfile.swf";
request = new URLRequest(resourceURL);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteHandler, false, 0, true);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler, false, 0, true);
loader.load(request);
The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.
The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.
If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.
private var gLoader:Loader;
private var gResourceURL:String;
gLoader = new Loader();
gResourceURL = gLoader.contentLoaderInfo.loaderURL;
gResourceURL = gResourceURL.substring(0,gResourceURL.lastIndexOf("/") + 1);
Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.
Saturday, September 18, 2010
HTML5 is nifty
I've been coding primarily in AS3 for a few years now, but I was tasked to do some research into HTML5.
While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.
Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.
While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.
Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.
Subscribe to:
Posts (Atom)