You have probably stumbled upon the concept of the Testing Pyramid at some point… It highlights the value of testing, but even more so the importance of knowing where and how to test. We want our tests to cost less and the results to be fast. How should we accomplish this? Let’s find out together!
I always had a big interest in the topic of technical debt (I will use TD for short). Technical debt exists to a certain extent in every project which I’ve been in development for more than a few weeks and influences the life of every developer. If you have a lot of it then your life is going to be full of suffering and the delivery time of new features will grow with every release.
Tests should be easy to read and fun to write! In our daily business, we add new features and do refactoring or bug fixes. Every change could lead to a failing test. If we look at the failed test, we should immediately be able to understand what the test is doing. But often enough this is not the case.
In this post I will show you how we improved the readability and maintenance effort of our tests by introducing a builder-like API to prepare the test scenario.
Well written automated tests can increase the understandability of code and make easier to maintain for a long time. But using unit-test on existing projects often felt like using the wrong tool for the job.
In this post I would like to show the different kind of tests I use to add tests to an existing (untested) code base.
Unity DOTS/ECS is powerful at processing huge amounts of operations. This performance relies on data lookup in continuous chunks, but what if you encounter dependencies between entities and have to jump between chunks? All entities should follow a moving target or entities should react to actions from another Entity? This post highlights how entities can interact with each other and what implications this has on performance.
When the requirements are given for a piece of software, they usually cover only a minor section of what the software should do and be. Aspect-Oriented Programming (AOP) provides a way to think about all the necessary, but not easily compartmentalized components of a software system.
In this blog post I will demonstrate how to use Unity’s EntityComponentSystem as well as Burst compiled Jobs to build a dungeon builder game like the good old DungeonKeeper.
This awesome old game turned out to be the perfect example to show of some techniques that will hopefully help you to get into the mindset of DOTS and EntityComponentSystems.
Is it possible to do Quality Assistance in the games industry remotely? Turns out it’s not that difficult.
Change is always scary, but at the same time essential for transforming an existing matter into something new and better.
What is an asset pipeline and how can you make asset integration more efficient, in a Unity project?
In this article I want to present our setup and give an introduction to developing custom tools, to help with some of the most common asset integration tasks.
In this article I want to take you on the journey of how we managed to reduce our mobile client build times from over one hour to about 20 minutes for God Kings.