The state of web-based Games
Thus far, gaming on the web has been a mixed experience. There are flash games, such as you would find on kongregate.com, and there are simple games written in HTML and whatever is generating said HTML — often PHP, Python, or Ruby. You know, those "click here to do some action", and then refresh the page. Or wait until the timer counts down to 0, which might take a few minutes or hours, at which point you can issue another command. I'm talking about slower paced text web games that don't really have any real-time action elements. Appainter, for example, let's you build such a game. They have videos demonstrating how it works (and it's really neat). But I'm talking about traditional action games. Things you'd see on a Super Nintendo.
Envision, something along the lines of Zelda, or Super Mario World. Now add MMO. Alright, so that's what I'm talking about. Responsive real-time action games. Until fairly recently, this is something that really hasn't been all that easy to implement in HTML, Javascript, and CSS. This has finally changed with HTML 5.
There's been talk about HTML 5 for a while. Some of the technology features contained within, along with CSS 3, are able to replace proprietary solutions such as Flash. The combination of HTML5 and CSS3 has even been referred to as "Web 3.5". Perhaps a bit too cute, but it works. And there's already been some folks out there busy with implementing some interesting prototypes that resemble more traditional gaming. In fact, right now, with HTML 5 and CSS 3, it's possible to implement games that have a similar feature set as nearly anything seen on a Super Nintendo. Canvas is one of the features making this possible. The next step after that is likely to be WebGL, which will provide us with N64-like capabilities on the web.
There are multiple instances of individuals working on their engines, and showing them off on YouTube:
Demo of Akihabara framework by Owen Rubel:
This seems to be an MMORPG engine written in PHP and HTML5:
There are a few other individuals dabbling away at these engines. But from what I can tell, their technology choice bothers me.
In some cases, these are purely client-side libraries, which means they're most likely single player game engines. And while it's still impressive that these can run in a browser, in just HTML and JavaScript, it doesn't strike me as quite the right approach.
In other cases, the server component is written in PHP, which in my opinion is one of the worst choices for a server-side language that's supposed to maintain and synchronize state for clients. Also, this is not a knock against PHP for the sake of it being PHP. I'm quite fond of the language, and have used it for years almost exclusively. I'm a huge fan of developing web applications in PHP and Zend Framework. The language just doesn't have the right architecture in order to support an MMO server.
- For one, you'll want a language that's performant. PHP isn't exactly fast. It shines because it's got a rich function vocabulary and interfaces with a million libraries instead.
- PHP isn't stateful. There's a teardown after every request. Maintaining state would require some sort of outside persistence mechanism. It could be memcache, it could be files, etc. It still requires reloading data and writing it all the time. And although one could implement a daemon IN PHP itself, accepting clients over sockets and what not…well, no, just no. Don't. Neither fast nor stable. Yes it works, but barely, and it's just not meant to do that sort of thing.
- There's no support for concurrency. There's no multi-threading. Although PHP can fork, and can use IPC, it's neither pretty, fast, nor stable. In fact, a huge feature promoted by Rasmus Lerdorf himself is the share-nothing architecture PHP uses. And that's okay (and works great, architecturally), just not when we need something long-running and stateful. Something about the right tool for the right job and all that.
And I think this is where there's room for a new type of web-based client/server MMO engine.
Print This Post
Game with HTML5 and Erlang
In a previous post I've mentioned web-based gaming, with regards to using HTML 5. There are already a number of HTML5 / JavaScript frameworks out there that all pretty much do a very similar thing, and that is abstracting away the DOM and providing an API that implement game development concepts such as sprites, blitting, and in some cases very simple physics engines.
In 2008 I've done some PHP work for a group of guys that had a project they wrote in Erlang. During that same time, Erlang had some exposure on various programming related sites because of its concurrent nature. So I got Joe Armstrong's book and casually read through it. I had briefly played with Yaws, mochiweb, and various other Erlang tools, libraries and documentation, which I found sparse, and somewhat experimental. There wasn't much of a community. There is trapexit, and a few other sites that offer some tools, as well as blogs, of which most are people just learning the basics.
It wasn't until March of 2009 that I also played with Flex, in conjunction with Papervision3D and Away3D. I was envisioning using Erlang as a backend for a 3d virtual world with Flex and Papervision3D as the client. To make it simpler, I'd wanted to create a space simulation. I thought that modeling a few (simple) space ships in Wings3D and using simple steering behaviors would be something achievable. Much more so than having to deal with terrain generation and animated characters.
It got to the point of having a few simple Erlang processes being able to talk to a client process that was connected to a Flex client via TCP, rendering a polygon to represent the ship. Although it would have been possible to continue down the road, I didn't think I was on the right track. Talks of HTML5 and hints of WebGL led me to believe that Flex wasn't the way to go. I don't know. I just lost interest. Perhaps it was the thought that I wasn't going to be able to produce something quickly enough. I've also had doubts that the math intensive steering behavior component was a good use of Erlang. So, Project canceled.
In June 2010 I stumbled across a demonstration of the HTML5 Aves engine.
I found this somewhat impressive, actually. And had thought about various techniques that might have been used to achieve this.
Most of the web-based games thus far weren't all that fancy. They're either written in Flash or had very simple game play. Or they were single player client-side only.
Various other JavaScript frameworks sprung out of the ground that used DOM elements or the canvas tag to handle simple game simulations. I found the Google tech talk presentation by Paul Bakaus inspiring enough to give some of the techniques a whirl.
So I started prototyping.
Nothing in particular. I'm just trying to play to the strengths of the various pieces of technology I'm using. I have over a decade of experience in imperative languages doing OOP, writing middleware and working with backends, and I'm quite honestly bored with it.
So early 2008 I started dabbling with Erlang, tried to implement some steering behavior (to be rendered with PaperVision 3D / flex) and ran into all kinds of issues. "Game loop" issues on the Erlang side (weak math performance), my lack of experience with functional / concurrency oriented languages, not quite understanding on how to efficiently share data when you're dealing with message passing, lag / protocol issues (flex only does TCP, and there were no docs on whether I could tweak / misuse RTMFP to somehow get UDP-like features). And ultimately, I didn't think I wanted to do stick with Flash, and PaperVision development seemed to have slowed down. All in all, it was kind of frustrating. I couldn't convince myself I was on the right path. So I dropped the project.
But I continued to buy into the power of Erlang, or rather, that concurrency oriented programming is going to "win". And with that I don't mean a particular language, but the message passing / actor model sort of approach. Stackless Python, Haskell, Scala, F#, and Go sort of languages.
I continued to read just about anything about Erlang, watch all the various presentations on infoq.com, erlang-factory, etc. and eventually HTML5 and canvas continued to grow in popularity, and lots of JS frameworks for game development sprung out of the ground, that all essentially do the same thing; manage game loops, game entities, collision detection and various other simple game engine aspects.
Print This Post
HTML5 - Canvas Clickmap Test
So, one of the prototypes was to test using canvas to build a clickmap that detects whether a mouse click occurred on a visible pixel, rather than a transparent part of the image. It's one of the techniques presented in the Building a game engine with jQuery that was used in the Google Tech Talk.
I looked at the slides for the code (it's on slide #50). Simple stuff, it needed some tweaks though. The idea is that if the pixel is transparent, the click shouldn't be registered as such. Essentially it means extracting the alpha channel from the image data, storing it in an array and using it to scan for click hits.
And this is pretty much the first step it took for me to get a taste of what's ahead. I'm no stranger to game development, the web, JavaScript, nor the canvas tag, but I was intrigued and curious.
The embedded page on the right with the character sprites (borrowed from Secret Of Mana) is the clickmap test. Try it yourself. Only clicks on colored pixels should register and result in a JavaScript alert.
The next thing I was wondering about is how they'd handle overlapping images, and detecting which one was clicked. The first thought was DOM event bubbling, because the tech talks mentioned heavy use of delegations, but that makes no sense since the various sprites are siblings, and not arranged in any kind of hierarchical way.
The obvious answer is to quickly iterate over all the sprites (maybe optimize with quadtree), do collision check with the mouse click via the clickmap, and give precedence to the top-most element.
So now I need a playground where I can put these sprites. The next experiment will be something map related, how hard can it be…
Print This Post
HTML5 Map Tile test
My next thing was trying to build a simple tile-based terrain. I don't really do graphics, so I borrowed tiles from Zelda. RPGmaker related sites have a ton of tile sets. Some more usable than others.
These tiles are 16×16. I wanted something with dimensions of power-of-two. Just in case this thing escalates into a native client or, more likely, using WebGL. The very first thing is just having a bunch of tags arranged as map tiles.
There isn't all that much going on here. A bit of CSS to define the map tiles along with a snippet of JavaScript to just render a bunch of div tags with random map tiles.
I used CSS to build a bunch of classes, one for each tile in the tileset to minimize the amount of specifications that were needed in the div tags' style attribute. The only thing that I wanted in there was top, left, and (later) z-index. Everything else goes into the class.
I don't even bother testing in IE at the moment. I do the development in Firefox (due to Firebug and all), and test in Chrome (as a best-case scenario test, I guess).
Alright, so rendering a static map is neither hard nor exciting. Having the ability to scroll the thing around a bit would be nice. So that's next.
Print This Post
HTML5 Scrollable Map test
So a few things have happened. I've made a larger, scrollable map. And it seemed I ran into some performance issues when it came time to scroll. Running fullscreen at 1680 x 1050, and having 16×16 pixel tiles covering the screen means nearly 7000 tiles. It's a lot, and it wasn't happy.
So my next thing was to try to build patches. On the client. Seems to work. The level is also no longer randomly generated. It's fed by a JavaScript array.
Print This Post