十萬單位同屏、RVO、割草碰撞：DOTS真正在項目里是這樣用的

01｜“十萬單位同屏”，是怎么變成事故的？

事情發生在一個很普通的版本迭代周。

策劃突然說：“我們想要一個兵海效果——屏幕上能堆滿單位，還要能繞路、能碰撞，最好像割草那樣爽。”

大家第一反應不是興奮，是沉默。

因為我們都知道這句話翻譯過來就是：CPU冒煙、GC抽風、幀率雪崩。

你會經歷這些熟悉的畫面：

• 測試機還行，上線機型直接掉幀

• 單位數量一上來，尋路和碰撞像在互相扯頭發

• profiler看過去，全是“腳本更新”、“物理”、“內存分配”

• 你明明沒寫Bug，但玩家會用差評告訴你：這就是Bug

于是，項目組開始進入“常規優化路線”：減少Update、合批、池化、降低碰撞精度、限制單位數量、加假人、加遮擋、調參數……

這些都能救火，但你心里會越來越確定：

我們不是缺某一個技巧，我們缺一條“能承載規模”的路線。

02｜你以為問題是“算不過來”，其實是“寫法承載不了”

有一次我盯著profiler看了很久，突然意識到一件事：我們的問題，不是“不夠聰明”，而是用了一套適合幾十個、幾百個對象的寫法，去硬扛幾萬、十萬的對象。

當單位規模上來時，你會遇到三種“必然”：

• 更新成本必然爆炸：OOP的“一個對象一個腳本”天然帶來調度開銷

• 數據訪問必然低效：數據零散、Cache miss多，越算越慢

• 系統耦合必然加深：尋路、碰撞、動畫、特效互相影響，牽一發而動全身

你可以用優化技巧把損失壓小，但天花板還在那里。這就是為什么很多人會在某一刻，開始認真看DOTS。

因為DOTS提供的不是“一個技巧”，而是另一種承載規模的方式。

03｜DOTS最大的問題：不是難，而是“你不知道該怎么開始”

但DOTS的現實是：你打開教程，看到Entity、Archetype、Chunk、Structural Change……

越看越像“要重新學一套 Unity”。

很多人不是學不會，是在開頭就被勸退：

• 學了一堆概念，但不知道能解決什么

• 想做個Demo，但跟項目需求對不上

• 硬上ECS，又發現和原工程協作成本太高

• 好不容易能跑，性能卻沒提升，反而更復雜

于是DOTS變成了“知道很強，但不敢用”的技術。真正缺的，是一條路線：

從項目里的痛點出發，帶你走到能落地的解法。

04｜如果把 DOTS 當“工具箱”，你會更容易上手

我們后來做了一個很簡單的決定：

不再“學DOTS”，而是只問一個問題：我們現在的真實需求是什么？

比如：

• 想要“兵海感” → 先解決RVO群體移動

• 想要“割草爽” → 先解決高效碰撞檢測

• 想要“大規模渲染” → 先解決EntityGraphics的渲染套路

• 想要盡量不侵入原工程 → 研究Prefab與DOTS混用、繞開SubScene的加載思路

• 想要Burst+Job性能但又不想ECS太重 → 走插件化/內存共享的思路

當你這樣拆，DOTS不是一座大山。

它更像一個可復用的工程組件庫：你先把最痛的那塊補上，然后再逐層加深。

05｜于是我們把這條路線做成了《用 DOTS 解決實際需求》

這套系列課程的出發點不是“講DOTS多強”，而是：

讓你從會用Unity開始，跟著一條“即學即用 + 逐層深入”的路徑，最終能做出“像項目方案”的成品系統。

• RVO群體移動（兵海）

• 割草類碰撞檢測

• Prefab與DOTS混用的框架實現

• 內存共享、插件化思路

• 弱引用與安全對象池（工程穩定性）

學習形式也盡量貼近工程師習慣：代碼注釋詳盡、視頻與代碼可對照、每章有框架圖，并提供可直接復用的成品庫。

06｜如果你也正卡在“規模”這道坎

如果你正在做：

• 割草類、兵海類、單位規模上萬的玩法

• 或者你的項目已經到了“優化技巧用盡”的階段

• 或者你想要Burst+Job的性能，但不想整套ECS全盤侵入

那你可能不需要再刷一堆“概念教程”。你需要的是：從需求出發的DOTS落地路線。

立即學習 享專屬答疑

全系列課程購買鏈接：

https://edu.uwa4d.com/course-intro/1/550

按章節購買請戳：

https://edu.uwa4d.com/bundle/17134192825114346

購買后添加? UWA小助手（微信），即可加入專屬答疑群！

僅限技術交流也可掃碼加入QQ群～

從“看著頭疼”到“動手爽快”，你只差這一套課！DOTS不再是一座孤島，而將成為你技術棧中最鋒利的那把劍！

更多內容歡迎前往UWA學堂（

edu.uwa4d.com