Forward Progess

A brief update from here at Crystalline Green HQ:

Exciting times for Totem Topple. We’ve now submitted the game into Nintendo’s Wii U approvals process (aka lotcheck). It takes a few weeks for them to go through everything and probably they’ll spot one or two things that need fixing at our end, so our current thinking is that the game will be released around the end of October or maybe early November. We’ll keep you posted on when we have an exact date!

Meanwhile, we’ve switched back to working on Flight of Light. We’re currently rebuilding the game from the ground up in the latest version of Unity (5.2). After having fixed a few performance issues, the game is now looking better and better graphics wise. I personally feel that as more games come to Wii U using Unity 5′s improved graphics package, Nintendo fans will be pleasantly surprised at what the console is capable of.

FLight of Light WIP 02-10-2015

We’ve still got a way to go to make Flight of Light really shine, but we feel the game is now firmly back on track. Looking ahead, we’re hoping to get a beta of the game finished by the end of December 2015, for release early next year. It means we’ve got our work cut out for us in the meantime, but we’re looking forward to making the game the best it can be and letting fans finally enjoy an (albeit limited) version of the game.

Translation Topple

If you’d like to help with translating Totem Topple, you can do so here:

Totem Topple is the first game where we’ve gone beyond English and translated the game into different languages. It’s always great for people to be able to enjoy games in their native language. All too often, there’s a touch of cultural arrogance from English speaking developers in assuming that the rest of the world will just deal with the fact the game is in one language only, so it’s nice to break that for once.

Voice and text can add a huge amount to the playing experience, but for those games that don’t have a narrative focus (or maybe even some that do!) it’s often a good idea to design out unnecessary text and voice acting to save cost and effort when translating.

For Totem Topple, voice acting is way outside our budget anyway, and we’ve very much aimed to reduce the amount of text we use. However, in compiling a list of all the words and phrases in the game, we were actually surprised by just how much there was!


A lot of the text does not in fact come from the game itself, but rather from things related to the game. Store descriptions and legal notices in the Wii U e-manual in particular have caught us out. It’s easy to add in a few lines of cool sounding description to entice players to buy and download, but that all needs translating if the game isn’t going to look odd and out of place with its English descriptions in amongst everything else in another language. Not to mention putting people off who maybe don’t immediately get the game from the screenshots or box art and then can’t work out what the game is actually about.

The good news is that it’s been technically easy to put the translations in so far. Whilst not perfect, it’s been relatively untroubbling to put in the code that lets us detect different languages and swap out text appropriately. We’ll probably come up against some problems when it comes to German, with its famously long words, and we’ve yet to try out a system for languages written from right to left, such as Arabic and Hebrew. The hope is though, that we can adapt the game as we go along / as we add more languages in the future.

As for sourcing all those different languages, it’s been bitty to say the least. Excited by the prospect of getting fans to help translate the game, and on hearing other devs have good experiences, we’ve posted out the call on twitter and facebook to help. However, there is a lot of text, and some of it is especially dense (the store descriptions) or boring (the e-manual notices about COPPA compliance and privacy policies). Since we’ve been asking people to help us for free, it’s only understandable that they can only give so much time and effort before it loses the fun and starts to feel rather like work. Equally, when we’ve asked friends and family, we’ve tried to use them more for proof-reading and double checking translations from elsewhere (though for one friend, corrections and edits turned out to be rather more work than either of us was expecting!)

missing_some_accentsMissing some accents?

We’ve also tried using resources like Polyglot, which whilst useful, will only get you so far before specialist or theme specific words start to crop up. How many games are there where “Demon spirit enemies are trying to knock your totem pole down”? (I don’t know, but betting Totem Topple is amongst the best of them!)

We’ve also used semi-professional translators from sites like, though it’s always difficult to know just what the quality of the translation is like. Many of those on the site are not individuals but collectives who farm work out, so no guarantee you’ll even get the same person translating next time. It’s cheap, but their work reflects on us, so we have to be very careful.

One area where we’ve tried to go the extra mile is with regional variations. Unlike English, which doesn’t really have dialects and is generally fairly uniform in its grammar and spelling, other languages can vary greatly depending on where or by whom they are spoken. In particular, Spanish of Latin America can be markedly different from that used in Spain itself, so our initial release will in fact have Mexican Spanish for North and Latin America, and European Spanish for European version.


What we haven’t done is fully localise the game for specific target markets. Mostly because we feel there isn’t much that we could change beyond superficial stuff like red colour used to mean good things, rather than bad things in China. (We’ve actually tried to avoid using red/green anyway because it’s an issue for many colour blind people).

With any luck though, we can reach the most people possible and through translating the game, bring smiles to the faces of those who otherwise wouldn’t have been able to enjoy the game.



Technical: Unity to Android

This will be a semi-technical piece, in a departure from the normal things I write about. It was initially a reply to a facebook post, but having poured all my knowledge into a single, comprehensive reply, I discovered I’d misread the initial question posed. So instead I’m posting it here. The question I thought I was answering was “What should I know about putting my Unity game on Android”

There are a few odd little technical things that can crop up when you first switch platform to Android in Unity. Mostly it’s solveable stuff though and no more than a couple of day’s work to get a build running on an Android device (or less if you’ve already downloaded and set up all the Android SDK’s, installed java sdk, set up environment variables etc). You may also find as you release, certain devices have odd bugs that are unique to them. They’re usually fixed after a quick search of stackoverflow but not before some user has got pissed off and left a 1 star review. You can head that off to an extent by looking up the lists of the most common Android devices, and using them against services that let you remotely test on different devices. But you’ll still be getting crash reports from your analytics package and/or messages from users of the most obscure devices for months after launch.

The big problem is resolution and screen size. In Unity you can force the game to stick in landscape or portrait, so you don’t need to account for both. But really, you need to have designed the game and especially the UI to be flexible and work at any given resolution and dimensions. (I prefer to do all my UI layouts in percentages of width and height when possible, but even then, things like text being too long for its surrounding box can easily crop up).


The game needs to work with a touch screen interface as well. Unity has Input.touch, which is fairly easy to figure out and Unity’s in built UI elements will mostly pick up touch automatically and treat it broadly the same as a mouse click. Some things will likely break or need some fixing from you though (e.g. drag & drop. Mouse hover doesn’t make sense either in a touch environment).

If you’ve made the game to use console controls, the good news is that Android supports many 3rd party Bluetooth controllers and Unity will automatically pipe through that stuff into your existing code, again using the Input class! Bad news is few people bother to connect their controller as it’s a pain to set up outside the game and can be really flakey in terms of reliability. So you’re going to have to do horrible stuff like virtual dpads (not recommended) or have a major rethink of your whole UI, both for gameplay and menus etc. As said before, Unity’s touch input is easy to get, but having to retrofit code to use it has potential to be a right pain depending on what you’ve done before and how much UI code their is to modify.

Performance is also an issue for many people with older or cheaper devices. You could pitch the game at the “check out how shiny this game on my brand new super expensive xyz phone that I just bought is!” Or you can, in the web portal you use to upload your game to Google play (app store), specify that you need a minimum Android OS version. Usually, lower end phones can’t handle an OS upgrade, so you naturally filter them out. You can also filter so only owners of particular devices can download the game but the list is as long as my arm and 5 columns wide, and you’ll always disappoint some users. Plus so many new devices are coming out, you’ll be continually be adding to the list forever after. I don’t recommend that approach.

There is no approvals process. You just sign up for an account with Google, pay a one time fee, upload your game, and a couple of hours later, your game is available to everyone in the whole world, from Poland to Pitcairn island.

There is some extra effort to put in In app purchase or advertising API’s, but it’s fairly easy stuff with a bunch of tutorials on the web on how to do it in Unity. (Forget premium pricing on Android. It just doesn’t work). Same with leaderboards and achievements, which take maybe a couple of days to do tops. You can spend more time putting in analytics engines, and again, all the good ones have quick, easy to implement Unity API’s or plugins you just download from the asset store.

Different countries also have different expectations of how to pay. India for example is all adverts and no one pays by IAP, whilst other countries IAP is the norm. Many places don’t have credit cards or don’t use Google Play, so telco/carrier billing is the way. Again there are a myriad of companies offering to help with that, all with their own API’s that if they’re worth their salt, will run in Unity.

Piracy is an issue. Even with Unity, it’s fairly easy for someone to reverse engineer your game, get hold of all your assets or hack the game to circumvent IAP checks. Pirating premium games is as simple as copy-pasting the right file from someone who has bought the game. You have to be prepared that once your game is out on Android, you may be unable to stop people using everything in it however they want.


Also, don’t forget stuff like Amazon app store and other odd non-google play 3rd party app stores, which can be more profitable than Google play (or totally useless depending). Don’t forget either Android TV stuff like FireTV or NVidia Shield or other Android set top boxes. They’re all a risk but could get you some good sales for just a few day’s work if your game is a good match. Again, they’ll all have their own API’s and plugins or packages you can download from the asset store or their websites, for Unity, with instructions, and should only take a couple of days to implement.

So overall, Android with Unity is easy to get started, but there are lots of little things to consider, depending on how professional / in deep you want to get.

On Apple TV (and why we’re sticking with Wii U)

Apple TV has been sat quietly at the back of Apple’s product line, ticking over for a number of years without the company making any sort of big, showy push for adoption typical of their other devices.

No longer it seems, with a large segment of Apple’s latest live show dedicated to the newly revamped set-top-box. They also demoed the remote control it will use, which includes amongst other things, gyroscope functions that make it very similar to Wiimote controllers used by the Wii and Wii U.

appleTV remote

For us, and especially for our game Flight of Light, that might sound almost too good to be true. The game is designed to use Wiimotes in a way that appears almost certain to work well with Apple TV. Moreover, the game is targeted at a more casual audience than the typical hardcore man-shooter fare sometimes associated with traditional games consoles.

All of which you’d think is great, and you’d be right. But not so fast! For now, we’re sticking with the Wii U, with a view to put the game on Apple TV at a later date. There’s a few reasons why:

Firstly, the Wii U is already here and we’re set up for development on it, whereas actually getting a game onto the Apple TV is still a way off for us. The game isn’t ready to launch yet anyway, so better to stick with finishing it on one platform before chasing others.

As I’ve said before, Wii U is also a much smaller, more manageable market for us. Whilst it is unlikely to ever bring in mega-bucks like the mobile app stores, it also means the damage is limited should we make any missteps when launching.

The Wii U’s smaller market, combined with its history, also means almost every game on the Wii U is guaranteed a certain level of coverage by specialist Nintendo and gaming press, and a good title has a real opportunity to shine and get noticed in a world where 2 or 3 games come out per week, rather than the hundreds per day as on mobile.

screenshot 2 08-08-14

At time of writing, we don’t know what the situation will be with the Apple TV store. Whether it’ll be a free-for-all like mobile iOS or whether Apple will take the opportunity to curate the store and hand-pick those games they want for it. Either way, visibility is king, whether it’s appealing to the consumer directly, or to Apple as gatekeeper. A Wii U launch gives our game that extra chance to do be seen. It’s a strategy others have made work - Start with console, then head to mobile later.

Apple TV is an opportunity for sure, but not simply because it’s a new device and virgin appstore territory. Rather, because we have the right product for the right platform at a time when we can take advantage of that. There’s still a lot of work to do on Flight of Light, and the game has taken a bit of a back seat to Totem Topple in the past few months. However, Apple TV is still an exciting development, even if not a “drop everything” moment.


Frantic First

Frantic mode is in many ways the “original” Totem Topple game with other modes coming later. In fact, Totem Topple was first forged in the fires of a 48 hour competitive game jam, meaning that there wasn’t time to implement many of the typical features of a tower defence game.

Instead it became an exercise in stripping back all extraneous elements and focusing on a single question: “What do I build next?” Place more wings now or try to build the totem pole up a bit further? Concentrate on damage dealing beaks or health boosting wings?


Once the decision is made though, it’s a simple case of pressing the right button. Unlike many tower defence games, the single tower concept means geography isn’t so much a factor in the game. There’s no need to navigate around different parts of a battlefield. There’s far less emphasis on building the right turret in the right place.

These combine, along with fast moving enemies and rapidly ramping up difficulty levels, to accelerate pace to the game, pushing the player to make their decisions faster. The overall effect creates the frantic, arcade style action of Totem Topple, offering a fresh twist on a genre usually associated with developing complex strategies and careful planning. (Don’t worry though, as that stuff can still be found in “Classic mode”).

Like Day and Night

One of the most fun things when making a game is adding the little details and touches that make a game feel alive. One of those is the day / night system in Totem topple. It wasn’t in the original plan for the game, but when doing the environment art for the later stages of the game, we ended up with some extra silver and blue scenes. With a bit of additional editing and few modifications to existing background elements, we were able to create a full set of night-time assets.


Similarly from a programming perspective, it was relatively quick to do a time-of-day check and depending on that, simply swap out the current set of mountains, clouds and background gradients with equivalent night time assets. The rising sun was replaced by a moon, with the rest of the game remaining otherwise the same.

Whilst certainly not as sophisticated as in some games, the day / night system adds a touch of variety to the game, and a nice little surprise for players to find.


Theme America

Totem Topple’s distinctive art style is one of the things that makes the game really stand out from the crowd, but how did the Native American theme come about?

It was in fact one of the earliest decisions we made when creating the game. After having settled on the initial design of a tower defence game, but in a single tower, there was a strong desire not to default back to the “usual” video game themes. No spaceships and lasers, no pseudo-medieval Europe fantasy worlds. Not because those things aren’t cool, but because they’re overdone and cliche’d.

concept art _1

The idea of a totem pole made a great fit conceptually with the game mechanics, which naturally lead to the native American theme.

Of course, we often talk about native American culture as a single thing, but there are significant differences between different tribes and regions. Totem poles have their origins in North West USA and Western Canada, and are not universal to all tribes.

Unfortunately the desert setting used in the game’s backgrounds doesn’t really match that, the mesas and mountains in the game being more akin to those found in the South West USA. Whilst we may add alternative background environments in the future, the more important thing to get right is to not accidentally cause offense with inappropriate use of what for many people is important and meaningful stuff.

In particular, we’ve avoided directly copying real world totem heads, wings or other artifacts and pieces of art. Often, they can represent specific spirits, Gods or ancestors, something that applies not just to Native Americans, but also other cultures who have totem poles or similar wooden sculptures. Of course, we’re always looking for feedback. Our hope is that even if the game is more “inspired by” native American culture more than being a true reflection, it’s at least inoffensive and maybe enough to inspire a few people to find out more about the real culture.

Getting Help!

Teaching new players a game is a dark art. It’s something that can vary hugely from game to game, and have a massive impact on players’ enjoyment, yet is discussed nowhere near as much as it ought to be.

Ideally there should be many different, complimentary systems in a game to allow player learning, catering for how different people learn in different ways. For Totem Topple, it’s an area where we’re constantly looking to improve, but for now, we have a few ways to help new players:

frantic tutorial


There’s an argument that well designed games shouldn’t need any sort of formal tutorial. That intuitive controls and smart level design will teach players through action and interactivity (or rather, trial and error). Whilst that’s the ideal solution for many games, it’s not appropriate for every game. Especially those, such as Totem Topple, which have a layer of conceptual abstraction: The player doesn’t actually have an avatar physically building the totem pole for them.

For Totem Topple, we have a “jump through hoops” style tutorial, where players are required to perform specific tasks, accompanied by contextual information explaining why they need to do them. Fortunately, most of the subtle complexity of Totem Topple comes from the decisions the player makes, rather than mastering the mechanics.

The tutorial teaches the player how to press the buttons, without telling them which buttons might be good or bad to press in any particular scenario.

Pause Help

However, it’s difficult to work out what each totem piece does simply from observing what they do in game. The heads in particular, there are no obvious clues from the way they look as to what exactly they do, (aside from delay inevitable death by making your totem pole that little bit taller). That’s largely a consequence of the art style used in the game, which for various reasons we can’t really change.

Instead, Totem Topple has an in game Help system. Players can call up the help system at any time, pausing the game and allowing them to get both descriptions and the underlying numbers / stats on different heads. Importantly, when played in Off-TV mode, players can also call up information on enemies and heads in play. This way, they can see the actual effect of placing this wing on that head, or how much damage this enemy took from that beak.

classic help


Feedback is one of the more subtle systems to help bind action with consequence. It’s all the little visual and audio cues and clues that most of the time are only picked up subconsciously by the player. It could be as simple as having a sound play when a player presses a button, or having a big red minus flash when an enemy does damage to a wing or head. This is one area in particular we’re going to be adding to in the run up between now and launch.


A Classic Strategy

A lot of people playing Totem Topple have commented that they’d like a slower paced game. One where they can sit and think tactics, and where reaction times aren’t so critical to success.

Rather than change the game completely, we decided to add in a new mode. We dubbed it “Strategic” mode, owing to the slower, more cerebral type of gameplay we were looking to create. Initially, strategic mode consisted of slower enemies and longer times between waves, to give the player more time to plan what they would do next. We also set the head-selection to not randomise after each placement of a new head/wing/beak to the totem pole. Instead players would be presented with four heads/wings/beaks and then choose which order they could place them down in.

totem topple strategic 1

However, the changes didn’t quite achieve the results we were looking for. Instead of giving the player time to think, the slower enemies at the start of the game, gave players the chance to slap down a load of heads unchallenged. Sometimes they’d built a super strong totem pole that shot every enemy before it could reach the base. Other times they’d continue straight on past the red line and be devoured by a bunch of super-hard enemies. In both cases, the link between enemies knocking down the tower and the need to then build back up the tower was broken, leaving players confused as to what they should be doing.

Another problem was that the enemies would still spawn at the same rate. Once the first enemies did eventually reach the totem base, the game became just as frantic as before. Longer intervals between spawns conversely gave players too much time to recover and rebuild their totem pole.

The extra choice given to the player of which order to place the heads etc similarly fell flat. With just four options, there was a very limited number of combinations. Neither was it particularly clear how different combinations made an actual difference to the game. And since the four options were randomly picked for the player, there was no sense of player agency.

We tried a system whereby players could see the next four heads coming up after the current four, so be able to plan a bit further in advance. And we added the ability to “skip” to the next set of four, in return for a time penalty before players could pick another head. Unfortunately, this still didn’t have the desired results. Players were still restricted to what felt like arbitrary choices.

So we decided to give players the option to choose any head, wing or beak they liked, at any time. To balance this, we introduced a currency system, with a cost to placing each different totem piece. Players then earned currency by destroying enemies.

Totem Topple Frantic Dual 5 Screenshot 2015-08-18 15-34-53

We were a little reluctant to do this, as to an extent, it doesn’t really fit with the original intention and vision for the game. It turns it into something much closer to a traditional tower defence game (hence calling this mode “Classic”).

However, from a gameplay perspective, we feel it works well, and definitely gives the player both a greater sense of agency, and the ability (along with the pause-help system) to really take their time and plan their next move.

Two Headed Disaster

Full of optimism, I took Totem Topple down to Brighton last month, and duly presented it at the PocketGamer Big Indie Pitch. The game did not win any prizes and was quite heavily criticised by the judges. Whilst maybe it shouldn’t have come as a surprise, it was still disheartening and led to some considerable introspection.

To give a little background, the Big Indie Pitch involves indie game developers doing a sort of “speed dating”, spending 3 minutes face-to-face pitching, presenting and letting play to one or two judges at a time. Then when the timer is up, swapping tables and pitching to another judge. At the end, the judges confer and pick a winner.

big indie pitch brighton 2015Scene of the crime

Things quickly unravelled once I got down to pitching, with a number of the judges wholly unimpressed. The problem was two fold:

Firstly, going into the event, the game was set up in production mode, so that once the tutorial had been completed, it remembered that fact and didn’t show up on next play through. After the first pitch, it was left down to me, in lieu of the tutorial, to try and explain the game as fast and succinctly as I could. All whilst the judges sat there, determinedly trying to play it.

A good tutorial accounts for the fact different people learn different ways, and some will always want to just jump in and start mashing buttons to see what they do. Unfortunately, this rapidly caused an issue with one of the game’s key features: It’s dynamic AI system.

The game is designed so that when the player is struggling, the difficulty of the enemies drops right off, with just a few especially weak enemies spawning. Provided a player can ride out the last of the difficult waves of enemies from before, they’re given a breather. A chance to recover before the difficulty begins to ramp up again.

At the time, the game did this by just counting the number of heads the player had left alive. The tutorial started players off with 3 extra heads, already putting them above this limit. However, the next play through, which is what the judges played, would only give one starter head.

Cue judges placing a single head and waiting to see what it did. Then when the starter head finally got destroyed, placing another head to replace it. And so on, at painfully slow pace, with the enemies never getting harder and the judges never getting beyond two heads at any one point. In some cases, leading them to write off the game completely as lacking player agency.

We’d had it pointed out before that this “trick” essentially nullified a large part of the game, letting players build risk free to infinity. But somewhat foolishly, we’d dismissed the idea on the basis that people would get bored with that tactic and default to just building quickly to match the “frantic” pace of the game.

Now, at the worst possible time, the same issue, but from a new player’s perspective of trying to learn the difference between each head, was painfully exposed.

We’ve since added in not only a new tutorial system, but also a sophisticated help system for those that like to skip tutorials. I’ll detail those changes in a later blog. And the AI system now has different checks for when the player is struggling, which should encourage players to naturally build up. (Though I’m not going to detail how as that would give the game away!)

And as for the pitch? Suffice to say, spending half my very limited time apologising for the lack of tutorial, and the other half telling the judges they were doing it wrong, didn’t go down well. It wasn’t a great experience, but we’ve learned from it, and the game is now all the better for it.