GAME JOBS
Contents
Secrets of Quick Iteration in the Core Social Space
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
June 6, 2013
 
Wargaming.net
Build Engineer
 
Gameloft - New York
Programmer
 
Wargaming.net
Build Engineer
 
Virdyne Technologies
Unity Programmer
 
Wargaming.net
Quality Assurance Analyst
 
Wargaming.net
Python Developer
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
June 6, 2013
 
Free to Play: A Call for Games Lacking Challenge
 
Cracking the Touchscreen Code [1]
 
10 Business Law and Tax Law Steps to Improve the Chance of Crowdfunding Success
 
Deep Plaid Games, one year later
 
The Competition of Sportsmanship in Online Games
spacer
About
spacer Editor-In-Chief:
Kris Graft
Blog Director:
Christian Nutt
Senior Contributing Editor:
Brandon Sheffield
News Editors:
Mike Rose, Kris Ligman
Editors-At-Large:
Leigh Alexander, Chris Morris
Advertising:
Jennifer Sulik
Recruitment:
Gina Gross
Education:
Gillian Crowley
 
Contact Gamasutra
 
Report a Problem
 
Submit News
 
Comment Guidelines
 
Blogging Guidelines
Sponsor
Features
  Secrets of Quick Iteration in the Core Social Space
by Gabi Shalel [Design, Production, Social/Online, Smartphone/Tablet]
7 comments Share on Twitter Share on Facebook RSS
 
 
May 13, 2013 Article Start Previous Page 3 of 4 Next
 

After spending some time individually coming up ideas to reinvent clan gameplay, we scheduled a brainstorming session with the creative team. Our technical director, lead designer, project managers, community management director, writing team, and lead programmer got together came up with a few alternate methods for approaching clan warfare. Once we had narrowed down our favorite choices, we met again several times over the following weeks to further develop concepts, poke holes in designs, and check what we came up with against our analytics. Eventually we settled on our current system, in which users take on different roles within each clan to capture, develop, and defend points on a larger game map to exert political influence on a larger map scale.

After deciding upon a rough outline of what we wanted to do, the process continued after the "official" meetings with live chats with everyone involved in the project. Anyone could put in their two cents, everyone had a chance to raise a red flag, and if we found ourselves stuck we could always call in the rest of the studio for a vote. We do this for everything, from casting voice talent to picking out new content designs. Aside from helping us power through creative log-jams, the added mutual investment in the project helped to inspire the team to work to their highest potential, and move past pet ideas without bruising any egos.



Once felt we had discussed the feature from every possible angle, our project manager broke up the concept into departmental tasks and each team went into prototyping. Our lead designer came up with several different approaches to the look and feel of the Emitters, brought them back for approval, and then passed them on to his team for modeling.

Our designers added a "charging up" electric arc animation to the final upgrade level on the Emitter towers. This, in turn, led the writing team to call another meeting, rewrite their original backstory, and include a mysterious final purpose for the emitters in the game storyline.

The process went back for another loop and we integrated the feature with a much better-developed story and added new non-player characters (NPC) characters -- Morgana, Mutants, and a deep back history explaining the origins and eventual goal of the Emitters (we were still fairly early on in the game and still had the freedom to do this). This new concept was the basis for many of our in-game missions further down the line. 

Here is a fully upgraded Emitter on the normal map scale.

After finalizing all storyline and design concepts, our programmers tried several different methods of sharing control and allocation of units and resources within Clans before settling on a "collective defense, individual offense" model.

Once the programming team had something workable, it went on to our QA testers on a closed server. After hammering out the inevitable bugs, we had the basic mechanics working well enough for gameplay. We followed up with a limited test release for some of our core users to check on feedback and get more user input. Sometimes a new feature is a hit, and sometimes we have to go back to the drawing board -- and for this feature we had to go back and forth a few times before we developed an interface they felt was intuitive enough to use.

Anyone whose done any development work knows how frustrating it can be when a feature gets a red light right before a release -- but it's much better than hearing it after we've gone live. Once we got the thumbs-up, we moved on to localizing and recording the content in all languages (we always try and release updates to various regions simultaneously), and added it to the main servers.

 
Article Start Previous Page 3 of 4 Next
 
Top Stories

image
Keeping the simulation dream alive
image
A 15-year-old critique of the game industry that's still relevant today
image
Here's the first list of Unreal Engine 4 integrated middleware
image
The demo is dead, revisited
Comments

Ramin Shokrizade
profile image
I was much impressed by the voice acting, graphics, and depth of this Plarium game when I evaluated it last year. I think it is essential that online games promote player interaction as this is the draw of online gaming for consumers relative to a more controlled single player experience. That said, the fact that your monetization model encourages gameplay imbalance seems to me to undermine many of your other design objectives, and presumably leads to the typical 95% conversion rejection rate with these models.

Have you considered making a fair F2P design where competition would actually be meaningful for your participants? I think your conversion and retention rates would be much higher. If you were somehow concerned that your player base would be uninterested in a strategy game that rewarded the participants primarily for their strategy and cooperation (as opposed to their spending propensity), then you could run both games in parallel under the different models and run a true A/B test to see which one performed better over time.

I personally think this would lead to much higher retention rates and allow you to do the type of iterative design work you describe here, with an increasingly loyal player base that would spend more over time instead of less.

Oren Todoros
profile image
Thank you for your thoughts and comments Ramin. To answer your question, one of our biggest challenges is to find the perfect balance between creating a fair playing field for our gamers, while building a sustainable long term business model.

We’re constantly working on new games and features with the “fun factor” and high retention rates in mind.

Ramin Shokrizade
profile image
Oren, what I am suggesting is that you can never achieve that balance of fair play using your current business model. You are in the business of selling advantage. I am suggesting you open your mind to the possibility that there might be more effective business models for your game designs and genre.

Senad Hrnjadovic
profile image
When I read about you making "real-time strategy games with deep game play mechanics" on social networks I was imagining something along the lines of Warcraft or Command & Conquer.

Slightly excited, I gave Total Domination a try, but the fights only gave me text reports. Did I miss something or is that what you understand unter the term RTS? Or do your other games more play like the classic titles? :)

Harsh Singh
profile image
With these quick changes, is there any dropout? I mean as you mentioned in your article there was change in a story as well as game play. So when existing player come across these changes, are there any dropouts? And how exactly you marketed new changes to existing members?

Pallav Nawani
profile image
It would be interesting to hear more details on your 'listen, brainstorm, work until we think it's perfect, get told we're wrong, fix it until it's right' cycle. At IronCode we are always looking for ways to reduce the time it takes for this cycle.

Oren Todoros
profile image
We're definitely going to go deeper into this subject on our upcoming blog. Stay tuned for that, and it would be great to connect directly to hear more about your service.


none
 
Comment:
 




UBM Tech