Sponsored By

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.

Is better always better?

Obsessively trying to make anything you work on better, in any sense of the word, can have worse consequences than you think.

Catalin Marcu, Blogger

July 23, 2014

5 Min Read

We as game developers are constantly trying to make the best game we can. You'll rarely find a developer saying "I just want to make a mediocre game" - poor work environments can lead to this, but that's for another talk. We all try to make something we're proud of and surely all of us have a list of things we wanted to do better in past projects.

The problem

The problem is that sometimes people forget about the "we can" part in "the best game we can". Somehow, wanting to make the best game leads them to think they or others should never stop improving their code / art / writing / music etc. And the worse part is that they don't think or care about the consequences. If they can't make the best game, it's because their bosses are stupid. It's because their colleagues are lazy. It's because the world doesn't understand their genius. In fact, it's only because they're selfish and they've found an expression to hide behind to pursue their own goals seemingly in the best interest of the game.

The best game is the one you finish making and rejoice with your team for this accomplishment. The best game is the one where you haven't destroyed the workplace atmosphere with your attitude, the one where you didn't almost bankrupt the company, the one where others didn't have to pick up work that you should've done just so you can improve what you've done so far.

Very important

There are 2 opposite school of thoughts in the industry regarding when you should release a game. One is to release fast then improve, another one is to release only when you feel you have a masterpiece or something close. The most important things both these lines of thought have in common is that you have to release. If you don't release, nobody will ever know what you worked on. They'll maybe hear of the potential, but that's it. You were just a possibility and they've forgotten already. So most importantly, make sure that your improvement attitude doesn't work against releasing something, either by burning out your team, spending all the funds, delaying repeatedly or just by convincing everyone around you that nothing they do is good enough.

But what I think is most important about releasing is to release when relevant. It's vital. Sure, you can work 5 more years to make it better, but will it still be relevant? Not only for the market, but for you, your company and/or your team? Set the release to a time when it's still relevant and try to stick with it. You're getting close to it and you feel you need more time? A month or two would make it better? Perfect, if you and the people around you feel that it will still be relevant, go for it. This isn't a talk against improving and delaying when necessary, it's about still being relevant.

Better attitude

If you suffer from the "always make it better" syndrome, then try to stop and think of the impact before trying to improve something. If you improve that, who will pick up the work that you were supposed to do? Do the people around you feel that it helps to improve that particular thing? Does it affect the schedule? And so on. Just think of the consequences first.

If someone else should improve something, can they? Do they want to? Can you motivate them? Because just telling them that they need to make it better and making them feel bad about themselves doesn't help. Always being the guy that says "You know what would be better/awesome?" will make people defensive and not wanting to show their work anymore. Nothing will ever be good enough for you, so why should they bother. Surely you're not the only person in the room who has awesome ideas, so why do you feel the need to always talk about them when others just congratulate that person on the good job they've done? When you think you're doing a great service to the project with your constant amazing ideas, you might in fact just put people down and make them work with less enthusiasm and care less about the game.

Game development is a collaborative work. So we all have to think as a team, as hard as that can sometimes be. If decisions are taken as a team, with more people accepting it than those rejecting it, it's a great step forward. And make sure you take into consideration the reasons why there were some rejections, especially the psychological ones. It's very important to remember that your teammates are people. Not assets, not robots, not your clones. People that can be tired, bored, sick, depressed and so on. The game can only be made by the team and if your team suffers, so will your game.

Possible solution

I call it the X iterations solution. Choose your own number to replace X, because it depends on the dynamic of your current team. Let's say it's 3 - 3 is always a good number.

If you or someone else iterated 3 times over something, it's enough. Depending on the complexity, it can be enough even after 2 or maybe after 5. But the idea is that sometimes enough is enough. He tried. He did his best. He's starting to hate you. Leave him alone. If you're a lead or more experienced and you're not happy, help him if you can and if he wants. Or let someone else have a go at it. Choose the best result. But don't keep pounding on that same person over and over.

Conclusions

  • Always trying to make something better is an issue

  • Releasing is important, doing it while still relevant is vital

  • Think about the consequences of your attitude

  • Think as a team because you're part of one

  • Limit the number of iterations to a reasonable amount

  • Improve your work, but know when to stop and move on

I didn't cover the last point so far, because I wanted to leave it for last. Don't be mediocre, try to be at least good. But if you can't, sometimes mediocre is better than nothing. 

Read more about:

2014Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like