Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 16, 2018
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


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

by Paul Kilduff-Taylor on 12/15/17 10:57:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutraís community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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

  • Can I solve the problem?
  • Is the problem worth solving?
  • How do I solve the problem?
  • How do I communicate the solution?

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:

“I’ve died many times purely because the camera got in my way.” (Alec Meer, RockPaperShotgun)

“…an intentional desire to make the camera a bit of an enemy” (Christian Donlan, Eurogamer)

“The problem is that the architecture is sometimes structured in such a way that there really isn’t a decent angle from which to view the action. This is a particular pain when you’re in a hurry, since your fingers are too busy making your character run around to try and turn the damn camera at the same time.” (jfictiony, Steam Review)

“you cannot figure out how to swivel the camera 90 degrees to see what is blocking you from moving forward” (transentient, Steam Review)

“Unfortunately, the artsy camera angles/controls make missions which require speed and precision unplayable.” (mrmeeseeks, Steam review)

..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:

“I have read ‘you need to constantly rotate the camera’ many times in both press and Steam reviews: this is patently false. You do not have to rotate the camera constantly to play the game: you often need to pick an angle and leave the camera there for a while, then make a specific choice to rotate it again later. “Constantly”, or a similar adverb here, betrays a fundamental lack of appreciation for the game’s basic mechanics, and so any related criticism can be dismissed out-of-hand.

The camera controls are demonstrably not “fiddly” or “dumb”: I challenge anyone to come up with something more intuitive than the defaults. I have seen, in person, players across a wide age range grasp the camera controls within a couple of minutes. For those who want (or need) to reconfigure those controls, we added key remapping. Camera rotation is also available as an option on the mousewheel on PC. You cannot complain about controls being fiddly when the defaults have been thoroughly worked through, and there is the potential for customisation, therefore there is no value in this opinion.”

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:

  • Search for trends
  • Feedback shows you the question but not the answer

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:

MACIEK: Our very first prototypes were 2D isometric in the style of old school games like Command and Conquer or Syndicate. The problem was that we wanted 3D gameplay with the player being able to engage atop and over structures. So after bashing our heads against that wall for a while, we switched to 3D.

The core goal initially was to retain a perfect isometric perspective, so we used a orthographic camera. To further the illusion we locked the camera to it’s 8 angles. So you switched rapidly between each. The gameplay idea behind this is that you can navigate very quickly to a view that makes sense. The speed is important in intense firefights.

After finding out that orthographic gave the player zero depth information and was waaay too hard to parse, we gave the view the tiniest amount of depth of field and parallax. Just enough to give the player info whilst still appearing to be isometric.

Added to this, the terrain was carefully designed so that each location had at least 3 angles (if not more) which the player needed to find for the best tactical advantage. We still think no one has gotten as close to achieving this level of interaction from this viewpoint.

SEAN: I still think that the 8-angle rotation scheme is part of the reason that the game is as beautiful as it is, and I reckon we roughly achieved the goal we set out to do with it. The way it was received ultimately helped me personally realise that maybe a more forgiving camera schema could have potentially made the gameplay better, but I think a change to this would result in a very different game from what it is now. It is intrinsic to the game’s core.

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.

SEAN: It felt like the ideal scenario here would be to have the terrain in front of the player actually fade out when the player was obscured by it, but when considering this there were a few immediate issues that we were unable to overcome.

There essentially was no easy way of fading discrete bits of a mesh while leaving other bits of the same mesh un-faded, which effectively meant we would’ve had to re-model the world into smaller pieces. This is in fact something we purposefully moved away from during development for the sake of performance, and we didn’t actually have capacity to undertake this from a development & regression testing perspective.

Another issue with this was that we would have to have some paradigm in place for the case where the player moved the mouse over a piece of faded-out terrain. Would they only aim on what was visible? Or would they aim on what was actually being faded out? How would they know, and how would they ever aim at something in between the player and the camera?

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

SEAN: Shaders are extremely powerful tools and from a performance perspective the use of more complicated shaders didn’t tighten the CPU bottleneck that the game is currently under. We elected to attach a slightly more complex shader to the important entities for this reason — not to mention that the workload overhead for this approach was much more within the bounds of what we as a studio could afford to do.

Coming to terms with how a change affects the fabric of a game is also an important part of this process.

MACIEK: It’s a good change, you can now identify enemies much more easily and even continue to dodge incoming fire even when you are behind terrain. I don’t think it changes the game massively, it maybe puts a bit more focus on the bullet hell side of things as it is now a spot easier to manage where previously you needed to be very deliberate about your approach and hidden dangers.

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!

Related Jobs

Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada

Concept Artist
Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada

Level Designer
HumaNature Studios Inc.
HumaNature Studios Inc. — Lahaina, Hawaii, United States

Lead Prototype Simulation Engineer
Zwift — London, England, United Kingdom

German Community Support Team Lead

Loading Comments

loader image