Successful start

There are two ways to create games or applications in Unity. You can write all the code yourself, which is very long and difficult. Or you can use ready-made plugins. These are packages with a set of development, design and other tools that you can just download and straight forward use in the game. Those plugins help to use all the parts of the project as playing with a constructor.

To simplify the development process, Unity created its own Asset Store (as an analogy of the App Store for iPhone), where developers posted and sold their plugins so others would not waste time and use ready-made solutions for their tasks.

At the same time, my colleagues from the KAPPS team and me started developing such plugins for Unity. We are developers. This means that no one but us better understands how to create products that will make developer’s life easier.

Our plugins really made us well-known around the community. Soon, we became one of the top 5 teams by downloading at the global Asset Store. The most popular of our plugins are Ultimate Mobile Pro, iOS Native Pro, Android Native Pro.

Therefore, the support of the Asset Store recommended us for Unity users itself. Because of this, such famous companies as Moon Studios and OneSignal asked us to help with their development. And we successfully work with them to this day.

But just as in every good story, right when we became popular among Unity users, we made one of the biggest failures in our career.

Loss of control and money

We started working on plugins as soon as they appeared in Unity. Back than we didn’t have that much of a experience, so we thought we were doing everything right. But at some point, the process started to snowball. And here’s why.

The creation of the plugins looks like this:

• you create plugins and upload them to the store;
• other developers download and use them;
• if something does not work, they write reviews or requests to fix it.

Everything here is just like in any other service: you get feedback and start doing everything to improve the situation. So we have been releasing new plugins and at the same time have been fixing everything that users asked us about.

Meanwhile, the competition and the demands of our audience were growing. We were shown a problem – we solved it, we were given a request – we fixed it. But again due to lack of experience, it had turned out that our plugin architecture was really bad. We worked fast and tried to quickly deliver fixed products, but forgot about the quality of the original code.

At that time, we launched twelve plugins for general use, which we were “renewing” all the time. It took a lot of effort, and, of course, money. And we realized two things:

• Fixing all the problems people complain about is unrealistic. It’s easier to just rewrite everything.
• The financial costs of supporting and developing the project went beyond what we have earned at the Asset Store.

Basically we had earned $ 5-7k a month from plugins sales. And exactly the same amount was paid to developers to fix bugs. This is an perfect example how bad code and bad architecture “killed” a really good product – our plugins. We did not cover the cost of product development. And it could not go on like this.

Difficult decision

So we made a very difficult decision. We stopped the current developing processes. We took a break, removed all our old plugins from the Asset Store and started writing new ones. It all took about a year. Every day we were writing new products from scratch. But this time it was different: it was a clean code and good architecture.

Product quality

The effect was amazing. After we rewrote the products, it became 10 times cheaper to maintain them! Whereas in the beginning our developers spent days fixing problems, now it takes several hours a week.

Previously, plugin support cost us $ 7-10k, but now it costs only $ 800. After this incident, we have learned forever that the correct architecture, clean and well-thought-out code will help us to develop the product way easier, cheaper and better. This principle applies to any job, project, or career.

Always put quality first. Then you do not have to redo the work and spend money on fixing errors that could have been avoided and therefore there would be no need to risk your reputation.

The post An amusing story of how we almost killed our product appeared first on KAPPS.

1. Through the Privat Bank, leave your donations via the bank app for Dobro fund or the Ukrainian Armed Force.
2. Through the National Bank of Ukraine.
3. Join the HelpList website for requests for help of various kinds.
4. Help social assistance in Kremenchuk (a woman simply buys baby food and diapers and delivers them, and she requires money for the goods and delivery). Card number to transfer money 4441 1144 4913 6637.
5. Purchase of pharmacy and distribution to Kharkov hospitals. Card number to transfer money 5457 0822 2693 6354 (Kirienko Andriy).
6. Who’s in Montenegro – visiting local military offices in Podgorica and buy everything necessary for military needs (from clothes to thermal imagers) or help refugees. DM us, if you’re interested to help here.
7. Help Carfinder, the guys are engaged in the selection of cars, we know them personally. They collect money for cars and the needs of the army, they also buy walkie-talkies, armor, and thermal imagers.
8. Bot for Ukrainian Borders.

ALSO, please send us contacts of local volunteers you know personally. We’ll be updating our article with new info on helping every day! Because in addition to the army, millions of families in Ukraine need housing, food, and money.

The post We stand with Ukraine appeared first on KAPPS.

Well, we will start from the beginning. ​​ECS is one of the Unity DOTS stack modules that was introduced back in 2017. DOTS includes several technologies, with the core ones as Job System, ECS, Burst Compiler, as well as other packages: Unity Physics, Unity Netcode, DSPGraph, DOTS Runtime, Unity Animation.

The heart of the stack is the Entity Component System, which includes: 

• Entity – entities that live in the project;
• Component – data components that give entities various features;
• System – pure systems that work with entities and data that are inside their components.

During our webinar, we showed a demo in which ECS DOTS, compared to MonoBehaviour, demonstrates incredible performance. We got this speed of work due to the fact that each of our Entity (data container), which we can very easily find, was processed in one place within our system. Solving the same problem with MonoBehaviour, we would do this operation in Update and in each MonoBehaviour separately.

It is very important to note that the DOTS stack allows us to work with the Job System and Burst Compiler without a data-oriented development approach. Accordingly, the Job System opens the door to the world of multi-threaded work with the Unity API. Although Burst Compiler imposes certain restrictions when writing code, as a reward from LLVM we get highly optimized code adapted to the current platform. Therefore, we can conclude that ESC is not the only way to optimization and performance increase when using DOTS.

Let’s analyze when ECS is really good and useful?

• When a project has a huge number of entities with the same archetype.

• ECS gives us flexibility in logic. It forces us to think and build the project accordingly DoD. It’s important to note that often when developers see methods inside components – they mark them as a mistake. Fortunately, this is not always the case, and let’s see why. A component can have logic within it that only handles the current component’s data. For example: inside the Vector3 structure, we can find many convenient properties such as Magnitude, Normalized or the Set method. All of them are created with a single goal – to help the developer.

• Photon Quantum (deterministic high-performance ECS environment). What is the main difference between PQ and the usual Photon server that we are used to interacting with in the Unity world? It consists in the fact that in the heart of Photon Quantum everything initially lives in the entities form. You will have to work with unmanaged code in C# and in this way you will be able to migrate to ECS in Unity almost seamlessly. In fact, the application on Photon Quantum works like a large simulation, and Unity is used only as the view-layer, which means that your game can live and work in headless mode. Photon Quantum has its own pathfinding, its own physics engine, and many others. Also, Unity’s physics simulation system is bad because it’s non-deterministic. This means that with the same input data, I will not get the same results of a physical simulation. In other words, we cannot rely on such a system if physics is an important part of the gameplay in our game. Therefore, Photon Quantum has its own physical deterministic framework (same input = same results on different clients).

And when is ECS not that good?

• When you need to be prompt. From a business and development point of view, there will be more time spent on developing an application that you create when using ECS. Because you will need to come up with your system, entities, components better and longer. The amount of the actual code that you will need to write for ECS will be literally bigger compared to MonoBehaviour. Therefore, your overall development time will increase. But it is important to remember that many frameworks suffer from this (they oblige us to write boilerplate code), but at the same time, having worked more at the beginning, we get more advantages later.

• When it comes to UI and animation. Very often in the ECS demo, we see some cool stuff. But the complete project is not just one gameplay. And the important part of the result that we want to see is the animated UI. And at this moment everything becomes difficult, because if we go to pure ECS mode, for example, we have Project Tiny, then in general we have no other Rendere and we cannot render in any way, except through ECS components. This means that we will have to build the UI in the same data-oriented stack. Doing this is not very pleasant, and in principle, ECS is not very well suited for solving these problems, not to mention the complete absence of any frameworks, developments, and anything else in this direction. That’s why, it will be very difficult for you to build a UI, not to mention animation and other features that you definitely want to fill your project with.

• When there is the readability of the code issues. This is a common programming problem. The larger amount of code you have, the more difficult it is to read and the more potential bugs it has. That is, imagine if I lived in the world of MonoBehaviours, then I would have only one class, where I have certain serialized fields that I use as data, and an update loop in which my logic spins, which processes each frame. If I were doing the same task in the ECS world, then I would have at least one more component class. And there must be some other bootstrapper that will create all my ECS entities so that it all lives in the ECS world.
• When you need to connect the MonoBehaviour (where we need to render something) and the ECS worlds (where there is only data and logic). Here everyone faces this “how to make them both friends” problem. You will write various data bindings, when in fact our Views will follow some entities, the positions of which we calculate in Job Systems. After all, many systems should interact within your project, and if they are from different worlds, then the implementation of their interaction will always be a very non-trivial task. In Unity, it is important to remember that people work with scenes and content. And ECS is not yet very friendly in this regard. Imagine that we do not see anything on the screen by rendering until world entities are created in the ECS domain. Artists and game designers cannot work like this, they need “live” scenes. If we recall our Unity inspector, then in ECS it will not allow us to edit values. This is what closes the doors of opportunity for artists and designers.

How and when is it best to use ECS?

ECS in Unity is most often associated with optimization. Because when the are some problems with a huge number of Monobehaviours appear, a developer can make a decision that they switch to a data-oriented stack and start rewriting the entire project. Of course, in many situations, ECS will give you a significant result, but first, we’d advise to ask yourself a few questions:

• Are you ready to rewrite most of your project? After all, everything will not be limited by just one system, and it will pull others along like a snowball.

• Are you sure you have considered other optimization options and ECS is the only way? We faced a lot of situations when developers gave up due to performance problems. But often those tasks were solved with a couple of detailed and combat profile sessions, implementing a few new ideas. The developer, if we’re thinking from C# point of view, has so many tools: optimization of the mathematics, of the algorithms themselves, basic optimization approaches in Unity, and, finally, the Job System and Burst Compiler (without ECS yet).

– Another very important factor in deciding whether to use ECS is the stage of the project. If the project is in the early stages of development and it is possible to put in extra time to build the same task using a data-driven approach, then we’ll be more okay to do it. After all, the number of systems that will need to be changed is less. But if the project is close to completion and is already in production, it is very difficult to suspend all development and start rewriting all the code for N months.

Also, we have deadlines for our projects, and pushing any of them back can cause a potential loss of position on the market. Sometimes it’s better to focus on current business conditions and opportunities, not just the technical aspect.

Therefore, all of the info we’ve shared today can be briefly summarized in one phrase: ECS has to be used not for the sake of the ECS development concept, but for the sake of performance when the application really needs it.

And do not forget that using any new technology or framework in a project is always a risk and very important to understand and evaluate beforehand. Good luck!

The post Improving a Unity project: what is ECS and is it worth using it in development appeared first on KAPPS.