Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Part 4 of 10: Design to Sell - 'In truth, a prototype and a proof of concept are two entirely different beasts.'
Part 4 of 10: Design to Sell [previous parts]
Creators and salespeople tend to misunderstand each other – not because their goals vary, but because their needs do.
Both try to deliver to the audience, but they act like divorced parents trying to win their kids over. Players get caught in the crossfire, because they need to judge something they have only a vague idea of. While they are perfectly right about their own feelings with regard to any given game, they’re unlikely to know what a “core combat loop” or a “unique selling point” is. They don’t judge game design by reading design documents and marketing strategies. They judge it by giving the game a test drive.
In one project, we learned about it the hard way when we showed our raw prototypes to the publisher. We felt it was such an impressive design, and they didn’t like it! At first, the sheer functionality was unclear to them, and they would often get stuck, because raw prototypes are notoriously easy to break. But even after we explained everything, their response was a big shrug: “So what? We don’t see anything cool happening”. They gave it a test drive and were left unimpressed. It’s not that the design was bad, but – we failed to “sell” it.
Since then, we took a salesman’s approach to prototyping. All special cases had to be handled, and the prototype had to be user-friendly. Each part of it had to showcase impressive use cases. It didn’t matter if the use case was feasible or representative – but it had to be cool.
At the same time, we stopped paying attention to whether the feature was holding together. Parts of prototypes that allowed us to examine the remaining design issues were removed, because they didn’t serve the purpose of selling individual features to the publisher.
It was particularly frustrating to creative people who built those prototypes. They saw how their work wasn’t making much sense under the hood, and they had to spend sonsiderable time giving polish to something that wasn’t going to make it into final release anyway.
The new prototypes would sell our concepts to the publisher very efficiently. But the design issues we neglected would bite us back later on. The moment of truth came when we needed to use new features in an actual level, and the publisher was disappointed to discover that most of the impressive use cases were not there. They couldn’t. They only worked fine in a carefully tailored showcase.
You could say changing the strategy was wrong, but that’s only one side of the coin. In truth, a prototype and a proof of concept are two entirely different beasts. One is just for you, and it shows how the game works on the inside. It's a creator's tool. The other is for your reviewers, and it shows how the game works on the outside - it's a salesperson's tool. Use both tools, but build them separately.
Lesson learned: Design to create. That is – build something that actually works as intended. Only then sell what you’ve created.
You May Also Like