The Wii U is reaching the end of its lifetime, soon we assume to be replaced by the as-still mysterious NX. I’ve spent nearly three years making games for Wii U in one way or another, and I plan to continue that for as long as Nintendo will let me. Why?
The Wii U has all the toys a game designer could want. Both touchscreen and buttons. Motion control as well as more standard console controller setup. This range of choice when it comes to input methods means a much wider variety of genres become possible. I grew up as a PC gamer and I love strategy games like Civilisation and Total War series. It’s just plain hard to do turn based strategy when all you have are buttons and sticks.
My first console game, Executive Star, was a case in-point. A local multiplayer strategy, made for the OUYA. Its design was based off board-games like Settlers of Catan, where trading resource cards between players is as simple as handing them across the table. Whereas for the console/TV experience, Executive Star had a great big grid that players would have to tab through in order to trade with each other – Use the left stick to go down to player 3, then across to the resource they wanted to trade. Press a button to increment the amounts. Then do same all over again for the other player’s half of the trade…
When making tower defence game Totem Topple for Wii U, the touchscreen allowed players to see all build options concurrently and pick which turret to build next with a tap of a finger. Rather than tabbing slowly through each option with buttons and menus. Adding in a Player 2, who could aim the game’s turrets, proved relatively painless with the Wii U’s support for extra controllers: Point the Wii Remote at the enemy you want to target and pull the trigger!
The Wii U’s much-maligned second screen may never have set the world alight, but it’s still by far and away the easiest way to build second screen experiences. Making games with multiple screens teaches a lot about what information to show or hide from players at which times. It also allows for experiments with asymmetry in (local) multiplayer gaming. Simply the fact that just one player has the GamePad, and the rest of the players don’t, has a huge impact on the dynamics of both the game, and the social interactions between players.
There have been a few brave attempts to explore the possibilities of second screen gaming on the Wii U. Affordable Space Adventures and ZombiU being notable examples, along with NintendoLand, which is still regularly discussed at length whenever I talk to Wii U owners about their thoughts on second-screen gaming. But it feels like the industry never really embraced the challenge.
Motion control gaming is another area I feel has not been allowed to run its full course. For all the fuss about Star Fox: Zero showing off what could really be done with the GamePad, Splatoon gets far more mentions when talking to regular gaming fans about Wii U. Many fps players really love being able to use the motion controls to spin round quickly when shot in the back.
With my current project, Flight of Light, it’s always fun to hand a skeptical looking “gamer” a Wii Remote at a convention, and see their reactions upon enjoying the game more than they expected. Equally, the sight of a Wii Remote, sat on a table, waiting to be played, still draws in a particular crowd. Especially young kids and their parents (much to my frustration: Flight of Light requires fine motor skills and quick reactions, both of which kids below a certain age really struggle with. Often resulting in disappointment).
That said, it’s taken years and endless iteration cycles to really nail down the controls. And I’ve been lucky in that having designed for Wii Remotes from the ground up, the game translates to other control schemes (mouse for PC, 6-axis motion control for PS4). As motion control has made a bit of a comeback due to VR, it’s been useful to have that experience of what works, and a lot more of what doesn’t.
There’s still more toys in the box I’ve yet to play with. Amiibo, and NFC “toys-to-life” in general are one I’d particularly like to have a go with. And something I don’t think has reached its real potential yet.
It’s also worth pointing out that console development is not always plain sailing from a programmers point of view. And as much as it might be fun for game developers to mess around with their hardware, platform holders are running a business – What works from a technical perspective might be a security risk or cause legal issues (no standing on GamePads please!)
We can debate why the Wii U has struggled commercially till the cows come home. It’s certainly however, provided opportunities to do some really interesting things in game design, and hopefully will continue to be a great device in the future!
Flight of Light is currently on kickstarter. You can find out more here.
We’re raising funds for Flight of Light’s soundtrack over on Kickstarter! The money will be used to pay a number of different musicians to compose the game’s soundtrack. If all goes to plan, there’ll be four musicians creating two pieces of music each to fit the game’s initial nine levels. (The ninth music track has already been composed by freelance musician Lawrence Shahid, which you can listen to in the trailer above!)
For the next month, we’ll be putting out updates on how the kickstarter is progressing alongside the usual dev diaries and updates on the game’s progress.
When I first started developing for the Wii U, it had already been struggling for the couple of years since its release. Nintendo were keen for more games to showcase the console’s GamePad, and being the bright-eye’d naive young developer I was, I arrogantly thought I could step up to that challenge!
After spending a bit of time getting the devkit and tools up and running, I realised the Wii U also supported Wii Remotes as well. I wrote out a list of game concepts for both GamePad and Wii Remotes to prototype when my current project was completed. Well that project fell through, and added to that, I’d got the devkit on a deferred payment scheme. So the clock was ticking to get a game finished and released, and make the cash needed to pay for the kit.
I decided to start with Wii Remotes, and an idea I’d had when first exploring the Wii U’s API’s. Wii Remotes at their most basic level output 3 floats to represent x,y,z rotation, and it seemed like most games simply mapped these real-world movement values one-to-one to movement in the game. Swing a tennis racket or aim a gun. Instead, I mapped those values to colour.
Change the hue, saturation and lightness. That was rapidly boiled down to just controlling hue in one dimension, as otherwise people would get lost in an ocean of grey, unable to work out how each movement corresponded to altering the lightness or saturation.
The simplest game I could make from that was matching colours. Players would be given a target colour, and have to rotate their Wii Remote in order to change their own colour to match. Point one end of the Wii Remote up and it outputs a 1. That translates into one end of the colour spectrum – red. Point the other end up, and you get 0, which translates as blue. Rotate between the two in order to cycle through the whole colour spectrum.
Flight of Light has evolved much since then, but in many ways, it is still the same fundamental game, underneath the many layers of visual abstraction that now separate it from those roots. Along that journey, I’ve been advised many times to change the game’s control scheme. Use discreet lanes, or discreet buttons, like guitar hero. Have the colours snap into solid bands. However, I’m glad I resisted those calls, as the game wouldn’t be where it is today otherwise. It’d be just another clone of the many rhythm games that have come before it.
Equally, having that continuous range of input has opened up paths that otherwise wouldn’t be there. Being able to race in-time to the music is now an integral feature, but may never have come about were it not for the way the game is controlled.
More over, it’s allowed the game to spread to multiple different platforms and control schemes. The game can be played with exotic devices like Kinect and Leap Motion, or more traditional mouse or console controller analogue stick. Or even touchscreens on mobile phones.
Why stick with motion control then, if more conventional controls are available? Firstly, motion feels the most natural to play with. That may be a consequence of having spent more time perfecting the control system with Wii Remotes than anything else, but for the most part, it’s intuitive. It’s a lot more approachable to non-gamers. When I take the game to conventions, people still associate the Wii Remote as something that let them be kinda good at games without needing to invest too much time mastering a complex rule set or sequence of actions to perform.
The downside is that Flight of Light isn’t nearly as kid-friendly as I’d hoped. Anyone below a certain age struggles to play, as the game requires fine motor skills and quick reactions. Little kids have neither.
Secondly, and somewhat related to the first point, I feel quite strongly that motion controlled gaming was never given the chance to fully run its course. It feels like most of the industry treated it like something outside of their comfort zone, and something they were all too happy to drop when the chance came. A lot of people bought Kinects and Wii’s, but how many developers stepped up to the plate to serve that audience?
I’m not pretending Flight of Light is anything revelatory or unique, but at least by experimenting with motion controls, I can say I’ve taken a different path to create something people have enjoyed.
Upgrading Flight of Light’s graphics had major and unexpected effects on the game’s playability
Previously, most of the game’s art was cobbled together placeholder assets, many of which had gone through multiple iterations of gameplay alterations, to the point where they no longer made sense or didn’t fit with everything else. That was fine for when the game was constantly changing. With the game’s recent change of direction, it also became clear the game’s graphics needed a major overhaul. However, having swapped out the old assets for shiny new ones, it quickly became apparent that the playability of the game had been impacted far beyond what we expected.
The biggest change came from trying to give the player a sense of speed. Pulling back the camera and widening the field of view as the player’s speed was boosted gave a great sense of acceleration. However it left the actual playable area of the game confined to a tiny portion of the screen.
The first instinct was to simply make the notes larger, so they could be seen from a greater distance. This worked, but the extra-large notes would frequently clip through the new scenery. The scenery also needed to be relatively close to the track to help with the sense of speed – trees and rock faces rushing past the player at close quarters.
Reducing the amount of camera shifting,combined with a slight increase in note size made the game much easier to play. No more squinting into the screen to try and make out the tiny notes in the centre. However, that really killed the sense of speed.
Actually increasing the speed (as opposed to simply the illusion of speed) helped, but also brought problems of its own. If corners were too tight, it would cause sudden jarring changes in direction. The notes would travel along the track so fast that the player would barely have any time to react. In the next blog, I’ll detail more about the process of re-making the track and forest level to fix that.
Adding in the new spaceship model also threw up unexpected issues. Being far bigger and, more importantly, wider, than the old placeholder model meant players would often think they had just clipped the edge of a note, only for the game to tell them they had missed. The game doesn’t use physics to calculate the collision of notes with the ship, but rather relies on timings, and on knowing what angle the ship is at versus the angle of the note.If the difference between the two angles is too great, the game will take that as a miss, regardless of what model is being used and how things may appear to the player.
Making the angle range within which the game recognised a hit had the knock-on effect of making the game that much easier. However, we’d noticed already that the effects used to show the player they had missed were already on the extreme side. Violent screenshake and asudden slowdown that really made players feel they were being punished harshly. We’re currently working on a way to make those effects more of a sliding scale, so that a small, occasional miss will still be noticeable to players, but not completely kill the flow of the game.
In the end, it’s been a combination of changes and small compromises in different areas made a huge improvement to the game’s feel and ease of play. And also a lesson learned about just how clousely coupled graphics and gameplay can be.
Back in May, we pitched Flight of Light to a number of potential investors. However, none of them were particularly interested in the game. A disappointing experience, but on reflection came the realisation the game lacked focus. It felt schizophrenic, two competing personalities and styles, neither of which was really fulfilling its potential.
We decided to redirect attention towards the futuristic neon racer side of the game. The simple reason that it was the closer of the two to being finished. It’s also much more technically within reach to make a really good job of it. I initially spent a number of days trying to improve the algorithm for the unfolding triangles on the Autumn level. So that it could unfold into any given shape, allowing for a whole landscape to unfold in-front of the player. Sadly, it was just beyond my capabilities, and left me banging my head against the wall, going nowhere fast.
We’ve also had issues for years with trying to illustrate how Flight of Light is played through video. Incremental changes are slowly making it easier to learn the game without instruction. That’s having a positive knock-on effect that it’s also easier to work out what is going on just from watching the game. However, even if it’s still a little hard to work out precisely what the game is all about, if it looks good, that at least encourages people to want to find out more about it.
Graphics really do matter, especially when selling a game, and it’s easier to create a futuristic racing game than an artsy, low-poly procedural musical experience. Furthermore, the audience for the former is arguably larger and easier to reach with the sorts of tools available to low-budget independent developers like us.
The aim is now to release version one of the the game by end of January 2017 (or thereabouts). That will then provide a platform from which the game can potentially be expanded to include different styles and new modes of play.
We’ve produced a short teaser trailer for Flight of Light. This shows the latest gameplay and much improved graphics. We’ve also updated the Flight of Light website and presskit with new screenshots and information about the game:
We’ll be going into more detail on how the game has changed in future blogs and videos over the next couple of months.
Introducing damage types into Totem Topple proved to be a relatively quick way of creating more variety and dynamism within the game. It allowed for new and interesting enemies to emerge later on in the game, and added an extra dimension to the game without burdening the player with too much extra to learn.
Change of Plan
Originally, the plan was that whatever damage type was selected when the player placed a beak (turret) or wing, that would be it’s damage type for life. However, this lead to issues whereby players would be stuck with a lot of ineffectual turrets that didn’t match the damage type of the latest wave of enemies. Or worse, not have enough supplies to build more beaks for the incoming enemy damage type, and be unable to collect any more due to being unable to kill those enemies!
Furthermore, it hugely complicated the tower building elements of the game. Since the game doesn’t have an undo function or any way to adjust the tower once built, having to account for different damage types in different places on the tower just put the game that bit beyond the player’s easy understanding. Placing mismatched wings and beaks on either side of a head because you forgot you’d changed damage types gets old really fast.
As well, firing in Totem Topple is done by simply aiming all the turrets at a single target. It doesn’t make much sense firing every damage type at an enemy when the player knows only a few arrows will have an effect. Especially if there are, say, both fire and ice enemies on screen, the player is better off letting the arrows shoot their respective damage types automatically. Rather than half their effective firepower by targeting a single enemy on which half their arrows will be ineffectual. That takes away the fun and point to being able to target specific enemies in the first place.
Instead, having a single damage type fired by all beaks made both play and implementation that much easier. However, allowing players to constantly switch damage types made things too easy. It took away the challenge of managing damage types, as the player could just spam the button to change damage type to whatever.
The idea of giving the player a limited number of changes in a given time period came about more by accident than design. Copying the other buttons used to build heads/wings/etc meant the change damage type button inherited a cool-down timer. That on its own was too harsh on the player, as often they needed to cycle between a couple of damage types to get to the one they wanted. Giving them a small number of changes, that would then replenish slowly over time, gave just the right balance. Forcing the player to be conservative with their damage type changes, but not to the point of being punishing.
Ready, Aim, Fire!
Some years ago, I participated in a game jam using Eye Tracking technology. My team’s game was a horrible mess, but the eye tracking technology itself was far more responsive and accurate than I anticipated. When it came time to port Totem Topple over to PC, I decided to have a go at integrating eye tracking, just for fun.
I used the eye tracking to let the player target enemies and shoot all arrows towards that chosen enemy until it was dead. After which the arrows would revert to their usual patterns until a new enemy was targeted. The result was really fun, to the point that people would forget the actual tower-defence and building aspect of the game, especially in Classic mode, and just have a great time shooting as many enemies as they could.
Later on, when creating the Wii U updates for Totem Topple, Wii Remotes proved a relatively straight forward substitute in for eye tracking (which Wii U doesn’t support). Pointing the Wii Remote at the TV and letting one player direct fire, whilst a friend or family member concentrates on building the tower and controlling damage type dealt, added a surprise extra social dimension to the game. In Off-TV mode, the enemies are seen on the Wii U GamePad, and the player can tap on the GamePad touchscreen to target them. Equally for the non-eye tracker PC version, players click with the mouse on enemies they wish to shoot.
The tutorial system in Totem Topple is something that we’ve wrestled with over a number of iterations. In the launch version of Totem Topple, it worked, in the sense that it gave players enough of an understanding of how the game’s basic mechanics worked to be able to play. Similarly, the complimentary Help system worked well in allowing players to see the underlying stats and numbers for the various heads and enemies.
However, the fact that many players resorted to using the Help showed how much the game was lacking in visual feedback. Many of the minor changes made to Totem Topple for the 2.0 release try to give players a better sense of how their actions affect the game.
For example, some heads give a bonus to their neighbours, as indicated by the radius wheel behind them. Unfortunately, the wheel itself, whilst it is clear where it is coming from, it’s not clear what it actually does. There are no visible links or changes on the heads it affects. In fact, some players confused it for some sort of shield or radial attack.
Instead, now indicator arrows point between heads, wings and beaks, allowing players to see when any one element on the totem pole affects another. For health buffs, the affected heads gain a purple glow as a show of high strength, at least give some indication to the player that this head is different to others. However, we’re still looking at ways to make it even more obvious when one head or wing afftects the health of another.
When it comes to rate of fire changes, the differential between the lowest and highest rates was not big enough previously. Whilst the way the game was balanced, a higher rate of fire made a big difference to the player’s ability to kill lots of enemies, unless they looked really closely, players were unlikely to be able to tell that.
To improve this, firstly the balance of the game was changed so that low rate of fire really did mean one measly arrow every couple of seconds, whilst the highest rate creates an almost constant stream. Further to this, a higher rate of fire actually means the arrow physically moves faster. The arrows also gain “go faster stripes” or speed lines as they are called by illustrators. These emphasise the speed, but also give an extra visual pointer to show that things have changed when adding a wing, or that this head-beak combo is better than another.
Adding in a simple, two step animation of the bird beaks opening and closing every time an arrow fired also helped to give players an extra visual clue that one head/beak is a lot more active than the others. Especially so when arrows are flying in all directions.
There were also a few combinations where beaks would have a zero rate of fire or arrows would do negative damage. To represent this, beaks would be closed, or fire broken arrows. Even so, this is probably a bit confusing for the player, so long term, we’re aiming to remove the need for these by rebalancing.
For damage, arrows now start off black and then slowly turn more and more brightly coloured depending on the damage type being fired. The highest damage dealing arrows are then given spectacular trails of flame, snowflakes or water jets to really drive home that these arrows were specially powerful.
Another problem was simply telling heads apart from each other. It’s not intrinsically clear what a bear or a wolf or an eagle does or represents. Unlike, say, a scifi themed game, where the players can work things out using existing knowledge: That gun-looking structure is probably a turret, and the box that emits a glowing shield is probably a defensive mod.
Previously we’d coloured the heads according to function. Blue for defensive and orange for offensive. However, players didn’t pick up on that, viewing each head individually, and trying to work out what each did one at a time.
So we gave each one a unique colour. We also simplified the designs. A lot of detail was getting lost or creating a pixellated mess on lower resolution screens, which made the heads all blur into one. Simplifying the graphics also helped to make the overall game aesthetic look cleaner. We did the same for the enemies, using the original higher-resolution enemy images for the much larger, newly created boss enemies. This had the added bonus of making them appear more special compared to their smaller, plainer counterparts.
Another complaint from the launch version of the game was that the hitboxes were too small. Players would see their arrows whisk right through enemies, apparently failing to hit them unless the arrow hit dead centre. However, increasing the enemy hitbox size caused a different problem, whereupon enemies would often hit the second bottom totem head as they moved into the base of the tower. The game is programmed as such to ignore these hits (as it massively complicates the game and its coding if non-bottom heads / heads half-way through the stack can be killed). As a result, the new enemies would often completely fail to knock the totem pole down.
The solution was actually to make the arrow hitboxes significantly larger instead. Some re-balancing in other areas made sure that the game didn’t become too easy as a result.
Some aspects of the game didn’t get a mention in the tutorial, yet were not common features to other games in the genre. For these, rather than let the player figure it out for themselves as before, “interrupt” style tutorial messages would pop up informing the user of key bits of information the first time they did something significant but otherwise non-obvious.
For example, the placing of towers and turrets is a key part of most tower defence games, yet Totem Topple eschews this as one of the limiting factors of the game, forcing players to plan ahead a bit more than they might otherwise need to. That’s all very well except that most players didn’t understand that, especially with placing wings.
So when a wing is first placed, the game now informs the player both about the functions wings perform and where they will be placed by the game on the totem. Small graphical indicators have also been added to help players subsequently quickly see where the next wing will be placed.
The other related issue is with the height warning. Way back when the game was first created, it would let players simply keep building up and up ad-infinitum. However, this meant players could for the most part mash the place head buttons (at least in frantic mode), and it didn’t really matter what heads they placed, just how quickly they could throw them down.
To get around this, a mechanic was added in which players were punished for this mode of behaviour, spawning huge waves of super-hard enemies if they built beyond the red flashing warning line near the top of their screen.
This rightly confused the hell out of most players, who did not make the connection between building “too high” and the game suddenly ramping up to impossible difficulty levels. This threat of “angering the spirits” and super-hard enemies did not raise the tension of the game as hoped. Rather, the seemingly arbitrary nature of the players’ demise just as they seemed to be making progress left many frustrated and feeling cheated.
So we simply placed a hard limit on how high players could build. No more than 10 heads, and then the first time they hit that limit, an interrupt would inform them of the limit. The red warning line was kept in, but now as a reminder of that limit rather than as an easily mis-interpreted signal of impending doom.
The game’s UI was also subject to improvements. On the tutorial, enemies would flash and buttons “ping” and scale to help cement the messages in the tutorial text, and better guide players towards the buttons they needed to press or things they needed to be aware of.
Various factors meant we were stuck with using Unity’s less than perfect legacy GUI. However, even simple changes, like using a font other than default Arial also made a big difference. Or adjusting the UI buttons and panels to have angular corners to fit better with the angular background art style.
Overall, the various systems that help the player learn now feel like they do a much better job, working together and in different ways to convey information. There are still many more improvements to be made, but with the changes made, the game doesn’t leave players so lost and confused as it once did.
I was pretty gutted with how Totem Topple was received after it launched back in November, both in terms of poor reviews and poor sales. The first reaction is always to get angry, but looking back on the comments, I quickly realised that most of the criticism was justified. When placing myself in the shoes of reviewers or players coming to the game with fresh eyes, the responses to the game were perfectly rational.
One video of the game was particularly telling: I watched as the player died, died again, died again. Then they checked the in-game help, compared what all the different totem heads did. They devised a strategy, and I’m sitting there thinking “Looks like they’ve got it now. Should be ok this time!”. Only to be taken out by chance enemy spawn that really, they couldn’t do anything to mitigate. The video ended there. Although there was no commentary, I could almost hear them thinking “I did everything the game told me to and still died every single time. **** this.”
The proper, professional response to this is to learn the lessons and bring them to the next game, but otherwise move on. Instead, here I am, still working on the game 6 months later. A mix of sunken cost fallacy and bruised pride sucking me in, leading me to try and rescue Totem Topple. This is the story of how I’ve reached this point.
For those not familiar with Totem Topple, the premise is players add different heads, wings or bird beaks to their totem pole. These represent the turrets, walls and stats boosters of more traditional tower defence games. Demon spirit enemies then float down from the top of the screen, attacking the base of the totem pole.
When the bottom head on the pole has taken enough damage, it is destroyed, and the whole tower drops down one level. When all heads are destroyed, it’s game over.
Totem Topple, like so many games these days, was born in the fires of a game jam. Over 2 days, myself and 3 fellow indie devs poured our efforts into creating a little mobile tower defence game at a game jam curiously sponsored by King, of Candy Crush Saga fame. After the jam, all the other team members had full time jobs, so I took on the task of polishing up our creation and putting it on Google Play. That took about 2 weeks, and whilst it got a smattering of downloads, it largely went unnoticed, another drop in the ocean app store.
I’ve heard a number of theories about why jam games do not make good candidates for full-production games. I personally subscribe to the idea that the best jam games really drill down to one central, super-polished mechanic, but as a result lack depth. Fun for 5 minutes, but without the larger game loops that keep the player engaged on an hour-by-hour basis, or make them spend their lunch break devising strategies for when they get home to the game.
This, plus a nagging feeling that the audience for console games would reject anything that looked too much like a “crappy mobile port” lead me to spend a lot of time creating a complicated “custom game” system. Players could tinker with all the variables behind the scenes, add new heads and enemies, re-order when different waves spawned, and so on.
I was encouraged when a couple of months into development, Nintendo announced Mario Maker. Suddenly, level editors were all the rage and the custom game feature felt like a part of a wider movement around giving players more control to modify and create content in-game.
In retrospect, I was putting too much time into a feature that very few people were ever likely to actually use. It also allowed me to fool myself when it came to balancing the game, allowing me to say “Oh, well balancing the game is hard, so I’ll throw it open to players and they’ll appreciate being part of the development process, with a developer who is humble enough to admit (by implication) that they don’t know all the answers.”
When really, the game would eventually release without the Custom Game feature, owing to the difficulty of making the user experience feel really smooth. And due to the difficulty to keep it maintained every time something else in the game changed.
As for the balance (or lack thereof), that would turn out to be the biggest issue people had when the game did eventually launch.
Down to Earth
Six months after its inception, the game was “finished”, and I was busy trying to drag the it through Wii U lotcheck process. One of the reasons for bringing the game to Wii U was to go through the process at least once, with what I thought was a relatively small, simple game. Use the lessons learned in helping bring the bigger, more ambitious Flight of Light to the Wii U, whilst also hopefully earning enough money from it to pay some of the artists and musicians that game would need to get it completed.
And I have learned a huge amount about that process, to the point that I’m confident in taking on projects like porting Gear Gauntlet to Wii U, or in simply offering up my experiences and advice to other developers going through the process for the first time.
However, I didn’t make things easy for myself, insisting on adding odd features like Miiverse integration, leaderboards and analytics packages. Whilst I was wading through all that, I took the game to Pocket Gamer Big Indie Pitch, at which the judges eviscerated the game for its various flaws.
I went away and decided the game needed some big changes. I removed the Custom mode and added in a “Classic” mode to replace it. The theory being that it was closer to more traditional tower defence games, and would be a good way for people to learn the game before going on to the original game, now rebranded “Frantic” mode.
When the game did come out, Classic mode had had far less time put into its balancing. Whereas most of the reviewers who actually played Frantic mode preferred it, universally, they all struggled with Classic mode. I’d pushed Classic mode to the fore of the game, placing it first on the menu, plus the name itself suggested it was a more logical place to start the game. Consequently a majority of reviewers took Frantic mode, which had far more time put into its balance, as more of a bonus mode, rather than the real core of the game.
The game also came out at a bad time. Right in the middle of the Christmas/holiday season, a day before two big 1st party Nintendo titles landed on the system, in a period full of the latest AAA games arriving on other platforms.
In terms of marketing, I stood on my virtual soapbox shouting at social media, but got nothing back. I wrote a bunch of blog posts about what I felt were interesting aspects of the game – It’s Navite American Inspirations, it’s day/night cycle, the differences between frantic and classic modes. Few beyond my immediate circle of friends read those posts, and certainly none of the reviewers picked up on the subtle things I’d included in the game, that to me represented the love and attention I’d put into it. Like how the music changed when the enemies started getting harder, then changed back when they got easier again. In fact, one reviewer claimed the game only had one single repetitive song on a loop. Which annoyed me intensely until I realised they probably never got past the first few waves, and so never heard the change.
Just Ship It
The other reason I gave up on making all those blog posts was that in the time between the game getting approved, and actually being available to buy, I’d run out of stuff to talk about. I thought I was being smart, storing up things to talk about with regards to the game. Keeping my power dry until the last couple of weeks before release. Only to find being approved does not mean the game is on the store next week (or anything close to that).
That exhausting process and a feeling like I’d already spent way too long on the game contributed to an attitude in the weeks leading up to the release of “just ship it”, and “so what if it was the wrong time of year”. I was determined to get the game out and into the world, and not be one of the long line of indies who never actually finish a game.
Another marketing fail was the video / trailer for the game. It just did not show what it was like to actually play the game, or even whether the player was trying to knock the tower down or build it up or quite what they were supposed to be seeing and doing.
Finally, I’d decided that getting youtubers and streamers to play the game was all the rage, and would make the big difference. So I planned to spend the couple of weeks preceding launch just handing out as many codes to as many people as I could persuade to give the game a try. However, Nintendo only gave me the codes 3 weeks before launch day, giving me just enough time to contact those specialist Nintendo review sites who I knew could make a real difference to the game’s reception.
Once their less than stellar reviews started trickling in, I immediately paused all my marketing plans, and determined that I must find and correct what was wrong with the game before continuing.
Another lesson learned the hard way was that patching is its own entire thing, and not simply a case of changing a few variables in Unity and pushing a fresh build to the game via Nintendo. In the heat of the game’s launch and the days after, I made a series of rushed changes to quickly re-balance the game and sent them off to be approved. The resulting patch did not arrive until end of January, long after the game’s fleeting moment in the spotlight of Nintendo fan interest had long since flickered out.
In fairness, a couple of reviewers did the game a decent service and took a second look, or waited till after the patch before giving their verdicts. But for it to have any impact on the game’s overall reception and sales, that ship had long since sailed.
That brings me to today. The second patch is now out on Wii U, and the changelog is as long as my arm. New features, new enemies, improved tutorial and UI, and everything rebalanced from the ground up. The game is releasing in new territories (Australia and New Zealand). Taking advantage ofUnity3d’s cross-platform building, the game now runs on PC, and hoping now to pass Steam Greenlight. You can see some of the changes made in the new trailer below:
Will it rescue Totem Topple? Financially, the chances of even modest success are vanishingly small at this point. However, the game as it is now, at least I can be proud of it, and give those who do take a chance with it a fun time.
In many ways, Nintendo have been playing catch up with the rest of the industry in the last few months, with their new account system and first mobile app Miitomo launching recently. Nothing exemplifies this more so than the nintendo.com website, which finally allows people to buy digital download games without having to log onto their console. For most consumers it’s a cool, if minor added convenience. However, for developers it represents a major fix to a once horribly convoluted purchasing process.
Essentially, developers and publishers can now link directly to a place where people can actually buy their games, no matter what device they are on. This opens up an array of new options for marketing eShop games. Whereas before, by the time the potential customer gets home and/or has time spare to log onto their console, they might have forgotten the game they saw advertised. Now, mobile and web-based ads become far more viable, as clicking through leads straight to the store page and the chance of an actual conversion.
Currently, I suspect that most eShop sales, particularly of indie titles, come from a small pool of highly active Nintendo fans. Consider a well received indie game can struggle to rack up 10k sales, whereas Nintendo 1st party titles can shift tens or hundreds of times that. Clearly there is an audience out there and willing to spend in the right circumstances.
Smaller developers in particular can now promote their games directly from their own websites, from their youtube channels, twitch streams, email lists, social media channels, and so on. Even when demoing at games conventions, developers/publishers can still direct people to the nintendo website and in theory make a sale on the spot.
Of course, it’s not perfect, as potential customers can still be lost in the in-between steps from landing on the nintendo.com store page, logging in, entering payment details, and so forth. However, it’s still infinitely better than what was there before.
With any luck, indie developers in particular will embrace this and factor it into their less conventional marketing plans. Certainly for our games, when we do have a cool and unusual idea for promoting our games, we’ll have a much more flexible, versatile way to convert an interested person into a sale and (hopefully) satisfied customer.