One Year of Data-Oriented Design, Burst Jobs and Other Optimizations in Unity

This is the story of implementing what I've learned into a gridless, interactive, world-building sandbox game called Minor Deity. Minor Deity on Steam: https://store.steampowered.com/app/3876240/Minor_Deity/ Minor Deity Discord Server: https://discord.gg/2NEb4HxwhF One year ago, I uploaded my first video covering data-oriented design, Burst-compiled parallel jobs, optimized rendering, and related topics. Since then, that collection of videos has grown to 25. To celebrate the year's progress, I thought I'd take a step back and look at how everything I've learned and implemented fits into the bigger picture. Because there's one overarching theme connecting all these techniques: making a performant game on a huge map. And that huge map is where it all started. At first, I had two main goals. The first was to terraform a huge map smoothly in real time. I knew I'd have to make proper use of Burst-compiled parallel jobs to have any chance of achieving that. The second was to find a highly optimized way to render the dynamic terrain and everything on it. So, I started researching tri-planar mapping, tessellation, and a bunch of other shader techniques. Looking back, these two goals also provide a natural way to organize this retrospective: first, how I build and simulate the world, and then how I render it. But before we get to that, the most impactful change I had to get used to was adopting a data-oriented design mindset instead of an object-oriented programming one. In a traditional object-oriented approach, each object typically holds its own data, with different objects potentially scattered across memory in managed arrays or lists. With data-oriented design, we instead organize data into large, contiguous blocks of native memory, grouping the same types of data for many objects together. We might have several of these blocks for different types of data, but the important thing is that related data is stored together rather than scattered across individual objects. This makes a big difference to memory access. The CPU can process data much more efficiently when it can access it sequentially, rather than constantly jumping between different locations in memory. And this is true even before we introduce parallel jobs or Burst compilation. Simply changing how we organize our data can already yield substantial performance improvements. 00:00 One Year Ago 00:56 Retrospective Agenda 01:07 Data-Oriented Design 02:14 Building the World 03:26 Dynamic Weather 04:23 Fire Frontiers 04:48 Terrain Shader 05:46 Units - People 06:44 Pathfinding 07:40 Herds and Flocks 08:48 Dense Foliage 10:00 Particles 11:22 Triple Buffering and Optimization 11:54 Other Tricks and Functionality 12:53 Culling and Manual Rendering 13:39 Gameplay Mechanics 14:30 Side Quests 15:31 Join Us!