Cập nhật đối tượng, nội bộ vs bên ngoài?

Tiêu đề hơi khó hiểu, nhưng tôi không nghĩ cách giải thích câu hỏi của mình bằng một cụm từ ngắn. Vì vậy, đây là:

Bất cứ khi nào tôi viết công cụ trò chơi, dù nó là vật lý / chế độ, v.v., tôi luôn đi đến điểm mà tôi không chắc mình nên quản lý mọi thứ như thế nào. Các thực thể trên thế giới nên tự xử lý, hay nên có một số hệ thống toàn cầu quản lý chúng?

Đây là một ví dụ dễ dàng: Di chuyển mọi thứ. Mỗi đối tượng nên nhìn thế giới xung quanh mình (kiểm tra va chạm) và di chuyển dựa trên đó.

[lưu ý, đây là trò chơi dựa trên ô xếp nơi đối tượng di chuyển trên mỗi ô, vì vậy tôi không sử dụng vật lý để chuyển từ ô này sang ô khác]

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            if (world.getTile(location) != solid && world.objAtTile(location) == null)
            {
                Tweener.addTween(this, location);
            }
          }
        }

Hay sự chuyển động của từng đối tượng nên được xử lý trong thế giới, nơi thế giới kiểm tra mọi thứ?

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            world.moveTo(location);
          }
        }

public class World
{

    public void moveObject(GameObject obj, Vector2 location)
    {
      //called from object

      if (getTile(location) != solid && objAtTile(location) == null)
         {
                Tweener.addTween(obj, location);
         }
    }
}

Tôi cho rằng điều này thực sự không quan trọng lắm đối với ví dụ này, nhưng tôi có thể thấy mình gặp rắc rối sau này. Cảm ơn trước.

Tôi thấy các ví dụ của bạn bằng Java, nhưng các thẻ của bạn không chỉ định bất kỳ ngôn ngữ nào. Trong C ++, câu trả lời là không - bạn không nên sử dụng hàm thành viên cho việc này!

void move_to(actor *a, world *w, vec2 location);

Không có câu trả lời đơn giản.

Như với hầu hết mọi thứ trong lập trình, đó là một sự đánh đổi. Cung cấp nhiều năng lượng hơn cho các đối tượng riêng lẻ làm cho chúng lớn hơn - và do đó chậm hơn - nhưng làm cho động cơ dễ hiểu và mở rộng hơn. Có một siêu hạng có thể xử lý mọi thứ cùng nhau có thể nhanh hơn, nhưng với chi phí để có một siêu hạng; đó là, nó thường được coi là hình thức xấu để tạo ra các lớp học siêu lớn.

Tôi đã đọc một số bài viết về thiết kế hướng thành phần và dữ liệu, trong đó bạn có một lớp duy nhất đại diện cho tất cả các đối tượng thuộc một loại nhất định, lưu trữ dữ liệu của chúng trong danh sách và chỉ truyền xung quanh các chỉ mục để lấy các thuộc tính của một đối tượng riêng lẻ. Mặc dù tôi có thể xem đây là một loại kiến ​​trúc khả thi, tôi cảm thấy nó khá khó khăn với toàn bộ hướng của đối tượng, điều này cũng đã nhận được sự chỉ trích công bằng của nó.

Cá nhân tôi khuyên bạn nên cung cấp thêm sức mạnh cho các đối tượng. Nó có ý nghĩa hơn trong một ngôn ngữ hướng đối tượng, và (tôi sẽ tưởng tượng) dễ hiểu và duy trì hơn theo thời gian.

Tôi đang cập nhật câu trả lời của mình vì rất nhiều điều không rõ ràng trước các bình luận. Hãy trần với tôi trong khi tôi giải thích suy nghĩ của tôi.

Nói chung, hai khía cạnh quan trọng cần xem xét trong bất kỳ thiết kế nào là sự gắn kết và khớp nối . Chúng ta đều biết rằng chúng ta cần sự gắn kết cao và khớp nối thấp để có thể tạo ra một thiết kế có thể tái sử dụng và mở rộng hơn.

Vì vậy, nếu thế giới phải quản lý mọi thứ, điều đó có nghĩa là nó có độ gắn kết thấp và khớp nối chặt chẽ (bởi vì nó cần phải biết và làm mọi thứ). Tuy nhiên, đây cũng là trường hợp khi một thực thể trò chơi phải làm mọi thứ. Cập nhật vị trí của anh ấy, kết xuất kết cấu của anh ấy, v.v.

Điều bạn thực sự quan tâm là tạo ra các hệ thống tập trung vào một khía cạnh của thực thể. Ví dụ: một thực thể trò chơi có thể có Texture, nhưng Trình kết xuất sẽ chịu trách nhiệm hiển thị kết cấu đó trên màn hình. Trình kết xuất không quan tâm các thuộc tính khác mà thực thể có.

Nói xa hơn một chút, một thực thể trò chơi chỉ đơn giản là một túi tài sản. Các thuộc tính này được thao tác bởi các hệ thống tập trung vào các thuộc tính cụ thể. Và đây là nơi các Hệ thống thực thể dựa trên thành phần (CBES) xuất hiện, nơi các thuộc tính = thành phần.

Cụ thể, CBES với Hệ thống (hoặc Hệ thống con). Thiết kế này có xu hướng có một vài Hệ thống tập trung vào các thành phần cụ thể của một thực thể trong khi không quan tâm đến những thành phần khác mà thực thể đó có. Ngoài ra, các Hệ thống chỉ được kết hợp với thông tin họ cần để xử lý các thành phần này.

Hãy lấy ví dụ của bạn. Vì đầu vào của nơi để di chuyển thực thể dựa trên bộ điều khiển của trình phát, nên bạn có thể sẽ có PlayerControllSystem. Hệ thống này, sẽ kiểm soát, ngoài nhiều thứ khác, PositionComponent của thực thể. Trong trường hợp này, PlayerControllSystem sẽ cần biết về Cấp độ và PositionComponent. Nếu sau này bạn quyết định thêm phát hiện va chạm, bạn sẽ tạo một CollisionSystem sẽ sử dụng lại vị trí của các thực thể, nhưng lần này để tính các hộp giới hạn (hoặc bạn có thể có BoundingBoxComponent, cuộc gọi của bạn). Thực tế là, bạn có thể dễ dàng bật hoặc tắt hành vi (ngay cả khi đang di chuyển) bằng cách thêm / xóa các thành phần. Vì vậy, nhiều hành vi hơn có nghĩa là nhiều hệ thống đang thao túng các thành phần của một thực thể, nhưng tất cả chúng đều nằm trong một lớp được xác định rõ ràng với độ khớp thấp. Muốn viết kịch bản? Thêm một ScriptComponent. BAM! Bạn chỉ cần thêm khả năng kịch bản với 2 lớp. Vật lý? Âm thanh? Lại như vậy.

Vì vậy, lý do tôi ủng hộ CBES với SubSystems là nó hoàn toàn OO và một hệ thống có thể bảo trì / mở rộng dễ dàng. Thêm một hành vi vào một thực thể cũng đơn giản như quyết định dữ liệu nào hành vi đó cần và thực thể nào cần nó.

Để biết thêm thông tin về Hệ thống thực thể dựa trên thành phần với Hệ thống con, có một loạt bài đăng blog tuyệt vời của T = Machine tại Hệ thống thực thể là tương lai của sự phát triển MMOG . Tác giả thậm chí đã đi xa đến mức tạo ra một wiki để thu thập các triển khai khác nhau có tên Dự án Hệ thống Thực thể

Một bài đăng chung (và nổi tiếng) về Hệ thống thực thể dựa trên thành phần nói chung là Phát triển hệ thống phân cấp của bạn , người đã tạo ra hệ thống cho Tony Hawk Pro.

Cuối cùng, nếu bạn đang tìm kiếm một thư viện có mã ví dụ, đừng đi xa hơn thư viện Artemis . Artemis chủ yếu ở Java nhưng đây là một cổng trong C # (mà tôi hiện đang sử dụng trong dự án XNA của mình).

Tôi thường đi với một thiết kế nơi các đối tượng tự xử lý (rốt cuộc đó là phương thức nào) nhưng Thế giới cơ sở có danh sách tất cả các đối tượng và nó sử dụng các danh sách đó để phối hợp chúng. Vì vậy, một cái gì đó như:

class World {
  var walls = [];
  var actors = [];
  function update() {
    for each (actor in actors) {
      actor.update(walls);
    }
  }
}

class Actor {
  function update(walls) {
    this.move();
    for each (wall in walls) {
      this.collide(wall);
    }
  }
}

Giữ nó KHÔ, ngại ngùng và nói với anh chàng kia.

Tốt hơn là yêu cầu thế giới di chuyển diễn viên của bạn hơn là hỏi thế giới nếu bạn có thể di chuyển đến nơi bạn muốn. Bằng cách này, bạn có thể thay đổi thuật toán tìm đường dễ dàng trong lớp thế giới và như vậy. Tất nhiên, bạn chỉ có thể để điều này lên một lớp cơ sở cho diễn viên, nhưng đó là hướng tôi sẽ đi và lý do tại sao.

EDIT: Viết lại do phản hồi cho biết tôi đã không vẽ dòng đủ rõ ràng cho câu trả lời này cho câu hỏi ban đầu.

Tôi muốn làm rõ câu hỏi hơn một chút nếu có thể. Nên logic tác động lên một đối tượng là bên trong hoặc bên ngoài đối tượng đó. Phần cuối của bài viết đặc biệt đề cập đến tuổi thọ của thiết kế làm cơ sở để đặt câu hỏi, để tránh rắc rối về sau.

Câu trả lời cấp cao đơn giản của tôi là giữ tất cả logic tác động lên một đối tượng trong đối tượng đó.

Bạn không cần thế giới để di chuyển một đối tượng, tất cả những gì bạn cần là đối tượng được di chuyển và vectơ đại diện cho vị trí để di chuyển đến đối tượng đó. Thế giới có thể đi vào hoạt động khi một điểm đến đang được chọn hoặc khi cần phải có phản ứng với môi trường do va chạm, nhưng những điều đó nằm ngoài ví dụ được đưa ra để làm việc.

Để giải quyết phần cơ bản của câu hỏi và đạt được tuổi thọ của thiết kế, tôi sẽ đề xuất một kiến ​​trúc hướng thành phần. Các kiến ​​trúc thành phần chia một đối tượng thành các tập hợp dữ liệu và chức năng riêng biệt (giả sử bạn đi với câu trả lời của tôi ở trên trạng thái nào để giữ logic với dữ liệu). Nếu cấu trúc của bạn trông giống như CEntity-> CHuman-> CSoldier-> CPlayerCharacter thì bạn sẽ luôn gặp phải các vấn đề khi bạn cần thay đổi một số logic và tùy thuộc vào vị trí của nó trong cây đó (ví dụ có bao nhiêu loại người khác?) nó có thể có ảnh hưởng quét trên nhiều loại đối tượng.

Thay vào đó, một hệ thống thành phần sẽ có một bộ giao diện xác định đối tượng CEntity được tạo thành như ICompRenderable, ICompMovizable, ICompHealth, ICompInventory, v.v. Nơi bạn sẽ có CCompMovizableHuman và có thể là CCompMovizableSoldier và CCompMovizablePlayer để tách các mẫu chuyển động riêng lẻ của chúng. Vì vậy, nói rằng Người lính được thay đổi để chạy trong đội hình. Thay đổi này sẽ chỉ ảnh hưởng đến các thực thể được xây dựng bằng thành phần đó.

Vì vậy, để tóm tắt, tôi khuyên bạn nên chứa logic với dữ liệu mà logic áp dụng. Tôi cũng khuyên bạn nên chia nhỏ các đối tượng thành các thành phần riêng biệt để cắt giảm 'Tôi phải đặt cái này ở đâu?' câu hỏi và cung cấp sự ổn định trong tương lai dễ dàng bảo trì và mở rộng của nó.

Hi vọng điêu nay co ich.

Tôi khuyên bạn nên cố gắng đọc lên các kiến ​​trúc dựa trên thành phần. Có khá nhiều bài viết trên blog, bài thuyết trình và viết lên đó về chúng có thể làm tốt hơn bao giờ hết.

AltDevBlogADay có khá nhiều bài viết về nó, một bài rất hay là loạt bài này về các thực thể trò chơi: http://altdevblogaday.com/2011/07/10/the-game-entity- nhiều phần tập trung vào vấn đề bạn đang cố gắng giải quyết.