So far, one of the greatest barriers to naturally integrating language learning with video games has been the user interface challenge: how do you represent a skill that is about combining a finite number of sounds into an infinite number of possible sentences, using only key-presses and mouse movements. Most attempts have simply asked the user to click on a picture or completed sentence. However, this skips the very core of learning to generate utterances in a foreign language.
(Who is Oscar Lake) (To be fair, this game was a milestone of excellence in language learning and video games back when it first came out in 1996)
Other approaches include having a user self-produce and evaluate their utterances:
Or using speech recognition technology:
3D Language: Spain [external link]
While speech recognition is a promising and rapidly improving technology, in its current state it is important that we also think through other possible interfaces for constructing language in games. A good starting point for this might be to examine how other types of languages, programming languages, have responded to this challenge. In one program, StarLogo TNG, non-programmers are scaffolded into creating complex programs by choosing individual puzzle blocks from a pallet of possible options on the left-hand panel. Each puzzle block is labeled with a word, and its shape determined by the function of that word. For example, blocks like "forwards" "backwards" "left" "right" "up" and "down" all share a common shape, but blocks like numbers and conditionals have different shapes. Each shape is chosen such that it can only be combined with other shapes that form meaningful combinations. An output window then generates a program based on the world created by the user's block combinations.
[Use controls to start video above]
In the same way that this interface is used to give directions to a computer, we could also imagine constructing an application in which blocks labeled in the L2 are combined to practice giving directions to a simulated interlocutor.
|(Other cars are live players on the internet)|
The first game was produced as a commercial title with a professional development team. The second game was created by two undergraduate students in a Belgian university as part of class assignment. When planning the development of an educational game, it is important to realize that a richer game experience does not always mean a more expensive budget. Rather, the most important question is often "how much of the game that I design has already been written for me?" Few successful entertainment games exist that look anything like the first game, so more of its development needs to be funded out-of-pocket. By contrast, racing games are a well established video game genre, so almost all of the components needed for the second game were already provided by the Torque Racing Game Starter Kit.
To be fair, the first game aims to teach a foreign language, whereas the second arguably revolves around rapidly hitting keys. However, middleware platforms such as a the Torque engine give us infinite flexibility to change or add any aspects of the games we need. One could easily imagine a replacement of the standard interface for driving the car with one requiring correctly constructed imperatives.
Typing of the Dead -- (Typing) -- An example of how simply changing the interface can add educational value to a game without detracting from the fun [external link]
Perhaps the strongest advantage of using middleware technologies is that they usually include pre-written support for hosting multiple players over the internet. For foreign language learning games, this provides numerous opportunities to incorporate collaborative and communicative elements directly into the games. For example, lets imagine implementing one of the most basic abstract game mechanics, Pac Man, with the Torque engine and a puzzle brick interface to create an engaging language learning experience.
With the Pac Man game mechanic, players are divided up into two teams. The goal of the player on the first team is to navigate their way through every point on the board without getting caught by the ghosts. On the second team, the ghosts need to try and catch the pac man. Although it is easy for the pac man to outmaneuver any individual ghost, if they collaborate together successfully they can trap the pac man.
By this point we have combined the puzzle brick interface, with the gameplay mechanic of pac man, with the middleware layer of the Torque racing engine.
Like the racing game, this encourages players to learn how to correctly construct imperative sentences in order to move their characters. In addition, for the ghosts, it requires communicative collaborate in the L2 (either through provided puzzle bricks to force properly constructed sentences or via a free-form chat that checks for L2 usage) in order for the ghost team to successfully trap the pac man. At the same time, this design builds upon already written programming code and already refined game mechanics to ensure affordable development costs -- even on an educational game budget.
While numerous other games like this could be devised for different underlying game mechanics and different communicative goals, the primary challenge in using middleware is that the game designer needs to have a firm understanding of the different components provided by the middleware layer and create designs that meaningfully extend them. All game designers in the mainstream entertainment industry know their middleware, literally, inside and out; pedagogical designers trained in extending middleware are considerably more rare. Yet, to have a game in which the gameplay and learning are integrated into one, pedagogical designers themselves must understand game and middleware mechanics. While currently this is rare, as new educational designers who grew up playing video games enter the field and momentum gathers for serious/educational games, we will undoubtedly see a leap forward in the quality of educational video games.