formerly "untitled gamification platform"
This project provides a platform on which to build gamified systems. The platform intends to solve a couple different problems. First, it provides an integration layer for different components within a system to talk to each other. Take for example Jesse Schell’s familiar smart toothbrush prediction, where a connected toothbrush is able to get us better brushing habits and cheaper toothpaste. Gamifying this task is fairly straightfoward when we’re just talking about a toothbrush, but what happens when the game designer wants to incorporate other devices, or information into gameplay, such as the faucet or the toothpaste tube? As the scope of the game expands, engineering a solution to integrate disparate components becomes more and more challenging. Using this platform, you can design a virtual model of all the components stripped down to just the properties that affect gameplay, and then in that virtual space develop the interactions between them.
Maybe more importantly, though, this architecture suggests a certain division of labor between building the game and building the components. Is it really appropriate that the people building the toothbrush are the same people that are building the toothbrush game? The toothbrush is just a single tool with a bunch of different sensors and switches, but once it’s out on the Internet, the toothbrush game exists in a much larger space. This platform is the first step of many in bringing structure to that space.
The mudlib foundation is just that, the foundation layer of a mudlib intended to run inside the LDMud game driver. If you’re unfamiliar with MUDs, they are multiplayer role-playing games conceived in the early Internet era, similar to today’s MMORPGs but smaller in scale and text-only. The foundation layer isn’t really a game ind an of itself, but a stage on which a game may be played, like a pool table or a deck of cards. There are some basic physics which govern how different components within the system may interact with each other, but there are no rules, no challenges, no goals. What it does provide is the means to log on, move around and look at things, communicate with other players, make social connections, and create content. There will also be support for some common gaming instruments, like currency, achievements, quests, leaderboards, group play and collaboration, possibly levels.
One element that using a MUD engine adds to the experience that should not be overlooked is narrative. For the uninitiated, the mudding experience might not seem seem too different than IRC, it’s just a stream of messages and some user controls. However, the MUD provides a fully realized virtual environment with all sorts of different classes of people, places and things. Instead of just being a collection of mathematical formulas and statistics, it’s a stage on which to tell a story. Unlike plain numbers, a story told with those numbers offers a sense of progress, and an emotional response greater than the sum of its parts.
For instance, let us suppose we want gamify the software development experience. Perhaps when you first start playing the game, you’re forced to enter and exit the game in a large dormitory where all the other new players “sleep.” Then let’s model a bunch of different buildings, each represent some division within the application the player is supporting. Furthermore, we’ll integrate those buildings with the organization’s bug tracking software and model every bug reported in that area of the application as a defect in the building that needs repair. As the player fixes bugs, the building is slowly improved, until it reaches a point where it is livable (perhaps according to some other game mechanic). The player may then move out of the dormitory and into the building that they helped fix up. It might seem silly, but it’s been shown that these kinds of devices can really increase a person’s level of engagement, especially in children.
It should go without saying that gamification need not always be the driving force behind playing the game. It could also be used to model some exterior system, just to observe what effect making changes within that system will have on emergent behavior. For instance, if you created a reliable model of our legal system, you could use it to test out laws before they’re passed in real life. Finally, you may also use the platform to create a game, just for the sake of creating a game. One pursuit of mine for EotL is to create a new mudlib on this platform and embed it inside the existing mudlib, thereby creating a game-within-a-game. You’ll buy an apartment in the “old” EotL which takes you to the new EotL when you enter it. Once inside, it’ll be an entirely new universe with different rules and content for EotLers to play with and contribute to.