Making games is exciting, exhilarating, and hugely fulfilling. Making good games isn’t easy. Making great games that work on multiple platforms is . . . what this chapter is about.

From control methods, to interaction design, to maintenance overheads, this chapter looks at many of the issues and opportunities concerning games made for desktop, smartphone, and tablet.

Case Study: Funfair Freak-Out¹

Scooby Doo Funfair Freak-Out is a game designed and developed for the BBC Television children’s website CBBC, the leading kids’ web site in the United Kingdom. As a member of the game’s development team, it was an honor to work with such cherished and ubiquitous brands as Scooby-Doo and CBBC. Scooby-Doo is a massive favorite with the large CBBC audience of 6- to 12-year-olds, indeed as it was for their parents—and, for some, their grandparents.

The goal was to make a compelling, fun, and engaging game that could be played and enjoyed on desktop and handheld platforms. The desire was for a game that used the classic Scooby-Doo plot devices and that felt like a true interaction with Shaggy, Scooby, Velma, Fred, and Daphne. If we’re thinking classic Scooby, then, zoinks, there can be only one setting—a spooky fun fair (see Figure 14-1).

With any game, major decisions need to be made in the investigation phase and then ongoing throughout the project: What is the game? How does the user play it? How deep should the experience be? How will the the project objectives be achieved using the available technologies? This chapter will look at these major building blocks with Funfair Freak-Out and consider how they were calculated and resolved in a way that delivers to multiple platforms.

Control Method

The first consideration for any game should be control method. How is a user going to input his or her choices into the game? Anything that is a barrier to easy control is a negative. Does the game have five-point control? Make it three. Need mouse and keyboard? Make it a mouse or keyboard. As the controls become more complicated, the number of engaged users will lessen drastically. Surely, maximizing the number of players is an imperative for most games. This is the primary reason for wanting to make a game that will work on multiple platforms.

Want your game to work on as many devices as possible? Then, you will need to come up with a control method that will work well on keyboard, mouse, touch pad, touch screen, and joypad. This is no easy task. A Venn diagram showing great games that work across all devices (desktop, smartphone, tablet, smart television) will have a very small area overlapped by all.

Of course, it is possible to make a virtual joypad on a touch screen that can implement all the clever interpretation features that can be thrown at the system—auto centering to first touch, analogue style “amount” metrics, velocity change consideration for recentering. Yet, one major factor makes this an ultimately poor experience: the user really just has “pictures under glass.”²

With a console joypad, ergonomics plays a huge role in giving the user subconscious information about the position of the controls and how they are being engaged. With a keyboard the user has access to discrete controls. These only afford eight directions, but there is constant sensory feedback. With mobiles and tablets the glass interface gives no positive feedback. This is a big problem and probably the main reason it is really hard to name a great smartphone game with joypad like controls.

An option in the application (app) space for mobiles/tablets is the gyroscope. This can be excellent for certain types of games. On the mobile Web, however, access to the gyroscope via HTML5 is problematic; the inability to lock the browser orientation, the specification for Screen.lockOrientation(), has yet to be stabilized,³ meaning that, in practice, it is inadvisable to use the gyroscope. Also, if a goal is to make a game that will really work on desktop, too, then don’t expect users to be spinning their laptops around.

Taking all this into consideration, big compromises will need to be made, in game design or in the number of platforms on which the game functions well.

With Scooby Doo Fun Fair Freak-Out, we acknowledged the control issues and designed the game to take advantage of them. The school of thought was that the simpler the control method, the better the game experience and the more inclusive the proposition.

The game design focused on how we could get the Scooby gang into a predicament that would allow us to use the very simple controls in a compelling way. We took this to a binary extreme by coming up with a stop-and-go mechanic. Scooby, Shaggy, and the gang are hypnotized at the spooky fun fair.The only commands a player can give are to stop (tap the screen/keyboard/mouse) and to go (release the tap). Everything is then down to the level designs. With big wheels, moving and collapsing platforms, falling crates, zombies, wolf men, ghosts, and Total Wipeout–style boxing gloves, timing becomes everything. The scene now set, we have a game that is a platformer, a constant runner, and a puzzler.

Funfair, rollercoaster, and haunted house zones provide the settings. Each zone has ten levels, with a different monster in each and the need to trap the baddie to finish the zone (see Figure 14-2). Once captured, the criminal is unmasked. All great fun and exactly right for the brand.

To make the game, baseline requirements were necessary:

• Parallax scrolling (horizontal and vertical)
• Up to 50 moving items on the screen at any one time
• Large graphics
• A simple physics engine
• Multichannel audio
• Reach as many users as possible

Performance Testing

Before doing any coding on the project, we ran through a process of performance testing on all our target devices as well as some periphery ones. This allowed us to compare our requirements against capabilities across the board in order to get a general feel for device performance as well as investigate the specific requirements for the game.

Other benchmarking systems are available, but we needed specifically to test different methods of representing graphics, and so a simple bespoke test suite was scripted. The suite looked at Canvas, image elements, div elements, CSS3 animation, and background divs and then tested with scaling for each.

The Scooby-Doo game was designed for kids. Young audiences access the Web, through desktop computers, much more than the mobile Web, on smartphone or tablets. There is a much higher-than-average use of older browsers—meaning those that don’t implement the canvas element.

Canvas should be the obvious choice for any HTML5 game rendering, but with Funfair Freak-Out, potentially up to 20 percent of the audience wouldn’t be reached. A difficult decision had to be made.

Benchmarking told us that DOM rendering would fulfill all our requirements within specification and reach 100 percent of our audience. As time goes on, and the old-browser percentage reduces, reasons for not using Canvas are dissipating. DOM isn’t going away and so will still work, but there isn’t a whole lot of HTML5 about it. Web Audio API and other HTML5 components were still used in the project, but when it came to rendering, we felt it neater to have a single method.

The compromises of going with DOM:

• No rotation of elements—fine on some browsers, a massive slowdown on others.
• No extensive particle effects—all would have to be prerendered.
• No visual effects via Canvas.
• Not really engaging with HTML5 features for rendering.

So long as simple rules are adhered to, great performance can be achieved with DOM manipulation (see Figure 14-4). Key is that virtually every time the DOM is touched, a redraw is initiated.⁴ A tip here is to update only on the condition that a relevant parameter has actually changed.

Interaction Design

Key to any user experience is how intuitive an interface is as well as how responsive. Many mobile web touch-screen experiences feel a little “laggy.” This is likely to be the result of the use of gesture events. For any gesture to be recognized, most browsers need to wait long enough (300ms) to determine if a double tap has been captured.

As a user, when I press a button, my expectation is for an immediate response—300ms can feel like a lifetime and certainly does so in game when timing is critical. Preventing the default action on all gesture/touch events can step around native deficiencies and allow the system to react immediately and under its own volition:

event.preventDefault ? event.preventDefault() : event.returnValue = false;

I have seen in many other games the use of multiple event listeners on a page, one for each button or interactive ED: engines. My preference is to listen for one key press/mouse interaction/touch per page and then interpret that action.

Physics Engine

In making an HTML5 game, it is vitally important that physics is well represented within the experience.

There are a number of solid-state physics engines available that have been successfully used in a multitude of games. However, when we are talking about working in the mobile Web, there can be major problems. The number of calculations required to deliver constrained, rigid body physics isn’t conducive to rendering a game well on a lesser device. The JavaScript game loops need to assign as much of the performance budget as possible to the render cycle; any excessive “juice” being burned by a physics engine could mean constraining your product to use on only the top-end devices and failing to reach as many users as possible.

To mitigate this, in Funfair Freak-Out we employed a bespoke physics engine. In the most basic cases, it is possible to implement physics in a couple of lines of code—apply some gravity to an object’s velocity, and presto. In this case, there had to be a fair amount of sophistication; we certainly required a system that would allow for collision detection, motors, and moving platforms. What we really needed was to minimize the number of square root calculations required in each game loop. A line intersection model afforded that option.

A simple, classic system would be to use bounding boxes. The drawback here is that the scene then has to be constructed out of blocks, lessening the capability of having organic shapes or slopes and slowing down the level design process.

Line-to-line, rather than box-to-box, intersection gave us the sophistication we were after.

By using a combination of linked lists, bounding boxes, lines, and edges, it is easy to draw scenes that feel organic and natural, with negligible processor overhead.

The base primitive object in the system is the edge, a simple connection between two points. A linked list collection of connected edges can form a line. The line has a bounding box. Now, I can move scene actors around with a first pass of looking at the bounding boxes. If and only if a collision is detected does a test run for line intersection (see Figure 14-5). Doing comparative tests using a single point is dangerous. This could allow an actor to fly through a collision without realizing the possibility of an intersection. But, if I take the velocity of the actor, I can create a bounding box around the start and end points. This will never miss an intersection.

So, the system discovers an intersection. Now, the link list is parsed through, and the edges are calculated for line-to-line intersection. The test is simple and works as follows:

• The whole coordinate system is translated to ensure that the actor’s start point is at (0, 0) (see Figures 14-6i and 14-6ii)).
• The system is next rotated so that the actor’s travel is along the x-axis (see Figure 14-6iii).
• The intersection point is then calculated by determining if the point where y = 0 for the edge is between 0 and the translated actor destination point (see Figure 14-6iv).
• The intersection point is rotated and translated back.
• If there is a result, then you have a contact and deal with it; if not, continue with the game loop.

The line intersection physics system has worked very well and is very easy to use when it comes to designing levels. The lines can be drawn onto a scene, delivering an instantly playable sketch of the level.

The system can help performance further with a number of precalculations based on acceleration from the steepness of a slope and friction. These are imparted to connected actors. Every opportunity to take a calculation out of a game loop should be taken. It is important to be a good “processor citizen.”

Audio

There have been teething troubles with HTML5 and audio. The situation has improved drastically in recent times, with more browsers implementing Web Audio API. On most mobile devices it was the case that sound sprites would need to be used—a single audio file containing all the game sounds. The sprite is constantly played, with the playhead being moved to the relevant time point, enabling playback of the required sound. This works to a degree, but when you have put your all into making a great game, the last thing you want is to settle for single-channel audio.

The logical decision path for which audio method to deliver to a user has to favor multiple-channel audio above all else. Funfair Freak-Out implements all three methods, as described in Figure 14-7.

In addition to sound sprites and Web Audio API, a third option is available for desktop: Flash playback. Okay, this sounds like it is going against the grain of open standards, but we are building user-facing products here. The primary concern should be the quality of the final outcome. So, on desktop the ubiquity of Flash and its audio capabilities means that it has to come ahead of sound sprites on the priority list.

Asset Sizes

It is easy to get carried away with adding more and more graphics to a multiplatform HTML5 project. Who is going to argue with a little eye candy? On desktop we arespoiled—the browsers all have a pretty high memory allocation per page. This isn’t the case on most mobile devices. Across the many projects that I have seen, problems have begun when the asset set starts to clock in at more than 10MB. The issues range from full browser crashes to graphics disappearing.

There are many hundreds of operating system and device combinations. Even with extensive quality assurance (QA) testing it is difficult to ensure that any multiplatform game will be 100 percent. With the price point of tablets tumbling, so are the specifications. Rather than the memory problems with mobile web–enabled devices easing over time, they are becoming more acute, necessitating stricter controls.

In Funfair Freak-Out every effort was made to ensure that the assets would be as small as possible. All the animation cycles were minimized. With the character animations, walk cycles were kept down to 10 or 12 cells on the sprite sheet. This maintained enough frames in a second to feel natural without becoming clunky. The simple color palette of the Scooby-Doo animation allowed for the use of the PNG8 format, 8 bit color with indexed transparency. This can typically be less than a third the size of PNG24. For those images that didn’t need transparency, the JPEG format was used to great effect.

Two asset sets were made available to the game: high definition (HD) and standard definition (SD). The HD clocked in at 6.75MB, and the SD, at 3.75MB. The appropriate set was delivered, based on screen size and resolution.

All unnecessary transitions (particularly those that added weight) were removed from the game. From screen to screen, elements were reused in differing combinations within each zone. On very few occasions were assets only used once.

For the audio, everything was reduced to mono and 80Kbps (MP3 and OGG). This still sounded great, and the total weight for the MP3 assets was 886KB, with OGG at 777KB.

Certainly, with HTML5 I have come to the conclusion that pushing the boundaries in terms of memory or processor usage should be avoided when trying to reach the greatest audience. There are many other areas in which to experiment, innovate, and deliver quality.

A further issue that is more user-focused relates to data charges when not connected to Wi-Fi. No user wants to discover a massive bill from his or her service provider. Typically, mobile web games are snackable and casual by nature. This is good; it means that the graphical assets can be scaled back. With projects that I am involved in, we set a 5MB budget and afford ourselves a little leeway. Anything above 10MB is regarded as the “danger zone.” and we definitely don’t want to go anywhere near there.

Interface Design

As device operating systems are upgraded, and updates are applied to browsers, the implicit rules for interface design are changing, and we, as game developers, are continually being required to adapt (we’re mainly talking smartphones here). Simplicity and consistency of experience are key, certainly in relation to button placement, input types, and user journeys. With all web games it is important to lead the player to game play as quickly and as obviously as possible. I’m a great believer in the value of a big button on the landing page that says, “Play.”

With Funfair Freak-Out the character and level selection pages were designed to be “swipeable” via finger or mouse. Supplementary buttons give a choice to those who would rather click or tap through the options. The dual method tested very well with users.

With the browser Google Chrome potentially interfering with play in many games, it is important to design around possible problems. Interface buttons in the bottom corners of a screen will likely interfere with the back and full-screen buttons on iOS devices; too close to the top of the screen, and Chrome could be initiated. These are painful problems that require large exclusion zones around the edge of the screen.

It has been noted in user testing with young children that they will place a device on a table and then lean on the device. Frequently, this will cause the corner of the touch screen to be nudged and input to the device, generated. Ideally, the exclusion zone will deal with the problem areas, but when we are talking about a smartphone, the available real estate is very slight. Heed must be paid to the areas with issues, while hoping that the browser manufacturers don’t do further updates to render your expertly crafted interface a relic.

Maintenance

The very first Flash games I wrote back in 1999 still work perfectly today. They have needed no updates, tinkering, or recrafting in any way. The Flash Player took the responsibility of making its content work on each and every browser. Every HTML5 game I have been involved with over the last few years has required a revisit to fix the audio, the rendering, the button placement, and much more. The need for maintenance and QA is a fact of life now. The proprietary “black box” nature of a browser plug-in was fantastic for backward compatibility. In the Wild West of unstable, un-ratified standards, browser manufacturers will deliver interpretations that are anything but standard. It is the nature of competition to deliver features better than your rivals’—“better” frequently meaning “non-standard.” For my team, delivering games with complex logic and display rendering systems, we need to assign a large fraction of our budget to a maintenance strand just to keep the games live. Typically, the QA budget rate is from 10 to 20 percent per project, with maintenance being the same again.

So, is there a way to insulate games from changes of standard implementation? Frankly, there is no silver bullet. The problems are coming from multiple areas: crossorigin resource sharing, browser behaviors, audio implementation, memory allocation, page embedding methods—the list goes on. As HTML5 game portfolios get bigger, so does the task of implementing a fix across the whole portfolio. If libraries are shared, then there are possibilities.

We are in a space now in which the interesting JavaScript libraries are still in development, and many haven’t even reached release 1.0 yet. This means that backward compatibility can’t be guaranteed. Over the next few years, the ecosystem will settle down, and many of the problems will ease. Expectations need to be managed, and budgets, apportioned to acknowledge the current state of play.

Conclusion

Remember, isn’t the reason we are working with HTML5 so that we can get our games onto mobile devices? It is very easy to get swept along by all the great advances being made on desktop browsers—the extra performance and Web Graphics Library (WebGL) goodness. Those features and possibilities don’t exist as yet in a standard and consistent way across the mobile Web. This doesn’t mean, however, that we shouldn’t still be excited about the possibilities of what can be achieved. With a mind toward optimization and creative thinking, within the technical constraints, amazing experiences can be produced.

On the desktop, Flash games matured to set a very high standard. This level has been carried on in the app space by some fantastic games. Publishers and clients now seemingly expect this quality from every game build, irrespective of language, technology, or platform. These expectations need to be managed; delivering with quality to multiple platforms is a complicated business.

Scooby Doo Funfair Freak Out was launched in early summer of 2013. It was the most successful game launch ever for CBBC, a portfolio that has seen more than 400 games. Now, a game made with HTML5 and JavaScript has reached the peak! This is undoubtedly due to hitting desktop, smartphone, and tablet at the same time and shows the strength of and potential for multiplatform projects.

________________________

¹CBBC, Scooby Doo Fun Fair Freak-Out, www.bbc.co.uk/cbbc/games/scooby-doo-game.

²Brett Victor, “A Brief Rant on the Future of Interaction Design,” http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign, November 2011.

³Mozilla Developer Network, “Screen.lockOrientation,” https://developer.mozilla.org/en-US/docs/Web/API/Screen.lockOrientation.

⁴Minimizing the DOM manipulation – (http://swingpants.com/2012/02/08/html5-game-dev-dom-manipulation-its-costly-so-minimise-its-use/ )