I have another topic that is growing as I write it, but I wanted to dip into a sidebar that struck me while I worked. I am writing this on an iPad. That is not very important, nor is the fact that I am a big fan of the device, but it did get me thinking. If you’re unfamiliar, one of the things about current generation iPads is that they are way more powerful than they have any business being. Some of this is due to hardware advances, but a fair amount is because the iPhone/iPad is a newer platform than the PC, so certain things were baked in from the ground up.

Specifically, iOS software has been historically designed for a very resource constrained environment. This makes sense. Early phones were not very powerful, so you had to be very careful in what you let them do (especially if you’re Apple and very invested in customer experience). One specific area where this comes up is memory.

You’re probably familiar with the idea of RAM – the memory that your computer keeps the things it’s actively working on. This memory is faster than the memory you use for storage, and the more RAM you have, the more stuff your computer can do. Simple enough.

Now, the thing is your computer only has so much RAM (and it used to have much less!), so some long ago nerds came up with the idea of swap space. In short, when your RAM gets too full, your computer will try to find parts of it you’re not using at the moment and move those across to storage (like your disk) to free up space. When you need them again, it moves them back. You lose a little bit of performance (this moving takes time) but your computer is able to run things that it otherwise would not have enough RAM for. Yay!

The thing is, iOS doesn’t do this. Lots of reasons why, but the long and the short of it is that if something uses too much RAM, it gets dumped. The app crashes. End of story.

In practice, this is not too much of a problem. Originally, iOS couldn’t even multi-task, so there was very little competition for RAM. Even after multitasking was introduced, the system remains outright draconian about reclaiming resources. The result is that if you want your app to run well on iOS, you need to create a tighter package. The extra overhead on a computer allows for a certain amount to slop that iOS just won’t tolerate.

So what does that have to do with anything?

Well, it has a lot to do with you, and it has a lot to do with games (and with almost anything we want to share with people).

Most of us, most of the time, act like iOS. We have a certain amount of capacity, and if a message is communicated in a way that will fit within that capacity, then we can potentially absorb it. But if it exceeds that capacity, there’s a good chance we’ll “crash” – reclaim the resources, discard the message and move onto the next thing.

But – and this is the trick – that’s not always what we do.

Sometimes we’re perfectly willing to sit down and read 300 pages of content or watch 10 hours of videos or otherwise dramatically exceed our capacity in order to learn something. This leads to an apparent paradox where people want both more and less content.

This is where the metaphor kicks in – when we care, we create swap space.

Which matters because it’s the answer (or not-quite answer) to a common question in game design – what is the right size for my game. It would be awesome if there was one answer, but the real answer seems to be “the more people care, the bigger it can get”. This is borne out by numerous examples, but perhaps most tellingly by the very idea of the “supplement treadmill” – if people are bought into your game, they want more.

Which means the question to ask is not “how big?” but rather “how can I convince people to care if they don’t already?” Thankfully, the answer suggests itself in the problem – the case for why people should care is something you need to fit in their current capacity.

At this point, we get into familiar territory – elevator pitches, quickstarts, promo pages – there are a lot of ways to present the small part of your game that will excite people, and a lot of practices that surround them. But the important thing about designing this for other people’s capacity is that you are designing it for other people.

That maybe seems obvious, but consider. Often, when we craft a quickstart, a demo, a pitch or the like, our goal is to create something small that is true to the larger product. This is not a bad instinct – we want to be honest and give a clear reflection of the bigger product. But when we do this, we are designing to the product, not the people.

To be clear, this is not an invitation to lie or deceive. Rather, it is a rule of thumb to help prioritize which truths you want to bring to the fore. The simple reality is that any abbreviation is going to be incomplete, and you must make prioritization decisions. You absolutely can prioritize accuracy, but you will be better served prioritizing the things that make your game exciting, interesting or attention grabbing. Your summary – whatever its form – is an argument for your game, and it is allowed to be biased in favor of your game. It is, I’m afraid to tell you, marketing.

(And if you find yourself wanting to make a pitch for something that’s not in your game but you think is exciting and awesome? Well, maybe you need to think about putting it in your game. )