Fun Over Features – Manifesto for Agile Game Development
I spent the first two days of GDC undertaking my Scrum Master Certification. As part of this course we had to add an extra item to the agile manifesto. I came up with the concept of “Fun over Features”. Focus on finding fun within your game rather than just adding features in the hopes “fun” will emerge out of the features in the future.
The existing list of items in the agile manifesto are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And below is my item:
- Fun over features
What does it mean?
Basically, it means finding the fun first. The fewer features you can add to your game to get the required amount of fun the better. Focus on the core gameplay that gamers will derive the most fun from, rather than adding outlandish features that make your game stand out. Don’t just add features for the sake of having them.
Some examples of games that have a low or high amount of fun and features include:
Low fun, low features – Cheap failure (e.g. many unknown flash games)
Low fun, high features – Big budget flop (e.g. Spore)
High fun, high features – Big budget success (e.g. Mass Effect)
High fun, low features – Low budget success (e.g. Canabalt)
Relationship between features and fun
Features and fun are tightly related. You can’t have fun without a feature. Fun is derived from experiencing a feature. However you can have a feature without it being fun. This is the whole reason we need to focus on the fun rather than just the feature.
Fun Amount vs Feature Size
What’s better, adding a small feature that isn’t too fun, or adding a large feature that is extremely fun? On the face of it, the former seems better. It’s not absolutely certain that a feature will reach a certain level of fun. However it is certain that a large feature will take a lot of resources and a long time. Completing the smaller fun features first seems like a logical extension of iterative development – ascending iterative development. Add features an iteration at a time starting with the smallest features first.
I’ve previously spoken about the cost to benefit ratio. My suggestion for which features to add is an extension of this concept. Look at the Feature size to fun ratio. Unfortunately this can be quite difficult to quantify, however you can do some simple calculations:
- Rate your feature on “fun” from 1 to 10 – how much fun players will derive from it
- Rate your feature on “size” from 1 to 10 – how large the feature will be to implement
- Divide fun by size for each feature – fun / size
- Order the features from largest to small (descending)
- Work from the top down
The obvious caveat to this is if you have core features that must be added to your game. However if they are quite low on the list I’d question the motives for why this is such a core part of your game if it isn’t fun enough.
Conclusion
So that’s a little investigation into a simple concept I came up with on the fly. I highly recommend Clinton Keith’s Scrum course which lead to this idea. I also highly recommend GDC to anyone thinking of going next year. I learnt more than I could ever have imagined and made countless critical contacts.
What do you think of this idea? If you could add an item to the agile manifesto what would it be?
That’s an interesting way to think about it. It’s easy to come up with cool feature(creep)s as we go, but thinking about some rough quantification seems like a good strategy.
I definitely want to get a simple and streamlined set of features solid and fun before going too crazy with anything else. With the project I’m currently working on, I think we’ve been doing a decent job of staying focused on the core fun, but still, something worth being aware of.
It does make me think to look at features more objectively, and separate out the ones that are part of the core set, from the periphery.
Looks like a sound principle to me.
In the world of business software, I would translate this to “usability over features.” I.e., focus on making software that’s easy for the customer and does what they want as opposed to throwing in everything and the kitchen sink in the hopes that the customer will like it. I’ve seen many projects on the road to failure because the management or team wanted to add every “killer feature” on the list instead of paying attention to what’s best for the end user.
fun is a quality measure and it is subjective; how can it be measured and before release itself to find the
features:fun :: cost:benefit? using polls?
Hi Alistair,
I’m still bemused as to what a ScrumMaster is – but i’m assuming it has little to do with rugby league