God stays for Game on Demand

Welcome Gamers and Players,

today I’ll start to write about something I promise some time ago. I mean the GoD Methodology. GoD stays for Game on Demand.

This and the following post will be about a way to “gamify” your business (not simply taking some spare game dynamics, but building a game that meets some business requirements in terms of crowdsourcing and/or outsourcing, or even on another business process).

I said, often, you have to start from business needs. That’s true, but you need to know how to analyze business process and requirements from a gaming point of view. In this post you will find some tips about this preliminary analysis.

First of all, start from a structural point of view. You have to think of your business in terms of process, as in a flow chart like this one:

The importance of a flowchart is capital: even if you’re a brilliant game-designer, you have to identify which area of business can be outsourced or gamified, why and how do this. Those are the basis.

When you have identified your business process in details, you may start to think about what can be outsourced. Try to not constrain yourself too much: probably you can gamify not a single passage of two in your process, but a lot more… in fact, an entire branch of your flowchart can be gamified.

See, as example, Socket Puncher and Shopping Suite (I refer to them because they’re already published on this blog: I could develop another games as examples, but I prefer to publish something new in the future).

After that you have identified what part of your business may be gamified, it’s time for brainstorming and go deeper in business process. You have to discuss and carefully think about any step of your flowchart: any shape (square, triangle, circle) you draw it’s a possible gamification target. On those shapes, you can build your key point to calculate Roi (see my previous post) and even make some brief predictions about how mechanics of the game have to work.

For example, creating a flowchart about socketing will make you write “draw socket” into diagram. That’s what is outsourced in Socket Puncher. Thinking about this target, you find out that at least 1 person have to play to generate this result.
In other cases you may have a higher minimum amount of players required: depending on business process, you can also highlight other business request on the shape you’re analyzing (ie – timeline, data format and so on).

So, the shapes in flowchart will lead you to a list of what your game have to do, and what business requirements it has to fulfill. At this point probably also some ideas on your game will start to flood into your head… but keep focused!
You have to take another step before game-design.

The lines connecting geometric shape in flowchart will be the next things to care about. They pinpoint dynamics, which means the best way to include them in your project is to full gamify them, transforming them in game mechanics.

For example, in Socket Puncher you should have drawn a line between “draw socket” and “best socket”. You have to choose best option to draw the “right” socket. This is fulfilled with a game mechanics that compares any combination created from players to choose the best one and awarding that.
Also if it’s fulfilled by a computer, it’s a pure game mechanics: the one that chooses the “winner”.

Then, you have a flowchart that represent your business and what can be gamified, a list of requirement for the game (aka “things that the game should do”) and a list of mechanics you have to develop in-game (aka “how te game drive output from point A to point B).

Congratulations! You have just made your first step.

See you again for the next move: creating the game!