Elastic Development Environment - Free to Play Games

Elastic Development Environment - Free to Play Games

For those of the Free to Play game development world, the standard pyramid structure of game development usually looks something like this:

In real life, every part of the Pyramid has a role to play inorder to make sure the game does what it has to do: Make money, retain users, give entertainment, and be stable.

If you wonder why I use "Real Life" I mean that at the end of the day, you have to make $$$$ inorder to pay for the studio in the first place, so a game that does generate revenue to meet the needs of the business is not going to last long.

So in general, each group has a driving overall focus that is important to the whole, but specifically tailored for there area of expertise.

PRODUCT:

• Monetization (Making sure the game can bring in $$$)

ENGINEERING:

• Stability ( FTP games are online 100% of the time, so the game must function at 100% all the time)

ART:

• Fidelity (The game has to be engaging inorder to get players to keep coming back)

Now this production pyramid usually causes a tention between the different groups as each group strives to keep there area of focus in view. 

Examples:

• Product needs new features released quickly to raise revenue without enough time to do enough properly have artwork or engineering develop the feature
• Engineering wanting to make sure a new feature is "100%" anti scripting compliant, so takes so much extra time that it misses the revenue targets, even though "99%" would have been fine.
• Art is working on a new game level and wants to add many extra embellishments to give it a "super polished" look, but turns it over to Engineering late so the game stability suffers or misses the venue targets.

Some Game teams tend to move to a more waterfall system in which the Product group is on Top and the other groups are in a pure supporting role. In this role, Product tells the other groups what is desired and how it will be constructed.

For some teams this works well, as its a very top down driven development cycle and when dealing with outside contracting groups, its gives Product a lot of control on the project. But on in game studios it can lead to some problems.

• There is no push or pull in the production cycle so both Fidelity and Stability can suffer
• Detachment of the production side of the team as there concerns can be down played.
• Game Teams have a lot of pride on there "Game" and a detachment of a sharing process can lead to "Just tell me what to do" work ethic.

An Elastic Development Environment is a much more fluid structure in which all three groups working together for the common goals of Monetization, Stability, and Fidelity. The Tention is both acknowledge and used to make sure the game is successful.

The trick with Elastic Development is that all groups have to understand that to make a successful game then its a combination of the three core values: Make a game can Monetize (as I said before, No Money means no team), have great Fidelity (game play and visuals), and Stability (If the game is not working, no one can see the Art or $$$).

I would argue that Monetization is usually the trump card in the pyramid but a well run team can handle the day to day tention.

More to Follow about how to run teams in this work style...