It Begins With An Idea
Video games typically begin with design, either starting with a great idea or pursuing a creative solution to a tough problem. It is entirely possible to imagine games for which there is no demand, or to identify a space where there is a need but no good game can be built. It is imperative to challenge your ideas and refine them to ensure it meets the qualifications of a good educational game. Once you’ve made that determination, you’re ready to start the game design process. As a broad overview we’ll discuss this process in terms of design, objectives, scope, and platform.
To begin the process you need to solidify your idea, leveraging what games do best, and establish that the content fits a need. Of the four main components this constitutes the design and objectives – the “what” of the project you are making.
Your objective, what the user takes away from the experience, will stay constant throughout development; however, design will be continually refined. Game design is a broad subject to cover. In the most distilled description, design thinks about what actions a player takes, how those actions are performed, and the feedback presented to the player as a result. In other words, design creates the reason for you to care, a method for you to reach a goal, and the journey to develop your skills. In educational games the actions and feedback are tightly coupled to the learning objective.
An example of a design and objective pairing is saving an alien race by piloting a spacecraft whose controls teach Newton’s Laws of Motion. Everything you build should serve those ideas, sometimes referred to as “the pillars” of your experience. It establishes that your focus is to create an interesting space environment while mastering the laws of motion.
Making A Dream A Reality
The remaining two components, scope and platform, constitute the path toward making your ideas a reality – in other words, the “how” of what you’re making.
Simply put, scope is comprised of the resources you have to accomplish your mission; typically time, money, and talent. A completed scope is more than just a budget; it should include a timeline of development, a description of what skills are required, and ideally a list of features core to the experience.
The term platform describes the technology used to develop the product, which often determines scope and quality. A well-defined platform should include minimum hardware specifications, performance, resolution, and target operating systems. Platform establishes how the game will be packaged and deployed, whether it is in an app store or a website. Most importantly, platform specifies the technology and strategy required to develop the game.
Platform decisions include evaluating the pros and cons of HTML5 or Unity and selecting a specific version. It also includes answers to questions like “will your game run on phones,” “will it be 2D or 3D,” or “will it be multiplayer,” because these decisions are disastrously expensive to change during development.
Platform is highly influenced by your audience. In order to effectively deliver the game you need to know your audience. Ask yourself:
- How is your audience going to find, access, play, and purchase your game?
- Will anything need to be installed or downloaded?
- Do you need to interface with other technologies? What devices are being used in the classroom?
It is often more important to pick a platform based on accessibility, distribution, and user base than the easiest platform for development. Your audience connects scope, platform, design, and objective together.
The Design Phase
This process is the expansion of your initial design concept, akin to going from a rough outline for a paper to your first draft. The game development equivalent is going from a concept at the level of a pitch (for example, here is the pitch for BioShock) to a game design document. You need enough of the early design to establish the core pillars of your experience. With that information, the design team has a space in which they can create.
However, the designer does not work alone. At the same time, artists are working to define the art style for the game. The goal is to identify a style, quality, and fidelity that fits within the production timeline, budget, and performance specifications.
Producers need to evaluate the work proposed and break concepts up into small discrete tasks. The development process requires identifying dependencies, calculating risk, establishing priorities, creating milestones, governing the budget, and making sure the timeline is realistic.
The one field that rarely produces anything tangible during this phase is programming. During this phase, programmers are busy prototyping and investigating solutions that will become the foundational architecture of the game. Basically, they’re challenging assumptions to ensure that they are technically realistic.
Typical pieces created during this time include concept art, storyboards, character design, and paper and pencil prototypes. The entire team should be rallied behind the vision that the designer has pioneered. At the end of the design phase there is a clear vision of what you’re building and a roadmap of how to get there.
The Production Phase
All of the work and communication up to this point have been done to make the actual development of the game run as smoothly as possible, because production is the longest and most expensive phase. If everything goes according to plan, production is pretty straightforward. Interdisciplinary teams collaborate and march through the work in chunks of time called sprints and milestones. In reality though, nothing ever goes smoothly. There will be underestimations, software updates, original ideas will need more iterations, and in general change will happen.
There are several key moments in development, as I mentioned in “costs and considerations,” and ideally you want to move from the riskiest features to easier and smaller features. In practice, it is rarely this simple. There are often many features of competing priority, sometimes resulting in submitting placeholders for missing pieces. You may have to leave current work at rough draft quality because the next feature’s rough draft is more important to work on. During development, game objects will likely have components (art, programming, sound, special effects) at varying levels of completeness. Even though it is incomplete, we are still trying to prove the efficacy and engagement of our idea.
The key moments, in order:
- The core game mechanic – the primary interaction the player performs, it could be rolling dice, playing cards, or building a city. It is the cornerstone of your experience and you need to establish that it is fun and engaging. It could still be abstract circles and squares, but the goal is for it to be a functional demo of a moment of gameplay.
- The game loop. Large parts of the experience could still be missing, but there is a flow from one action to the next. Typically this manifests itself as a complete level or a repeatable cycle of interactions. In a game where you are a space miner, the core mechanic is mining, the game loop is complete when you can mine multiple places and sell minerals at market. This is the first time someone can really “play” your game.
- Content complete / feature complete. At this point all art assets and programmed interactions are represented at some level of completion. Even though you might not be at “version 1.0”, you shift from creating to editing, iterating, and polishing.
- Naive User. It is a period of thorough playtesting with people that have never played it before; you need to discover all the places where someone gets lost, confused, or otherwise stuck. While quality assurance has an ongoing role throughout development this is the period were you manage defects. It is also typically where design fine tunes the “balance” of the game, adjusting values for all the controls, powers, and rewards.
A Look Into Production
I have lamented that no one knows what a game looks like during production and I would like to show you. This was a game built to teach energy exchange using the familiar concept of pinball. We used HTML 5 and it needed to run on affordable tablets. The development time was about nine months.
This is the first version of the game that we shared with our client. It isn’t much more than an interactive wireframe where objects are roughly blocked in. This was after two months of development. HTML5 doesn’t have support for collision detection or physics and we knew that a robust system was going to be necessary, so we wrote that code from scratch. This debug view of collision volumes was available throughout the project.
Game Progress: 33%
After another month of development, a third of the way through production, you can see our first pass at some objects (walls are still missing art and invisible in this view). More importantly we embraced tool-driven development and you can see the designer utilities taking shape so that they can create, edit, and save content.
Building a game is similar to building a house. There is a long period where it is just a hole in the ground while the foundation is being laid. Then you frame in the home and it starts to take shape.
Game Progress: 50%
At this point we finished our first pass of the user flow, which included a summary screen that tracked how energy moved through the system over time. We were still adding to the game while iterating on existing parts. This was an important milestone because it was the first time that we could put the game in front of other people and validate our ideas with playtests.
Halfway through development we had a first pass at the majority of the art, with newer features still having “programmer art” (I was very proud of my “spaghetti waves” of heat, an early pass at visual effects). At this point we were trying to hone in on the experience of the player. This is also the first time that you can see the learning objective in action. The kinetic energy of the pinball was transformed into electrical energy when passing through the spinner; then energy was converted to heat.
Game Progress: 75%
The next month and a half, roughly three quarters of the way through production, was an explosion of development. We went from a handful of levels to more than one hundred. We doubled our number of “energy parts.” New systems added to the game included sound, a tutorial, options, and just-in-time help. To top things off, art contributed the majority of final quality assets during this period. Camera work and other special effects were incorporated. At this point, everything that will be in the final product is represented at some level of completion.
Big questions were resolved (How big are parts? How big are levels? What feedback do we show for energy exchange? How does the inventory system work? Do the interactions feel natural?). At this stage of development we were able to leverage our previous work and focus on generating content. For example, the investment in a tool to create levels supported their quick construction and iteration. While it seems like there was a dramatic increase in productivity, the same number of people worked the same number of hours during this period.
Game Progress: 100%
The last 25% of development time added polish to the visual design, but no major artistic changes are made. The remaining time left on the project was dedicated to bug fixing, creating a web app version, saving player data, communication with servers, and performance optimizations to ensure the game would run smoothly on tablets.
The app version of the game is available on iTunes.
Lessons From A Builder
In the process of an idea becoming a reality, you shift from answering big questions to solving the nuanced details. Early on your dream can change effortlessly and you are unencumbered by the harsh truths of hardware limitations, budgets, and sunk costs. Production can be stressful. For a vision to materialize every rule and relationship needs to be well-defined. Even though decisions are smaller; there are more of them, they are happening rapidly, and they become expensive to change.
As seductive as it is to think about the end result, and as passionate I am about being a maker, it is critical to address the importance of the pre-production phases of development. Obviously early decisions affect how much time is required in production. More importantly, it is easy to set your project up for failure in pre-production. It is impossible to recover from mistakes like not knowing your audience, not filling a need, or picking the wrong market. The production goal is to create an experience where the topic is approachable, engaging, memorable, informative, and fun. Real success comes when that experience fulfills a need.