I recently visited a friends’ game studio to bounce some ideas on how they should manage several new projects they have. These new projects are based on the freemium model with micro-transactions while their previous titles were mostly for game consoles. The shift from games as a product to games as a service brought up several methodology and processes issues. One of those issues raised was the game design aspect, which I’ll touch in this post.
* Since this post became featured on Gamasutra I’m getting increased traffic. Feel free to add a comment and say hi – and share the post if you like it!
Traditional vs Social Game Designers
In more traditional games (Games as products), the game designer is mostly free from ongoing business concerns. Once the genre was decided and the project got a green light, it’s up to him to design the most immersive and fun experience he can. That’s it. The marketing and bizdev guys (or rather, the publisher’s marketing and bizdev guys) are the ones tasked with the “dirty sales work”.
This can’t be more different with designers working on freemium titles. The upsell points needs to be completely part of the game design. The designer needs to find a balance between the immersive gameplay and the need to monetize. The game needs to encourage players to buy (virtual currency / better items / more game time) while not being too frustrating for the non paying players (the majority) which will cause them to leave. The designer of freemium games also need to be fluent with the measure-optimize cycle, write small features that can be developed quickly and gather information from A/B testing – responsibilities console game designers never have to face.
I believe you cannot separate the two in social games. A social game designer needs to be very business oriented and fluent with numbers, beyond being a “Fun Engineer”.
(This subject definitely deserve it’s own post. Maybe the next one I’ll write..)
Designer Roles and Responsibilities
These are the basic R&R of a designer in a social games studio:
- Create new game features to achieve target KPIs
- Analyze real-time feedback and metrics, and adjust game setting in order to reach set goals
- Write and maintain clear game design documents, accessible to all relevant personnel in the company.
- Work with producers, developers and artists to direct and oversee the implementation of the design
- Define and communicate the game’s long-term vision.
- Remain up-to-date with Game Design literature and best practices, and bring that knowledge into the organization
KPIs (Key Performance Indicators) should be set by management. To be precise, the KPI priorities should be set by no other than the CEO. Once the designer has a set goal, it’s much easier to focus on designing a feature that will hit target. It’s important the exact metric goal be in agreement – eg, increase ARPPU to $X or increase 2nd Day Retention to Y%.
The designer also needs to be the first line analyst. He needs to look at the numbers daily, identify points to optimize and come up with ways to test his theories.
Last, while it’s encouraged that all team members will play games, it’s the designer official responsibility. He needs to play games in and outside of the genre, draw inspiration from books, movies, popular culture and bring this knowledge into the team.
Design within development stages
Every studio has a slightly different methodology, so the following is just a general breakout of the stages.
- Preproduction Stage
- Activity: Research and High Level – Concept, Game Genre, Core Mechanics, Initial art style, writing the design skeleton, prototyping etc.
- Documents: Concept Doc / HLGDD (High Level Game Design Doc). Basically, one document based on the Skeleton Template – format is flexible.
- Duration: 2-4 weeks before production
- Production Stage (Pre-Launch)
- Activity: Deeper design in parallel with development, prototyping, calculating all level/economy/other tables, re-writing design where needed, defining Launch Version (minimal content required for launch).
- Documents: Updating and filling the GDD (game design document) skeleton, producing a Cycle Design Doc – Encapsulating content per cycle based on design document
- Duration: Until initial release
- Live Game (Post Launch)
- Activity: Analyzing daily performance, adding new features and adjusting existing ones to reach the set goals.
- Documents: Features design based on the Feature Template
- Duration: Game’s lifetime
Of course, every studio use a slightly different template, but I think all these templates should be based on this skeleton:
- Feature Name
- KPI affected, estimated results (quality & quantity)
- Community reaction, increase inflation/deflation, 3 rd party dependency, Gameplay change (FAQ/Tutorial) / None. (Make it short – points only)
- Detailed Description
- Frontend (inc. wireframes/mockups), Backend, Admin, Algorithms, Art & Sound Assets
- Metrics & Reports
- Events to be sent, reports requested
- Release date, goals achievement, success/failure. Possible screenshot
Scope of Design Documents
There is always a conflict between wasting too much time on writing every little detail and making a quick draft that leaves the developers puzzled on how the bloody thing should work. Every team needs to find it’s own balance, and even this will keep changing frequently. The following are the basic guidelines I found to work best for the teams I managed.
- Design a strong (yet not bloated) Admin Dashboard. Game designers & Artists should be able to tweak game features and add content to the live game without using developers time.
- Detail design of all algorithms is required. Add Excel files.
- Provide guidelines for end cases, but giving a full list of edge cases and behaviours is only optional.
- Leave space for team members’ contributions (Animations, effects etc)
- Designs need to be clear, shortest possible, easily read and with wireframes / mockups. There is no point to write something long no one will bother to read.
Mockups can easily be done using Balsamiq Mockups or any other tools the designer is comfortable with, but there must be a visual representation of the feature (if it is, indeed, a visual feature). It’s also fine to paste images from other games/websites/movies/scans, as long as the visual look is clear.
Analytics and Game Design
Metrics and analysing stats are key in social games and the designer is the first line soldier in this. I would go as far as saying that designers in the freemium space need to be half business/sales guys to be successful, and they certainly need to be numbers people as well as creative. Still, it’s important that game designers will limit their digging into numbers so they could actually get work done in the right pace.
Deep analysis and finding patterns is the work of the Analysts. They will take raw data, or combine data from several sources to discover deeper patterns, and bring up insights. It will be the designer’s job, however, to design actionable features based on those insights. Analysts are people with degrees in statistics, they use “heavy guns” data mining tools like SPSS Clementine and others and take a long time to come up with some pretty cool insights. Game designers cannot (and should not) perform this level of analytics, even if they have the time (and they never do).
It’s important the game designers will have access to good visualization tools so they could get a clear picture of the daily stats. Graphs, pie charts etc are important time saving tools, so if you can afford the services, these should be available to designers at all times. You’d be surprised how a small insight your designer came with by just staring at the stats can make a significant impact on the KPIs.
The game designer is obviously a critical element in the success of a game. It’s critical he’ll get the core gameplay correctly at the initial launch and even more critical he’ll know how to measure-test-optimize once the game is live. you cannot separate the business and analytics aspect from the gameplay design, which makes designing social games a very challenging (yet very interesting) job.