Welcome to another installment of our Top App Dev Interview series. Each interview in this series focuses on a successful mobile app or developer and the path they took to get where they are today. Today’s special guest is Matt Rix.

Matt is a Unity guru, successful indie developer and game jam aficionado. Matt is best known for being the creator of Trainyard, a global #1 app store game in 2009.

When he’s not busy creating exciting games and working as an indie developer, Matt spends plenty of time with his family.

The Beginning of the Story

What are the top 3 things that you attribute to your success with Trainyard?

Having a good game. Making a good product is no guarantee of success, just like making a bad product is no guarantee of failure (see: the old fart app craze), but the quality of Trainyard definitely swung the odds in my favor.

The release of Trainyard Express (the “lite” version of the game). Having a free app was crucial to the game becoming well known. It drastically increased the “word of mouth” marketing potential.

The popularity of the game in Italy. For some reason, Trainyard caught on in Italy before anywhere else in the world. This led to Apple learning about the game and deciding to feature it on the U.S. App Store.

In your blog post “The Story So Far”, you mentioned that several times during the development of Trainyard, there were various interruptions that de-railed (pun intended) development – yet you always came back and got the game done.

What advice would you give to developers struggling to wrap up their projects and get them out the door?

There are really two ways to get things done. Either:

• Small amounts on a regular basis, or
• Giant amounts on an irregular basis.

In theory, if you work for only an hour per day, you will eventually finish your project, but that doesn’t seem to work for most people. Sometimes what is needed, especially to finish something off, is to allocate an entire weekend and just push through the tough stuff.

One common reason developers get derailed is they get bored of working on the same project, and get excited about something new and shiny. How do you deal with this?

This is something I struggle with constantly, especially after working on the same game for over two years now. Coming up with new ideas and prototyping them is my favorite part of game development, so I feel a strong need to do it. The key is to know what is your “main project” and what are your “side projects”, and allocate time to them accordingly.

Most “shiny new ideas” can be prototyped in a weekend, but then they should (usually) be put aside after that. On the other hand, if you find yourself constantly thinking about a certain side project, maybe it really should become your main project! It comes down to knowing why you’re making your work in the first place. Are you looking to make:

• The most financially successful thing?
• The most thought-provoking thing?
• The most innovative thing?

It’s really easy for us developers to switch to a new project solely because the technical challenges are more interesting, but I think very few of us have the primary goal of “make something technically impressive”.

You have to be very introspective about why you are really making this thing. Is it because it’s an exciting technical challenge now, or is it because the final product is going to be great?

If you could jump back to 2010 when you were building Trainyard, what would you do differently and why?

These days, I wish the game had been built in Unity, so it would be easier to update. With that said, I think that Cocos 2D and Objective-C were the right technologies to use at the time.

If I chose to build in Unity it would have been much easier to port the game to other platforms. The Android port was done by Noodlecake (who did a great job!), but it would have been nice to do that port myself.

I also wish I’d been able to make a Steam version, but it would have required a complete rewrite. If I’d made the game in Unity, it would have been a piece of cake.

Updates to Trainyard would have been much easier too, I’ve actually considered rewriting it in Unity for that very reason, but I think I will save that for the (eventual) sequel.

The Indie Story

Are you still a full-time indie? What’s your typical day look like?

Yes! On weekdays I get my kids up, make their breakfasts and get them ready for school. Then I work for 6-8 hours before picking the kids up again. Most of my work day is spent in Unity and communicating with Owen (my business partner) via Skype chat.

How do you plan your day ahead? For example, do you keep a TODO list, or use any tools to help with task management or planning?

So at a company level, for our high level planning, we use Gantt charts on tomsplanner, and for regular TODOs, we use Trello.

For me personally, I have a very specific way I track my tasks and manage my time. I don’t like using digital tracking tools because I’ve found I always forget to use them. Instead, I use only Action Runner notepads. Any notepad could work, I just love the look, size, and feel of these ones!

At the end of each workday, I write down the next day’s date and tasks on a new page. This is really important because it means that I can carry my train of thought from the end of one day into the beginning of the next. Otherwise I might forget something by the next morning! The size of the Action Runner limits me to a max of 8 tasks per day, which is ideal (at least for me).

To track my time, I set consecutive 1 hour long timers with my phone. Every time it goes off, I mark an X at the top of the page. This makes it really easy to go back through the notepad and see exactly what I was working on and how many hours I worked.

It’s a simple system, which is why I’ve been able to stick to it for so long now.

What is your take on the “indiepocalypse” discussion? Do you think it’s still possible to make it as an indie, and why or why not?

Disco Zoo, created by Matt Rix and Owen Goss

There is some truth to the indiepocalypse, especially on mobile. Apple features don’t have the impact they used to, and even high chart positions don’t come with as big download numbers as they used to. The key to making it is to design your business around not requiring “hit” games. There is a great talk on that topic here.

I haven’t felt the effects yet, but only because I haven’t released a game in a while! I think we’ll have a hard time getting FutureGrind noticed by press and players, but we’re hoping that the quality of the game will shine through.

With that said, we’ve actually been quite fortunate, because Disco Zoo continues to do quite well on the App Store, despite being released over two years ago.

What mistakes do you often see indie developers making?

I think developers (myself included!) spend way too much time on our games. This is for two reasons.

1. We are just bad at estimating how long games will take to develop.
2. We simply don’t weigh the development time of the game highly enough when we’re choosing what game we want to make in the first place.

From what I can tell, there is very little correlation between development time and game success, so in general, we should be making games that are faster to develop. This doesn’t mean low-quality games. They should be high-quality games with limited size and scope.

One of the most important things game and app developers can do is promote their product well before it’s actually released. I still see way too many developers who don’t do ANY marketing or promotion until a week before their product hits the store. That’s way too late!

The Unity Story

What made you start working with Unity, and what are your favorite features?

Unity is great! Here are what I consider the top three advantages of Unity:

1. The biggest advantage is that it uses C#, which is a great language to program in.
2. The second advantage is the way it’s built around the component-based architecture, which makes game dev a lot more fun and flexible.
3. The third advantage is the easy “one-click” publishing to many different platforms.

These days I love hooking everything up using public fields in the editor instead of in code. I don’t call GetComponent anymore, I just make a “public” property and assign it in the editor. I also don’t use prefabs anymore; instead, I put my prefabs within a disabled game object and instantiate them from there.

One specific feature I use a lot when making mobile stuff is Unity Remote, where you can view & play your game instantly on your device. The visual quality isn’t great, but it’s good enough to get a feel for whether UI elements are the correct size, and whether the multi-touch code is working properly.

In the past, you developed your own code-centric 2D framework for Unity called Futile. Can you tell us a bit about that and what happened with it?

Futile was my bridge between my previous worlds of Flash/Cocos2D and Unity. It allowed me to create games in the same code-centric manner I was used to. I was basically using Unity as a publishing/rendering layer and not much else.

Futile still exists and works great, though I don’t use it for most of my projects anymore. I’ve become used to making games the “Unity Way” now, which makes it easier to take advantage of the great 3rd party plugins for Unity out there (such as TextMesh Pro).

You seem to be quite proficient with making editor tools in Unity, judging by the track system you have in place in Future Grind.

How much time have you spent making editor tools for your games, and what advice would you have for developers considering making editing tools for their games?

I’ve probably spent too much time making editor tools! I love it so I can’t help doing it.

It’s easy to spend too much time making tools. The tools often increase the complexity and development time of the game rather than reducing it like they’re supposed to!

The main advice I can give is to build the game first, and then build the tools. For example, don’t build a level editor before you’ve built a few levels manually! You may find that the game design doesn’t work, or that building the levels manually was easy enough.

What’s your process when designing a game? Do you use pen and paper or do you dive straight in and create a playable prototype? And how does this fit in when working with Owen Goss on upcoming games?

A little bit of both. I often write down a few initial ideas on paper, but if I like the idea at all, I usually start making a playable prototype well before the entire idea has been figured out. There are very few games where it’s possible to fully plan them out on paper.

We’re lucky because we both have similar taste when it comes to game design, so we agree on gameplay ideas 99% of the time. It doesn’t matter who comes up with the idea, if it’s a good one, we’ll use it. Owen is a programmer by trade, but on our recent games, he has switched to being the main artist (and doing a great job at it!). I end up doing most of the programming and the UI design.

How did the partnership come about? Do you have any advice for finding the perfect working partnership you have with Owen?

I’ll give the same advice I give for everything else: start small! The game jam I did with Owen was the perfect way for us to get a chance to work together without a lot of commitment. There wouldn’t have been any bad blood if things didn’t work out.

There’s nothing wrong with a few disagreements, in fact I think it’s good to have them! The key is about the level that the disagreements happen on. If you have core philosophical differences with your partner, I really don’t see how that can work out long term.

For example: if your goal is to make art, and your partner’s goal is to make a massive hit, I think you’re constantly going to be butting heads.

I really think the key to any relationship is trust. You need to trust the person that you’re dealing with. You need to know what their motivations are, what their goals are, etc. Not just what they *say* they are, but what their actions show you.

What advice would you give someone that has never made games before and want to make their first one using Unity?

Just do it! Make something super small and simple, and then work on expanding it one tweak at a time.

Tweaking things is the best way to learn how to use any new technology. Start with something that works, and then make tiny changes to it. That way it’s easy to roll back if something goes wrong, and meanwhile, you are tackling only one thing at a time, so you won’t get overwhelmed.

Here is a list of actions I do for releasing a brand new game:

1. Create prototype
2. Make sure game is actually good (send prototype to friends etc)
3. Come up with a good name and brand/style for the game (names are important)
4. Start a blog (or vlog! I don’t think this is actually that important, but it’s a good outlet as a developer)
5. Create a PR page
6. Tweet about your game. If your gifs aren’t getting lots of retweets/likes, figure out how to make them more appealing. Twitter likes short & sweet gifs with gimmicks, like this:

I think there's a bug in my respawn code #TOJAM https://t.co/QRegvBYtaG

— Matt Rix (@MattRix) May 7, 2016

1. Demo game at a conf (this depends on the type of game. I don’t think it’s actually important for PR, but it’s a really good way for you to get feedback and see how people react to your game)
2. Beta test the game with friends
3. Beta test the game with a larger audience (depending on the type of game, you could do “early access” at this point)
4. Finish making the game. Do not launch the game the moment you finish it. Schedule the launch a few weeks later!
5. Spend a couple weeks contacting press, making a trailer, building buzz in whatever way you can!
6. Launch the game
7. Support the game. How long this takes depends on the type of game AND how big your audience is. If your game is a flop, try to make some key fixes to solve the major issues, but spend your next year supporting it (unless that’s really what you want to do).
8. Start working on something new!

Where To Go From Here?

And that concludes our Top App Dev Interview with Matt Rix. Huge thanks to Matt for sharing his past with Trainyard, his love for Unity and finally being a successful indie games developer.

We hope you enjoyed this inspiring interview and if you’re thinking of building your very own game will consider using Matt’s experience and advice to heart.

If you are an app developer with a hit app or game in the top 100 in the App store, we’d love to hear from you. Please drop us a line anytime. If you have a request for any particular developer you’d like to hear from, please post your suggestion below!