JetBrains Rider – Alternative to Visual Studio

For quite a long time Unity installer was coming with custom MonoDevelop distribution to assist Unity developers with starting with game development. At that time it was the only available option for many, since other solutions were simply too expensive. Then Visual Studio Community has been introduced and almost immediately it became the default Unity C# IDE, but only on Windows operating system family. It seems like quite soon we will have another player on the market and his name is JetBrains Rider.

.NET enslaved by Windows

It’s not surprising that the language created by Microsoft works best on Windows operating system family. It seems that even Microsoft is surprised by how .NET got so popular these days. It’s a bit of a problem, because today we’re entering a new era in which Windows is no longer a dominant operating system in the world and .NET is widely used on variety of platforms thanks to Unity. If Microsoft wants to keep .NET position and profit out of development tools, .NET must become a cross-platform framework for real.

The first step of becoming more open to multiple platforms was introducing .NET Core (wikipedia) – the first open-sourced .NET implementation. Then Microsoft introduced Visual Studio Code – the first editor with “Visual Studio” in name that works on MacOSX and Linux. Still Visual Studio Code is “only” a GitHub Atom fork. It’s a great editor, but it’s nothing when compared with original Visual Studio IDE running on Windows with ReSharper onboard. Speaking of which…

There’s a new player in the game

There’s a market gap for sure – more and more developers tend to use Mac OS X or Linux as their development platform and beside Visual Studio Code and MonoDevelop (which is good, but not so great) there was nothing worth considering until recently.

JetBrains is a Czechia based company known for the creation of a great Visual Studio extension called ReSharper, and IntelliJ IDEA (IDE for Java developers). It seems like they’ve recently decided to merge those two.

JetBrains Rider is a cross-platform .NET IDE based on the IntelliJ platform and ReSharper. If you don’t know either one of those, then consider this as a great opportunity because learning these two tools will change the way you work with your code forever. Do I need to tell that it will increase your productivity? Yes, it’s a buzz-word, but it’s true! What is more important, it will make your work easier and you – happier.

How valuable your time is?

Do you value your time? How much time do you spend on writing easy but bloated code and how much on focusing on problems that matter? ReSharper is a tool that helps you to get through the parts of the code that are not requiring too much of your brainpower. It consist of powerful generator and refactoring methods that will assist you on demand. It also includes code analyser that makes sure you won’t make any simple-to-prevent mistakes. Besides that, it just tries to be smart and friendly to a developer.

Rider comes with native Unity plugin! It does not only make it aware of *.meta files, but also know MonoBehaviour specific methods like Update(). Thanks to it you will see a code-completion of these methods and you won’t be seeing any warnings about unused functions.

It’s even aware of Unity-specific optimizations like tag-comparing:

And maybe it’s not that important, but it also shows how Rider developers are getting into details – colouring of Color struct constructor:

Yeah, your guess is right! It shows you the actual defined color!

I won’t make a complete list of ReSharper features, because there’s just too many of them. Instead, please browse the documentation. There’s a lot of great and simple to understand examples out there.

Still, it’s important to mention that Rider, by contrast to Visual Studio Community and Visual Studio Code, is not free. Actually, it is distributed via Early Access Program which now costs nothing, but it’s justified to believe that Rider will be using a subscription payment model. For many people this information would be a no-go, but consider whether it is worth it – it can increase your productivity (in my opinion quite a lot, if you get to know it well).

But I’m happy with my Visual Studio on Windows!

I’m also a satisfied Visual Studio user on Windows. Why changing it then? The reason may be quite simple, take me for example. I’m working on Windows about 50% of time. Rest of it I spend on my MacBook and Linux Mint. On all three I sometimes need to do something in Unity. The real pain is that I have to use totally different IDE on all three platforms since Visual Studio Code for some reason does not play well with Linux (some strange mono issues) and I had to use MonoDevelop there. I’m really looking into Rider to get out from EAP to use it constantly on all of my 3 development platforms. And even now, while it is still in early stage, it works really, really well! Yet, if this scenario doesn’t fit you at all, I still encourage you to try it!


Rider is a fresh approach to .NET development. It focuses on developer’s productivity, happiness and it is aware of current market trends, which makes it an interesting alternative to Visual Studio.

JetBrains reader can be downloaded for free from its home page. Each version has a expiration period of one month. New versions are released at least once a month so until Rider is still in development, you will be able to work with it without any costs.

I strongly encourage you to learn as much shortcuts as you can – this IDE has been created for those who favor keyboard over mouse. If you don’t know the shortcut that you’re looking for, try hovering over an option to see a tooltip that often will tell you wanted key combination or try pressing shift twice to open Search Everywhere popup. It allows you to search through all of the Rider actions.

7 Ways to Keep Your Unity Project Organized

I saw a person on Quora the other day, asking how programmers are able to write projects that consist of over 10,000 lines of code. When software gets bigger, it is more difficult to maintain and that’s a fact. So here’s the thing – if you don’t keep your project organized, you’re going to have a hard time to keep the pace. Later on, you will find yourself wasting time with a messy project instead of adding new features. This is also true regarding any Unity Project. Here are (in my opinion) the most important tips that will help you with keeping your project organized.

1. Directory Structure

We cannot talk about organization without mentioning organizing project directory structure. Unity gives you a total freedom in that matter, but because of that, it can frequently get really messy. This is the directory structure I personally use:

  • 3rd-Party
  • Animations
  • Audio
    • Music
    • SFX
  • Materials
  • Models
  • Plugins
  • Prefabs
  • Resources
  • Textures
  • Sandbox
  • Scenes
    • Levels
    • Other
  • Scripts
    • Editor
  • Shaders
  1. Do not store any asset files in the root directory. Use subdirectories whenever possible.
  2. Do not create any additional directories in the root directory, unless you really need to.
  3. Be consistent with naming. If you decide to use camel case for directory names and low letters for assets, stick to that convention.
  4. Don’t try to move context-specific assets to the general directories. For instance, if there are materials generated from the model, don’t move them to Materials directory because later you won’t know where these come from.
  5. Use 3rd-Party to store assets imported from the Asset Store. They usually have their own structure that shouldn’t be altered.
  6. Use Sandbox directory for any experiments you’re not entirely sure about. While working on this kind of things, the last thing that you want to care about is a proper organization. Do what you want, then remove it or organize when you’re certain that you want to include it in your project. When you’re working on a project with other people, create your personal Sandbox subdirectory like: Sandbox/JohnyC.

2. Scene hierarchy structure

Next to the project’s hierarchy there’s also scene hierarchy. As before, I will present you a template. You can adjust it to your needs.

  • Management
  • GUI
  • Cameras
  • Lights
  • World
    • Terrain
    • Props
  • _Dynamic

There are several rules you should follow:

  1. All empty objects should be located at 0,0,0 with default rotation and scale.
  2. When you’re instantiating an object in runtime, make sure to put it in _Dynamic – do not pollute the root of your hierarchy or you will find it difficult to navigate through it.
  3. For empty objects that are only containers for scripts, use “@” as prefix – e.g. @Cheats

3. Use prefabs for everything

Prefabs in Unity are not perfect, but they are the best thing you will find to share pre-configured hierarchies of objects. Generally speaking, try to prefab everything that you put on your scenes. You should be able to create a new level from an empty scene just by adding one or more prefabs to it.

The reason why you should use prefabs is that when a prefab changes, all the instances change too. Have 100 levels and want to add a camera effect on all of them? Not a problem! If your camera is a prefab, just add a camera effect to the camera prefab!

Be aware that you cannot have a prefab in another prefab. Use links instead – have a field that requires a prefab to be assigned and make sure to assign it when instance is created. Consider auto-connecting prefab instances in Awake() or OnEnable() when it makes sense.

4. Learn how to use version control system (VCS)

git logoYou may already know something about GIT, Subversion or any other VCS out there. As a matter of fact, “knowing something” is only a small piece of what you may learn. You should focus on learning about important but infrequently used features of VCS of your choice. Why? Mostly because VCS systems are much more powerful that you think, and unfortunately many users are using these as nothing more than a backup and synchronized solutions. For example, did you know that GIT allows you to stash your changes, so you can work on them later without committing anything to your master branch?

Programmers tend to comment out blocks of code in case it’s needed later. Don’t do that! If you’re using VCS learn how to quickly browse previous versions of a file. When you are familiar with it, your code looks a lot nicer without unnecessary block of commented code.

Here’s a nice resource of tips for GIT users:

5. Learn to write editor scripts

Unity is a great game engine in the matter of extensibility (see Asset Store). Learn how to write editor scripts and utilize this knowledge. You don’t necessary need to create fancy GUI for your scripts, it can be something simple, as menu entries that are doing something useful. Here are some examples of editor scripts that I have created not so long ago:

  • Google Sheets .csv download – I had a translation spreadsheet saved on Google Drive. It automatically downloaded the newest version as .csv file, so I never had to do it manually.
  • Randomize the position, rotation and size of trees – I had a lot of trees and wanted it to look more like a forest than a grid.
  • Create distribution – Built for specified target, zips all the files and copy to the right place.
  • String replace in the sources – I had several files that contained the application version.

You can learn how to create editor scripts from the official documentation.

6. Learn to program defensively

Have you heard about defensive programming? Wikipedia defines it as follows:

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming techniques are used especially when a piece of software could be misused.

Generally when you’re writing MonoBehaviours, you should make sure that:

  • All needed references are set
  • All required components are present
  • If you’re using singletons, make sure that they exists
  • If you’re searching for objects and expect to find something, do it as fast as possible
  • Mix-in editor code (ExecuteInEditMode and #if UNITY_EDITOR) to do as many checks as possible before you run the scene

For many of these checks you can use asserts. You should also read A Story of NullPointerException Part 1 and 2.

7. Implement in-editor and/or in-game cheats

After you learn how to write editor script, you should be able to write a set of in-editor cheats. It can work as menu entry that unlocks something (all levels for instance). It’s really easy to create:

Generally you should write cheats that will allow you to:

  • Unlock all levels, characters, items etc
  • Give you immortality
  • Add/subtract values like time, money, coins etc
  • Allow you to see things not meant to be seen by players
  • Anything else that will help you with testing your game

Of course more practical (but harder to write) are in-game cheats. These type of cheats can be executed outside Unity editor, but you have to think how you would like to execute it. See our other article about implementing cheats subsystem controlled by mouse.

Myths and Facts of the Unity Game Engine

Unity is only for games

It’s a myth. Of course Unity has been created as a game engine, but it’s so flexible that it is successfully being used in other industries, such as architecture, medicine, and engineering. For an example, see 3RD Planet.

It is the largest online consumer event platform, showcasing the top tourist destinations in each country with Unity 3D.

The Coherentrx SuiteAnother example is The Coherentrx Suite.

CoherentRx is a suite of point-of-care patient education applications that combine realtime 3D anatomy models with HIPAA-compliant doctor-patient messaging. CoherentRx apps currently address ten medical specialties, from orthopedics to opthalmology.

In the Unity Showcase there’s a separate category for non-game applications. Check it out yourself!

Unity is free

It’s a myth, but not entirely. You can download Unity for free. The free (personal) version of Unity has all the features that Unity Professional has (with some small exceptions). When your game is ready, you can publish it and make money out of it! It’s just like that! But if at one point your company exceeds a turnover of $100,000, then you are obligated to purchase the Unity Professional license. It’s not too expensive at that point, because the cost is $1500 US dollars. Sounds really cheap when compared to $100,000, doesn’t it?

The difference between free license and pro license is that in the former one mobile games and web games display a Unity logo for few seconds on startup. It’s not a big deal, but as a professional game developer you may want to get rid of it sometime in the future. Also, you aren’t allowed to use Unity editor pro skin and Cache Server.

You can only do small games with Unity

It’s a myth. The reason why there are so many small games created in Unity is that it is very indie-friendly. Unity does not constrain your game size in any way. You can create a clone of World of Warcraft if you really want to! All scenes can be loaded and merged in the run-time, so player won’t see any loading screens while playing. It’s also not true that Unity performance degrades when you have too much objects on your scene. Of course you have to optimize it in a special way. So it’s all about the experience.

One of the greatest examples of a large-scene and well-optimized Unity game is City Skylines.

Unity is worse than Unreal Engine

It’s a myth, but it really depends on what are your needs (it’s not worse in general). Unity has been always compared to Unreal Engine because the latter always had the upper hand in game development industry. Today the situation is a little different. While Unreal Engine was targeting PC and stationary consoles, Unity took its chances with mobile devices. Unreal was always about big games with stunning visuals, but this approach made it more difficult to learn and use. Unity on the other hand is based on the Mono platform. Thanks to that you can program your games using C# instead of C++ which is quite difficult to learn.


Unity GDC demo – Adam – Part 1

Today Unity is trying to take over the Unreal Engine market. The first steps were made by Unity 5 graphics enhancements and by the optimization of scripting backend. On GDC 2016 Unity Technologies has published a stunning real-time demo of what Unity 5.3.4 is capable of. From today it will be more and more difficult to tell the difference between Unity and Unreal Engine graphics capabilities.

You don’t need programming knowledge to use Unity

It’s a fact. It’s easier when you have at least some programming knowledge, but you can easily build a complete game without it. One of the most popular editor extensions on the Asset Store is Playmaker. Playmaker allows you to build finite-state machines that will drive your entire game logic, and it does it well! If you need a good reference, then Dreamfall Chapters is a damn good one!

playmaker screen

Because of this fact many people may consider Unity as a toy rather than a serious tool for creating games. The truth is that Unity can be used by everyone, regardless of your skills!

You cannot spawn threads in Unity

Again, it’s a myth. Many people are confusing Unity coroutines with threads. Let’s get this straight: Coroutines have nothing to do with threads. Coroutine is only a way to delay code execution without too much effort. It’s really a great method of writing game code when some routines are needed to be executed in sequence over a time (like animations), but everything is still done in a single thread.

Yet you can create threads in Unity. You will not find too much about it in the official documentation, because there’s not much to be said. All you need to know is that Unity API is not thread safe, but it is a good thing! To learn more about how to use threads in Unity please read our article about threads.

All Unity games looks the same

It’s a myth, of course. Every developer who decides to use one game engine or another is asking himself a question how this game engine will help him and how it will constrain his ideas.  Unity is quite interesting because it’s easy to learn and hard to master. Yet if you will master it you will realize that you can do almost anything with it! You can even create your own game engine within! If you’re still wondering if Unity constrains your creativity, stop right now. It doesn’t!

You need to know that many of Unity components (like physics) can be replaced by anything you want. There’s no requirement of Unity game using components provided by Unity. This is a great deal if you have very specific needs.

Unity has a lot of bugs

It’s a fact. Since Unity 5 the developers were rushing forward with new features, but with a cost of stability. On GCD 2016 current Unity CEO John Riccitiello announced that Unity will take a road of increasing Unity releases’ quality. At the time Unity 5.3.4 has been released and Unity 5.4 entered a beta stage. Let’s hope for the best, because we all need a tool that is as stable as possible, and lately there was a serious fear of upgrading to a new release that could be heard in Unity community.

How to Make a Custom Editor Window in Unity

Today we will cover creating custom Unity editor windows. They can be used in many different ways. Most probably you know them from 3rd party assets. Even if you’re not an asset developer, creating custom windows may help you greatly with your game development!

One of good examples of how the custom Unity editor window may be used is an implementation of in-editor cheat subsystem. Some time ago we created a cheat subsystem that is working within the actual game. Implementing some cheats using the editor windows has one significant advantage – it’s much, much easier to write and use! Read this article further on to learn how easy it can be!

Creating an editor window

First, we have to create a new window. In order to do that, we need a new class inside Editor folder (see Special Folder Names).

editor cheatswindow script

Then start with code like this:

Let’s explain:

  • At line 4 we have to make CheatsWindow class, a derived type of EditorWindow class
  • At line 6 we’re telling that the following method should have a Unity menu entry. It will be available at My Game/Cheats in this case.
  • At line 7 there’s a static method to create a window.
  • At line 9  a window is created (if does not exist) or focused (if exists) – see GetWindow documentation.

When the Unity compiles this code, you will notice a new menu entry.

cheats menu entry

Try clicking on it, and a new empty editor window will appear!

empty editor cheats window

Now let’s try to fill it with some content!

Adding content

To add content to our new editor window we have to implement OnGUI method just like for MonoBehaviour classes. The only difference is that you now have the access to EditorGUI and EditorGUILayout classes, but still you can use GUI and GUILayout classes as well! Let’s try it.


That was easy! But as you might have noticed, you won’t be able to edit the data just then. GUI functions are returning a new value as a parameter and a current value should be passed as a second parameter to make it work. Let’s implement new Cheats class. This one will be located outside the Editor directory so the game script will be able to access it. Watch out, this is a big one!

OK, let’s split it to smaller parts.

#if and #endif are so-called preprocessor directives. The #if UNITY_EDITOR evaluates to true if UNITY_EDITOR symbol is defined. The Unity defines UNITY_EDITOR symbols when you’re working in the editor, but not when you’re building your game to the target platform. That way using UnityEditor; will be stripped-out when you build your game (see Platform Dependent Compilation). And this is necessary, because the Unity compiler will yield an error if you try to use the UnityEditor namespace inside game scripts without any environment check.

Next, we have a property:

And the getter:

This is working very similar to previous preprocessor construction, but here you also have an #else directive. The #else code block will be included if the #if condition evaluates to false. Simply talking, inside the Unity editor this code will get boolean value form EditorPrefs, and outside the Unity it will always return false.

Setter is very similar to getter, but here we don’t need an #else directive, because we don’t want it to set anything outside the Unity editor (there will be nothing to set it).

The rest of the file consists of two more properties with similar construction.

Now let’s modify our window code:

As you can see, since we made our cheats data this way, it’s really easy to read and save the persistent data. Now, even if you restart your Unity editor, the cheats will be still in effect!

Adding buttons

How about a reset button? That’s easy!

cheats reset button

But by default the reset button is quite big and located right below other fields. This makes our window look kind of unfinished. Let’s fix that using GUILayout.FlexibleSpace() before rendering our button.

cheats one flexible space

Now if you want your button to be smaller you have to play with EditorGUILayout.BeginHorizontal() and flexible space.

cheat window two flexible spaces

And maybe a final touch.

cheats window final touch

The package

As always you can download the unitypackage containing scripts described above. Feel free to download, modify and adjust it to your own needs!

Unity 5.1 Assertion Library

There’s a great article by Yegor Bugayenko called Need Robust Software? Make It Fragile. It’s about Fail Fast philosophy where you should write your code in the way that your application will fail as fast as possible if something is significantly wrong with your data or environment.

When you’re building a mobile game with Unity then most probably you’re eager to set Script Call Optimization to Fast But No Exceptions option, as soon as you’re sure that you can do it.

Fast But No Exceptions option is hidden in Edit -> Project Settings -> Player menu (Other Settings/Optimization section). By selecting this option your code will be stripped from the exception handling code in a favor of better performance. By enabling this option you’re also taking a great risk. From now on, any exception will immediately crash your game and you won’t even know what was the cause (crash log may be not so helpful at the time).

Knowing what the stake is, you may want to enable Fast But No Exceptions option only when you’re pretty sure that your game won’t throw a single exception not ever once. There’s a plenty of situations when something may go wrong. Moreover, if you’re not the only person working in the project, the risk is even greater. It’s really easy to get NullReferenceException when your MonoBehaviour script setup requires reference to some other game objects and somebody will delete those from the scene.

Don’t assume anything

Don’t assume that your script is set up correctly. Be a pessimist and think of worst case scenario all the time. Let’s take this script for example:

This is a very basic example on how the Plane may interact with an Airport. I think you already know what I am going to say. This code will break if there’s no airport set. This is the case where we assumed that anyone who is working on the scene will be careful enough to connect all the references between the objects. It’s not so easy, because the Unity won’t give anyone any error or warning when they don’t connect all the references unless they run the scene and see the exception (that says very little for non-programmer person).


OK, let’s try to make this script a little more self-aware. We want it to make a noise when something is wrong with it. In order to do that, I will use MonoBehaviour.OnValidate() message. OnValidate() is called:

  • In the editor without the need of entering the play mode
  • when any script value is changed
  • when the scene is loaded

So the script may now look like this:

That will print error messages to the console that something is wrong while playing with your game in the editor, and for most cases this will be good enough. However, you may also want to check if the airport is not null on the runtime (OnValidate() function works only in the editor).

OK, you’re now quite sure that your game is not throwing any exceptions, and all the validations are causing some (small, but still) overhead. How to get rid of it? Maybe preprocessor will help?

OK, that’s pretty lot of code for such simple task. Maybe there’s another way?

Asserts to the rescue!

If you’re Unity 5.1 (or above) user, then you can take advantage of the new assertion libraryIt’s really easy to use and all needed functions can be found inside the Assert class. Let’s use it instead of a simple null-check.

As you can see, I’ve used Assert.IsNotNull(). This function tells that I am expecting the value to be not-null and if it is null then I’d like to know about it.

Asserts have some advantages over manual checking:

  • Simple and readable code
  • Error messages are clean and readableassert error message
  • By default asserts are stripped off when building the game is in non-development mode (you don’t need to use preprocessor).

If you want asserts to be included in your build (asserts are not exceptions by default) then all you need to do is to define UNITY_ASSERTIONS in Script Define Symbols that can be found in Edit -> Project Settings -> Player menu. Asserts are not breaking the execution; assets will just print the error and the execution will continue. If you want it to act just as exceptions (breaking the execution), make sure to set Assert.raiseExceptions to true from your code.

And remember, the asserts may be used anywhere in your code (it doesn’t have to be at the beginning of Update), but it is a good practice to check as many things as possible before the actual code is executed. Fail fast and be safe!