黃色代碼部分即為通過循環來設定精靈腳底的占據區域。在WPF/Silverlight機制中跨線程調用必須在與Dispatcher關聯的線程上執行委托(這與以往有些不同)，所以此時要實現跨線程的異步處理我們必須通過this.Dispatcher.BeginInvoke()的來實現。並且此線程同樣為比較重要的處理，因此優先級別我設定為DispatcherPriority.Normal。
額外的，如果您想調試障礙物刷新的次數或處理其他的相關數據，您可以在注冊的後台工作完成事件中進行計數之類的設定，例如下面方式，這樣可以很好的對異步結果進行管理(通過e.Result捕獲傳遞過來的結果參數)：
private void BackWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) {
count +=1;
}
通過以上4個步驟即輕松完成了動態障礙物的構建。BackgroundWorker的強大對於處理這區區一丁點的運算還是綽綽有余的，您還可以將更多的任務托付給它。例如我們同樣的可以將上一節中講到的主角頭像面板與監視對象頭像面板的刷新方法一起放進RefreshFace()中；這樣在游戲運行過程中，我們不再需要去管理它哥兩，後台工作者會每間隔1秒左右更新它們一次，就象保姆一樣照顧得無微不至且不打擾到您的任何其他工作。
下面讓我們來測試一下吧。我在屏幕左下角放了個按鈕，每次點擊地圖最上面的妖精怪物都會向右下方移動50象素，大家不妨走到它旁邊，然後在它每次動後在站到它移動之前的位置上，測試一下障礙物此時是否還存在，並且向它新的位置方向移動看看新的障礙物是否已成功設置：
最後總結一下：以1秒為頻率刷新動態障礙物在高精度需求的游戲中是不夠的，往往需要設置為<=500毫秒；並且也不能太小了，過小不僅會造成過度的性能消耗；同時由於異步的原因也極其容易導致錯誤的障礙物識別，直接的結果就是穿越。我個人建議是在WPF中間隔設置為500毫秒，在Silverlight中間隔設置為1秒。大家在玩2D-MMORPG游戲時是否有過這樣的經歷：在城裡人多的地方，如果游戲網速突然慢了一下或者游戲突然卡了那麼一下，一不小心你的角色精靈就與其他某位玩家的角色精靈重疊在一塊了，並且此游戲正常情況下是不允許重疊的（回合制游戲允許重疊，而ARPG類的是絕對不允許的）。根據本節講解的原理我們可以很快的找出原因：在還未來得及更新出最新的動態障礙物數組前，兩位角色已經跑到了當前被定義為非障礙物的坐標上。但是大家不要為此過份擔心了，或者說此情況屬於完全可以接受的范圍中。因為由於障礙物數組的固定值部分(即固定的障礙物) FixedObstruction在游戲地圖加載的時候就已經加載並固定了，意味著只要地圖不更換它是不變的。所以不管處於異步處理的任何階段，固定的障礙物如房屋啦、牆壁啦、樹木啦等等之類的東西將永遠無法穿越，這或許才是我們最終希望達到的目的。
這裡還需要說明一下，本節構建的動態障礙物只是相對於主角的，也就是只能為主角所用。在後期加入怪物AI後，可以有兩種常見的解決方案：第一種為所有怪物均使用FixedObstruction固定障礙物，這樣怪物之間會發生重疊。第二種為給精靈增加一個Obstruction屬性來保存相對於它們自身時時的障礙物信息，這種方式實現的結果是完美的，但過程是極其損耗空間與時間的。至於還有第三種更完美的方案嗎？這是當然的，大家不妨想想，只有當精靈在移動的時候才會用得上障礙物對吧？那麼我們是否只需要在每次發起移動前對全局的VaryObstruction進行拷貝，然後稍微處理一下此副本使之成為此次移動所要面對的障礙物，或許這才是最完美的解決之道。
那麼來張測試圖吧，此地圖上隨機布局了20個怪物，大家可以嘗試在裡面穿梭體驗饒過怪物的爽快(由於怪物的圖片是提取出來的，只做了稍微的加工調整，腳底並未完美的定位到中心，因此障礙物有時顯得並不精確，這不是系統問題，而是圖片結構引起的 ^_^)：
相對於主角的完美障礙物系統總算構建完成。暴風驟雨來臨的前夜，讓激情燃燒我們的斗志吧，偉大的勇士！下期敬請期待。
