Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 24, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Limited gaming/development experience for cross-platform HTML5 games.
by Przemyslaw Szczepaniak on 03/18/14 10:35:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


A comment I received recently to my post titled "Where and how can we play HTML5 games?" has inspired me to think about the limitations which developers can run across during the development of HTML5 cross-platform games. The experience created for these games can depend on how developers will use the code and how they will create game mechanisms. In the end, imagination and overcoming a few technical issues are the only limitations, and those have to be kept in mind when developing a game. Having fun with friends who use different devices can be very attractive. The gameplay thanks to the cross-platform feature can happen on multiple platforms and operating systems, but before we start to create a cross-platform game, we need to think about the limitations that we will have on each of the devices we are targeting.

  • The first issue we meet is the input or the steering.

Before developing a cross platform HTML5 game, we need to think about about the gamer's experience and how they will operate the game. For PC's or consoles it is pretty simple. Most games developed for those platforms use a keyboard and mouse or possibly a special input device such as a gamepad, joystick or steering wheel that can also be customized. But for smartphones, tablets or devices running similar OSes such as Smart TV's, it is much more difficult. The touch, tap, or slide features limit the user in steering in a game, and we cannot customize it. The TV controller is also limited in its function. This is a very obvious issue, but it may be crucial to gameplay and game types available. Think about it seriously before creating a prototype, and then test it so you don't run into future issues in the project's development.

  • Testing the games may be difficult.

Creating the game code for many platforms in a multiplayer game can be difficult, especially since developers have to sacrifice extra time for testing and fixing issues for the various devices. It is fairly obvious that the slogan "One code, multiple devices" doesn't really work as easy as it sounds. It may cause extra frustration. I'd like to quote one of Gamasutra's articles "While HTML5 might be designed to run on a wide range of devices, there's still no reliable way to maintain performance across varying hardware specifications". In this article, EA creative director Richard Hilleman said that "On my own computer, which runs on an i7, I couldn't get more than a few frames per second [from our demo]". Futher in the article he explained that "high performance JavaScript is obtuse at best", so it's hard to predict how an app will run on a given hardware specification. For a developer there is a need to solve a lot of problems during the game testing. The variety of devices in your gaming studio has to be really big, and it's not only limited to devices that have the latest system updates or simply the newest smartphones or tablets. Developers also have to think about older devices, the ones who are owned by gamers who don't update their hardware or systems very often. Because of those issues the game may not simply work on bigger part of devices. The same issue occurs with older versions of browsers on multiple devices on various platforms.

  • The speed of the game on various devices requires code optimization.

This may be very difficult, and it is strongly connected with the game testing process because a game can work great on a PC, but the performance on a smartphone can be poor because of the lack of CPU power or memory (or vice versa if a game was designed for a smartphone in the early stages.) It is important to design the game while keeping the technology limitations in mind for various devices. For example, you might create a great game based on WebGL, but it simply will not work on a tablet, or worse will not work on a smartphone. This may sound obvious, but I believe you get the idea.

  • Issues with audio implementation for mobile devices.

Issues may occur with game lags or even the browser crashing while playing. Develop-online posted the words of Chris Herbert, technical lead of Remode Studios, where he says, "... audio is considerably behind the rest of the platform’s features, with problems such as lag and file support", although he believes there could be vast improvements in this area in the future. There are clearly areas of HTML5 that need some work, audio being an area that’s lagging behind quite dramatically, particularly in mobile browsers (...) "The problems mainly relate to how sound data is swapped out of sound channels, many browsers are experiencing a lag, or in some cases jumps or pops (...) Also, the support for audio file formats is inconsistent, with some browsers favouring the ogg vorbis format whilst others – such as Safari – favour the MP3 format." But further in the article, Sandy Duncan, CEO of YoYo Games, confirms that this issue is being worked on, and it just needs time to be fixed. Hopefully we will expect that fix soon, since this is one of the core elements of having fun. It hasn't been the biggest issue for mobile since most HTML5 mobile games don't have sound, but it is not acceptable by players who play those games on PC. It would be great to have same the sound experience for all platforms while playing a game.

  • Big screen vs small screen experience

The difference in screen resolution can be an issue. If for example developers make strategy or rpg games where there is a vast map that players have to move their units around on then there can be a problem. Players with lower resolution screens (smartphones) don't have a chance to react as easily if they need to scroll the whole map to defend their city or send out troops. We may find similar problems with a difference in game design for the different size screens. On the other hand, simple games made for mobile devices may not look as nice on high resolution TV or PC screens, so this would also require a solution. The developers could only consider building the type of games that will not cause a problem for any platform.

  • Multi platform interface

During the start of development of an HTML5 game, developers have to design different types of game content on the screen (especially different user interfaces) for players on different platforms. This can become quite complicated, because every platform will use a different type of screen setup. Yes, it is very similar to resolution issues and for sure it requires planning of the screen setup. This is the moment where UX and easiness of game use comes in, and it is crucial to plan the interface according to the limitations of design possibilities for various devices.


Those issues are not the reasons to give up on HTML5 cross-platform game development. These are just some obstacles that each developer meets during game creation. We have found out already that many past issues with games performance and speed have been solved. Nothing is impossible as long as developers and the companies which create browsers, operating systems, and coding languages find a way to solve some of these issues. Do you agree? Have you found other issues in HTML5 coding and solution you would like to share? I'd like to hear them from your point of view.

Related Jobs

Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Bluepoint Games, Inc.
Bluepoint Games, Inc. — Austin, Texas, United States

Senior Graphics (or Generalist) Engineer
Intel — Folsom, California, United States

Senior Graphics Software Engineer — Hunt Valley, Maryland, United States

Graphics Software Engineer


Lennard Feddersen
profile image
I've just released a playable version of Real Estate Empire 3 which was my first experience with coding an HTML/Javascript/PHP/CSS type game. My results will not be applicable to everyone as REE3 is a turn based game where user events typically trigger a page load. That said, what I have found is:

1. I decided to target a 1024x768 display. Future devices would be a simple port rather than trying to support all devices up front with one code base. This means that I work out of the box on desktop and larger tablets. At this point I'm really glad I made that choice. Now that I'm up and running I don't know how I would shoe horn this design into a smart phone anyhow and trying to figure out scaling for all kinds of devices up front was just wasting time. Going forward I may decide to work with smart phones but, as I mentioned earlier, I will fork the code base and do a quick port rather than try and support all devices at once.

2. Keep it simple. My client server model is that the client provides input to the server where all decisions are made - I think you would have to work pretty hard to cheat at the game right now since the client only provides input to the server logic. I keep a global block of variables that I pass down to the client using PHP's json_encode to write a simple javascript array. A big array of global variables is pretty old school and, for this simple type of game, incredibly productive. The client pages can reference the variable block but never make changes to it. The server reads and writes the variable block to a user unique simple, flat file.

3. I tried the Aptana editor for awhile - the color coding of my javascript was pretty helpful but I eventually went back to my old sidekick of VC++ 6.0 and it's half baked BRIEF editing capability. I use Firebug to debug my javascript and tend to test with Chrome and Firefox open on my second monitor in two windows. I've just started using Komodo this week for local PHP debugging and it just works. I downloaded it, pointed it at PHP.exe and was debugging effectively within minutes - I expect when the 21 day trial is over I'll be a year by year subscription customer.

4. I've not decided how to make money with the program yet. Since it loads a lot of pages over a single play through I'm going to see how beta testing goes over the next month or two and see if I can just keep it free. TBD.

You can play Real Estate Empire 3 at the Rusty Axe Games website - I'd be happy to hear from you (I've got a contact button on the website) about your experiences if you do!

Vladislav Zorov
profile image
Hi, thank you for the great article!

About the first issue, I guess that's only relevant if you're trying to make a traditional PC game run on a mobile device. The game I'm currently making, touches and swipes are not only not limiting, but in fact essential to the game experience - sure, it's playable with a mouse (it's how I debug locally), but it's not nearly as "physical" without the touchscreen. Hitting the ball with your finger is so much more satisfying than the abstraction provided by keyboards, mice or gamepads (or TV remotes).

About the different screen sizes, I'm trying to make everything scalable, so only SVG files and procedural graphics need apply - this takes care of the different resolutions, however nothing can be done about the different physical screen sizes. You just need space to play, and you can't just make everything smaller, because game elements are directly related to the size of the spot a finger (or two) make on the display. My solution? Make sure it's clearly mentioned that the game is ONLY for tablets, and, even though a smartphone may run it, it won't be playable.

About audio, I'm not there yet, but the Web Audio API ( looks like it might be the solution to real-time game audio issues. Sadly it's only supported on iOS's stock browser, which might mean the game will only be playable on iOS tablets and nothing else (although it should also work on Chrome for Android).

In conclusion, I'm actually making a game for the newest-generation iOS tablets, but I just don't want to use Objective C and a Macintosh computer. So, no cross-platform issues here - if anything else happens to run it now or in the future, great, but supporting every possible device and type of device under the sun (especially from a single code base) is not a requirement. Of course, standards are being followed religiously, so as to maximize the chances of that happening :)

Lennard Feddersen
profile image
Vladislav, have you found any browsers that don't support SVG? I've been thinking about some of my graphics and converting them to SVG. There's an online tool that does a credible job on my houses.

Vladislav Zorov
profile image
Lennard, I'm still using debug graphics, but I was kind of assuming it will work, since SVG has been pretty widely adopted in browsers for a while now -

Using SVG in canvas requires the same machinery as displaying .svg files on the web, so if you can view .svg files, you can use .svg sprites - it's just a `new Image()` with a specified width and height (that you set dynamically at runtime), see

Ryan Christensen
profile image
Snapsvg is great for this: Adobe supported and the creator originally created Raphael back in the day one of the first SVG toolkits. Mobile and desktop support for SVG solid for the first time ever:

Bart Stewart
profile image
To a couple of the points raised (graphics and performance), an article a year or two ago at Gamasutra noted that a big source of performance hits is letting the platform do graphics scaling.

Substantial speed improvement came from referencing graphics that are sized exactly for each target platform. I don't know if that's still a factor for current implementations of HTML5, but it was a memorable comment at the time.

Also, nice to see someone else who appreciates BRIEF. :)

Vladislav Zorov
profile image
What I'm doing is allocating a new invisible canvas for every asset as part of the loading code, to which I render the SVG (or oversized PNG) sprites with the appropriate size for the screen. Then each frame is just a canvas-to-canvas copy without scaling, which seems to be very fast (and, of course, the scene canvas is sized 1:1 with device pixels).