We're still here!

It's been a while since I've posted anything on here. Just letting you know we're still around and development on our latest project continues. Check back later for some more info!

HTML5 & Games

For my first real post, I want to talk about about the potential of HTML5 for game development. This has become a hot topic lately, and there is a lot of controversy over whether HTML5 is a viable option for game developers; or the idea that HTML5 means devs will no longer have to deploy native versions or bother themselves writing in C++ or Java. Even on mobile platforms you can write your app in HTML5 and have a native wrapper that just contains a UIWebView (iOS) that displays it for you. While that approach is valid, the idea that HTML5 is the future of app development is simply not true. I'm not going to go into why, instead I'm going to focus on the former argument, which is most certainly true. That is, HTML5 is a very good contender when it comes to deciding what you want to code your next game in!

First of all, if you don't know or if you're a purist, you won't actually be writing your game in HTML5. You will be writing it in Javascript. I think this causes a lot of confusion to those who aren't familiar with the technology. Writing a game in actual HTML sounds ludacris. But you're really writing it Javscript for the purpose of being run on an HTML5 platform. I find these semantics to be nitpicking though, really. It is analgous to Flash (which I bring up again later). You don't actually write a game in Flash; you write it in AS3. Flash happens to be the environment running your AS3 code; similarly, HTML5 is the tech that allows your code to run and render to the screen. Now that that's out of the way, I'm going to stop using the term HTML5 and instead refer to Javascript the rest of the article since that is the main attraction, except when I'm explicitly talking about a subcategory of HTML5 (of which JS happens to be).

So why is JS an a good option for game dev? From a broad point of view, I'm going to list a few reasons:

• Portability

  Possibly the biggest reason. You write an app once, and it runs on nearly everything. Every computer, every mobile device, even some game consoles have a browser. And if you aren't living in the stoneage, the chances that your browser supports all the latest and greatest is almost guaranteed!

• Ease of use

  From a development & end-user POV. JS is incredibility easy to learn and use (subject to debate. I much prefer static typing for one example), debug and rapidly prototype. As an end user, you don't have to download any new app, install anything or agree to any store terms. You most likely already have a browser open anyway. Just navigate to where you want to go and BOOM! You're playing a game!

• Performance and availability

  Most browsers these days have amazing JS engines. They support WebGL and hardware acceleration. Input is incredibly easy to handle. Chances are if you're writing an indie game, you aren't pushing the limits of hardware (this isn't always true), but you can get some pretty amazing results. Mozilla released a demo of Banana Bread, which is really just a slimmed down port of Cube 2, quite a while ago. Granted if you're targeting mobile as well, you're more limited when it comes to performance, but not as much as you might think.

• Replacement for Flash

  This has been an argument of its own for years now. It's sad to say (is it really?) but this is becoming a reality. Flash is on its way out and JS & the corresponding HTML5 technologies are a great, if not better, replacment. If for no other reason than this and you are specifically looking to make browser-based games, which are still very popular, JS is the way to go.

There are of course other reasons, but those are the major ones. If I you feel there should be others up there, comment away!

Now that you're considering making your own JS game, I'm going to rattle off a bunch of technologies and projects that you should definitely take a look at. These will defintely sway your opinion if I haven't yet. I've already mentioned Canvas and WebGL, which are the driving forces that even make this possible. Over 90% of JS games will utilize one or the other. Most browsers (even some mobile) support WebGL. WebGL is exactly what it sounds like. Canvas is similar to a Canvas object in AS3. This means it is pixel-based and limited to 2D, but it is very powerful in these regards! For sound you have HTML5 Audio and WebAudio. There's even WebSockets for networking, and the GamepadAPI. As you can see, there isn't much limitation when it comes to making a full-fledged game in JS.

At this point, you're probably thinking, "That's cool, but how can I use them!?" Well, another great bit about JS is the large number of developers and community surrounding it. Much of the 'lower level' code has been written for you. There are already many JS game engines out there to use. Then there's options such as PuzzleScript which greets you with nearly a full IDE. Even Unity can deploy to HTML5, but that's not the impressive part. The following list contains links to some awesome JS libraries that you can use when making your own games:

• pixi.js - A 2D rendering engine that uses Canvas and WebGL
• three.js - A 3D rendering engine using WebGL
• howler.js - A gratuitous audio API that utilizes sound sprites. If you want decent audio in your games you'll need this!
• socket.io - A simple sockets library, which allows for cross platform networked games in browser.
• Box2D - Even Box2D has been ported to JS

The list goes on! I think now would be a good time to mention node.js and npm, as well as Grunt. These tools will make your JS development life much more complete. Definitely check them out if you are at all serious about HTML5 games, or even just experimenting. Anyway, as you can see, you have a lot of options at your fingertips. JS itself is very easy to pick up, and there are many web developers and other resources to help you along the way. With the help of libraries such as the above, you won't believe how quickly you can get something decent up and running.

Convinced now? Excited? Ready to go crazy with JS?

Great! Now I'm going to tell you why JS, and consequently HTML5, IS NOT good for making games. Again, list time...

1. While HTML5 has come a long way and support has improved incredibly, there are still many features that aren't guarenteed to work, or have yet to be finished; some of those features are detrimental to a good game. This is a problem with web apps and JS in general. A quick google search will bring you to many pages outlining such issues.
2. While portability is one of the strongest arguments FOR making an HTML5 game, it's also one of the strongest against. While JS is supposed to be standardized, most browsers handle things differently (especially that damn IE. Is anyone still using that???), and feature implementation is sporadic at best. What works in one browser may not work the same or at all in another. While this has also vastly improved over the years, and there are many API's (i.e. jQuery) that handle these issues to the best of their ability, you may (will) still run into problems. Furthermore, since all the technologies that allow a game to be made with HTML5 are still rather new, not every browser supports every variation of the feature you may be using. If you've done any kind of web development before, you've encountered the never-ending, recurring problems that define web development. This still applies.
3. Despite all the great links and the Banana Bread demo, performance is still a concern. Especially if mobile is your target, where many users have crappy devices and/or outdated software. This is discernible though; know what you want to make, then decide if it's low-performance-intensive enough that this wouldn't be an issue for you.
4. Security is also a concern. In many ways. Let's tackle code first. While your game doesn't have to be open source, your source is always open to the public. You can't hide it. You should always minify and obfuscate before deployment, but this is easily undoable, so keep that in mind. The nature of JS also allows your game to be easily "hacked", allowing players to cheat. Depending on your design model, and if networking is involved, there could also be a security risk involved with stored information and server exploits. Just know what you're getting into and do it right, and you should be fine!
5. Unless you're making games completely as a hobby, you're probably looking to make some income at least some of the time. You can't really sell an HTML5 game. You're basically down to the same options as flash devs: sponsorship and advertisements. You also can adopt an IAP model (this seems to work well for FB games), but that comes back to the security concerns. Think about the intention of your game with regards to monetization before you jump in!

I think that should cover the basics! In conclusion, HTML5 is not a replacement (except for maybe flash). You shouldn't drop everything and focus on HTML5, but definitely pick it up, play around, and consider it for your next game. Think about your goals for the game, your target audience, your hardware requirements, what type of game it is, etc. HTML5 may be a viable option. I hope you enjoyed the article, and continue to read this blog! Feel free to comment!

Lastly, since this is the Fuzzy Rhombus dev blog, I'm going to do a follow up post soon about the HTML5 game we're currently working on. Check back periodly to see what's in store!

Introduction

Welcome to my new blog! My name is Ryan, and this is the official game dev blog for Fuzzy Rhombus, our upcoming indie game studio. It will contain usual dev blog stuff, as well as maybe some news posts and occasional articles.

Some real content should be up soon. Stay tuned!