[This is a repost from my blog, doolwind.com]
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
- 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?