Designing Games for the Classroom: Technical Considerations

You’ve built a beautiful game. You’ve tested it, kids love it, and teachers can’t wait to use it. Then one day, you bring it into a classroom — your child’s classroom — to show what you do for a living. Your kid is beaming with pride. The students open their Chromebooks. You hold your breath.

And then it happens. The game takes forever to load. Half the text is too small to read. Those beautiful animations — the ones that looked perfect in the lab — are glitching like crazy.

Field Day’s studio director, Sarah Gagnon, knows this from experience. That’s why she works closely with lead developer Autumn Beauchesne to make sure the games they make aren’t just beautiful, fun, and educational — but actually work in the real world: in real classrooms, on some of the cheapest laptops ever made, with the worst screens and the glitchiest internet connections imaginable.

“Part of what enables us to make games that run well in classrooms is thinking about the context that the game takes place in.”

-Autumn Beauchesne

Autumn spoke about this at the 2025 Play Make Learn Conference, as part of a Field Day presentation about Ten Years of Making Learning Games: What We’ve Learned (and What We’d Never Do Again). As Field Day’s lead game engineer for over a decade, they’ve coordinated requirements, technical specifications, and artistic possibilities — all within the constraints of audience, classroom context, and budget.

To make games that run smoothly in classrooms, Field Day builds most of its projects in the Unity game engine . Over the years, Autumn’s team has also layered in custom code modules for anonymous player login and event logging through Field Day’s Open Game Data infrastructure, helping researchers and educators learn from real classroom play. “Unity provides a skeleton, and we build on top of that to develop our games,” explained Autumn. “It also means we are able to easily share these modules with other game researchers and developers working in Unity.”

It is a challenge to get the balance between the visuals of the game, the download size, and the overall performance. If we want kids to play the game and have a meaningful experience, that's what we have to do.

Designing for the Classroom Context

As in any design framework, it is critical to consider the audience you are designing for.  When building games for classrooms, they need to be suited for that context.  Games need to run on the devices the students are using, meaningful gameplay needs to fit into classroom time, and network environment constraints have to be taken into account.  Additionally, not all students will have experience playing games, nor will they all have access to headphones.  Key design questions to ask are: Where are people playing the games? When are they playing them? How long are they playing them? Why are they playing them? What kind of devices are they playing on? 

Field Day specializes in building learning games for fourth to twelfth grade students.  “Part of what enables us to make games that run well in classrooms is thinking about the context that the game takes place in,” said Autumn. “We try not to think like gamers.” Not every player in a classroom is fluent in gaming so we make sure they work for players who are less familiar. Field Day makes it a point to do in-classroom playtests to watch students play games.

Timing for School settings and the Importance of Player Codes

Classrooms run on bells. A good educational game needs to fit into a 30-minute period — and still leave students feeling accomplished when the bell rings. The important thing is that those short sessions still have to be productive. “You can't just take a game that is a 2-hour continuous play, and then say, alright, chunk it up in 30 minutes,” said Autumn, “unless you're considering what is the player going to accomplish, and are they gonna feel satisfied within a 30-minute session.”

It is also important to have player codes that allow players to both start and resume the game later on.  While many players use the same device for their entire playthrough of a game, not all of them do. Plus, a code means the student can pick up the game outside of the classroom. Codes also ensure that any data collected during gameplay remains completely anonymous – and as a bonus, that sessions can be connected.

High-Use Access in Low-Bandwith Network

With 20 or 30 people all loading the game at once, it may take several minutes for the game to boot up and render on the screen. “Network bandwidth is pretty limited,” said Autumn. “If you're one person playing the game on your home Wi-Fi, that's one thing. If you have 30 students playing the game and loading it all roughly at the same time and there are many other people in the building also accessing the network for other activities, that's going to slow things down.” 

The Field Day team has found the best option for getting games into the classroom is designing games to minimize download sizes.  Students access games via web browser. HTML5 is universally supported as are WebAssembly and WebGL. This means hard choices on graphics, resolutions, textures. “There's a nice tool we use called PNGQuant for that, which handles compression so that an image looks almost identical but takes about a quarter of the space,” said Autumn. Not all images can be run through this process - particularly those with subtle gradients - but it goes a long way to reducing the download size. 

Another constraint: the games have to be playable without audio. That doesn't mean that Field Day doesn’t focus on audio for the players that do have that capability, but for students that do not have access to headphones, can't play with headphones, or may be hard of hearing, they build in captions or subtitles. “The game still has to be playable, and more than playable, it still has to be engaging,” emphasized Autumn. “So, that means we can't just play a sound to indicate something's happening. It's good to have some sort of visual component.”

Designing for Chromebooks (and Other Low-Power Devices)

In general, students are using Chromebooks.  Some of the design constraints to consider when working with players using Chromebooks include limited capability for number crunching and intense simulations; limited graphics bandwidth; low contrast and resolution as well as screen color variability.  Small text is a big problem.  “Just based on the fact that students are playing games in a browser and may have several toolbars and things like that, really reduces the amount of space we have available on an already pretty limited resolution,” said Autumn. 

The Unity editor does not provide an internal way to simulate a Chromebook.  This means that testing on a Chromebook is a necessary part of building any classroom game to check screen loading, targeting frame rates between 30-60 FPS, and working to eliminate frame spikes and excess memory pressure.  

Balancing Beauty and Performance

The goal is to build beautiful games that run well on underpowered Chromebooks in limited network bandwidth settings.

“We want to make sure our games showcase beautiful artwork,” said Autumn. “We have a lot of 2D art, nice animations…stylized, but detailed, believable 3D environments, and we want to make those run on a Chromebook. And we also want to make sure that games are not wasting battery life.”

Of course, managing all of these goals requires a lot of compromises. And educational game development requires a lot of additional compromises about learning goals and standards in addition to the context compromises.  The good thing is that game developers are trained in compromise and optimization. The important thing is to understand your vision for the player experience, what kind of mood and tone you want to set.

Everyone has a different model of what those look like in their heads. It's important to use descriptive sentences rather than single words or short phrases.  The more descriptive, the easier it is to get everyone working together.  What are players looking at in the game, what are they interacting with? How often do they see certain things? How often do they interact with particular things? How visible is it?  And set priorities from there. 

Flaws in the visual fidelity are inevitable.  You want to prioritize detail and visual quality where players are going to notice it.  “If things look blurry and really chunky where they're spending 99% of their time, they will notice, and that will give them an impression of the quality of the rest of the game,” said Autumn. “But, if there are some lighting artifacts in 3 pixels of the screen, in an area that the player can only see at a specific angle, we don't care, especially if it makes the game run better.”  Embrace details where it matters most.

There are a lot of different ways to optimize a game.  It is a challenge to get the balance between the visuals of the game, the download size, and the overall performance. If we want kids to play the game and have a meaningful experience, that's what we have to do.

Join the Conversation

To learn more about design approaches – and to share yours! –  sign up for Open Game Data Open Office Hours or contact us at info@fielddaylearninggames.com.