42 Problems and a Fix Ain’t One: Fixing Tokyo 42’s Camera

When there’s a problem with your game, there are four questions you need to ask:

Here’s a look at an issue with Tokyo 42 and how its developers, Sean and Maciek at SMAC Games, attempted to deal with it.

We posted a really significant update to the game yesterday. Here’s a video:

This update takes a meaningful step to address one of the most common criticisms of the original game. I’ll let a selection of reviewers and users describe it:

..and so on

When you have expended a significant amount of thought on a feature, it’s easy to be extremely defensive in the face of criticism. Having been along for the ride on Tokyo 42 for a couple of years, here’s what I would say if I gave into that temptation:

But here’s an enormous surprise: being defensive is always the wrong approach to feedback of any kind.

When looking at qualitative feedback on a game (or indeed anything), there are Two Big Rules:

This isn’t to say that individual feedback independent from trends is worthless — far from it. Occasionally, specific testers will spark a thought or make you aware that of something that may eventually become significant: it’s always important to listen.

There’s also the vital human element of small-scale game development: sometimes you’re able to do simple things which have a big personal impact on a very small subset of players. This is especially important when it comes to accessibility: stories like this one abound in indie game development.

I’ve seen people use “feedback won’t give you the solution” almost as a mantra. My concern with that is that, very rarely, a tester will hit upon the correct direction. Sure, they definitely won’t present a nuanced understanding of the pro’s and con’s, and they won’t be able to tell you how to precisely configure your solution. But marching straight past someone who has a great direction in mind wearing a t-shirt that says ONLY I CAN SOLVE THIS will not set you on the path to great wisdom.

There are also, of course, cases where a problem seems complex to you but is genuinely simple and has an obvious solution. There’s a very human tendency to believe our problems are uniquely arcane, when in fact they are startlingly generic. It’s always worth watching out for this!

With that in mind, focusing feedback on identifying a problem is the best thing a player can do. Explaining the issue clearly and expressing how it affects your play gives the developer the highest quality information possible. As soon as criticism becomes vague, incoherent or vitriolic (“the camera is dumb”), it becomes a lot harder to parse and easier to ignore. Ideally, players would approach feedback in the same way they would attempt to help a friend — raising a problem in a sensitive way, listening, and then discussing solutions at their instigation. Unfortunately, the internet favours forms of communication which divest participants of all recognisable forms of human empathy, leaving us only able to express ourselves through flailing appeals to subjective emotion, so that’s never going to happen.

Can it be solved?

So, Tokyo 42 had a problem with its camera. But was it fixable?

There is an expectation among players that devs will attempt to solve every problem with a game.

Unfortunately, in a lot of instances, this just isn’t possible. Sometimes, problems are genuinely innate to a game: game design is about compromise, and compromise embraces downsides. The opacity and difficulty of Spelunky’s new player experience, the mind-boggling complexity of Crusader Kings’ UI, the feeling of random unfairness in your first few Hearthstone matches, the sponginess of Destiny 2’s enemies: you simply can’t iterate those away.

Here are the devs on their original vision for the game:

So, we initially classed the camera issues as being innate to the design, but with some time and perspective — this is not a pun — the devs felt that they could take some steps to mitigate them.

Mitigation has a lot of value. If a problem is truly innate to a game, taking the edge off can be immensely wise. Take Stellaris’ tutorial, for example, which does its damndest to lead the player gently through the dense forest of brain-destroying detail which comprises the bulk of the gameplay.

A footnote: we currently believe that the camera controls cannot be altered. In my defensive rant above, I mentioned that they are fully remappable, and that the defaults work well for the majority of players. Unfortunately there was really nothing else to be done there! One reason that developers do tend towards stonewalling criticism is the frustration of being criticised for something that literally cannot change. Again, it’s important to move past this and look for possible avenues of change.

Is it worth solving?

Sometimes, a problem can be solved but the dev simply can’t afford to do so. This is a reality of game development, and one which is poorly understood by players. While a particular issue may matter to you personally, there is a good chance that fixing it will not benefit the developer in any way. “If the devs just fixed this one thing they would make more money / save the community etc” is a hugely unhelpful opinion, and one which is often totally false. This sort of comment serves only to galvanise community discontentment.

Optimisation issues sometimes require a total systemic overhaul, for example, or a convoluted physics system can result in literally unpredictable bugs. At a late stage, especially post-launch, it’s often not commercially viable to rip out and replace an entire system.

Occasionally though, devs will take the risk and go for a huge intervention in the core of their game, as Heart Machine did when they put in a heroic effort to bring Hyper Light Drifter up to 60fps. It can pay off, but it’s certainly a risky process, not least due to the opportunity cost.

The “camera problem” was so persistent that we felt that even some mitigation here would help to curb some of the negative Steam reviews. Positive user feedback is a big help with a game’s long tail — when new customers are alerted to its existence during sales and other events, the user reviews are often the first thing they see.

Like a good crime, fixing a problem requires means, motive and opportunity. You need to take into account the financial and especially the time cost of fixing an issue (including any iteration that’s needed), you have to be genuinely motivated to look for a solution and you have to pay attention to anything else you could be doing at the time.

You can never truly tell in advance if a fix is worth it — you can only trust your judgement and then look at the reaction. It’s always possible to be wrong, and it’s always possible to make things worse.

Sometimes it’s better to pay attention to the audience you already have, rather than the hypothetical fans you hope to reach, and SMAC did exactly that initially — fixing bugs and working on the Smaceshi’s Castles DLC, which really pushed the challenge that the game was able to offer to its die-hard fans.

With that completed, they were able to afford the detachment and space to address the camera.

How do we solve it?

“Why not just fade out the terrain?” would be the Reddit-thread solution to this problem, and sometimes it’s worth looking at the unlikely brute-force approach first. That’s exactly what Sean did.

The duo then hit upon the current “silhouette” solution as the paradigm they wanted to try.

How do we communicate it?

There’s a somewhat annoying tendency in game development circles to tout both of the following aphorisms simultaneously:

“You only get one launch”
“You should release early, fail fast and iterate”

With a game like Tokyo 42, which can’t build an audience through very long retention times and users sharing their own creations, interest is galvanised largely through pre-launch marketing. This puts an enormous amount of pressure on the launch itself: trailers, press, paid advertising and engagement with any mailing list that has been built up through development are the only real tools at your disposal.

Tokyo 42’s marketing is an entire separate blog post (which I hope to write at some point relatively soon). Suffice it to say that we tried everything possible to get the game out there and managed to achieve some quite significant interest, thanks in no small part to Maciek’s incredible visuals.

However, unless you’re Destiny, fixing issues with a game is simply not newsworthy. Fixes largely appeal to those who are playing the game already even if they will have a big impact on the new player experience.

Obviously the priority here was to get the word out to existing players, which we did via our Steam Community, a Steam visibility round, social media and YouTube, but this has a very limited reach.

We could make a new trailer, but I feel that the game is somewhat “trailered out” in terms of the content we’ve shown. Big budget games get around this by creating lavish cinematic trailers with celebrity voice-overs, but the economics of indie game development are very different!

The only thing you can do when other means are unavailable to you is fall back on creating some additional content yourself, usually by trying to tell the story. My hope is that this will be somewhat interesting both to game developers and also those players who genuinely want to inform themselves about the process of making and releasing games.

Often, the thinking behind a decision is something that interests players, particularly those who are very invested in a game and will go out and advocate for it. As always, making something like this public is an experiment: the reaction can be deafening silence, vitriol, adulation or something in between. We’ll see!

Fixtures and Fittings

Tokyo 42 has been a success commercially, and with players, even with its camera issue — good news for all involved. However, it is sometimes possible for a game to be sunk on the basis of a single flaw — it can be utterly heartbreaking.

Amazingly, these issues can also completely slip through user testing: in playing the game at shows, having testers send in video footage and extensive feedback, and through our own testing absolutely nobody flagged this as a significant problem. It was simply something that was part of the game, and those people who liked the game accepted it. There’s definitely lessons there about the type of feedback and exposing a game to a wider array of players early on, but ultimately sometimes things get missed.

Parsing feedback, evaluating the costs and benefits of a solution, executing it and “selling” it is a tough process. It often requires some soul searching, and a willingness to re-open old wounds.

But it can also be tremendously liberating — after implementing a considered fix you can know, with absolute certainty, that you’ve done your best. The market for games is insanely fickle, but one of the great joys of game development is that your work can persist: it can go on to be discovered by new players over time, and knowing that you’ve given them the chance to experience your creation in the best possible light is a huge motivator.

If you played Tokyo 42 before and didn’t get on with the camera, we’d urge you to have another go. And if you’d like to revisit your Steam review…that’d be even better!