I love seeing how games are made.1 And now that I am making a game I feel like I should be sharing as much as possible for anyone who might be interested. And since I am somewhat of a nerd, I can’t help but talk about technology first.
So here is my first little step, for my fellow web geeks, for future reference, or for no one in particular: this is what makes my new WebGL game Skycraft possible.
WebGL draws pixels on your screen really, really fast, using your GPU. But you have probably heard of it (or seen it) already, so I don’t have to tell you why that’s awesome. WebGL is actually becoming quite stable, and it’s even supported by all your friendly neighbourhood browsers: Chrome, Firefox, Opera and Safari. Note the unsurprising absence of a certain blue browser, though.2
Web Workers are bascially like threads, or processes, that you can use to process data without locking the UI thread. Skycraft uses this for world generation, as the world has to be generated as the player moves around. The latest version of all the major browsers support Web Workers, even the Blue One That Must Not Be Named.
WebSockets enables TCP-like connections to a server, without all the HTTP overhead. Skycraft uses this to store the blocks on the server (though not in the demo). It has had a bit of a bumpy ride, with the first versions being turned off in browsers due to a security flaw.3 But it’s now supported by all browsers, hurray!
Then we start moving into the frontier: The Fullscreen-API allows you to.. well, you get it. Together with PointerLock, which hides your mouse cursor, this allow you to make first-person games, and/or other games that actually look like real games, since they cover your whole screen. Both of these APIs are so hot out of the oven that both Chrome and Firefox had settings you had to enable to try it until just a few months ago, but they now work out of the box. PointerLock is sadly missing in action in both Opera and Safari, effectively blocking users of these browsers to play Skycraft.
While the tech demo of Skycraft only has singleplayer, the multiplayer alpha will have peer-to-peer multiplayer using WebRTC. The MDN page is a bit outdated, and not very helpful, but just look at it like WebSockets without the server. Both Chrome and Firefox support WebRTC, but the implementations are still pretty volatile.
Last, let’s look at something a bit more on the horizon. IndexedDB and the File System API which give ways of storing large amounts of temporary or persistent data in the browser. Skycraft processes huge amount of data, too much to keep in memory, so this would allow for even larger floating islands. Currently only Chrome supports IndexedDB inside a Web Worker, and the File System API, so the plans to use IndexedDB are still on hold, but hopefully Firefox will come along soon.
While re-inventing the wheel can be fun at times, its just proper street-smarts to use some frameworks. So let’s talk about the frameworks I use.
Three.js: You didn’t think I actually wrote pure WebGL, did you? Well, the most time-critical parts of Skycraft are almost pure WebGL, but Three.js let’s you do that in an easy way, while still providing lot’s of convencience, and that’s just pure awesome. Probably the most popular WebGL library out there, with plenty of examples to learn from, but very little to no documentation yet, as the code is still very much evolving.
Grunt: makes it somewhat easier to do stuff like combining, compressing, gzipping, and deploying files. You could quite easily write bash-scripts that do the same thing, but why re-invent the wheel? Finding a script that deployed files to S3 was as easy as
npm install grunt-s3.
Modernizr let’s you test whether a user’s browser has a certain feature. This is great, because you can give the user some feedback about why something doesn’t work before it crashes. Skycraft uses this to give a helpful error message to those who haven’t got WebGL, the Fullscreen API, Web Workers or PointerLock.
Get ready to not be surprised: it’s almost all AWS.
Skycraft is currently running directly on S3, which keeps me from having to think about scaling, caching or even setting up nginx. The payments from Paypal are processed through a node.js server on a micro EC2 instance, which talks to an RDS database. One great thing about AWS is their Free Tier, which lasts for a year, and gives you most of what you need when starting quite small. My Amazon-bill is currently 64 cents per month! And that’s only because of the DNS Route 53 not being completely free.
When a payment is completed, the purchaser gets an email sent through Mailgun. This could also be done by AWS, but I wanted something that could handle incoming mail as well, and I just completely love look and name of the service and just the mental image of the recieving and firing off mails as seen on their frontpage.
When the multiplayer hits this fall, the world servers will be on EC2 as well. The numbers of servers will be auto-scaled depending on the amount of current players, with a bit of headroom of course. The storage of the world will most probably be as files on S3, or EC2 instances with Redis, which is a sort of beautiful bastard child of memcached and a NoSQL database. I’ll experiment quite a lot with this during the summer.
That was a lot of stuff, I’m surprised you made it this far! At least you now know a bit more about how the sausage is made, probably far more than you want to. This was just an overview though, there’s a lot more to tell about the nitty gritty details of the voxels and the game itself, but I’ll save it for later.
If you have anything in particular you’d like to know though, or just want to comment on this post, feel free to direct cute little blue birds at @haeric.