The findings below from these and other recent studies apply directly to our work at Filament Games, and we want to share what informs and inspires us!

Games matter.

There is consistent evidence that games can benefit all students, especially those with the greatest need.

Across 57 studies that compared teaching with a game to using other instructional tools, incorporating a game was more effective (SD .33). Using a game improved cognitive learning outcomes along with intrapersonal and interpersonal outcomes. [1] Researchers looking at other collections of studies have found that games help students retain what they’ve learned. [2]

In a survey by the Joan Ganz Cooney Center, teachers reported that they found games provided the greatest benefit and boost to engagement to lower-performing students. Of all teachers surveyed, 47% of teachers reported that low-performing students received the greatest benefit from games in their classrooms, almost as many as all other categories combined, and 65% reported that low-performing students became more engaged with content overall when it was presented in the form of a game. 55% said that their lower-performing students were more motivated when playing a game. [3]

Design matters.

Although benefits from using games have been demonstrated broadly, the degree that students benefit from a game depends on the design of the game itself, and on the design of lessons that incorporate it into the curriculum.

Across 20 studies in the 2014 meta-analysis by Clark et al., students playing games with design additions informed by learning theory outperformed students playing standard versions of the same games (SD .37). [1] In studies that allowed students to play a game more than once, learning outcomes were significantly higher when students played multiple times, even though many games allow students to practice a skill several times during a single play session. [1,2] This suggests that it is important to choose games that have been designed for learning, and to incorporate them into lessons in a way that gives students the opportunity to reflect and incorporate what they’re learning between gameplay sessions.

Teachers matter.

Teachers are designing the experiences their students will have in the classroom every day. It is up to the teacher to create or select instructional tools and decide how best to incorporate them into their lessons. These decisions have a significant impact on learning outcomes, irrespective of the qualities of the particular tools involved.

While using games can improve learning gains under a variety of circumstances, the greatest gains have been achieved by teachers who surround students’ game experiences with additional support and instruction. The benefit added by games was greatest when the teachers complemented the games with a mix of different surrounding activities. [2]

The whole student matters.

Games support both academic and social-emotional development.

The Gamesandlearning.org project at the Joan Ganz Cooney Center highlighted the results of a recent study in the UK that looked at social-emotional effects of video games. A study of 11,000 students found that video games in general did not have negative emotional or behavioral effects, and did not adversely affect attention. [4] Another study of 5,000 students took a more detailed look at gameplay, and found that students who play games up to an hour a day demonstrated greater social and emotional well-being. [5]

References

1. Clark, D., Tanner-Smith, E., Killingsworth, S . (2014). Digital Games, Design and Learning: A Systematic Review and Meta-Analysis (Executive Summary). Menlo Park, CA: SRI International. Accessed September 10, 2014. http://www.sri.com/work/publications/digital-games-design-and-learning-systematic-review-and-meta-analysis-executive-su
2. Wouters, P., van Nimwegen, C., van Oostendorp, H., & van der Spek, E. D. (2013, February 4). A Meta-Analysis of the Cognitive and Motivational Effects of Serious Games. Journal of Educational Psychology, 105(2), 249-265.
3. Joan Ganz Cooney Center (2014). “Teachers Surveyed on Using Digital Games in Class.“ Games and Learning Publishing Council. Retrieved September 10, 2014, from http://www.gamesandlearning.org/2014/06/09/teachers-on-using-games-in-class/
4. Parkes, A., Sweeting, H., Wight, D., & Henderson, M. (2013). Do television and electronic games predict children’s psychosocial adjustment? Longitudinal research using the UK Millennium Cohort Study. Archives of disease in childhood, 98.5, 341-348. Accessed September 10, 2014. http://adc.bmj.com/content/early/2013/02/21/archdischild-2011-301508.full.pdf+html
5. Przybylski, A. K. (2014). Electronic gaming and psychosocial adjustment. Pediatrics, 134(3), e716-e722. Accessed September 10, 2014. http://pediatrics.aappublications.org/content/134/3/e716.short

The post Research Roundup: Studies Support Game-Based Learning appeared first on Filament Games.

“Alrighty, who’s ready to read my 30-page GDD that I spent the last two days writing?!”

Yeah, me neither.

I’ve seen a number of game design documents get out of hand and become a chore to maintain and read. They end up looking more like a wall of text than a handy design guide. What the team needs is something that’s easy to navigate and takes them to the most relevant info as efficiently as possible. It seems so obvious in theory and yet it’s so difficult in practice.

Now, I’ve written a plethora of GDDs and probably a few hundred supporting documents for them, so I am no stranger to writing out design. I take on a new project every couple months, meaning I get to start from scratch, learn from my mistakes, and try new things often. It also means there’s a huge potential for me to be buried up to my neck in time-wasting writing when I could instead be designing the thing.

I’d like to share some things I personally do to avoid writing a soul-sucking GDD that takes over my life and wastes people’s time.

Starting the GDD

Wiki or a Word doc?
I prefer wikis for the following reasons: – Always current. If I can’t tell if a doc’s the latest version without digging around or asking someone, I die a little inside. – Easy to navigate. All the sections of the GDD are linked right there on the side. The devs can quickly get to any section without scrolling around or remembering page numbers. – Access control. In the rare event that I ask someone else to edit something, I can grant them access to just that section. – Encourages concise writing and division of features. I don’t know what it is about Word, but it tends to steer people toward writing long wordy paragraphs. We’ve given talented designer applicants challenges that include writing a small GDD for their design, and it’s astounding how many are formatted like a mini novel.

Whatever you go with, use a platform that supports writing the GDD in a way that it can be used as a convenient reference, not a book.

Defining Terminology
Once upon a time I designed a game that had missions. It also had warp missions. Then there were levels, which was a group of three missions. Levels were also called stars. Sometimes people called levels missions or puzzles. Whatever, I knew what they meant. No big deal.

Except that it was. By the time I got around to encouraging official terminology for everything we had wasted so much time going back and forth with each other to clarify what we were all talking about it would have been comical had it not been happening to me. Discussing design was like a real life Abbott and Costello skit.

These days I define terms right off the bat before writing anything. Does this game have levels or puzzles? Or are they called challenges, missions, stages, or worlds? Do we call a character’s history a bio or a description? What exactly is a “Turn” in this game? Pick terms and stick with them.

Establishing Ownership
Behold my mantra: “I am the Keeper of the GDD, Maintainer of the Docs, and Holder of the Key to all Editing Capabilities.” To preserve order, I am the only one who edits / adds to / removes from the design docs. It keeps everything in one voice, ensures proper use of terminology, and helps me know exactly what’s in there and where it all is. I serve as the funnel through which the team’s ideas flow into written form.

Same rules apply to massive teams that have multiple designers: establish who is responsible for the writing and make sure those people maintain ownership.

Maintaining the GDD During Production

Start Small
Keep the GDD simple and general, letting it build up slowly as production progresses. Only fill in niggly details after it’s been determined they’ll be part of the game. The game’s design will change a million times so don’t bother wasting words at the start.

Don’t Forget Separate Documents!
I use Google Docs a lot which can be edited live and are always current. They have a revision history, are easily linked to from the GDD, and are often looked at more than the GDD. The GDD doesn’t have to be the documentation’s home, it can just be the hub.

Document All the Text in the Game
I spent 5 hours last week procuring all the text from a couple games because we decided to have it proofread for standard English. It wasn’t all in one place, some of it wasn’t current, and a lot of text was just entered right into the game and never even lived in a document. Shame on me!

If you ever want to proofread your game’s text, do translations, record some voice-over, or if you just want to tweak things, make sure all of it is easily accessible (i.e., you can quickly give the text to someone else at a moment’s notice). Dialogue, tutorial text, descriptions… write it all down and make it easy to find. Learn from my mistake.

As I always say, “I don’t always retro-update my docs, but when I do, I update the in-game text.”

What Not to Do

Everything I avoid.

Don’t Write a GDD if No One Needs It
Not every game needs one. I’ve gotten by with just a one page pitch doc, a set of storyboards, and a list of user stories. Or nothing at all. GDDs are a tool to help designers do their job and provide extended reference for team members who need it. If the game’s small enough it may not be necessary.

Don’t Sort Features by Priority in the Doc
Never have I ever! Design docs are a reference source, not a task management tool. All sections are arranged in a way that makes them easy to navigate. They are never labeled by priority.

To prioritize, I turn all the features into user stories, put them in a backlog, and rearrange them periodically as production progresses. If anyone wonders what’s coming down the pipe, they look in the backlog.

Wordy Explanations are a No-No
I write mainly for the programmer, who just wants something quick and organized. I save the lengthy paragraphs for when I absolutely can’t do anything to avoid it. Use bullet points and flowcharts wherever possible.

The GDD is Not for Communicating New Designs to the Team
Face it, no one actually wants to read your lengthy GDD all the way through and you can’t make them. Going into a meeting, always assume nobody read it. I try to communicate the game’s design through more reasonable means instead.

I talk with my team, show off prototypes, draw on a board, and then at the very end point them to the GDD as a reference for when they need it. Everyone ends up with the same clear vision of the game. When the time comes to start making features, I direct them toward the specific sections they need to look at for each feature.

No Printing!
It’s a lot of paper to waste so everyone gets a copy of something that’s going to be outdated in a few hours. Printing the whole thing means you want to give it to someone to read, which we already know is not an ideal way to communicate design. GDDs are living and breathing beasts, after all. I never do it and no one’s ever asked me to, so there you have it.

Hold Back on Retro-updating the GDD to Match the Current State of the Game
Feeling tempted to go back and update the GDD to match what’s already implemented? I always ask myself first: is it necessary for me to document this? Is anyone on the team going to need to read this in the future? If so, do it. If not, ignore it. Let sections of the GDD die a natural death as features are added to the game, only focusing on the new and important things you need to write about.

These are just a few little philosophies of mine to keep documentation alive and useful. The best advice is to talk to your team and find out exactly what they need and be adamant about maintaining docs in a manner that meets those needs. You will end up with a nice, customized system that works for you.

The post Writing a Game Design Document Your Team Can Actually Use appeared first on Filament Games.

We have a soft spot in our hearts for kids who are interested in learning about programming and game development, and we make it a part of our mission to look for opportunities to give back to our community. In December, Filament Games was invited to participate in Activate!, an annual event designed to give Girl Scouts the chance to experience and participate in various STEM-based activities curated by local businesses, partners, and experts.

The Filament Games team wanted to create something custom for the event that would excite the girls about programming, illustration, and game design. Specialists from multiple disciplines of game development in our studio participated in the project with the intention of creating an activity that allowed the Girl Scouts to make something of their own.

Development on the idea took about a week, and was treated like one of Filament’s own game development projects. Our game designers prototyped an idea and passed it off for an initial design to the user experience team. From there, an illustrator added more art assets, and one of our programmers developed the working game.

On the night of the event, girls started with prototyping their own game idea. Girl Scouts drew themes from a basket and doodled various live-action play screens on their sheets of paper. Topics like “inventions” and “race car” turned out game names like “Speed Build”, “Build a Computer”, and “A Adventure of Magic” [sic]. The girls chatted animatedly to our team and to each other, explaining their game rules and what made their game unique.

Our other activity was built around learning basic programming and used the game that one of our programmers coded. Our game was a special, Girl Scouts-themed avatar creator that not only let girls customize their own avatar, but also use small pieces of code to change elements like hair color, glasses, and their avatar name. The Girl Scouts who played with the avatar creator had questions answered on-site by one of our programmers, Rachel Berkowitz, and were given a printout of their avatar and a summary of the code they used.

“It was inspiring to see young girls getting excited about that moment in programming when you hit “run” and something really neat happens on screen because of your code,” Rachel said. “Remembering how it felt the first time that happened for me and giving them that agency – even in a really small way – was very rewarding.”

If you’d like to try the avatar creator, or if a girl you know might be interested in game design or programming, check out the working game here. To see a full photo album from the event and some of the Girl Scouts’ prototypes, click here.

The post Filament Games Team Inspires Girl Scouts to Code appeared first on Filament Games.

What may not be as apparent are the benefits of game-based learning for adults. Keeping in mind that the average gamer is 37 years-old and has been gaming for nearly 12 years [1], it should come as no surprise that game-based learning can help educate and engage adults as well as children.

Companies are finding success integrating game-based learning into training, on-boarding, and employee development programs. The Milwaukee Fire Department encouraged employees to play Cool Choices, an online card game developed by Filament Games which is designed to promote actions that save money and protect the environment. Through the game, players are awarded points based on the level of impact the action has on energy usage and the environment.

The results for the Milwaukee Fire Department were impressive – the study indicated that engine houses participating in the Cool Choices game used 3.1% less electricity than the same period a year prior, while non-participating engine houses used 3.5% more electricity than the same timeframe the previous year [2].

Overall, players that have participated in the Cool Choices card game have saved more than $730,000 annually and avoided more than 7.5 million pounds of annual CO2 emissions [3].

Game-based learning isn’t just for the classroom. Incorporating game-based learning into corporate culture can lead to benefits for both the employee and the organization. Visit the Cool Choices website to learn more about the game and its impact on the Milwaukee Fire Department and their employees.

1. Brink, J., (2012, May 7) Game-based learning for the corporate world. Retrieved from http://www.trainingmag.com/content/game-based-learning-corporate-world 

2. Milwaukee Fire Department (2014, March 20) Impact of Cool Choices Game on Milwaukee Fire Department Electricity Use Memo. Retrieved from http://blog.coolchoices.com/wp-content/uploads/2014/03/Memo-Impact-of-Cool-Choices-Game-on-Milwaukee-Fire-Department-Electricity-Use-3.20.14.pdf 

3. Cool Choices Retrieved from https://coolchoices.com/#about-us

The post Cool Choices: Game-Based Learning Benefits Adults appeared first on Filament Games.

More than 50% of survey participants indicated that digital learning games are used weekly or monthly for teaching purposes. The most common use for digital learning games in the classroom is to cover mandated content as opposed to teaching supplemental material.

The survey also showed that the majority of teachers believe games are effective for motivating students, helping reinforce previously taught content, providing useful information about student learning, and teaching new concepts. In addition to teaching content, games are being used as formative assessment tools.

The A-Games study revealed that 34% of teachers use learning games on a weekly basis for formative assessment and 13% of the time for summative assessment. Learning games as formative assessment tools are used more frequently in self-contained classrooms (42%) when compared to subject-matter only classrooms (28%).

Game-based learning is growing and its role in the classroom will evolve as teachers become more comfortable using digital games as teaching and evaluation tools. The game-based learning question has shifted from “if” games will be used in the classroom to “when.” Check out the resources below and make sure you’re ready to harness the power of game-based learning.

Resources:

A-Games Study 
What Makes Great Learning Games?
Research Roundup: Studies Support Game-Based Learning

The post A-Games Study: How Teachers Use Digital Learning Games appeared first on Filament Games.

Good learning games aren’t designed just for fun; they are designed to teach students predetermined learning outcomes. A case study on the game Backyard Engineers shows how learning games, used in conjunction with other classroom activities, can increase student learning.

Download the case study to learn more!

The post A Case For Learning Games: Measurable Results Seen Playing Backyard Engineers appeared first on Filament Games.

Children have small hands.

A phone is a tablet to a child, and a tablet is a TV. What’s comfortable to me may not be comfortable to a kid sitting at a desk.

At the first school playtest I attended, I watched a child lay her test phone down on her desk and tap at it like she was hunting and pecking at a keyboard. The game required dragging from the top of the screen to the middle of the screen, and her thumbs couldn’t reach when she held it in two hands. That feedback helped the development team make the decision to change the game layout so that players now drag from the bottom of the screen to the middle of the screen.

Children have a small vocabulary.

We develop games for many age groups, so it’s important for me to know what children’s vocabulary capabilities are at various grade levels when I’m checking text in a game. For instance, a game aimed at first graders needs to be deliberate in its wording, because first graders probably can’t use context clues to figure out unfamiliar words. Writing content that is appropriate for the age group is the game designer’s responsibility, but QA plays a role in checking those words to make sure a child can understand and interpret them.

Children may never have seen a controller.

This is probably the hardest part about testing learning games. I’ve been playing games for almost 30 years. I’ve played games of every imaginable type and on any platform you can name, so I can pick up any game and understand what I’m supposed to do within minutes. Children do not have the same benefit of experience. I have to approach a game as if I’ve never played that game—or any game like it—before. If a tablet game has a virtual controller, I need to approach the game as if I’ve never used a real controller before.

Of all these considerations, the most important thing a tester of learning games can do is to watch children play and get a better understanding of their perspective and their tiny hands.

The stakes are high for testing these types of experiences – a child who doesn’t know what to do next or is struggling to read the tutorial text is distracted from the game and less likely to connect with the material. When testing from the perspective of children, QA needs to identify these problems so that designers and developers can fix them, allowing kids to play a game that feels like it was made for them.

The post Quality Assurance and Learning Games appeared first on Filament Games.

I would argue that this is a skill, not just something that happens naturally when a team comes together. Scratch that, I know it’s a skill because I used to be bad at it, back when I was a wee designer. Nowadays, I’m proud to say that the teams I work with have enthusiastically shared how pleased they are with the amount of ownership and input they have with each game. It’s positive feedback they’ve given on multiple occasions, so it’s a very big deal to them.

Like any skill, there are actionable things we as designers can do to maximize our team’s creative input. These are a few of the techniques I use, and I apologize if some of my action items don’t translate well to your own workplace environment. The point is that we’re actively thinking about these things!

Include team in early design discussion

Designers need to get their team member’s input early in design. A team member is pretty much anyone who will be working on the game (sound, interface artists, programmers, etc). They should all get a chance to see where the game is in the early stages because they may have radical ideas that steer the whole design in a better direction. Their input is valuable.

In my workplace, there is generally a period before production where most of the work falls on the designer’s shoulders. It’s usually me doing this by myself while my future team finishes up another project. I’ve found that there is a sweet spot during this time where I’ve designed enough of the features to be able to pitch the game to them but still haven’t fleshed everything out yet. It’s when I reach this magic moment that I rally the troops to get feedback before wasting my time on taking the design further.

I suggest gathering this kind of early feedback in small increments with a few team members at a time. Any more than that and you risk opening a door to a full-blown design jam situation with too many cooks in the kitchen. This is a time to probe for ideas, not to make everyone else do the design.

Leave problems for the team to solve in your designs

When you design a feature, think about what parts of the feature your team would be able to design better. If you want your game to have a system for collecting and managing inventory objects, for example, don’t come up with the specifics of exactly how the player adds, moves, shares, and deletes objects in their inventory. Let your interface designer solve that problem.

Ways to do this are to make sure your user stories and feature descriptions are worded in a way that leaves the method of implementation up to interpretation. Compare the following user stories:

“As a player, I can share an object in my inventory with another player by dragging it out of its slot and placing it over the other player’s character.”

“As a player, I can share an object in my inventory with another player.”

Which story do you think leaves room for your team to come up with creative ideas and solutions for the feature? The second one gets across the functional design of the feature without putting a solution in the story title itself. Feel free to leave suggested solutions to a feature in its description, but don’t word things in a way that immediately limits everyone’s ideas.

Don’t leave too much for team to design

This is where some balancing comes in. Don’t leave things so open that others are pretty much doing design for you. If you’re leaving certain things for a dev to design, ask yourself “Is this a unique issue that this person is more qualified to solve than I am?” If it’s not a resounding ‘yes’ then design it yourself. Remember, you can always fully design things and still leave the user stories worded in an open way so that others can step in if they feel so inclined.

Don’t leave too little for team to design

A quality team is one where everyone feels responsible for making the game great. Everyone wants opportunities for their ideas to shine, and we as game designers have a lot of control over this. If your designs and demeanor all lean towards shutting others out from making decisions then the quality of the game will suffer in the end.

Approach spontaneous design discussions with solutions to the problem

If you have to involve others in solving a problem, it’s always good to come up with some solutions on your own before hand. Otherwise they may perceive you as leaving too much design up to them and as incapable of solving problems on your own.

This has happened a couple times to me where I saw my inclusion of the team in problem-solving as a useful thing, but because I left it so open and didn’t have my own ideas to pitch at the start they got worried that maybe I couldn’t handle design on my own. Total opposite of what I wanted! Nowadays I approach the team for design help when I already have some options for us to discuss. It also keeps me from wasting their time.

Be open to accepting and implementing feedback

It’s common as a designer to be approached by others who thought of something cool or had an idea they want to discuss with you. Give them your time and let them know you’re listening. Never shoot down these ideas, and be honest if you say you’ll consider it or get back to them. Then follow through. Even if I’m not sure about including someone’s idea into the design, I always write it down somewhere so that I can reference it in case it’s useful later.

Have frequent one-on-ones

If you have an open office where you sit near your team and use scrum, you’re probably already having lots of conversations with your devs. Take the time to approach them individually outside of dedicated discussion times to give them an opportunity to share with you what they’re struggling with and ask questions / share ideas. Some people won’t open up to you unless you approach them yourself and give them the opportunity to. I have found that stopping by people’s desks just to chat about what they’re currently working on has produced tons of valuable feedback and cool suggestions that otherwise would never have seen the light of day.

These are all simple things that a designer can do to make sure the team feels listened to and included. I can promise that you and your games will not be worse off for actively making sure the team has a role to play in the design of a game. I never got a whole lot of feedback from my teams early on in my career when I wasn’t so good at this, but I got a heck of a lot of positive feedback from them after I made these changes. So give it a try and see what happens!

The post The Balancing Act: Including Others in Your Designs appeared first on Filament Games.

Though it may not seem obvious at first, there are significant differences between creating learning games and entertainment games. Not only must developers add in specific learning objectives, the business models are fundamentally different. Most companies in the game industry are focused on making the next big hit and success is a blessing and a curse.

In the games for entertainment sector, the business case for turning a single hit into a franchise is so seductive that you will be making the same game for most of your career. Consider the developer Bungie who developed the hit title Halo. After Halo’s success, Bungie spent the next nine years making more Halo games, eventually Bungie split from Microsoft with undertones that “Apparently MS just wants Bungie to make Halo for the rest of their natural days.” 

Ironically, Bungie’s first game since Halo is Destiny, yet another futuristic first person shooter that has a 10-year franchise plan. In contrast, Filament is never going to create a franchise or build sequels to teach the same learning objective. There is an endless and diverse amount of content to pull from that keeps the creation of learning games novel.

My favorite rule from school was that you are allowed to build whatever you want, but no shooting violence. The reason was because it stifles creativity, it is too easy of a mechanic to use without really thinking. It is much more challenging and interesting to build a game that has never been made before. It is also more risky so there are not many opportunities to make completely new experiences.

Filament’s development model is composed of many small teams and it is highly desirable to work on small teams. The big blockbuster game titles have multimillion dollar budgets and often teams of more than a hundred people. Developers on those teams end up with very specific roles. You would only work on animating, networking, artificial intelligence, or perhaps an even narrower subset of a discipline and it is incredibly difficult to transition to a different role. In a small team you are exposed to every facet of development, it keeps work interesting and is better for your career.

My first big break into the games industry was on a big team with the focus of working on user interface. It was a fantastic experience, I still enjoy working on user interface, it is the magical veil between the game world and reality. Despite having other skills and interests, I could only get return calls from hiring managers for the same niche role on other projects, of which there were few options available.

Most game development has to address ‘the content problem’ at some point. The content problem can appear in several different flavors; predominantly it materializes as the rate the studio can produce more of the game space (levels, worlds, environments, stories, missions, etc), or the speed at which the player can progress through the game (if too fast you have to produce that much more content – which creates the first type of content problem, if too slow then your experience can turn into a dreaded grind). Learning games still need content; however, we are overjoyed when players quickly progress through the experience because it equates to mastering the learning objective.

Games made purely for entertainment value attempt to create a space where the virtual world draws you in and you become more invested, interested, and excited about the potential experiences in that space. Learning games flip that paradigm and inform, inspire, and drive passion about the real world. There is still a large amount of overlap between conventional and learning games; both have the same essence of engagement, feedback, challenge, and desire to be the best part of someone’s day. The added potential of real world impact is incredibly fulfilling and is why Filament is involved with organizations like Games For Change.

The creative culture at Filament is composed of a variety of content and work that inspires us, as employees, to make a positive impact on the world. When we craft an experience it is our goal to make learning engaging and to spark interest in the subject long after the game ends.

The post Why Build Learning Games? appeared first on Filament Games.

A Checkered Past

There were two prominent statements made in November 2011 about the state of HTML5 game development. Zynga’s head of HTML5 initiatives said “audio is still broken” and “if you look at the demo scene today, it reminds me of the Flash demos in the ’90s.” EA’s creative director lamented “high performance Javascript is obtuse at best” with wildly varying results across hardware. At the same time Adobe announced that it was no longer going to develop the Flash player plugin for mobile devices. Early adopters of HTML5, including Facebook and LinkedIn abandoned it and returned to native apps. It was clear that HTML5 was going to be the answer for cross platform development, but it wasn’t quite ready yet for games. In April 2014 Microsoft ended support of Windows XP and with it Internet Explorer 8 – it was at this point Filament Games revisited HTML5 as a platform for game development.

The Current State of HTML5

The promise of HTML5 is applications that can run on any device with a web browser, an idea referred to as “write once, run anywhere.” It is an inherently complicated platform as some browsers only have partial support of the standard and implementation varies. You still need to be knowledgeable about the differences between Chrome, Firefox, Internet Explorer, Safari, Android, as well as the past and proposed future versions of each browser.

HTML5 is just a framework – a core set of essential technology that gives us the capabilities to build rich content. There are two ways to render content DOM versus canvas and you have to very strategically pick out a suite of software layered on top of that core.

What Devices Does Filament Support

There is significant diversity among all devices, and choosing HTML5 as a platform implies your goal is to reach as many devices as possible. The performance of your application is absolutely critical to reach into the phone and tablet market. In the industry we refer to the least common denominator as the “minimum specification” machine or “min spec” for short. Filament Games typically targets the iPad 2, iPad mini, and comparable android devices for min spec HTML5 machines. In addition to the disparity of performance, design accommodations need to be made so that touch interfaces feel as good as using a mouse, and the wide array of potential screen resolutions need to be elegantly supported.

The browser and hardware market shares are public information. Here are browser examples from venturebeat and w3schools and the current tablet market from statista. While general geographic market share is easy information to find, some markets data like school device adoption can be dramatically different and harder to acquire. While HTML5 works on all browsers, the tough problem is identifying the oldest version of a browser to support and navigating the technical implications of going back one more version. The min spec device / browser version is a critical issue to address as it directly affects the capabilities and capacity of the project as well as the cost of quality. This is what Filament Games supported at minimum in our latest HTML5 games:

• iPad 2 / iPad mini running iOS 8
• Nexus 7 / Galaxy Tab 10.1 / HP Slate 10 running Android 4.3
• Internet Explorer 9, Firefox 38, Chrome 43, Safari 6 (the previous 2 versions of each major browser)

How Does Filament Support That Hardware/Software

Though the HTML5 standard can be conceptualized as a list of features all browsers should support, not all of the standard is finalized, and browsers can still decide how to implement those features (performance can vary across browsers). The older the browser, the fewer of those features are supported. We frequently have to reference websites like caniuse or examine compatibility tables on MDN. Any holes in support or deprecated features in browsers lagging behind the standard need to be patched with what are referred to as polyfills.

It is important to note that backfilling support is just as important as looking forward to where the standard is going. Some things as basic as keyboard support (specifically for virtual keyboard on mobile) and requestAnimationFrame (how we request draws of the screen) needs programming to wrap varied support with fallbacks when there is no support. Vast lists of polyfills exist to support as much as possible.

Audio support is tough cross-browser issue; Internet Explorer still uses the HTMLAudioPlugin when most browsers use the WebAudioPlugin. The difference is so extreme that we use two completely different strategies to deliver a rich audio experience. The difference in plugins is compounded by the fact that Internet explorer has a limited amount of sound files that can exist in memory. This limit is particularly crippling because the HTMLAudioPlugin uses audio tags, which means each sound file is linked to one reference in memory. Internet Explorer can only playback one instance of a sound per sound file. In order to support Internet Explorer, we group some sounds into audio sprites, stream sounds that play infrequently where latency on playback is acceptable, and unload sounds when possible.

Filament’s Technology Stack

Incorporating and managing all of the software required for HTML5’s full potential is a job in itself. We use Node.js’s npm and bower as package managers. We use these tools to encapsulate and sync source code to specific versions. As a studio we went with rendering to the canvas and leveraged our existing Flash expertise with CreateJS libraries. Based on past experience writing large Javascript projects, for more robust and scalable code we went with Typescript. All of our external data is stored as JSON.

At this point we examined several HTML5 game engines that supply the rest of the traditional game making logic, including Turbulenz and Phaser. Ultimately we wrote our own support for data structures, geometry, animation, sound, and other things typically available “out of the box” on other platforms like Flash and Unity.

What Sets Filament Apart

This is the nature of the platform, and there are similar stories told by other developers. Everyone has to address these issues, Spil Games, intolabs, and previously mentioned turbulenz all share similar insights on the same tough problems. Filament’s vision of the HTML5 platform is reaching as many devices as possible, and what sets us apart is our expertise in performance. It is surprisingly easy to make a game that will not run on a tablet. Turbulenz has some gorgeous games dedicated to their vision of high end HTML5 games, but at least in the case of Save the Day it does not load or is unplayable on various iPads.

On most devices and browsers we have tools to analyze memory usage and profiling to diagnose issues with framerate, iPads do not have these tools. It is true that there are iOS simulators available that run on Apple laptops which is useful for debugging, but not for insights to maximize the performance of specific hardware. Ultimately we had to resort to testing on analog devices with better tools and tedious black box testing on iPads.

Memory Considerations

Our min spec machine has 512MB of RAM, which sounds like a reasonable amount. That 512MB includes the memory required to run the operating system, the browser, and anything else that happens to be running on the device. Javascript is a great language, but it is not as optimized as other languages. We had similar results with intolabs, the layers of Javascript (CreateJS, polyfills, jQuery, hammerJS, etc) required to make the platform viable takes roughly 100MB before any game development even starts.

There are several generic concepts that we used to work within this constrained environment. We reused objects as much as possible (static memory, free lists, object pools, etc), and had designs were games could have sections unloaded from memory. Designs also included modular art assets to minimize the overall art memory footprint. Allocating artwork seemed to have extra overhead and in some cases we created art assets ahead of time and distributed the creation over time to avoid memory spikes.

Something specific we discovered was a secondary memory limit for textures on iPad and similar tablets. Roughly, there appears to about 7-8 pages of 1024×1024 of active texture memory; exceeding this amount has performance implications.

Some of Filaments earliest HTML5 projects involved converting children’s books from Flash to HTML5, which gave us a lot of insight into render speed and memory since it was almost completely art with minimal programming. Despite all the artwork of a book fitting in memory, interactive pages suffered significantly until we restructured the project to keep minimal art in memory.

Rendering Considerations

The canvas renderer is very simplistic. By default the canvas object clears the entire screen and redraws everything every frame. There is no clipping or occlusion culling, every- part of every visual object is drawn. There is also significant cost for each individual draw call, so many small and simple objects can still be very expensive to render.

There are many ways to draw fewer objects or draw less often. IBM outlines some of the popular strategies of layering canvas elements redrawing the foreground and background less frequently, and covers the beginnings of writing your own renderer with redraw regions (redrawing only part of the screen, which is common in many 2D systems including Flash).

At Filament we took a slightly different approach. Our strategy to draw less relied on extensive caching. Caching flattens an object into one texture (sometimes referred to as baking) and instructs the renderer to not redraw it. Cached objects can still be moved, rotated, scaled and otherwise transformed, but the tradeoff is that it is a large memory allocation. Display objects still need to be structured in groups and require extra programming to manage when they need to be redrawn; however, art and design can iterate quickly since the source material is still in pieces. Our goal is to render 50 draws or less per frame, and a similar rule of thumb exists at other studios.

In addition to removing vector art from our content pipeline, no texture had a dimension greater than 1024 pixels and any key frame animations were converted to spritesheets. Key frame animations would not play smoothly on min spec devices, at least on their first play through. The necessity for spritesheets, combined with a max texture size of 1024×1024 and a limited number of those textures allowed, created a limited animation capacity.

Conclusion

HTML5 development implies operating under heavy memory and rendering constraints which requires extensive optimization and insightful design. For a developer new to the platform there is a large investment upfront to write support from scratch and research javascript libraries. We are excited to see browsers continue to improve, and at this point our view of HTML5 is that it is a very capable platform but time intensive to develop at high quality.

The post Getting the Most out of HTML5 appeared first on Filament Games.