So a lot of people ask me why we're not using Unity, and there are so many reasons that I realized I should just put it all into a blog post.

The License Terms

The most obvious reason is of course the Unity license terms. We much prefer to stick to 100% free and open source (FOSS) software, which of course means that we're fully free to use the software commercially without having to worry about paying license fees to anybody. As well, here at WindFish we tend to make our own contributions to open-source projects; not just to give back to the community but also to ensure that the FOSS software we use meets our needs while also allowing the general public to enjoy those improvements which we've made.

Best Practices

The much more important reason we've stayed away from Unity is that as a framework, it doesn't really adhere to any software engineering "Best Practices".

Lack of Formalized package/dependency System

In most other languages (for example Ruby, Javascript, Python, Elixir and Go) there's a defined structure for package dependencies. This means that your project (and indeed, what ends up in your VCS) contains only your source code. The rest of your dependencies are downloaded and installed automatically via commands that come bundled with the language itself, for example: npm install in Javascript, gem install in Ruby, pip install in Python, mix deps.get in Elixir, or go get in Go. This is so common that it's become a nearly-universal part of software development.

In Unity instead of having the typical package-dependency structure, you get "Assets" which are bought from the Unity Assets Store. These "Assets" adhere to no formalized structure; they typically consist of a mix between game assets (like textures, meshes, materials) and also raw source-code, with itself adheres no particular predefined structure. Instead of enforcing a strict separation between your code and its dependencies, in Unity when you download an asset it all just ends up in your project folder, intermixed with your own code.

Version Control Hell

Firstly, This creates for an ugly situation when it comes to using version control systems like git where ideally you would only want to version the code itself, which is what git was designed to do. A much better practice for versioning large assets (textures, meshes, materials and the like) would be to use a 3rd party storage service like S3, where one can also version the binary assets themselves. All the while, keeping the binary assets and the actual source code separate.

Modularity (or lack thereof)

Secondly, the lack of separation between your project's code and the code of its dependencies is a violation of the "separation of interests" principle of software development. It's widely recognized in the field that maintaining a high degree of modularity is always the ideal way to construct a project of any size. In Unity a developer is faced with the proposition of having to modify the source code and structure of the dependencies they choose to use in an attempt to make all of the projects source code conform to some consistent pattern. This wouldn't happen in any other language.

Since most developers understandably choose not to do this, as their application grows they end up with very un-modular code, where much of the logic in the game becomes inextricably tied together, forming what has come to be known "spaghetti code". As an application grows large, spaghetti code actively impedes development, which is an effect which grows worse over time.

Truly modular applications which adhere to the "separation of interests" principle are agile, meaning that because the modules aren't logically tied together one is able to change and/or replace them easily. Spaghetti code tends to mean the opposite: a change in one module can cause problems in a number of other modules because they are all logically tied together in ways they shouldn't be. This leads to development taking much longer than it should have to.

This is not only due to the fact that Unity lacks a truly modular and formalized package dependency system, but also because it doensn't really enforce (or even suggest) an over-arching structure for the source-code in a game. As such, lacking any formalized framework or guidelines to follow, it's an extremely commmon problem in Unity that as a game grows large it becomes increasingly harder to develop.

One great example is this job-posting from Finji games in which they're struggling so much with their Unity-based spaghetti code problem that they're looking to hire a new team-member just to "come fix it". This loss in productivity ends up costing real game studios real money.

The UI Problem

Really the reasons listed above represent the most important reasons why we've chosen not to use Unity, but there's still more.

At WindFish Studio, we're writing a game which is extremely heavy in UI (User Interface). In simulation/strategy games we have to communicate a lot of data to the user, which can easily get out of control and become overwhelming unless we have a sophisticated UI engine with which to do it. At present, the most used virtual machine on earth is the web browser (or "navigator"), which specializes in presenting highly-customizable "rich" user interface to the user, while also providing a truly agile framework to the developer. These are sophisticated front-end UI development technologies which themselves have been in development for over twenty years.

As well, in recent years it's not uncommon for a multiplatform games to run on extremely variable screen sizes. A single game might need to run on a screen as small as a smartphone, scaling all the way up to an 8K television screen. The UI in the game has to be responsive to those changes in screen-size. Leveraging traditional "web" technologies ends up being a fantastically simple way to overcome these issues without having to re-write lots of code or many versions of the same UI.

While there are tools that exist in the Unity ecosystem to overcome these problems such as NoesisGUI, they are specialist tools as compared to what can be acheived with more common "web front-end" technologies. They lack the ample development community which has grown unbounded during 20+ years of front-end web tech proliferation.

Attack of the Clones

Finally, using a tool like Unity can really improve development time if your game mechanics fit into a predefined "template" of previously-seen games. For example: if you're making a platformer game or an FPS game, Unity might be a great choice for you to save time in development and avoid writing a lot of code, although the previously-listed problems in this article continue to be very real.

These games are mainly "content-focused". Meaning the mechanics and basic concept of the game is already well understood having been seen many times in the industry, and the real focus on the game is it's art and level design. The main challenge in development of a "content-focused" game is mostly about the development of the assets themselves and the integration of the final product into a single cohesive package. The actual code in the project is usually reduced to a minimum.

For this reason it's become increasingly common for game studios to purposefully choose to pursue ideas that don't actually contain any unique mechanics or play-concepts, specifically so that they can use an engine like Unity and reduce the entire game development to "content development". Writing code is difficult, and hiring a large software engineering staff is expensive.

However, the final result is that we're seeing a flood of games in the industry which lack any real originality in terms of game concept. It's almost like there's thousands of games where the basic idea is the same or perhaps minimally tweaked, but then it's been "re-skinned" over and over with different art and sound. To me, this represents a decline in the overall creativity of the industry.

Too many game studios are choosing which projects to develop based on financial motives, instead of creative motives. At WindFish Studio we're trying to buck the trend.

Final Thoughts

Since our game concept doesn't really fit into any pre-defined game "template", using Unity wouldn't really have gained us much savings in development time. Rather, we would've often found ourselves fighting against the framework to try and express the mechanics that we wanted to express at the scale which we wanted to acheive. For this reason coupled with the many reasons listed above, it just wasn't the right choice for our studio.