LIFE AT NORDEUS

HOW CORETECH TEAM HELPS OUR GAME TEAMS?

Developing a game is a huge multidisciplinary effort. It includes a lot of experimentation until all the game mechanics are determined and polished. Game teams need to focus on these gameplay features and quick iterations upon them.

Unfortunately, as soon as the project reaches some complexity, hurdles on their path start popping up that are not essential for the gameplay and yet require tackling. Some examples are:

• performance issues,
• game engine not providing an out of the box technical solution needed for some game feature,
• updating third party SDKs and Unity itself,
• or just ending up with a bad project architecture that is slowing the team and their iterations down.

Comparing performance of old and new UI framework

When developing a game as a service there are a number of backend services that game teams also expect to get as easy as possible but with flexibility they might need. These might include support for sending push notifications, payment processing, handling localization, user authentication and others.

When a studio starts developing and maintaining multiple games it becomes important to have an efficient way to share code, libraries and services in order to reduce maintenance costs and need to reinvent the wheel on each project.

Since it is very hard for game teams to handle all these challenges and remain focused on making  games, usually a separate team is formed to handle them. That is why at Nordeus we  have a Core Tech team that needs to have a high technical expertise, solid familiarity with all the projects and being able to closely collaborate with game teams.

Let’s take a look at some of the things that this team needs to work on in more detail.

EXTRACTING AND MAINTAINING COMMON CODE

There are many aspects to effectively sharing code among multiple teams.

• The code needs to meet a certain quality criteria so that teams feel comfortable updating it.
• The API it offers needs to be well designed to fulfill all of the team’s needs but remain as simple as possible.
• It should allow teams to easily debug and step through that code.
• It should also allow teams to easily edit that code and submit fixes and improvements.
• It should be well defined and stable so that one team can’t easily make a breaking change for another team.
• It needs to be easy to distribute and update such code in different projects.

Most of this shared code is foundational, something that higher level systems then depend on. Usually this code is something that originated in some game project in some prototype state. Core tech team needs to identify such code, understand it completely and see how to extract it and improve it. Through this process a lot of foundational knowledge is collected and documented like platform limitations and possible workarounds, performance bottlenecks, proper error handling etc.

Through the years we tried a few approaches to code sharing for Unity projects, from copying code to using git submodules but we settled on using NuGet packages with a modified version of open source NuGetForUnity tool that we are also maintaining.

A good example are our two packages that act as wrappers around UnityWebRequest. At some point we noticed that we are using the UnityWebRequest class in multiple places and that often those places contained a lot of similar code around it. We analyzed those places and identified two primary use cases: sending a simple web request and downloading files from the internet. These two use cases had some different requirements. For web requests it was important to be able to easily send and receive objects serialized as JSON while for downloading files it was important to properly handle timeouts, retries, download progress, decompression, file caching and similar. That is why we created two packages: WebHelper and DownloadManager. We made sure to properly handle all the possible errors, content encoding, headers and to provide a much easier API for use. We also implemented unit tests within these packages that can easily be run even on devices with a very small and fast to build Unity project.

Game projects now have a simple API for sending web requests and downloading files with a consistent error handling and whenever Unity changes its API around UnityWebRequest we only need to make the update in two places which are these two packages and all the projects can benefit from it.

DEVELOPING A CUSTOM UI FRAMEWORK

The games we develop are extremely UI heavy. When we first started using Unity we went with Unity UI but quickly realized it has too much usability and especially performance issues for our needs. We then adopted a third party NGUI solution which solved most of our performance issues but didn’t improve much on usability. Through time we modified it a lot, trying to increase its usability and although we made significant progress we hit some system limits that made it really hard to improve further.

In the end, using all the experience we got so far and knowledge about things that bother us we developed our own UI solution. The approach we took is actually similar to what Unity is now implementing in their UI Toolkit framework but we are much more feature complete at the moment.

Because it is very important for us to be able to visually design the UI of the game we also implemented our own visual UI designer. Within it we also implemented a custom tool for making UI animations with curves. As you can imagine, as in any UI framework there are always new ideas for improvements like: UX improvements in the designer, performance optimizations, adding features to controls, adding new controls and addons, adding new features to the designer etc. We must have a very thorough understanding of the whole UI system and how Designer is functioning in order to support game teams in all their needs. We also have to follow what game teams are doing and how they are using the tools we provide so that we can find things that need to be improved. Tech artists in game teams, for example, can easily implement many additional features to the designer and animation tool that everyone can benefit from.

WRITING AND MAINTAINING COMMON SERVICES

There are a number of services that all games require at some point. The examples are services for sending push notifications, processing payments, providing configuration to the clients and similar.

For implementing any of these services a good understanding of requirements from the game teams is a prerequisite. Next step is coming up with many possible solutions like should it be an independent service or library that needs to become a part of another service or support both, does it need to have a web dashboard, does it need a Unity tool that communicates with it etc.

Here we get to use the latest C# features and web frameworks and possibly then transfer some of that knowledge to Unity projects. We also need to do some web development but by using .NET Blazor almost everything can be written in C# and there is rarely a need to use Javascript. Again, one of the most important skills required here is good API design, especially since you constantly need to have backward compatibility in mind once the service becomes live.

WHAT OTHER PROJECTS CORETECH TEAM CAN HELP WITH?

There are many more things the Core Tech team can do to help game teams and through them there are a lot of opportunities for learning. Here are a few examples:

• Doing performance measurements and optimizations where you learn about tools you can use for this, what are things you can and need to measure and discover how code can be written in a more performant way. With more practice you get better and better at writing more performant code from the start while still keeping it readable and understandable as much as possible.
• Providing tools and services for remote logging and metrics tracking from clients where you learn about cloud management tools, how to manage huge scale of requests and huge amounts of data.
• Investigating and trying out different ways to organize game projects to fulfill different needs like having support for easy unit testing or making it difficult to write bad code and making it easy to write good code where you learn about different architectural styles and their pros and cons.
• Thinking how can you make creating a next game from scratch as easy as possible you get to learn about the latest Unity and C# features and tools.

Our job is to become go-to people for any technical questions anyone might have and to be the prime movers bringing better ways of working. If all this sounds like a good challenge and a lot of fun (which it often is :)) make sure to check our careers page and get in touch with us.