3 articles Articles posted in WebGL

HTML5 – The Best Platform For Rapid Game Development

It’s a bold claim, but I’m going to make it and back it up with two example games… HTML5 is *the* best platform for rapid game development available right now.

Nick vs Bus

I’m a student at the University of Texas, and two weeks ago, another UT student was hit by a bus (video embedded below, he made it out without serious injuries). As soon as I saw the video start going viral, I decided I would make a game for it. 24 hours later, the game was complete and went viral itself. In just a few days, the game had 25,000+ unique visitors, 1,500+ likes, and articles on sites like Kotaku, News.com.au, and the Statesman. Here’s the link to the game: Nick vs Bus

The game makes use of <canvas>, SVG (Scalable Vector Graphics – which were remarkably easy to implement), and Clay.io. It’s written in CoffeeScript, here’s the source code (keep in mind it was made in <24 hours). Thanks to HTML5, it’ll run from your phone’s browser as well (assuming have a semi-modern smartphone).

Nick vs. Bus wouldn’t have received anywhere near as much response if I had released it two weeks after the incident, and HTML5 was the perfect language to crank it out in such little time. (Keep in mind when I say HTML5, what I really mean is <canvas> and JavaScript)

The graphics aren’t great, but that’s not my background (if you’re curious, I used Inkscape)

Word Wars

The second game that backs up my claim that “HTML5 is the best platform for rapid game development” is a game called Word Wars.

Word Wars was initially developed by a couple other students and friends during a 24 hour hackaton at UT. It was called Worldle at first, and had some good reception from Hacker News. One of the developers didn’t even know JavaScript going into the thing (pretty impressive).

What’s more impressive about Word Wars in relation to Nick vs Bus is it has a backend + multiplayer (nowjs), all done in less than 24 hours. This one was done in pure JavaScript rather than CoffeeScript like the first — it’s really just a matter of preference, CoffeeScript isn’t going to drastically reduce your development time.

Again, the game works from mobile devices as well

That’s two games developed in less than a day, both with a pretty good reception.

Bonus: Since it’s the development time is so little, I even made a game for TechCrunch in an attempt to get noticed for an article. That attempt wasn’t successful (a couple editors tweeted about it, but no article), but here is the game anyways.

Why HTML5?

The best candidate to compare HTML5 to for rapidly developing and deploying games like Nick vs Bus and Word Wars is Flash. Java, C++, Unity, iOS and the rest all typically have longer development cycles, not to mention they simply wouldn’t have spread as quickly since people are forced to download the game (or use the terrible Java applet). Sure, you can create a game fairly quick in those languages if you’re very familiar with them, but I’d argue that, given an equal knowledge of all languages, HTML5 would win out on rapid game development. If you’re hoping to create the next Call of Duty (we definitely need more games like those /sarcasm), go with C++… WebGL is great but we’re probably still a couple years away from seeing console-quality games using it.

Why HTML5 over Flash?

Mobile Support

This is the big one in my eyes. Right now the main benefit of HTML5 is it’s “cross-platformness” by nature. 3,000 of the 25,000 visitors to Nick vs. Bus came from mobile devices. Most of those came from people clicking the link from Facebook’s app.

Sure, you can get your Flash game on the App Store (when I say App Store, I mean iOS, Android and WP7), but that takes time, and any update you make takes time as well… With HTML5, you can get your app on the App Store if you’d like, plus your game can be played straight from the browser.

For the Nick vs. Bus game, mobile support would just now be ready… two weeks later… if I had used Flash.

In addition to mobile support, HTML5 paves the way for games to be playable on smart TVs (in the hopefully near future), Windows 8 apps, and perhaps even consoles as Microsoft is very supportive of the new markup.

No compiling

Having to wait for a compiler sucks. With JavaScript you don’t have to. (Yeah, I use CoffeeScript,  a compiled language; however, it’s very quick to compile and certainly not necessary). That also leaves open possibilities like this.

Easy Testing

As per the nature of the web, to test a game on different platforms, you just point your browser at wherever you chose to upload your game. Testing for mobile is the same, and since most browsers and mobile browsers have their own JavaScript console, it’s fairly easy to find the issue and debug quickly.

Same language for a backend

Should your game need a backend (if for example, you want a multiplayer component), you’re able to use the same language: JavaScript (node.js), which just makes sense. Why write a game in two different languages when you don’t have to? For one of our games, Slime Volley we run a separate instance of each game on the server. In our implementation, we simply share code between the client and server, so there’s no need to rewrite the mechanics in another language. The game’s source code can be found here.

It’s not a plugin

Okay, okay… pretty much everyone has Flash, but it’s hard to argue against a standard being better than a plugin. Apple has already taken a stance against Flash. Sure, none of the major players in browsers are going to publicly take a stance against Flash, but I can see HTML5 being favored over something that is completely beyond their control.

It’s not controlled by a single corporation

Adobe does fine work with their products, but in this case Google, Mozilla and Microsoft all competing against each other will be able to continue making something better. Chrome was the first to really make HTML5 games viable with the V8 engine, and now Firefox and even IE are doing their part to push the limits.

Great stuff is being pushed out like the Gamepad API and Notifications API.

More active development

Because it is new, more and more developers are building tools for HTML5. New doesn’t necessarily mean better… in fact, it means it’s likely less stable. What it does mean however is there is likely much more active development going on and much less legacy code / excess bulk.

HTML5 games get more attention

Honestly, HTML5 games get more attention just for being HTML5 – deserved or not. It’s still a buzz-word, and early adopters seem more likely to have a look, opposed to flash games which they’ve played hundreds, if not thousands, in the past 10+ years.

HTML5 Weak Spots

The two biggest criticisms of HTML5 are audio and security. Audio still needs work, I’m not going to beat around the bush on that. It shouldn’t be long though…

As for security, I just wrote an article for DZone about this. It’s not published yet, but you can have a look at the Google Doc for it here. Basically, you can make your game secure, you just need a backend that can be done fairly easily with node.js.

Finishing Words

I’ve written a three part series on HTML5 game development tips — things I’ve picked up on along the way. Part 1 is about style & performance tips, part 2 covers input methods (keyboard, mouse, touch, accelerometer, etc), and part 3 (link to Google Doc since it’s scheduled to be published on Monday) talks about security tips.

I’m betting on HTML5 which is why I’m building what’s essentially “Steam for HTML5″. It’s called Clay.io. You can have a look at more HTML5 games in the Clay.io store. For developers, have a look at the HTML5 Game Development Tools we offer.

Global Game Jam 2012

I woke up Friday morning to learn that there was this thing called Global Game Jam happening at UT this weekend – it’s something that sounded right up my alley, so I gave it a shot. Basically you get together, form groups, and develop video games in 48 hours. I chose to fly solo this weekend, since most game developers don’t have a background in JavaScript and I like a challenge.

This was a  good opportunity to make a game for my new project, which now has a name: clay.io. This game had to be simple because of the time constraint, so I set upon an idea similar to a mini-game from Mario Party. The premise is, you, and 1-3 others are on a platform, and have to duke it out until one person comes out on top. Of course, I added my own flare to the game as well.

The game uses WebGL, to render 3d graphics right from the browser without plugins, and a combination of node.js and socket.io for the multiplayer networking. To help make WebGL a bit less painful, I used GLGE. For the 3d-modeling (if you can even call it that…) I used sketchup. That’s definitely the weak point of this game: the art. All of this was done in less than 48 hours by someone who doesn’t consider himself a game developer. I’m surprised more people aren’t hopping on board with WebGL yet.

Here’s a quick demo video – I’m happy with the results so far:

You’ll see I just have two Chrome windows open, showing the multiplayer support. It’s kind of lame watching me fiddle with it by myself, it’s much better when actually playing ;) Packets between the server and client are being emitted 10 times per second, much less than the typical 20-30 per second – interpolation takes care of everything in between.  The player can be controlled with either the mouse or keyboard, and the goal of the game is to survive the longest.

There are 3 abilities to help you survive. One is ‘stomp’, where if you jump in the air and hit the “C” key above you opponent, it will smash them and they won’t be able to move for 1 second. The second is “Push back” – which is something you can use to prevent an opposing player from getting too close to you, or to try and push them off the edge. The final ability is just “Attack” – if you get behind another player and press “R”, it will damage them. 5 hits and they die.

As you’ll also see, parts of the platform are constantly rising and falling, with a short warning shake beforehand. This adds another dynamic as you have to make sure you don’t fall off.

I was able to get the game to a playable state, with all the features I’d initially written down. However, it’s still not at the point where I want to release it. There’s a bit more polishing to do before that – but once it’s ready I’ll have it released within clay.io. Right now it’s just 2 players max, but I programmed it with more in mind so it’ll likely be 3 or 4 players in 1 game at a time (it’s more interesting that way).

That’s all for now – I’m running on 90 minutes of sleep in the past 31 hours so it’s time to relax, watch the Pro Bowl and get a good night’s sleep.

My Infatuation with WebGL

WebGLThe past year plus, whenever I’ve had free time, I’ve used to it to familiarize myself with WebGL, a new technology that allows some pretty awesome graphics to work in your browser without any plugins (utilizing HTML5′s <canvas>). Part of that time has been spent developing a game (which can be very hard work), and I even used the technology to make my girlfriend’s anniversary gift.

Most software has moved to the web in the past 5 or so years, and games are sort of an exception. Of course there are web games, and some very popular ones at that (Farmville, Words with Friends, Sims Online, etc), but no truly awesome 3d games. With WebGL, hopefully that can happen.

Here are a couple cool demos using WebGL (you’ll need a newer version of Chrome/Firefox, or some beta builds of Opera/Safari): Cars and Rigging

There are even projects in the works to get this all working with gamepads. As I was developing my game, I made use of APE Project to handle multiplayer connection, so if you’re interested in developing a multiplayer game, consider that.

WebGL is something I hope to continue working with, I’ve always been fascinated by video games, and I have a few ideas up my sleeve – so watch out!