Games in HTML5

5 Essential Practices for Building HTML5 Games… in Action!

HTML5 is great because it’s versatile, it’s not geared towards a specific use case. The most important thing is that HTML5 is universally usable. It’s on the PC, on the phone, on the tablets… and for all I know, one day we could even have it in household appliances.

Putting these two properties of HTML5 together – its versatility and its universality – we can clearly see why many developers are inspired by this technology. And as the proverb goes, “when developers feel inspired, they usually get to programming games” (okay, I may have changed that a bit).

Luckily, game development for this platform is now widely available. But instead of that, I’d rather give here a brief introduction to those things that we should keep in mind before we start programming games with HTML5 and while we’re working with them.

What can you learn in this article? I’m going to talk about game development environments for HTML5, how we can reach a lot more people by supporting smartphones and tablets, how we can advance game state control, how to solve performance issues and how to get the most out of it. to this gaming platform that is your browser.

So without further ado, here are the 5 must-have best practices for making games with HTML5, in action! (this “in action” is to add some more drama).

Good practice 1: use an environment

Writing simple games in HTML5 is easy, but if we want to get any further, we need to do certain things to ensure that the game will work correctly.

For example, when we use a lot of images, sound effects and other resources, the browser can spend a long time downloading them from the web server. If you do not take this into account, you may be in for a surprise when programming the game, because image and sound files are loaded asynchronously, the Javascript code starts executing before all resources have been downloaded. This often results in a “popping” effect (images appear as empty boxes) and sound effects don’t work as they should. A good way to solve this effect is to create a preload routine that delays the execution of the script until all the files are already downloaded.

Another problem that you will surely have is that on each machine, or even in each browser, the same game works at a different speed. While it’s true that we can hardly do anything here, we can nevertheless make sure that animations and movement speeds are independent of the frame rate per second at which the game itself is running.

There’s definitely a LOT of codebase that we have to put into the game to make it work well. But don’t worry: you won’t have to write it yourself. There’s a whole family of environments that let you focus on business logic without having to deal with all these little (or big) things that are needed to make the game run smoothly.

The only downside to using an environment is that there are so many to choose from. Some frameworks, for example, are designed to help solve practically all aspects of the game development process, while others, such as, are mainly oriented towards the graphical part of development. In the end, it is your decision to choose the environment with which you feel most comfortable. This may seem like a trifle, but in the world of Javascript, choosing an environment often means adapting to a particular programming style.

ig.module(
monster
)
.requires(
‘impact.game’,
)
.defines(function(){

Monster = ig.Entity.extend({
eyes: 42
});

});

A good example of what I’m talking about is ImpactJS, which not only provides us with abstractions to display graphics or play sound effects, but also incorporates its own object model and inheritance, as seen in the code above.

Ascended Arcade has published three games in three months using the ImpactJS environment.

Although there are many HTML5 games today that are based on one of the frameworks, many developers are still toying with the possibility of doing it all themselves. While it can be considered a great learning opportunity, if you want to finish your programs in a reasonable amount of time, using an environment is certainly the best way to do it. As an example, take this excellent work that has managed to publish three excellent (and recognized) games in just three months, with the help of the ImpactJS framework.

Good Practice 2: Be aware of small screen and touch devices

Possibly one of the strongest selling points for HTML5 is that it works on desktop PCs, laptops, tablets, and even smartphones (if you haven’t seen IE9 running on a Windows Phone 7 Mango yet, ).

This unique cross-platform capability (think of this word in the RAE dictionary now, please!) is intrinsic to HTML5 and generally requires very little adaptation work on the part of the developer. However, there are a couple of things that we have to keep in mind…

First and foremost: Screen sizes vary enormously between different types of devices, as do resolutions and display formats. If we want our HTML5 games to work well on mobile devices as well, we need to make sure that they support multiple resolutions or that they don’t exceed the window size of WVGA displays (800×480 pixels).

Also, since most mobile devices have too small a screen to be able to see the entire web page at once, they often offer very sophisticated screen zooming and panning systems that can be counterproductive when playing games. These features can be disabled by program using the . The following block of code makes the viewport of your games occupy the entire horizontal surface available on the screen. By setting the “user-scaleable” parameter to “no”, we tell the mobile browser to disable the zoom option, which often causes a lot of problems with in-game controls based on moving your fingers across the screen.

content=”width=device-width; user-scaleable=no; initial-scale=1.0″ />

Once we’ve verified that the game renders well on small screen devices, let’s give some thought to data entry. Most touch-type devices have a virtual keyboard, but it tends to take up quite a large area of ​​the screen, making it an unhelpful alternative to controlling characters and figures in games. If strictly touch-based input is a must for your game, you’ll need to develop a stripped-down virtual keyboard that contains only the buttons needed for your game (for example, the arrow keys). However, it is best to be a little more creative and prepare other alternatives to control the game that do not require adding more elements on the screen. A good example of this is the game , where you drive a car with one finger (something we shouldn’t try in real life).

Good Practice 3: Auto-save player progress

With features like the , browsers try to give web applications the same status as normal desktop applications already have. However, the idea of ​​websites running as applications is relatively new, as is the notion of web pages that save client-side state. You think twice before closing an instance of Microsoft Word, but you probably don’t have as many precautions when you open a web page. Most of the time this is not a problem, since almost all web pages either do not take state into account, or keep log information on the server.

Web browser games, however, are a slightly different case. Since the JavaScript code is executed on the client side, HTML5 games typically keep state information within temporary memory (ie RAM). You close the browser window and that hard-earned score is gone forever.

Now you can argue with me that a sensible person would be careful not to close the game they’ve been playing for eight hours, but… crashes happen too, especially when you have multiple tabs on the screen or when your batteries go crazy.

In summary: when programming games for HTML5, a must-have good practice is to save the level of player progress every so often and let players recover the game in the same place when they reopen the web page they They have previously closed.

Now where do we have to save the game state? In the past, the obvious place was a server-side database, or a client-side cookie. None of these options is very attractive. If we follow the server-side alternative, HTTP requests must be executed whenever the stored information needs to be saved or retrieved. The cookie strategy greatly limits our workspace and the longevity of the cookie itself depends to a large extent on the browser settings.

A much more practical solution is to use the . DOM storage allows us to store several megabytes of data per website using an interface that closely resembles those used to store key-value pairs (or the Javascript expand object). It’s very convenient, but in the context of HTML5 games, it would surely be nice to be able to save complex data structures, something that DOM storage doesn’t natively support.

Luckily in this case, current Javascript implementations have built-in mechanisms that allow us to serialize objects into a well-known compact notation. With this technique, the DOM storage can also be used to store any information we want. The following two functions show how game state can be saved and retrieved later using DOM storage and JSON functions built into ECMAScript5:

function saveState(state) {
window.localStorage.setItem(“gameState”, JSON.stringify(state));
}

function restoreState() {
var state = window.localStorage.getItem(“gameState”);
if (state) {
return JSON.parse(state);
} else {
return null;
}
}

Good practice 4: Use a profiler

One of the most difficult challenges when developing a game is being able to maintain high frame rates per second as we add more…