Làm thế nào để Pháo đài Lùn theo dõi rất nhiều thực thể mà không làm giảm hiệu suất?

Trong Pháo đài Lùn, bạn có thể có hàng trăm Người lùn, động vật, yêu tinh, v.v. trong trò chơi bất cứ lúc nào, mỗi người đều có AI và thói quen tìm đường phức tạp của riêng mình. Câu hỏi của tôi là làm thế nào điều này không tạo ra sự chậm lại đáng chú ý? Có phải mỗi Dwarf chạy trong chủ đề riêng của mình?

Bất kỳ hệ thống nào có một luồng cho mỗi trong số rất nhiều ký tự sẽ hết tài nguyên rất nhanh. Các luồng có thể cung cấp cho bạn quyền truy cập vào các lõi xử lý bổ sung nhưng chúng không làm cho mọi thứ thực sự hiệu quả hơn và chúng đi kèm với chi phí hoạt động.

Câu trả lời đơn giản là hiệu quả trong việc xử lý từng thực thể trong trò chơi.

• Đừng xử lý mọi thực thể mỗi khung.
• Phân chia xử lý thành những thứ cần làm thường xuyên và những thứ không cần làm thường xuyên.
• Truyền bá các thuật toán chạy dài trên nhiều khung để chúng không chặn xử lý trong các hệ thống khác.
• Đảm bảo rằng các thuật toán hiệu quả và cấu trúc dữ liệu được sử dụng.
• Lưu trữ kết quả của các tính toán đắt tiền nếu chúng có khả năng được sử dụng lại.

Pháo đài lùn không phải là nguồn mở và trong khi có rất nhiều phỏng đoán và kỹ thuật đảo ngược có thể đi sâu vào cách thức hoạt động của tất cả mọi thứ, thay vào đó tôi sẽ tập trung vào một số kỹ thuật cơ bản để tối ưu hóa một trò chơi 3D (không phải đồ họa 3D, thế giới 3D) của cùng loại.

Như trường hợp của tất cả các trò chơi video, có rất nhiều khói và gương đang tạo ra ảo ảnh về sự phức tạp từ các quy tắc và hệ thống đơn giản. Những phạm vi này từ việc sử dụng các số ngẫu nhiên đơn giản cho chuyển động không có mục đích cho đến trước khi nướng một lưới các nút cấp cao để tìm đường.

Phong trào

Nói về tìm đường, đây thường có thể là một vấn đề rất khó giải quyết đối với các không gian rộng như bản đồ DF có thể (nhiều như 768x768x64 IIRC) tuy nhiên vấn đề có thể được đơn giản hóa và tăng tốc theo những cách sau:

• Mạng nút được nướng sẵn: Khi bản đồ được tạo, thế giới có thể được chia thành các phần và mỗi đoạn có thể có lối ra và lối vào được ánh xạ. Khi một đoạn được cập nhật, chẳng hạn như khi một bức tường được xây dựng, chỉ có mạng lưới của đoạn đó cần được cập nhật.
• Tìm đường theo giai đoạn: Chạy một đường dẫn trên toàn bản đồ, ô cho ô, sẽ mất rất nhiều thời gian, thay vào đó bạn sẽ tìm đường trên mạng chunk lớn hơn, ánh xạ tất cả các kết nối giữa các đoạn, và sau đó chỉ chạy một đường trong khi chuyển từ chunk sang chunk. Điều này làm 2 điều cho bạn. Nó tăng tốc độ tìm đường bằng cách phá vỡ nó trên nhiều mảnh nhỏ hơn và nó cũng cho phép thiết bị thay đổi hướng một phần dọc theo đường dẫn khi một đoạn cập nhật. Nó sẽ đường dẫn lại qua mạng lớn nếu có bất kỳ nút nào cần cập nhật chéo.
• Chỉ đạo ngẫu nhiên: Khi không di chuyển đến mục tiêu, đơn vị chỉ cần đi bộ không mục đích. Nhiều roguelike chỉ di chuyển đơn vị theo một hướng ngẫu nhiên, cảm thấy không tự nhiên. Có thể sử dụng nhiều kỹ thuật lái khác nhau, những kỹ thuật đơn giản được ưu tiên để di chuyển theo đường thẳng và càng ngày càng ít cơ hội di chuyển theo các hướng tỏa ra phía sau, chỉ có khoảng 1% cơ hội. Vì vậy, các đơn vị đôi khi sẽ đảo ngược hoàn toàn hướng, nhưng chỉ hiếm khi.

Tôi sẽ không bao gồm những điều cơ bản của tìm đường. Hầu hết các roguelike sử dụng A *, nhưng có những phương pháp khác để lột da mèo. Mmmm da mèo ..

Nhiệm vụ cá nhân

Một trong những điều quan trọng khiến các đơn vị DF bật và cảm thấy sống động là danh sách mục tiêu cá nhân của họ. Trong thực tế, nhiều trò chơi roguelike có điều này ở mức độ cơ bản. Về cơ bản, mỗi đơn vị có một danh sách các mong muốn (và đối với dorfs của bạn, các nhiệm vụ họ có thể nhận mà bạn yêu cầu thực hiện) và họ sẽ chọn từ chúng dựa trên tính cách (số liệu thống kê của họ).

Một số nhiệm vụ có yêu cầu. Làm một chiếc váy da đòi hỏi dorf phải ở trong một cửa hàng tương tự và có các mặt hàng X. Vì vậy, tất cả những người được kiểm tra và thêm dưới dạng nhiệm vụ vào danh sách của họ. Đơn giản như thế.

Vì hầu hết thời gian một đơn vị sẽ quá cảnh, việc kiểm tra xem đơn vị nào đang thực hiện có thể rất nhanh, chỉ một số đơn vị sẽ đưa ra lựa chọn tại bất kỳ thời điểm nào và do đó, tổng thể không có sự chậm lại nào cho hàng trăm hoặc Hàng ngàn đơn vị. Và hãy nhớ rằng, trong DF mọi thứ từ ong đến troglodyte đến cây đều là đơn vị.

Khi thực hiện một số nghiên cứu bổ sung, rõ ràng là, vui nhộn, DF đang thực hiện một công việc khủng khiếp là tìm đường nói chung. Nó không phá vỡ bản đồ thành nhiều phần, nó phá vỡ bản đồ thành các phân đoạn hoặc khu vực được kết nối, (tốt hơn là không có gì chắc chắn) vì vậy đánh giá trên của tôi thậm chí còn ít hơn một ví dụ về cách DF hoạt động hơn tôi nghĩ. :) Điều đó không phải để nói rằng DF là bất cứ điều gì ít hơn đáng kinh ngạc vì hàng triệu lý do khác.

Nó cho thấy rằng điều quan trọng trong một trò chơi là chơi trò chơi. Không đồ họa, không lập trình tuyệt vời, không viết hay, không nhạc hay, thậm chí không có giao diện; không có gì khác thậm chí là 1% quan trọng như chính trò chơi.

Từ trang này :

Chà, [đường dẫn] trông tuyệt vời từ cuối của tôi, vì có một tấn các nhân vật cùng làm một lúc.

TA: Người lùn chủ yếu di chuyển xung quanh với A *, với heuristic đường phố cũ thường xuyên. Phần khó khăn là nó thực sự không thể gọi A * nếu họ không biết rằng họ có thể đến đó trước, hoặc cuối cùng sẽ làm ngập bản đồ và giết chết bộ xử lý.

Tôi không biết liệu đây có chắc chắn là cách anh ta ngăn chặn "làm ngập bản đồ" hay không , nhưng cách thông thường để làm điều này trong các trò chơi là sử dụng một sự thay đổi thành A * được gọi là Tìm đường phân cấp A * , hoặc HPA *. Ý tưởng là chia lưới thành nhiều phần nhỏ hơn nhưng lớn hơn, sau đó sử dụng A * để tìm đường đi tốt nhất từ ​​mỗi khối đến các đoạn lân cận. Bạn có thể sử dụng điều này để xây dựng một biểu đồ nhỏ hơn nhiều để chạy A * cho mỗi đơn vị.

Bạn cũng có thể nhóm các khối đó thành các khối thậm chí lớn hơn, đó là nơi "phân cấp" đến từ.

Thuật toán này chỉ tìm thấy các đường dẫn gần tối ưu, nhưng đối với các trò chơi như Dwarf-Fortress thường là ok. Nó vẫn được đảm bảo để tìm một con đường nếu một người tồn tại; và khi không có đường dẫn, nó sẽ chỉ lấp đầy đồ thị nhỏ hơn, tiết kiệm một lượng thời gian khổng lồ.

Ngoài ra còn có một bản tóm tắt HPA * liên quan đến các đơn vị có thể đi qua một số địa hình nhưng không phải là các địa điểm khác (chẳng hạn như vách đá, các đơn vị không khí có thể đi qua nhưng các đơn vị mặt đất không thể) . Nó được gọi là HAA * , và có một bài viết rất dễ giải thích ở đây .

Bạn có thể đọc thêm về các thuật toán tìm đường khác nhau ở đây .

Nếu bất cứ điều gì, thì ngược lại - toàn bộ mọi thứ chạy trên một luồng và giờ nó đã chạm đến điểm đang trở thành yếu tố chặn (lần trước tôi đã kiểm tra!)

Lý do nhanh là không có đồ họa lạ mắt. Thật là lừa dối, nhưng điều chính yếu làm mọi thứ chậm lại là vẽ mọi thứ (nghĩ lên hai phần ba khung hình trong các tiêu đề AAA). Vì pháo đài lùn khá cơ bản, nó dành phần còn lại của thời gian đó để làm những điều thú vị.

Tôi không biết DF được mã hóa như thế nào nhưng số lượng AI không thực sự gây ấn tượng với tôi bởi vì những gì mọi người thường giám sát rằng AI không cần độ chính xác . Hoàn toàn khả thi để làm hầu hết mọi thứ chỉ sau vài giây. Cũng có thể sử dụng các tính toán không chính xác. Sự không hoàn hảo tiết kiệm rất nhiều hiệu suất . Bạn có thể chạy quy trình ra quyết định 100 đơn vị cứ sau 100 ms hoặc bạn có thể chạy nó với 1000 đơn vị mỗi giây, sẽ mất cùng thời gian CPU nhưng ... bạn có 10 lần đơn vị.

Đây là một ví dụ đơn giản về cách người ta có thể xử lý nhiều đơn vị:

int curUnit;
Array<Unit> units;
[...]
while([...]) // Game Loop
{
  [...game logic...]
  // process 10 AIs per Frame
  for(int i=0; i++; i<10)
  {
    curUnit++
    if(curUnit == units.length()) curUnit=0;
    if(curUnit < units.length())
      units[curUnit].processAI();
  }

  // Update the position of all units, this should be as optimized as possible
  foreach(Unit& unit in units){ unit.move(); };

  [...graphics...]
}

AI sẽ ngày càng ít phản ứng hơn, nhưng người chơi có thể sẽ chỉ chú ý đến nó trong những trường hợp cực đoan.