Damian Connolly | divillysausages.com

Moving on

Mon, 23 Jan 2023 20:40:00 +0000

I'm a little bit late doing this (it's been over 6 years since my last update 😅), but after nearly 10 years at TripleFun, then Betclic, I'm moving on and joining Spendesk as a Senior Back-End Engineer.

It's a bit weird to think "10 years".

10 whole years.

It's such a long time, but it doesn't feel that long when I think about it. Time has flown.

TripleFun was a journey and a half - multiple different games across different technologies (Flash, native with Obj-C, then Unity) culminating in Microgolf Masters, a game which ultimately touched a few million players. Along the way, I made a lot of mistakes, learned how to fix them, and started on the continuous learning path that I've been able to benefit from since.

I started with backend code, learned how to handle servers on AWS with the help of some very talented people, learned a ton about admining a game of that size, handled the support for a number of years (if one thing teaches you about the game you're making, handling support for it is that thing), learned about tools, and statistics, and analytics, and prototyping. In short, if you want to have a hand in everything, join a startup.

When our CEO, Nicolas, went back to Betclic, he brought TripleFun with him, and we slowly merged into a larger whole. Over time, the focus became less on making games and more on using our unique skills to benefit the mothership. We made a lot of prototypes touching on a lot of subjects, and again, thanks to some amazing people, I was able to add a few more skills to my belt, most notably everything serverless (AWS, Lambda, DynamoDB) and later Flutter (which, in my opinion, should be the first and only step if you're looking to develop apps - seriously, I ❤ this tech).

I guess the flow of different projects and technologies contributed to that feeling of time flying by. It's interesting that the more you learn, the more you realise that all the flaws in everything that you did previously could be handled sooooo much easier with the knowledge and tech that you have now. But I suppose the nature of things is to keep building and keep making the next thing that bit better.

So, after nearly 10 years, I'm starting a new position in a completely new domain, learning a new way of doing things. Everything is different, and the experience has been humbling to say the least 😅 (Imposter Syndrome is real 😂). TripleFun and Betclic have been fantastic places to work, and I wouldn't be where I am now without them. I know they'll have the greatest success (anyone looking at Betclic's transformation over the last number of years will agree), and I want to thank Nicolas Beraud for the opportunity that came my way back in 2013.

Let's go 🚀

Microgolf Masters: Tips, tricks, cheats, & hacks

Sun, 04 Dec 2016 23:40:00 +0000

Microgolf Masters is our realtime multiplayer golf available on iOS and Android. Want to know how a simple way to get unlimited gold and diamonds? Read on...

TL;DR: You can't.

Like most devs, I occasionally put the name of our game into Google to see what comes up. Sometimes I fall on reviews, sometimes I get Let's Play videos on YouTube, but often I find sites that promise you the world for nothing. Normally, the obviously auto-generated layout of these sites should be enough to let you know that it's not exactly legit, but recently I came across a site that was quite well made, to the point where it got me thinking, Hey, hang on a minute...

The thing is, and I want there to be no doubt about this:

There is no way for an external service to give you free gold or diamonds
There is also no way for someone to modify the game client to give you free money

See, everything in Masters goes through the server and the DB. When you win anything, it's the server that gives it to you. When you buy anything, it's the server that says if you can afford it. When you connect to the game, we download your details from the server, so there's nothing on the client to change. Even if you did modify the memory variables to give yourself more cash on the client, you wouldn't be able to actually do anything with it, because the server rules all; it knows what you actually have.

The DB itself isn't accessible from the public web, only through internal routing, so no-one can connect to the DB to update your info.

Except us, obviously.

If you go to a site and they ask you to run something, it won't work. If they ask you to install something on your phone, it won't work. If they ask you to install something on your PC, it really won't work.

And in the best traditions of there's no such thing as a free lunch, these sites aren't doing this out of the gratitude of their hearts or just for the lols. Best case scenario, they're driving you towards a page full of ads, worst case scenario, you've just installed malware on your computer or are now part of a botnet.

So this is a Public Service Announcement: don't fall for this please. They can be convincing, even to us. But be safe and ask yourself if the possibility of getting some free coins in an online game outweighs the probability of putting something bad on one of your devices (hint: it doesn't).

If you've ever run one of these - and not just for our game - then the first thing you need to do is to run a scan of your system. If you find anything, then I'd recommend CCleaner or Malwarebytes to get rid of it.

Stay safe, players.

Microgolf Masters

Sat, 04 Jun 2016 23:40:00 +0000

Microgolf Masters
Images

This one was a while in coming - our current TripleFun game: Microgolf Masters.

About the game

Masters is the sequel to MicroGolf Challenge, itself the sequel of MicroGolf, so it's interesting to see the evolution of the game as time has gone by. As of the time of writing, MicroGolf Challenge has been removed from sale to stop any confusion amongst players.

While Challenge was a good game and enjoyed modest success, there were problems with the inherit conception of the gameplay and monetisation, so after meeting with other CEOs of mobile games companies, Nicolas decided that the best course of action would be to release a new game. That way, we can make any number of breaking changes with the previous one without suffering the wrath of an existing playerbase.

And there were a hell of a lot of changes. Here are just some of the differences:

More granular upgrade system (In Challenge we underestimated just how quickly players would progress). Balls can now also give boosts
Progression through courses was replaced by a League system (previously named Rank). Winning matches gained you crowns. Win enough crowns and you pass to the next League. The top League is Masters, where the ranking is ELO based.
A new season system. Every week, a new season begins. You win rewards based on how you placed in the previous season, and your League would be reset (depending on where you finish, it'd be reset more or less)
A new solo mode, where players are presented with a new course every day. Get the best score of the day for your League, and you win rewards, as well as a medal for your profile
8-player Tournament mode, where players face off in 1v1 matches until there's one winner. Amongst other things, that winner gets a trophy for their profile
4-player free-for-alls, or 1v3, where 4 players play on the same course, which is pretty fun
A Card system. As you play, you'll win or buy Cards, which can be used for all sorts of things, such as getting new balls, upgrading your stats, getting Boosters, etc
Boosters! In games, you're allowed to bring 2 boosters with you. These are special items, that used at the right time, can turn the tide of the game. Some of the Boosters included are extra Strength/Accuracy, Confusion, Anchor, Invincibility, Assassin, and Unsinkable.

More updates are coming down the line. At the minute, we're finishing up a big performance update, to get the game back up under 60fps and silky-smooth, and after that we're planning on a teams feature, where players can face off against each other in 2v2 matches.

A bit about the development

Challenge was our first Unity game, so by the time we tackled Masters we had a bit more experience and could tell what was working and what wasn't. Although we were working from the same codebase, we profited a bit at the start of development to restructure and refactor anything that wasn't up to scratch.

One thing we set from the start, which I'm glad about, it focused solely on Android development, so we were only on one platform from the get-go. This was a huge timesaver in the long run, as, if you don't know about it, the time to release on different platforms is wildly different.

Though it's better nowadays, iOS would routinely take ~2 weeks to validate a release. As you're working in sprints of about 2 to 3 weeks, this meant that you had to support the version in dev, the version in pre-prod (that was currently being validated), and the version in prod. So anytime there's a bug, there was a 2 to 4 week delay before we could fix it (once you've figured out if it's already been fixed or if it's a regression).

Android, on the other hand, has a release window of a few hours. The difference is day and night. Release in the morning, then monitor, and you still have time to scramble a fix if necessary. As an anecdote, we were cleaning up plugins and requested permissions, and I removed one that inadvertently changed the path to the Application storage directory, which is where we saved the player's save file, including their login details. So I borked every single player that wasn't signed in with Facebook. Needless to say, that's a good feeling. Happily, the files weren't gone, so once I'd found the problem, two releases in the same day later, everyone was back up and running. That would have been impossible on iOS.

Another thing that we did was enlist the help of fellow Unity devs BeTomorrow. They're based just down the road from us, and we had help from Gaël Lequeux and Alix Fumoleau, both of whom brought their Unity expertise to the table and helped us out with the UI and perf.

We're also using the services of Logmatic.io, which is a company specialised in logging and metrics. We had our own solution, but we'd always have to wait a day before the logs were available in our backend. With Logmatic, all logs come in in real-time, and we can do some pretty deep searches. This is a life-saver when it comes to support and bug-hunting. As a result, the majority of support questions can be resolved in around about a minute from the time we open the mail.

The release

Masters was in soft launch on Android for quite a long time before we pushed it on iOS. All in all, there were around 25 versions released on Android while we added, fixed, and polished new features.

When we did release on iOS, it was to a pretty awesome feature. We ended up on the home page of the US iTunes store and ended up in the top 10 overall, and top 5 for sports and strategy. On the french store, we hit #1 and #2 for sports and strategy respectively. Considering the other games on offer and their respective advertising budgets, this was huge!

The effect of this was pretty immediate; we were gaining around 50k players per day. Our server started crying, but the effect in game was pretty impressive. Searching for games was immediate. Even tournaments, which would normally take a bit longer to fill up, were instant.

On our end, aside from the heady rush that comes with topping the charts and having a huge influx of players, we were scrambling about trying to make sure everything kept running. Our poor server guy, Camille, got about 3 hours of sleep until we could nail down a deadlock situation that was happening if players did specific things in the tournament. Once you start getting big, the law of large numbers takes over, and what can happen, will happen.

All in all, we can't really complain. To be featured at all is a massive gain, and can easily make a company. The fact that we were able to build and release so quickly on Android meant that we were coming to iOS with a pretty solid app that had already proven gameplay, so it was well received.

One mistake we did make around this time was to reset the League of all existing players. The rationale was that we'd just made a big change in how the League system worked, and we'd start all players off on the same foot, but it obviously could never been the case. Old players figured themselves unjustly treated (players love getting new things, but absolutely hate losing them, especially if they've felt they've worked for it), and we got slammed in the ratings. New players, on the other hand, were coming in, and right away facing off against seasoned opponents with much higher performance and better balls, so they were getting creamed in games. For them, they didn't know what was going on, so it was just like the game was badly balanced, and I'd say we lost a good number because of it. I think the day after that update when live, I must have answered over 200 emails on the subject :D

Lessions learned

With every game, we learn something new, so here are a few of the take-aways that have stood out for me:

Unless you have a specific reason not to, focus on Android first. While for Masters the ratio is currently something like 6:1 in termes of iOS:Android, focusing on Android first allowed us to nail a lot of the functionality and bugs before releasing mass market. Once iOS is in the measure, expect your effective dev time to double
Sometimes all you need is a little presentation change. When we first released tournaments, we had maybe 1-2 a day, simply because it was so hard to get 8 players together at once. Players would join, see no-one, then leave. To get into a tournament, it wasn't uncommon to wait for half an hour or just get very lucky. We were discussing all sorts of solutions, each of which non-negligible in terms of development. In the end however, we went with a simple "Starts in..." countdown that would automatically show over the tournament button on the client for 5 mins every half an hour. No server integration or fancy logic, just a simple label. Result: the next day, we had over 400 tournaments played
Don't use Scenes: I can't count the number of problems we've had because we've used Scenes in our game. If you're just doing a hard switch, then maybe you can get away with it, but the minute you start trying to do transitions, you're opening yourself up to a world of hurt (all special classes (e.g. Android Native) need to be marked DontDestroyOnLoad, you'll have to create your own destroy-all-old-GameObjects logic, only to discover some wonderful consequences (UnityIAPs, I'm looking at you), in an old version of Unity, destroying a Scene cleared out all statics declared while that scene was active, etc)
In the quest for performance, you'll find yourself going against the Unity grain as often as not. When you first start in Unity, everything is components-this, and components-that. After a while, you see that you've about 10k active objects in your scene and they could all be replaced with simple non-component code. You'll also find that the default shader for 2D sprites is suuuuuuuuper slow. Write your own. I wrote a whole post of different performance tips for Unity.
Getting featured by Apple is a big deal. Overnight we added maybe 700k players. This was just after our server guy went on holidays and you suddenly find your server falling over under the load, or threading/race conditions/deadlocks now happen with frightening regularity. Sorry for ruining your holiday, Camille :D
Invest in your support tools. As previously mentioned, Logmatic.io soon proved themselves pretty useful in helping find and solve problems, but the other end of the stick is being able to do something about it. With each release, we've beefed up the support tools. Everything happens through restlets for ease of use. Some of the things you should be able to do:
- Search for players by key, ID, nickname, transaction ID. Generally, anything unique. If you're not returning the full Player object, then you should at least have all the important info
- Gift them hard and soft currency, in-game items, you name it. If they can get it in the game, you need to be able to gift it
- Change their XP, level, or League. This is also useful when testing, and you have gated content
- Change their stats, win-loss ratio, medals, trophies. Again, also useful for testing leaderboard/profile display
- Have a way to transfer/recover accounts, as people will lose access to theirs, and they'll sooner quit that start all over again
- Push new content, and reload it into memory without having to restart the server. We can do this with pretty much any of the data objects in the game, so adding/changing/fixing content is relatively easy
- Assign A/B groups if you have A/B testing
- Turn on and off features of the game, such as debug logs, A/B testing, access to non-essential features such as leaderboards etc
Know why your players are spending and what they buying. Without a doubt, I think the most important feature of the game is the ranking leaderboards. The people that will get the most addicted to your game will be the ones at the top, and they'll generally make repeated purchases to keep their advantage
Analytics and metrics are super important. While there are a lot of debates over gut- vs data- driven game design, you can't deny the usefulness of seeing the immediate results of your choices. At the very least your data should be set up at a cohort level, so you can effectively measure if you've improved in the right areas.
Be careful touching monetisation. Early on in development we modified the economy of the game to make things cheaper. Woah boy, was that a mistake. Aside from tanking our revenue to about a third of what it was, we'd never gotten so many emails. People were complaining that things were cheaper. Once you think about it, it makes sense: those that have purchased, especially just before the update went live, immediately had their purchase devalued. After the update, the same purchase would net you about twice the amount of in-game items. This was especially bad with players that had made repeat purchases, as they felt that everything they'd spent was now worthless, even though they were technically our most valued customers. Interestingly enough, a small percentage of players were also angry because it now let other players reach their level easier. When the economy is tight and IAPs are relatively expensive, purchasing something gives you a distinct advantage (better equipment etc), so some players were enjoying topping the charts simply because their purchases put them out of reach of most players. It's something to think about.

Play Microgolf Masters

Microgolf Masters is available on both iOS and Android, so go give it a shot. Once you're in on it, it's very competitive. We've got the whole floor where we work playing it after lunch and 4-player mode is genuinely fun when you're all together.

You can also check out some images of the project.

Microgolf Masters Images

Sat, 04 Jun 2016 23:10:00 +0000

Microgolf Masters
Images

Some images from Microgolf Masters, available for iOS and Android.

I'm an author!

Mon, 16 May 2016 17:06:00 +0000

Things have been a bit quiet on the site at the minute, as aside from working on Microgolf Masters (which I'll write about soon), I wrote a book!

It's called Shepherds: Awakening and it'll be out on Amazon soon in eBook, then soft-cover formats.

To go with that, I've created another site, damianconnolly.com to act as my author persona (this being my developer one). I'd originally grabbed the domain a long time ago and it was serving to redirect to this site, but I figured it was best to separate out the two seeing as the perspective audiences could be quite different.

On a side note, a big shout-out to my hosting provider SiteGround, who once again have been a huge help. When I had a question, I opened a support ticket, and literally 9 minutes laters, they'd answered and fixed it.

I'm currently setting up a mailing list, so if you'd like to get yourself an advanced reading copy of Shepherds: Awakening for FREE, then head on over to the site!

Leaving Jekyll behind

Sun, 24 Jan 2016 18:50:00 +0000

Update 23/01/2023: After about 6 years of leaving this project as-is (I haven't been very active updating the site 😂), I finally wanted to get the finger out and make the site automatically build and release whenever I pushed a commit, so I put on my big-boy pants and spent the weekend updating all the dependencies, removing those that were no longer necessary, and generally turning it into a project that can be run via CI/CD. See the section at the end for details.

A while ago, I posted on how I was moving away from Drupal towards Jekyll, thus changing from a dynamic site to a static one. Well, over Christmas, I upgraded my 8 year old laptop for a spanking new Dell XPS 13 (which is great btw) and in the process of reinstalling all my programs, getting my different dev environments set up, and generally keeping my computer as fluff-free as possible, I took a good look at what was actually necessary.

Jekyll uses both Ruby and Python. I had originally installed Ruby a long time ago to test some Ruby on Rails stuff, back when it was the hot stuff, so it influenced my decision to install Jekyll in the first place. For my new laptop, I didn't want to install both languages just to generate my site, and firing up my old laptop just to do a build seemed like a pain (once you go SSD, you never go back), so something new was in order.

Enter heckle

I do do Node.js development though, and in searching around for a Node.js Jekyll replacement, I came across heckle, by marijnh. It seemed pretty straight-forward and did everything I was looking for, with the exception that it uses Mold as a template language instead of Liquid. Hmmm...

Enter liquid-node

Hunting around some more, I came across liquid-node (changed to liquid), by sirlantis. Liquid-node is a port of the Liquid template engine to Node.js, using Promises for all the asyncy stuff. Two points stood out on the features panel: "Based on original Ruby code" and "High test coverage". Seems like it would do the job just nicely.

JekyllJS

I started a project (TypeScript), based off of heckle, using liquid-node, and named it JekyllJS, the idea being that you could take your existing Jekyll site, run it through JekyllJS, and it'd produce the same content.

All in all, development went surpisingly smoothly. I found another Node.js module, js-yaml to handle reading the _config.yml and each post's frontMatter, and with heckle's code as a reference, I was able to get something up and running pretty quickly.

Until I hit an Unknown tag: "{% highlight %}" Exception anyway. I guess Liquid has been updated since the Node.js port happened.

Highlighting code

I have a lot of code samples across my site, and you can set up Jekyll to use Pygments or Rouge to handle this for you. I didn't find a Node.js equivalent, so I settled for highlight.js, which happily allows itself to be installed as a Node.js module to allow for server-side pre-rendering (as opposed to each client highlighting the code on each page load).

Liquid-node allows you to write your own custom tags, so I wrote one for the {% highlight %} tag that takes the chunk of text, and pipes it through highlight.js. The results are obviously different from what Pygments or Rouge generate, but I can live with the difference - as an added bonus, the CSS is smaller.

Other differences

I also had to hack a patch for the {% include %} tag, as the liquid-node version doesn't allow for tokens in order to use dynamic includes, which I use for adding comments and files to posts. The patch doesn't handle assigning variables, but there's an issue open for it, so maybe it'll happen in the future. It's included at the end of the post (as liquid-node is written in coffeescript and I don't know that). Just replace the include.js file in the node_modules/liquid-node/lib/liquid/tags/ folder after all the dependencies are installed.

It looks like this has been fixed, though as I changed how I was doing things, it was no longer an issue though. I did have to rewrite {% include_if_exists %} tag though, which I used to automatically include files and comments for posts when the relevant include exists. In any case, as liquid is no longer actively maintained, you're probably better off moving to liquidjs, but I didn't have the heart to changing rendering engines after getting everything working again 😅. The update to the {% include %} tag does mean that you need to drop the filetype from your includes. So {% include footer.html %} becomes {% include footer %}

When I added Markdown support using the marked node.js library I found that it was escaping all quotes for all reasons, including normal text ("don't", "can't", "I'm", etc). I don't particularly like this behaviour (it's still valid HTML though), so I added a fix around it. Just replace the marked.js file - included at the end of the post - in the node_modules/marked/lib/ folder if you want to do the same.

Another difference is the way that dates are parsed. Normally in your frontMatter, you'd specify a date like so:

date: 2016-01-23 19:50:00 +0100

and Jekyll would treat this date as-is, i.e. +1hr after GMT. JavaScript however, takes into account Romance Daylight Time, which handles the extra hour for daylights time. This means that if you're in the EU and you use CET during the winter, you'll use CEST during the summer, or during the last Sunday of March to the last Sunday of October, and +0100 will act as +0200.

var d1 = new Date( "2016-03-01 00:00:00 +0100" ) // Tue Mar 01 2016 00:00:00 GMT+0100 (Romance Standard Time)
var d2 = new Date( "2016-04-01 00:00:00 +0100" ) // Fri Apr 01 2016 01:00:00 GMT+0200 (Romance Daylight Time)

Depending on when you've published your post (i.e. the date), this behaviour can change the rendered day, or even month, which may or may not be a problem for you. I've not found a way around this behaviour, but if it's affecting you, you can try changing the date set in your frontMatter.

As for categories, I don't use them in my site, so I've no idea how they're supposed to render, so I didn't include them in JekyllJS.

The final thing I came across was when using {% if %} checks. I was checking to see if a variable was set in one of my templates using {% if someVar == null %}. For liquid-node, I had to change this to {% if someVar == undefined %} or simply {% if someVar %}.

The JekyllJS config

JekyllJS comes with a simple config file, config/default.json, meaning you can change a few things without having to re-compile the project. It looks like this:

{
	"src":{
		"404":"/404/"
	},
	"meta":{
		"keywords":"default,keywords,here",
		"description":"default description"
	},
	"opengraph":{
		"fb:admins":"XXXXX",
		"og:type":"article",
		"og:image":"/img/open_graph.png"
	},
	"highlight":{
		"parentClassName":"highlight",
		"shouldWrap":true
	},
	"server":{
		"port":4000
	}
}

which translates as

src.404: the path for the file to serve as the 404 page, if you have one
meta.keywords: the default meta keywords to add to each page if the page doesn't specify any. Set to null or leave out to ignore this
meta.description: the default meta description to add to each page if the page doesn't specify one. If null or left out, then the description in _config.yml will be used (if set)
opengraph.fb:admins: the ID of the Facebook user that you want to associate as the admin of the page. If null, then it's not added to the page
opengraph.og:type: the default type for each page, unless overwritten. If null and not overwritten, then it's not added to the page
opengraph.og:image: the image to use as the default OpenGraph share. If null and not overwritten, then it's not added to the page
highlight.parentClassname: the classname for the parent node for highlighted code. Use highlight to keep with the Jekyll generated code, or hljs to use the highlight.js version
highlight.shouldWrap: Should we wrap our generated code in a div? Use true to keep with the Jekyll generated code, or false to use the highlight.js version (in which case the highlight.parentClassname will be applied to the code tag
server.port: the port to use when serving the site

Create this config file in the root your site project (e.g. as _siteGenConfig.json). When executing JekyllJS, the code will take that folder as the site path to start discovering and parsing files.

Running JekyllJS

I compared the generated site using an SVN diff, and aside from the Date and difference in highlighted code, it matches out. If you try it and see something, let me know.

~~As for running it, you can generate your site using~~
~~node app.js | "./node_modules/.bin/bunyan" -o short~~
~~from a command line. The bit at the end is just running the output through Bunyan, which is the logging lib I use in the project.~~
~~If you want to test your site, JekyllJS will also serve it for you via~~
~~node app.js serve | "./node_modules/.bin/bunyan" -o short~~
~~which will start a local webserver under the port set in the config. It'll also handle 404 errors with the specified URL.~~

I've completely changed how to run JekyllJS and generate your site in lieu of it supporting CI/CD environments. Previously, you executed code from the JekyllJS folder, which didn't make any sense. Now, you create your config file in the root path of your project, then create a new npm project and install it as a dependency:

npm install --save git@bitbucket.org:divillysausages/jekylljs.git

Once that's done, you can create scripts that will generate and build your site, and optionally serve it locally, using npx:

"scripts": {
	"build": "npx jekylljs ./_siteGenConfig.json",
	"serve": "npx jekylljs ./_siteGenConfig.json serve"
}

When running this in a CI/CD environment, simply deploy the _site folder to S3.

Get JekyllJS

You can find the code over on Bitbucket, and you can install the dependencies using npm install. Also on site is the liquid code that I use to generate my tags, archive, and feed.xml if it's something interesting to you.

Performance tips for Unity 2d mobile

Thu, 21 Jan 2016 21:33:00 +0000

Update 09/2018: As this is one of my more popular posts, I've updated it with even more tips that I've learned in the meantime. At the time of writing the update, we're using Unity 2018.2.

At the minute I'm looking into performance with our latest game, so I figured I'd gather together all the different tips that I ended up using to get our game running back up at 60fps.

You see, it used to run at 60fps no problem, but as development continued and the Unity versions piled up, occasional hiccups became more and more obvious, so it was time to dig down and figure out what was going on behind the scenes. ~~We're currently Android only (as it's a ton quicker to iterate and get everything working as it should), but~~ The latest Unity version (5.3 as of - original - writing) seemed to exacerbate the performance problems on this.

Our game

There's no one silver bullet to optimisation, and what works for one person mightn't work for another, so with this in mind, this is our game constitutes of:

It's a 2D golf game, for mobile, using basic Sprites
It uses multiple scenes, and the new Unity UI
In the game scene, the world map is built with individual tiles
While the levels are still built with individual tiles, we now render all the static tiles to a single RenderTexture, which sharply reduces the number of draw calls
It's multiplayer, so you get CPU spikes as messages come and go
We've since moved the compression/decompression and serialisation/deserialisation to different threads, so while there's still the issue of memory etc, there's less of an impact on the framerate. In the long term, we'd like to move to Unity JSON and the built-in compression etc in .Net 4.5, but it requires some work
We don't use any lights, multiple cameras, etc

It goes without saying that the performance issues were found using the profiler, so if you have it, it's something you should be using.

Also, these tips are mainly focused on 2D. Your mileage may vary.

The dumb stuff

Let's get the dumb stuff out of the way first. These are the simple things you need to do, and don't need much discussion.

Set your Application.targetFrameRate to 60. By default on mobile, it's 30
Otherwise you can turn on vSyncCount in the quality settings. Apparently, on some Android devices, with Android 5, you can render at more than 60fps, so if you don't force vSync, you run the risk of an unresponsive device, as it's rendering too quickly, so it's possible that future versions of Unity will force this
I originally misunderstood the first two points. I'd assumed that Application.targetFrameRate was the "code way" of enforcing vSync. Because we were switching from 60fps in-game to 30fps in the menus (good for battery life), we switched off vSync and just used Application.targetFrameRate. However, they're two very different things, and what ended up happened was that the CPU was issuing frames faster than the GPU could handle them, as we ended up with intermittent stuttering. Enforcing vSync makes the CPU wait. Basically, the framerate went from https://imgur.com/a/lE0LedF to this https://imgur.com/a/EPq6q7T.

Now, I'd highly recommend enforcing vSync. Unity doesn't recommend using both vSync and Application.targetFrameRate at the same time though, as it could lead to CPU frame drift. If you'd like the full story, you can find the thread here.
When testing, test on an actual device - you can run on the desktop to make sure it doesn't crash, but it won't tell you a tap about what's happening on the device
If you're not using object pools, use object pools
Use something like TexturePacker to pack your images into one, so you can get Dynamic Batching going
Remove empty callbacks from components. If they're there, even if there's nothing in them, they'll get called, which slows you down
Cache components you use regularly. Ditto for GameObjects. No GameObject.Find() when you can get away with it, especially not in Update/FixedUpdate
Disable/Disactivate GameObjects/Components when you don't need them, especially if they have Update/FixedUpdate calls
If using physics, don't move Rigidbody2D yourself (i.e. directly setting the postion), especially if they've been marked as static. The physics engine doesn't like and will let you know. If you need to, disable the GameObject, set the position using the Transform (there's currently a bug when setting the Rigidbody2D.position while the GameObject is deactivated), then re-activate it
Watch your poly count. We had a pretty high-resolution ball, which was fine with 1/2 players, but we'll be releasing soon with 1v3/teams, so all of a sudden your poly count doubles
If you have lights in your project, but don't need shadows, or don't need shadows on everything, turn off the Cast shadows/Receive shadows checkboxes on the relevant MeshRenderers
Don't use Coroutines when a simple timer will do the trick. Coroutines are heavy

After that comes all the things that require a bit more effort on your part.

Let's go a bit deeper.

Control the garbage collector

One of the worst things that can happen in the middle of playing is the GC kicking in. You'll usually notice if it looks like your rendering is skipping every so often.

Now the important thing to remember is that the GC only kicks in when the application requests more memory. The default behaviour is to try and free some up before asking for more from the OS. This means that if you instantiate everything you need up front, and you have no other memory allocations during play, you'll never have a problem with the GC.

If you're using object pools, easy, right?

The killer is the hidden allocations. These can be big or small, but they build up until eventually your application requests another memory page, resulting in the GC crapping all over your game.

Now you might see something like a few hundred bytes every frame, and think, "No big deal". At 60fps, 100 bytes becomes ~6KB a second, ~350KB a minute. It all adds up.

Using a foreach will allocate 32B of memory for the enumerator. While it might not sound like much, a couple of these inside an Update/FixedUpdate and you'll feel it
Adding or removing a callback from a delegate will allocate 104B of memory. I've not seen a way around this outside of directly calling the method (introduces dependencies etc), or, depending on your use case (e.g. UI needs to show the player's health), you can use ScriptableObjects
Strings allocate memory as you create them. Keep a special eye out for concatenation - "Hello " + "world" - as in this case you're actually allocating 3 strings here, one for each part, and one for the final result (strings are immutable). This is pretty easy to do if your calling Debug.Log() a lot. Using StringBuilder or the String.Format() where you need to
Know the difference between classes and structs and when to use them. Classes are created on the heap, while structs are passed by value. Be especially careful of Lists of structs
If you see SendMouseEvents showing up, then you're hitting a dumb bug with a GetComponent() call. There's some code in the MouseEvents class that does a lookup for a GUILayer component on your camera. Normally GetComponent() calls are cached, however Unity can't cache it when it's null, meaning you get hit with it every frame. Solution: add a GUILayer to every camera in the scene. You'll get a warning that it's a deprecated class, but there ya go
If you see IMGUI showing up in your GC panel, that's the legacy Unity UI code. Comment out any OnGUI calls that you have running outside of the Editor platform
Pre-size any Lists and Dictionaries, even if it's a complete guess. The default limit is 0 when it's created, then 4 when something's added to it. Due to the way list resizing works, if you're adding a number of elements, you'll get hit multiple times with the resize-and-copy operation. Print out the max sizes so you get a feel for what you need
If you're using JSON, Unity's built-in JSON is miles ahead of other solutions, such as JSON.Net, both in terms of speed and memory. Use it where you can. There are some downsides, such as having to workaround derived types (deserialise common field (e.g. "classname"), the create the right class) and not supporting Dictionaries (though if you know the names of your keys, make it a straight object), but the benefits make up for it
Instantiate GameObjects directly into their parent rather than creating, then adding. It's much quicker, and uses a lot less memory
A lot of APIs can allocate memory in the background. For example, calling Collision2D.contacts generates a new List each time. Use GetContacts() instead. Ditto for Input.touches and Input.getTouches()
Be careful of things like getting/setting GameObject.name, as it allocates memory with each access, as it's calling native code behind the scenes
Similarly, if you need to compare a GameObject.tag with anything, use GameObject.CompareTag() rather than a ==, as for the same reason, it's accessing native code
If you're not using occlusion culling (possible for a 2D game where everything is on the screen), then turn it off by setting useOcclusionCulling = false on your Camera components
Beware of unnecessarily heavy code - e.g. checking for duplicates when adding objects to a list. If you're doing this at the start of the game, when you're populating your data structures, and you know there'll be no collisions yet, turn off the check temporarily, as it's a massive waste of time otherwise

In the CPU Usage of the profiler, you can sort by GC Alloc column to find out who's allocating and when. Removing as many of these allocations as possible means your game will have a smoother ride. Some will be outside of your control (such as physics engine allocations), but we can live with those.

In the Memory Area of the profiler, you can also take a snapshot of the current memory state, which you can use to help you see if there's a memory leak somewhere.

You can also call the GC yourself, using System.GC.Collect(). Do this when you can afford to. We do it, for example, at the end of a shot, when the ball has finished moving, but before the next player has taken their turn. We allow a collection here, which lowers the chance of it happening where it would be visible (such as when balls are moving).

It's possible to turn off Unity's GC, but it's undocumented and doesn't work on iOS, so I wouldn't recommend it. You also run the risk of having your app crash because of an out-of-memory error.

Logging

In relation to one of the previous points, you'll need to remove any calls to Debug.Log() etc that you have. This is because:

LogStringToConsole() - the method called to print out your message is super slow. Even if you're not listening for it (i.e. have adb or whatever connected), it'll still get called
As well as that, when profiling, you need to select Development build, so the log message also grabs a stack trace (similar to how you'd see it in the Unity editor), which is even slower. You'll see a spike for every message when profiling
One of the reasons that it's super slow is that it's grabbing a stack trace on both the C# side and the native side. The latest versions of Unity allow you to set this behaviour to None/Script only/Full for each log type.
As well as that, creating the message to log will entail lots of string concatenation and memory allocation, especially if you've overridden ToString() (and you should), and your logs are something like Debug.Log( "Player " + player + " is doing something in game " + game );

"No problem", you say, "I have my own log function that wraps Debug.Log(), so I only need to set a compilation constant inside there to early return out and not print anything!"

Sure, that'll solve the call itself, but a call to an empty function will still allocate the memory for the string message passed, giving you eventual garbage collection problems.

In the end, you have ~~two~~ ~~three~~ four solutions (James and Max from the comments showed a pretty neat way of removing Debug.Log() calls):

Wrap each call to Debug.Log() in a compilation constant so that the call doesn't exist when you do a production build
Before you build, do a Find and Replace or run a script to comment then all out

Use the C# Conditional attribute. It's essentially a neater, more elegant way of doing conditional compliation. Inside a class, add the attribute to a static void function. If the define is declared, then the function, and all its calls are included. If not, it's like they never existed:

#define USE_LOGS // NOTE: changed in 5.5 - see note below
using System;
using System.Diagnostics;

public class Trace
{
    [Conditional("USE_LOGS")]
    public static void Msg(string msg)
    {
        Debug.Log(msg);
    }
}

// elsewhere in the code - if USE_LOGS is defined, you'll see this output, otherwise,
// it's stripped from the build
Trace.Msg( "Hello world" );

NOTE: I'm leaving the previous code example up for historical reasons, but as of Unity 5.5, they've changed the way this works. Apparently the previous behaviour was a bug, and the #define now needs to be set where you *call your method*, not where it's declared. Because of the way Unity projects work, this leaves two options: 1) add a #define in every file, which is awkward, or 2) add your constants in the PlayerSettings > Scripting Define Symbols box. They go in the form USE_LOGS;SOME_OTHER_DEFINE.
Update May 2018: Max makes a great point in the comments that you can blanket kill Debug.Log calls by setting the Debug.unityLogger.logEnabled property to false. This is great for removing logs in code that you don't control (read: Plugins)

We originally went with the second option as it's easier in terms of dev (as I didn't know about the third one, but we now use that one as it's amazing), and you only need to run it just before a build, then Git revert the changes. On a Mac, you can make a shell script that goes something like this:

grep -rl --null "Debug.Log" "./Assets/Scripts" | xargs -0 sed -i "" 's|Debug.Log|//Debug.Log|g'

which uses grep to list all the files containing Debug.Log() calls, and pipes the result to sed which comments them out, in place.

There are a few things to bear in mind however:

You need to be careful about unclosed conditional statements and the like, otherwise:
```
if( something )
	Debug.Log( "Something happened" );
myObj.Foo();
```
can become
```
if( something )
	//Debug.Log( "Something happened" );
myObj.Foo();
```
which leads to unexpected behaviour. I have another script that pulls out all the logs and the line before, that I can feed to a JavaScript tool that prints any non-wrapped log, so I can fix it (JS is great for building quick, crappy tools)
If you're using Application.logMessageReceived or Application.logMessageReceivedThreaded (e.g. if you're sending errors to the server), then watch out that you don't comment out the logs that you're interested in (you can tweak the regex to ignore LogError() calls, for example)
Some code uses UnityEngine.Log.Debug() instead, so check for that as well (and first)
If you're using the script, because it's changing the line in place, it's like typing with the Insert key selected, so Debug.Log( "Hello" ) actually becomes //Debug.Log"Hello" );. As you're commenting this out, it doesn't really matter, but it's something to keep in mind if you want to adapt the script for something else

NOTE: That whole previous section is great, and I was reasonably pleased with myself when I finally got it working, but just use the third or fourth option :P

Remove Global Illumination

This was one of the more recent additions to Unity, and it seems to be turned on by default. As we're not doing anything relating to lighting, you can turn them all off (Precomputed Realtime GI, Based GI, Fog, everything). You can find the option in the Windows > Lighting panel. You'll need to do it for each of your scenes.

Depending on your Unity version, you might still see some spikes of GI in the profiler. This is apparently a known bug and is already fixed in an upcoming alpha.

Force OpenGLES 2.0

Unity is optimised for OpenGLES 2.0, but will allow you to select 3.0. It's also set by default and kind of hidden in Player Settings > Other Settings, where you need to untick Automatic Graphics API and remove OpenGLES3 from the list.

It'll be selected if your phone supports it, but your performance will tank, so it's better to force 2.0. This one will obviously improve with time though.

To be transparent, we no longer specifically state OpenGLES 2.0. As far as I can tell, any issues have since been fixed.

Set your colour/depth buffer

Make sure you're using the right sized colour/depth buffer. You shouldn't use the 32bit colour buffer unless you notice banding in your gradients. As our app is pretty much gradient free, it was an easy switch to gain a lot in memory. Ditto for the depth buffer. 2D games shouldn't need much in the way of a depth buffer, so you can bring it right down. You can find these in Player Settings > Resolution and Presentation.

NOTE: Unity 5 seems to have done away with the ability to set your depth buffer. While it seems like the default is 16-bit (though I haven't found any confirmation of that so don't quote me on it), you can now only opt to disable it (and the Stencil buffer) altogether. You can also get a small bit more control using the DepthTextureMode property of the camera.

Set your quality settings

A few simple tweaks here can go a long way:

First of all, disable any selections higher than the defaults (Simple for mobile)
Set Pixel Light Count to 0 as you're probably not using them
Set your Texture Quality to as low as you can get away with. Even Half Res on mobile is mostly unnoticable, and you'll gain about 75% memory
In a similar vein, disable mipmaps if you're not using them (i.e. scaling down), as this'll save you about 33% in memory
Turn off Anisotropic Textures as you probably don't have any textures that you'll see at an oblique angle
Turn Anti Aliasing off or set it to 2 passes, which should be enough to cover any jagged lines (only really noticable if you're using stuff like LineRenderers anyway, as most of the rest should be images
Reading more into it, because most (all?) mobile GPUs use tile-based rendering like Mali or Vulcan, it means that anti aliasing is essentially free (up to 4x, I think)
Turn off Soft Particles. They're for blending properly into meshes, but that's a 3D problem
You can also play with the Resolution Scaling Fixed DPI Factor, which renders the screen resolution below the device's native resolution, then stretches it up to fill the screen. It can make a big difference on high resolution devices, like the iPhone X
Turn off Shadows

The two big ones are texture quality ~~and anti aliasing~~. Texture quality directly impacts your memory and how long it takes to upload images to the GPU, ~~while anti aliasing is applied to the entire screen, so on higher resolution devices it's going to be more expensive~~. The less passes for that, the better.

Canvas and the EventSystem

We're using the new UI (and you should be as well), and every UI element needs a Canvas parent. By default, one is created when you add a new UI element, and by default, each Canvas adds it's own Graphics Raycaster so that you can hittest against it. More than one of these however, and you can expect your performance to tank, so remove any that you don't need. If you have the profiler, you'll see this come up as EventSystem.

This doesn't seem to be much of an issue any more, however throwing all of your UI elements onto one Canvas does. It all comes down to redraw, and dirty blocks.

When a UI element moves or is changed, it's marked as dirty, in order to be redrawn. A dirty element will also force its parent to rebuild its geometry, and so on up the line. So basically, if you have one moving element (e.g. a timer, or a health bar), you can end up redrawing the entire Canvas.

If you have a Sub-canvas, or a Canvas nested inside another Canvas, this will isolate their children from their parent. You can alternatively have multiple canvases.

Generally speaking, you want all your static UI in one Canvas and all your dynamic stuff in another (or more, depending on refresh rates).

The Unity fundamentals on UI do an excellent job going in-depth with all of this.

Speaking of UI, unless you specifically want to click on an element, make sure to untoggle raycastTarget, otherwise that object'll be included for interaction. On UI heavy scenes, this can easily add up (we gained 10ms on our shop scene). If you're coming from flash, this is the equivalent of mouseEnabled.

I've also read that you can get a performance hit from not having a material on UI elements. I didn't particularly notice any difference, but there are some default UI materials included, so you can add them if you want.

Use the right shaders

Speaking of materials, make sure you're using the right shader on your materials. The default Sprite-Default for 2D sprites handles transparency, which is not ideal. Transparency on mobile is a real buzz kill, especially if you have it on large areas of the screen. On the profiler you'll see this come up as something like renderForwardTransparent(). As we're using tiles, changing the default for a lot of them to a basic unlit brought the rendering time down significantly.

This will obviously only work for solid sprites (i.e. square), and the fact of having a different material will split up Dynamic Batching, but the gains are worth it.

Watch out for Unity UI Text

Unity UI Text is pretty powerful, but it's not the fastest, and you need to be very careful how you use it. We have a lot of text on the screen, with different effects such as outline, and it was hitting performance bad. We've recently made the switch to the Text Mesh Pro asset, and aside from the first frame where it's generating the texture, it's takes about half the time to render. This was a huge gain on some scenes. It's not a drop-in replacement though; you'll need to go through and replace your textfields one by one, but it's definitely worth it.

If you want to stick with Unity Text anyway, then make sure:

raycastTarget is turned off; it's on by default, but you're probably hit-testing against a background anyway
Rich Text is turned off, unless you're rendering HTML etc
Don't use Best Fit unless you really have to, or at most limit the min-max font size and only have 1 or 2 per screen. If your min font size is 10, and your max is 30, then what happens is Unity goes through the entire render cycle at 30, and checks if it fits. If it doesn't, then it goes down a notch and tries again, and so on. As you can imagine, with each render until you get the right size, this is pretty slow. Either fix your UI so you don't need to do this, or have one or two sizes in code and change them manually
This one comes from Jaysama in the comments: Avoid dynamic fonts if you can. Dynamic fonts can be useful if you're using a common font and trying to save on download size, or working with asian languages, where the resulting font texture can be quite large. Unity won't pre-generate a font texture, but will use the underlying OS to render the text on the fly. This obviously has performance implications, especially if your text changes often.

Update: Unity have announced that TextMeshPro will become an official part of Unity!

Update: TextMeshPro is now built into Unity directly, and you can access it through the Unity Package Manager. If you already have it in your project (i.e. you bought the asset), then follow this guide on how to update your project. Fair warning, you lose easy access to the code, which is useful if you need to modify it (see the WebGL section below).

Watch out for overdraw

Overdraw is where the same pixel on the screen is hit multiple times. Aside from being redundant, when you combine it with transparent areas of sprites (and multiples thereof), it'll soon start to hurt. In an ideal world, you'd write to each pixel once, but this can be hard, especially with UI. In the Scene view, there's a dropdown that will show you the overdraw for the current scene, so you know where to apply your efforts.

Unity has a polygon mode which will replace your square sprites with much tighter outlines. You have more verticies and polygons, but less overdraw, so it can be a big help. If you're using TexturePacker (and you should be), then this is already built in for you.

Another thing to keep in mind is draw ordering. Normally, we'd be used to drawing a large background covering the screen, then drawing other elements over it. On mobile, it can be better to draw your front elements first, then make use of the depth buffer when drawing the background. A depth check is much quicker than overwriting a pixel.

Draw calls, Dynamic Batching, etc

By default Dynamic Batching should be activated (if not, you can find it in Player Settings > Other Settings). Basically it gathers up all sprites using the same material and renders them all in one draw call. There are a number of things that break batching, such as differing scales, tints, textures etc, so you might need to reorganise how you draw your elements, or combine textures into a spritesheet. A Text UI element will probably not be rendered with UI sprites, and for one example that we had, simply moving it from behind one Sprite to in front of it brought our draw calls from 3 to 7. Changing the Pos Z of the element will also probably break it.

Each draw call you have means a context switch for the GPU, which is expensive on mobile. I'd say any more than 10 is probably too many, and more than 20 will give you problems. Basically get it as low as you can, either through batching or combining your models/textures.

Static batching gives a better performance boost, but it means that you can't move, scale, or rotate anything that it's applied to. Unfortunately it also doesn't seem to work yet with SpriteRenderers, so it's only for meshes at the minute.

If you use the Frame Debugger to analyse your frames, most of the time it'll give you the reason why a batch change occurred.

Set up your audio properly

An easy thing to overlook is your AudioClip settings.

Force To Mono: I'd always set this unless you have a specific reason not to. Unless the user is listening with headphones, most speakers are mono anyway
Load In Background: Set this for every AudioClip that you don't need to play immediately. It'll push it on to another thread so it doesn't block the main one
Preload Audio Data: Specifies whether it should be preloaded, or loaded when you first play it. For short SFX, set it, otherwise ignore.
Load Type: Decompress On Load will decompress it immediately, Compressed in Memory will keep it compressed, but load it anyway, and Streaming will only load what's necesssary to play, when you're playing it. For short SFX, I use Decompress On Load, while setting music files to Streaming
Compression Format: PCM is the best, but largest, memory-wise, ADPCM is probably the best for short SFX, while Vorbis is the best for music. On mobile, everything is loaded as Vorbis anyway
Update 20/04/2017: As pointed out by Min Shin in the comments, I was actually reading the AudioFiles Manual page wrong. The actual text is:
When audio is encoded in Unity the main options for how it is stored on disk is either PCM, ADPCM or Compressed. [...] The default mode is Compressed, where the audio data is compressed with either Vorbis/MP3 for standalone and mobile platforms, or HEVAG/XMA for PS Vita and Xbox One.
which I took to mean that only Vorbis/MP3 is used on mobile, but it's rather that Vorbis/MP3 is used on mobile, *if you choose Compressed*.

Making a few simple changes brought our app time-to-Home-screen down from around 30s to under 15s, as well as freeing up a lot of memory.

Enable Multithreaded rendering

This point is Android only (it's always enabled if you're using Metal on iOS), but in Player Settings > Other Settings you'll see a toggle for Multithreaded Rendering. This puts all rendering on another thread, freeing up your main thread for application logic, obviously a good thing.

It comes with it's own caveat though, as depending on what you're going with your project, especially if you interacting with textures, it can give graphic glitches. The only thing to do is try it for your project and see if you get away with it. It might also not work on some devices, though I'm not sure if Unity turns if off automatically or not.

If you see problems with it on certain devices, I almost say just disable that device, as the benefits are pretty awesome.

Scrolling

Doing any scrolling in your game menus? The new Unity UI has a scroll component built in, but its performance can be horrible. Solution: scroll the camera itself - if necessary create a new camera with the right necessary rect. Moving a camera is a simple matrix change, so the rendering is the same, while moving via a ScrollRect seems to modify all the RectTransforms all the way down, meaning everything has to be recalculated, and if you've half-way complicated UI, this can be a huge drain. Scrolling the camera alone can easily make it twice as quick. You might need to jump through hoops to get mouse coordinates working properly, but a bit of extra code to get rid of janky scrolling is doable.

Update 08/2016: TFG Studios got in touch through the comments to show off their optimised ScrollView. It looks pretty nice, but you can check it out yourself on YouTube

Know when to break from Unity

When you first come into Unity, everything is component-this and component-that, but sometimes you need to know when to break from Unity and do things a simpler, more direct way. As an example, when we first started making the map for the games, we did a naive approach where we use tiles and each tile has a component that helped with its behaviour; one for the tile properties (drag, etc), one for the physics, one for special considerations (e.g. flashing, or affecting the ball).

This works for quick projects, but pretty soon you realise that you've about 10k objects in the game, and most of them are useless. The properties were split off into static variables, the physics were removed and a collision/trigger mesh generated by our level tool instead (so one PolygonCollider2D instead of one for each tile that needs it), and any special cases were merged where possible, so we'd have one loop rather than 50 Update() methods running.

For the rendering, we also made use of a RenderTexture and Camera culling masks, so all those tiles would get rendered exactly once to the texture, then hidden. For some tiles we couldn't do this (e.g for the ones that break or flash), but for the vast majority we could, which meant that our map and border tiles are one simple mesh. And because the semi-transparent tiles are baked into the texture, we can apply one super fast non-transparent material to the mesh to get the quickest rendering possible.

Use threads where you need to

Because our game is multiplayer, we use sockets via TcpClient to send and receive messages. Originally we were doing a synchronous write and an async read. As the EndRead() method is on another thread, there was no problem when deserialising/decompressing the received message. But that left the problem of sending. Normally it wouldn't be too bad, but sometimes you would get a message being sent out while the ball is moving, and compressing/serialising to JSON are pretty slow operations, so you're looking at minimum 1 dropped frame. Even sending the shoot message as you fired would introduce a tiny bit of lag on the client, which meant the experience wasn't great.

A simple threading system is now in place which means that all that is pushed off the main thread, so there shouldn't be any impact because of it. Some of the logic in the game had to be rewritten to accomodate that - because the writes were synchronous before, we could reuse objects, which we can't do with async - but the performance gains are worth it. Joseph Albahari has a great resource on threading in C#.

WebGL

If you're building your game for web, there are a few things to keep in mind:

Everything is single threaded, so any cool threading features (that you might have used to gain some speed) are out the window
In the same vein, all Jobs are now run on the main thread
Sockets don't exist, so if web players are playing on the same server as mobile players, you now have an extra layer of redirection, going from WebSocket -> Socket and back again
The memory that you assign when your project starts is all you get, so it's highly likely you'll get some Out-of-memory crashes in the beginning until you find your sweet spot (NOTE: it increments in steps of 16MB)

As memory is such a big issue, and even an empty project results in a pretty hefty download and an unskippable delay at the start while million-odd lines of JS are compiled, it's super important that you work on getting your project as slim as possible. To that end:

Make sure Strip Engine Code is ticked in the Build Settings. If you're using something that you're not directly referencing (e.g. an AssetBundle is using a class that your main file isn't), then you'll need to use a link.xml file to explicitly stop those files from being removed
Use Crunch compression, as it's awesome. There can be some artifacts if you're using gradients, or issues with thin sprites (as it's a block-based compression), or sprites that you use for a clipping mask (e.g. round images can have block artifacts around the edges, and as clipping masks are either on or off, you lose your smooth edge), but it's worth it
Make use of AssetBundles, if you want to remove as many embedded assets as possible from your project
Enable Brotli compression if you can. You'll need a web server that can support it, and have to serve your site over HTTPS, but you'll save a few MBs, easy. Modern browsers have brotli decompression built-in, and being HTTPS will also give you access to HTTP/2, so it's win/win

A somewhat broken, but useful tool to use is http://files.unity3d.com/build-report/, which you can use to see which libs are actually going into your build. It'll tell you if a lib is being added because of another library (e.g. Particles might require Wind), or scripts (though not which script).

We found out that we had the 5MB 3D Physics lib being added, even though we're a 2D game. Why, you ask?

Well, aside from UnityPurchasing for some reason (but UnityPurchasing doesn't work on the web, so we could just delete it), it was being brought in by TextMeshPro, which has a feature to let you make physics-enabled text in 3D, and thus had Collider references.

As mentioned above, because we had the code for TextMeshPro, we could go in and comment out the offending classes, but if you're using the Unity built-in TextMeshPro, you'll have to wait until (or if) they do it.

Check out the Lightweight render pipeline

This is a new addition but it's pretty awesome. Basically, Unity have opened up their rendering, allowing devs to make their own custom pipeline.

Honestly, looking at the code necessary to set it up gave me the shivers, but happily, Unity provide a Lightweight Pipeline and a HD Pipeline.

It's very easy to drop in and setup - if you're using the Unity shaders, you don't need to make any changes - and it simplifies rendering enough to give you a noticeable boost.

Check out the new ECS system

Another new one, and one we've not done yet. The new Entity Component System is definitely on the list for the next game though. Combined with the Job system, it's specifically built to take advantage of multithreaded systems, and lets you write high-performance code straight up.

Entities are reduced to mere ints. Components are nothing more than containers for data. The real meat comes with the Systems. They're made to treat lists of components all at once, and just bang it out.

If you've ever used something like Ash in AS3, you'll be right at home. One of the great advantages of this setup is that it becomes much easier to debug your code. You work on insular Systems, and only need to keep the code relative to that System in your head. You can modify freely without impacting the other Systems. It's a different way of thinking about things, but once you get into the swing of it, it's great.

Resources

While going through all of this over a number of different weeks and months, I started saving a list of useful links. In no particular order:

The entire Performance Optimisation section - if you're having issues with framerate, the info in the graphics section can help you figure out if you're CPU-bound or GPU-bound
Pretty much the entire Best Practices section, specifically Assets, UI, and Profiling
Unite Europe 2016 - Optimizing Mobile Applications
Unite Europe 2016 - Overthrowing the MonoBehaviour Tyranny in a Glorious Scriptable Object Revolution
Unite Europe 2017 - Squeezing Unity: Tipes for raising performance
Unite Europe 2017 -Practical guide to profiling tools in Unity
Unite Austin 2017 - Writing High Performance C# Scripts
Unite Seoul 2017 - Tips and Tricks for Optimising Unity UI
Unity UI optimization tips
When it pays to be cheap: Tips for big games on low-end mobile - some great stuff in here, though a lot of it bypasses Unity
Understanding optimization in Unity

Conclusion

Optimisation is a pretty big subject, especially when so much of it is guesswork or slowed by the constant change > build > test cycle, which on mobile isn't quick. I also find the profiler on Unity not as good compared to others, such as Scout. Your history extends as far as the window, you can't select multiple frames to get averages (even though they have this information), and ~~you can't save the results~~ (update: you can now), so before and after comparisons either work through your memory, or screenshots.

Still, it's what we have to work with, so if you have it, use it, as sometimes, what's causing your slowdown isn't what you think it is. You don't need to profile all the time, premature optimisation being the devil and all, but you should do it regularly.

If there's anything I've missed, let me know! Happy hunting.

Hacking how Node.js launches in Visual Studio Code

Sun, 12 Jul 2015 23:39:00 +0000

I've been using Visual Studio Code lately, working on getting my socket sever, Sir, off its feet. As any good dev will tell you, the first step for good debugging is good logging, so I was on the search for a small, fast Node.js logging module.

And thus I came across Bunyan.

Bunyan does a lot of things, but when you run it, a simple

log.info( "Hello world" );

becomes

{"name":"Sir","hostname":"divillysausa-PC","pid":2244,"level":30,"msg":"Hello world!","time":"2015-07-12T21:47:30.576Z","v":0}

in your console.

While undoubtedly useful, it also makes actually reading them a bit awkward. Happily, they've thought of this, and have included a CLI that takes that output and transforms it to:

[2015-07-12T22:12:45.698Z]  INFO: Sir/4900 on divillysausa-PC: Hello world!

They've even colour coded it for your convenience!

Where Visual Studio Code comes in

All of this is relevant to the title, I promise.

In order to get this wonderful output, you simply need to change your node call from

node app.js

node app.js | "node_modules/.bin/bunyan"

In essence, what you're doing here is piping the output coming from node and sending it to bunyan.

So, how do you actually do that?

The first time you hit F5 to launch your app, Visual Studio Code will create a launch.json file for you that looks like this:

{
	"version": "0.1.0",
	// List of configurations. Add new configurations or edit existing ones.  
	// ONLY "node" and "mono" are supported, change "type" to switch.
	"configurations": [
		{
			// Name of configuration; appears in the launch configuration drop down menu.
			"name": "Launch app.js",
			// Type of configuration. Possible values: "node", "mono".
			"type": "node",
			// Workspace relative or absolute path to the program.
			"program": "app.js",
			// Automatically stop program after launch.
			"stopOnEntry": false,
			// Command line arguments passed to the program.
			"args": [],
			// Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
			"cwd": ".",
			// Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
			"runtimeExecutable": null,
			// Optional arguments passed to the runtime executable.
			"runtimeArgs": [],
			// Environment variables passed to the program.
			"env": {},
			// Use JavaScript source maps (if they exist).
			"sourceMaps": false,
			// If JavaScript source maps are enabled, the generated code is expected in this directory.
			"outDir": null
		}, 
		{
			"name": "Attach",
			"type": "node",
			// TCP/IP address. Default is "localhost".
			"address": "localhost",
			// Port to attach to.
			"port": 4000,
			"sourceMaps": false
		}
	]
}

I tried adding my | "node_modules/.bin/bunyan" line first in args, then runtimeArgs, then env, before finally realising that these were being passed to your app.js program rather than to node itself. Then I tried modifying the program parameter to read "app.js | \"node_modules/.bin/bunyan\"", but it complained that the file didn't exist :)

The key to getting this hack working is with the runtimeExecutable property. By default it's null, which means that VSC will search in your PATH directory for node. If you specify a path, then VSC will run that instead.

With that in mind, I created a small bat file (I'm on Windows), nodeWithBunyan.bat:

@echo off
node %* | "node_modules/.bin/bunyan" -o short

Basically, what it's doing is calling node, passing all the parameters that VSC is passing (%*), before piping the output through bunyan (the -o short at the end is just telling bunyan to use its "short" output mode, which is even more concise). As we're passing all the VSC parameters, we even get to keep debugging.

If you're working in a bash environment, then I think the equivalent is

node $@ | ./node_modules/.bin/bunyan -o short

Back in VSC, we replace the runtimeExecutable property so it reads

"runtimeExecutable": "./nodeWithBunyan.bat"

hit F5, and *jazzhands*!

If, for some reason, you want to switch between the default launch and the new, snazzy one, you can simply create another config, add it to the configurations array in your launch.json file, then choose between them in dropdown menu on the Debug tab.

You can also use this technique if, for example, you want to set the DEBUG or NODE_DEBUG environment variables when launching:

NODE_DEBUG=http,fs,timers node %*

Enjoy!

You are the Monster - Ludum Dare #33

Sun, 12 Jul 2015 23:39:00 +0000

Another Ludum Dare, and hooo boy, what this a tough one. Because of other commitments through the weekend, I wasn't able to spend the full 48hrs on it - I'd say I managed around 18 all told - so to get solid blocks of time, I ended up doing an all-nighter on Saturday and right to the deadline on Sunday.

The theme this time was You are the Monster. As I wasn't going to have a lot of time, my weapon of choice was the tried and trusted workhorse, AS3.

About the game

You're happily passing your day in your underwear, when the classical damsel in distress comes screaming in, as there's a monster on the loose. This is the day you've been waiting for! Impress people! Win friends!

Kit yourself out as best you can with the money you have, and essay forth to slay the foul beast.

Be careful however, there are whispers of a curse abound...

Development

As I was used what I'm used to, development went pretty well. Because I didn't have the full weekend, I couldn't put in any sound effects or music, which is a shame, as I have a pretty good library full of swords and grunts and the like. So, if you could do me a favour, and provide your own "huurgh", "hiieagh", etc, that'd be fantastic.

I was pretty pleased with how the art turned out - I'm not great at it, but the colours work, and the characters aren't too ugly. These are the benefits of pixel art.

The actual art is draw to 1/4 of what you see on the screen, and scaled up, in order to get that nice chunky look. It makes it a bit awkward when working with objects with competing scales, but there you go.

The idea itself owes a large part to Defect, which is a game about building a spaceship, to have the crew mutiny, then building another one to beat that first one, to have the crew mutiny, etc. I saw a video of it a few weeks/months ago, and I guess it stuck in my head. Marketing works, people!

The game

The game is available to play below and if you'd like to vote on it, you can at http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=12486 which would mean a lot. The full source is also available, if you dare to look at it.

Play

An intro to Socket.io

Sun, 12 Jul 2015 00:28:00 +0000

Recently I've been playing around with Socket.io, which, according to the site, enables real-time bidirectional event-based communication. Damn, that's some sexy copy.

Basically you can use it as a real-time server, and one of the things that makes it so interesting is that it works on pretty much every platform, browser, or device. I thought I'd write an intro on the subject as I found their documentation to be lacking in some cases and confusing in others; I frequently found myself with questions that I only answered through trial-and-error and reading the source code.

And you should never have to read the source code.

TypeScript!

I'm using TypeScript, so one of the first things I did was try and hook myself up with some definition files so I could get some code completion. I found the excellent DefinitelyTyped project and related tsd, or TypeScript Definition manager.

Unfortunately, after scratching my head for a day or two, I finally realised that the d.ts files were for an old version. Sadface.

So I learned how to create TypeScript definition files, and went through the code and created new definitions for the latest version (1.3.5 as of time of writing). If the pull request hasn't been accepted yet, then you can find them at the bottom of this post.

They're even commented to boot.

AND I went out of my way to describe the options object, which nobody apparently does, but blow trawling through documentation and READMEs for a lark. If it's not code-completed, it doesn't exist.

The setup

For the setup, I worked from the Chat example on the Socket.io website, with the exception that I didn't use Express (on a side node, Express is great and all, for beginners, one framework at a time, please). You should be able to follow that example in order to get setup. To install Socket.io (locally), just use:

npm install socket.io

Like in my tutorial for Using Phaser with Visual Studio Code I'm not using Express, I'm using node-static (as all it does is serve files from whatever directory you throw at it, so it's a perfect light-weight solution). If you want to use that, then install via:

npm install node-static

Then set up your app.js file like this:

import nodeStatic 	= require( 'node-static' );
import http			= require( 'http' );
import socketIO		= require( 'socket.io' );

// create our file server config
var file = new nodeStatic.Server( 'bin', { // bin is the folder containing our html, etc
	cache:0,	// don't cache
	gzip:true	// gzip our assets
});

// create our server
var httpServer = http.createServer( function( request, response ) {
	request.addListener( 'end', function() {
		file.serve( request, response );
	});
	request.resume();
}).listen( 4000 );

That's it. From this point out, it's all Socket.io. Note that when we call http.createServer(), we save the returned Server as our httpServer var; we'll need that later when binding Socket.io.

The basics

First of all: connecting. On the server, setup Socket.io like this:

var sio = socketIO();
sio.serveClient( true ); // the server will serve the client js file
sio.attach( httpServer );

// listen for a connection
sio.on( 'connection', function( socket ){
	
	console.log( 'User ' + socket.id + ' connected' );
});

To explain a bit:

var sio = socketIO() - here we're just creating our Socket.io server using the socketIO import above (NOTE: if you're not using TypeScript, then your import is in the form var socketIO = require('socket.io');)
sio.serveClient( true ) - here we're telling the server to serve any requests for the socket.io-client.js file. You can serve it yourself if you wish, but this is pretty handy
sio.attach( httpServer ) - here we're attaching Socket.io to the httpServer instance created above via http.createServer()
sio.on( 'connection', function( socket ){... - this is called every time a client connects. In the callback function is where you'd add all your event listeners to the socket etc.

On the client, you embed the client side code via:

<script src="/socket.io/socket.io.js"></script>

That particular path is if you're using sio.serveClient( true ). Otherwise, if you're serving it yourself, replace it with the right path. To connect to our server, it's simply:

var clientSocket = io();

Start your server (node app.js), go to http://localhost:4000 in your browser, and you should see something like

User 8fyIQvC4HUYEpZeDAAAA connected

in your console. Eassssssy.

Namespaces and rooms

A quick note on namespaces and rooms and what the difference between the two is. By default, when you call io() on the client to connect, what you're actually calling is io( 'http://localhost:4000/' ), as by default, it will take the host and port of the current page, and connect to the default namespace, which is /. If you wanted to connect to a namespace called 'foo', then you'd have to call io( 'http://localhost:4000/foo' ).

So what's a namespace?

It's a way of separating your code. It's one socket to a namespace, so if you called:

var news = io( 'http://localhost:4000/news' );
var chat = io( 'http://localhost:4000/chat' );

while it might use the same physical TCP connection, they're two separate objects - news can't send messages to /chat and vice-versa.

The main namespace, /, is created by default, and all clients join it, even if they connect to another namespace.

On the server, when a namespace emits an event, all sockets connected to the namespace receive it.

After that, we have rooms. Rooms are essentially grouping of sockets, and let you send messages to a subgroup of a namespace. You only need to know the name of a room to send a message to it. Unlike with namespaces, sockets can join as many rooms as they want.

Think of it like this: the Socket.io server is your game website (e.g. all-poker.com), namespaces are each game (e.g. /texas, /omaha), and rooms are private rooms within each game (e.g. table1, table2, etc).

The differences in list form:

Namespaces are joined when you create the socket, rooms are joined as you want, but you need to build your own events to call join() and leave()
One socket per namespace, but one socket can be in multiple rooms
Sockets can leave rooms as they please, but to leave the namespace, they need to disconnect
Communication can happen between rooms, but not between namespaces (there are work-arounds if you keep references on the server)

Or in picture form:

Sending a message to the client

To send a message to the client, we call emit() on the socket, passing the event name, and whatever data we want to send:

socket.emit( 'greetings', 'Hello from the server!', socket.id );

Then on the client, we add a listener for the 'greetings' event:

clientSocket.on( 'greetings', function( message, id ) {
	console.log( 'Got a message from the server: "' + message + "', my ID is: " + id );
});

Note that we're sending the socket.id to the client with the emit() call. We could have also called clientSocket.id, but we can use this technique to send the IDs of other sockets, which will become useful later. The id is a auto-generated ID set when the socket connects. It'll be different everytime, so there's no point storing it.

Also note that the only parameter that's actually required is the event name, in this case 'greetings'. Anything after that is sent to the client as parameters for the callback - with one exception: if the last argument is a function, then it'll be used as an ack - called when receipt of the message is acknowledged. This is a bit more advanced, so for the minute, we don't care.

Sending a message to the server

Sending a message to the server is exactly the same. On the client:

clientSocket.emit( 'message', 'Hello from the client' );

While on the server, we need to add any listeners to the socket that we get during the 'connection' event:

// listen for a connection
sio.on( 'connection', function( socket ){

	console.log( 'User ' + socket.id + ' connected' );
	
	// listen for the 'message' event
	socket.on( 'message', function( msg ){
		
		console.log( 'User ' + this.id + ' sent message "' + msg + '"' );
	});
});

Note that in the socket callback, you can use this to reference the socket (or socket as it'll be bound).

This is about the height of what you need to do on the client. Everything after this (sending messages to different people etc) happens on the server.

Sending a message to everyone in the namespace

To send a message to everyone, instead of calling socket.emit(), which only sends a message to that socket, we get the namespace itself to send the event.

In this example, we're using the sio Server object, created when we created Socket.io on the server.

socket.on( 'tellEveryone', function( msg ){

	sio.emit( 'heyEveryone', msg, socket.id ); // pass the socket.id so other client know who it's from
});

The sio.emit() method here is actually a helper function that gets the default namespace (/) and calls emit() on that. The following 3 calls all do the same thing:

sio.emit( 'heyEveryone', msg, socket.id );
sio.sockets.emit( 'heyEveryone', msg, socket.id ); // sio.sockets is a reference to the main "/" namespace
sio.of( '/' ).emit( 'heyEveryone', msg, socket.id ); // of( '/' ) is how we reference a namespace, in this case the main "/" one

Notice that last of( '/' ) call? That's how we reference other namespaces. Remember how I said sockets in one namespace couldn't send messages to sockets in other namespaces? This is how you get around that:

socket.on( 'tellNamespace', function( msg, namespaceName ){

	sio.of( namespaceName ).emit( 'heyEveryone', msg, socket.id ); 	// NOTE: namespace will be created if it doesn't exist
});

Sending a message to everyone in a room

To send a message to a room, you need to know it's name. You don't actually need to have joined the room to send a message to it, but you do if you want to receive messages from that room.

socket.on( 'tellRoom', function( msg, roomName ) {

	socket.to( roomName ).emit( 'heyThere', msg, socket.id ); // NOTE: room will be created if it doesn't exist
});

You can also use in( roomName ) instead of to() if you wish.

You can also send to multiple rooms by chaining the to() calls:

socket.on( 'tellRooms', function( msg, room1Name, room2Name ){
	
	socket.to( room1Name ).to( room2Name ).emit( 'heyThere', msg, socket.id );
});

Note that on the client, if they've joined multiple rooms, when they get a message, they won't actually know which room (if any) sent it, so it's generally a good idea to pass the room name as one of the parameters.

Sending a message to everyone except you

The socket has a broadcast flag, that when used will send the event to everyone in the namespace/room except for yourself. For a namespace:

socket.on( 'broadcastMsg', function( msg ) {

	socket.broadcast.emit( 'broadcastFrom', msg, socket.id );
});

or for a room:

socket.on( 'broadcastMsg', function( msg, roomName ) {

	socket.to( roomName ).broadcast.emit( 'broadcastFrom', msg, socket.id );
});

Sending a message to another user

To send a message to another user, we can go about it two ways: we can get the socket of the other user from the connected dictionary on our namespace and call emit() on it:

socket.on( 'sendToUser', function( msg, userID ){
	
	// try and get the socket from our connected list
	var otherSocket = sio.sockets.connected[userID]; // NOTE: sockets is the default "/" namespace
	if( otherSocket )
		otherSocket.emit( 'messageFromUser', msg, socket.id );
});

But remember when I said it's a good idea for the client to know the IDs of other clients? This is because when a socket connects, one of the things that it does it join a room with the same name as its ID. So to send a message to a client, we can use the same logic as sending a message to a room:

socket.on( 'sendToUser', function( msg, userID ){

	socket.to( userID ).emit( 'messageFromUser', msg, socket.id );
});

Technically this means that if we join() this room, we'd be privy to all the private messages sent to this user, which opens up all sorts of interesting possibilities.

Getting the IDs of connected users

If you want to send a list of all the socket IDs in a particular namespace, you can go through the connected dictionary on the namespace:

var sids = keys( sio.sockets.connected ); // sockets = default "/" namespace

To send all the IDs for a particular room, you need to go through the adapter property on the namespace:

var socketsInRoom 	= sio.sockets.adapter.rooms[roomName]; // sockets = default "/" namespace
var sids 			= ( socketsInRoom ) ? keys( socketsInRoom ) : []

Nicknames

To enable nicknames, you simply need to keep a dictionary of socket ids => nicknames on the server. Then you can either do two things:

Instead of sending the ID to the client, you send the nickname instead. Although this means that you need a way to convert back to the socket ID if you want to send one player to send a message to another, and nicknames generally aren't unique
Send the client the socket ID/nickname dictionary, and it's up to them to keep it up-to-date and display the right name. A bit more awkward, but more flexible as well.

Fin

So there you have it! You should be set up for firing messages left and right. If there's another scenario you want covered, leave a comment, and I'll add it in.

In the meantime, check out Socket.io and download the v1.3.5 TypeScript definition files below.