通常我们并不迷信制作大量文档的方法，我们更愿意创造GDD，它是游戏设计日记（Game Design Diary）的缩写：每个Sprint阶段都会写下一个新的章节并与团队分享。这样我们可以向初始理念添加细节，并保持追踪整个项目的历史。每个团队成员都可以看到开发过程中发生变化的内容及其时间，这有利于进一步分析。此外，从更小的文件入手更容易写下新故事。
Using SCRUM in indie game development
by Paolo Gambardella
For Hover Cabs we choose to use the Scrum-ban methodology to manage the game development. This post is not to explain you how SCRUM actually works, since there are a lot of free sources on the Internet that will explain it better than us.This post is to share the way we implement it since there is not so much information for small teams. From our point of view the best of this methodology at the very end is:
1. each team member is responsible of the project
2. you will foster learning more than the game itself
those principles, as you can easily notice if gamedev, are criticals for every team. We all know that a good game can be successful, a bad one will surely not. At the end of the day, the team is what remains in a company, and it grows up with its experiences. In every case the team should learn a lot, to take the maximum advantage independently from results. Responsibility and learning should be strongly encouraged, and SCRUM marries this philosophy perfectly. The kanban is an enhance which gives a clear visualization of the work stages.
Our workflow starts with Personas which are descriptions of possible players. We have to start with some assumption, since we do not have any player yet. Write down imaginary profiles for our future players helps us to drive the design toward them: that means to play better with engagement and retention, design side. An example of Persona:
John, 28 years old car mechanic from U.S.A.
He wants to have the time to play games, but he hasn’t. Anyway he owns a Nokia Lumia 520 and loves to download free games to play while at job. He cannot spend too much time and he is more likely to play during pauses at work. He has friends on Facebook and doesn’t use to pay a cent to play freemium games.
short game sessions (average)
Personas will become Play Personas once the game is released and we will get a clear idea of their behavior through tracking and direct feedback.
Basing on Personas we wrote down the concept document generating player’s stories: those are a great way to divide the problem into subproblems in order to conceive all the tasks each member of the team should satisfy to solve it. Here it is some example of story:
I want to…
see the taxi going alone
I can focus on dodge and take passengers
see my winnings in the summary: rewards, kilometers
I will have the sensation of my mastery
encounter obstacles during my trip
I will have a clear challenge
use gestures to control my taxi cab
I can get the feeling of move it with my fingers
have a new track from the second time I play
I can have the feeling of variety in the game
have a vertical layout
I can use my phone with a single hand
choose whenever to carry a passenger or not
I can choose to run for money or for km
we use to distinguish the players in 3 categories:
1. newbie: the players in the first day
2. casual: the players with normal retention and low engagement
3. advanced: the players with high retention and engagement
Every Sprint has the goal to solve a set of stories which are chosen from the product backlog and considered to satisfy the basic Sprint goal: to develop a potentially shippable game. Each story is enriched with a class of metric that will be tracked and we use the categories suggested in this post.
Four our kanban we use the typical four columns:
To Do: tasks which are not taken from anyone
Doing: tasks which are in current development
Test: tasks completed which should be verified from something other from the team
Done: tasks that can be considered ended
As you can easily notice, the last point is pretty ambiguous. In fact if you underestimate it may easily become an issue for your workflow. To avoid it, part of the efforts of the team during the Sprint Planning Meeting should be focused on the creation and the maintenance of the Definition of Done:
Here in Thousand Gears we are a small team developing a game for the Nokia AppCampus and to keep things clear and controllable we choose to have short iterations (Sprints). Each Sprint lasts 1 week, normally. We use to track the speed of the team through burndown charts; doing so we noticed that the team is capable of estimate the 60% of real hours in the Sprint planning meeting, which is consistent with the average in literature.
Each week we release a potentially shippable product, imagining we are going to participate to jams and competitions. At the end of each milestone (a set of one of more Sprints) we produce a new increment for our game. Our milestones are:
1. Pre-prototype: concept creation and implementation of a very basic system (even with objects and paper) showing the main loop
2. Prototype: establish technology and tools to develop a first basic release of the game. Imagine that you are going to participate to a Ludum Dare or something similar.
3. Demo: Create levels, art assets and implement features.
4. Alpha: Improve the content and the art assets with a basic bug-fix
5. Beta: final bug-fix
At the end of each milestone we run playtests. The first one (pre-prototype) is the only one internal, the goal is to motivate the team to the “let’s do it!”.
From the Prototype they are public, you can see our releases here and here.
What about design?
In general we do not believe in producing a huge amount of documentation; we prefer instead to create a GDD, where the acronym stands for Game Design Diary: each Sprint a new (and lightweight) chapter for the diary is written and shared with the team. In this way we can both add details to the original concept and maintain track of the history of the whole project. It will be totally transparent for every member of the team what is changed (and when) during the development, which is good for further analisys. Plus, it is easier to write down new stories starting from smaller documents.
In game development there is not any magic formula for success; the whole process is trial -> result -> learn. Scrum is not a method, it is a methodology: it is a philosophical thinking on research techniques more than an implementation of a logical-rational path through action. It happens that we should take some clear decision, so the best is to keep the things as simple as possible and measurable. The whole process is empirical, you have to study a lot about best practices and then apply them to your context and culture, in order to adapt them more to the people of the team.（source：gamasutra）