Creator of Trainyard, Unity Expert & Indie Dev: A Top Dev Interview With Matt Rix

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.

Original design concept for Trainyard

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

Matt’s business partner Owen Goss

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

7. 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)
8. Beta test the game with friends
9. Beta test the game with a larger audience (depending on the type of game, you could do “early access” at this point)
10. Finish making the game. Do not launch the game the moment you finish it. Schedule the launch a few weeks later!
11. Spend a couple weeks contacting press, making a trailer, building buzz in whatever way you can!
12. Launch the game
13. 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).
14. Start working on something new!