How people are writing games these days, anyway?

Current Landscape of
Unity Engineering

Artūras Šlajus


Unity has its own style

Unity usage tends to fall into one of two patterns:

  1. Unity-style ECS (entity-component system)
    • Entity is GameObject.
    • Component + System is MonoBehavior.
    • Object-Oriented, imperative.
    • Original way of developing with Unity.
  2. DOTS-style (Data-Oriented Technology Stack) ECS
    • Oriented at fast computation and parallelism.
    • Not Object-Oriented (Data-Oriented), imperative.
    • The future way of developing with Unity.

And it works pretty well...

...for gameplay.

Gameplay code is:

  • Concerned about object identity.
    • Two units in game are considered distinct even if they are at the same exact position and have same exact hit points.
  • Does a lot of updates every frame.
    • Entities are moved, damaged, upgraded, etc.
  • Often does not require complex relationships between things.

Imperative programming is a great paradigm for gameplay programming.

However... are not only gameplay.

They are also:

  • Meta-game around the main game loop: progression, upgrades, economy.
  • Configuration and content systems for live operations.
  • Orchestration between different parts of the game.
  • User Interface (UI) code. Loads of it.
    • In fact, in our games the UI code usually a much bigger part of the code base than the gameplay code.

And unfortunately imperative programming is a suboptimal paradigm for all of those things.

And it shows

Games are known as notoriously buggy pieces of software.

Rise of Cultures

Why does it matter?

Nobody wants to play buggy games.

Buggy games result in:

  • Loss of sales and existing players.
  • Bad reviews which make it harder to attract new players.

Why does it matter?

It also inflates business costs directly.

  • Development takes longer trying to fix bugs - more costs.
  • Developers become frustrated with buggy codebase and are more likely to quit - more costs for recruitment and onboarding.
  • Projects then suffer from brain drain and can enter a state where:
    • nothing works;
    • nobody knows why (because the original authors have quit);
    • nobody can figure it out and fix it;

Are we doomed?

Companies that have been working for years still make buggy games.

Company Established Years in business
Ubisoft 1986 36
Blizzard 1991 31
CD Projekt Red 1994 28
InnoGames 2007 15
Activision 1979 43

I mean, if a company that has been in the business for 43 years still can't make a properly functioning game, then surely there is no hope?

Luckily, no ;)

U1. Current Landscape of Unity Engineering

By Artūras Šlajus

U1. Current Landscape of Unity Engineering

We talk about the default way of writing things with Unity, and why they are lacking.

  • 392