Fun vs features

You have a system. Let's say it's a system where you can throw darts. And you have to open your bar in one week.

Throwing darts might have a bad interface. The dartboard might be too small or too big or poorly lit. Darts may be a perfectly nice idea, but the implementation of it needs tuning.

At this point, you have a feature, but not fun. It's gonna take you four days to make it fun.

You can refine darts, get it fun. Make the UI good, have a great physics model and control, great graphics, and in general, you can get it to where you have a fun feature.

The exercise here is going to be threefold: making sure the inputs afforded to the user map well to their view of the "black box" that is the darts system; making sure the darts system itself offers interesting repeatable challenges; and making sure that the feedback from the black box Is both juicy and educational, so that the user can get better at darts. All this is hard.

Then you face a choice. Three days left, if you made darts fun. You can either go implement a pool table, or you can add content to darts. Content would be new kinds of darts, more kinds of dart games, etc. They don't call for a new system, just other kinds of data. Not much new code (and new code runs the risk of introducing bugs). You can make the best darn darts game in the country if you spent the three days on that.

The pool table, you could get that in instead. But what if it's not fun on the first try, just like darts weren't? Then you'd have a decent darts game and a crappy pool table.

Which is better, having the best darts game available, or having a middling darts game and a bad game of pool?

Adding features offers the potential for fun, but fun comes from tuning and balancing. It isn't magically there just because you got a pool table.

In order, I would have to tackle the black box, then the inputs, and finally the feedback. I can't make a bad system much better with great affordances and while I can make it juicy, it usually won't hold players.

I would choose to polish up darts, and promise to get a pool table in there as soon as I can. And when I do put in the pool table, it'll be as good a game of pool as we can make rather than being rushed to fit in before the bar opens.

This isn't the answer I would always have chosen in my career. I have done plenty of kitchen sink design. I have also settled for poor affordances and feedback far too often. I have even had perfectly wonderful systems be unusable because we could not figure out a way to make the feedback comprehensible.

I've always leaned towards elegant systems, meaning ones with few variables and few rules to them. When you populate a game with many of these, they very frequently end up leading to emergent behavior, which can be quite fun. But when you lean on the creation of simple systems, the temptation is even greater to have lots of them in your game. And that can and will lead to most or all of them feeling unpolished and unfinished.

I've gotten good enough at coming up with simple rule solutions that gosh, almost 10% of them work on the first try! (Yes, read that as sarcasm aimed at myself). But these days, I tend to assume that it will take me ten times longer to polish up and tune that rule system than it will to come up with the rules in the first place.