2009-11-05 49 views
15

gần đây tôi đã cố gắng viết mã trò chơi trong C#. Tôi không sử dụng XNA cho điều này, vì tôi nghĩ rằng tôi sẽ tìm hiểu thêm nếu tôi mã hóa các trò chơi từ đầu (mặc dù tôi đang sử dụng một công cụ đa phương tiện).Lập trình trò chơi - giao tiếp giữa các đối tượng trò chơi trong 2d

Tôi đang cố gắng thiết kế trò chơi RPG 2D - một chút tham vọng mà tôi biết, tuy nhiên tôi hiểu rõ ít nhất các phần cơ bản của trò chơi (ví dụ: mã 'đĩa nồi hơi') và tôi ' đã đạt đến một phần mà tôi không biết phải đi đâu từ đây.

Trong trò chơi 2D, bạn tiến bộ thông qua trò chơi bằng cách đi bộ xung quanh các khu vực khác nhau. Khi bạn nhấn 'ô cửa sổ', bạn sẽ được chuyển đến khu vực tiếp theo, v.v.

Tôi đang gặp khó khăn khi tìm hiểu cách thiết lập đối tượng khu vực này. Đây là ý tưởng đầu tiên của tôi: Mỗi khu vực có một vài cấu trúc bộ sưu tập khác nhau (ví dụ, một quadtree tầm nhìn, một quadtree va chạm, một danh sách thực thể AI vv). Vì vậy, nếu tôi đã thêm một thực thể đối phương vào trò chơi, nó sẽ được đưa vào quadtree tầm nhìn, quadtree va chạm (vì bạn có thể va chạm với các thực thể) và danh sách thực thể AI. Khi khu vực nhận được một yêu cầu cập nhật, nó sẽ yêu cầu mỗi cấu trúc này tự cập nhật, để cho các thực thể tự cập nhật. Tất cả tốt, cho đến nay.

Câu hỏi của tôi là: Điều gì sẽ xảy ra nếu kẻ thù này cần giao tiếp với các đối tượng khác? Ví dụ: có thể cần phải biết liệu người chơi có ở trong phạm vi nhất định của nó hay không. Hoặc liệu nó có bị người chơi đánh hay không. Hoặc nơi tất cả các đối tượng collidable trong khu vực (vì vậy nó có thể pathfind).

Giải pháp đầu tiên (và kém) cho vấn đề này đơn giản là chuyển từng thực thể tham chiếu đến từng bộ sưu tập. Nhưng điều này rõ ràng khuyến khích các đối tượng kết hợp chặt chẽ, đó là không tốt.

Giải pháp thứ hai mà tôi đưa ra là để mỗi thực thể có thể truy vấn khu vực, thông qua cấu trúc thư. Vì vậy, một kẻ thù sẽ có thể nói "Hãy cho tôi một danh sách của mỗi thực thể trong vòng X khoảng cách của vị trí của tôi" và khu vực sẽ trả về một câu trả lời. Tuy nhiên, điều này sẽ ngày càng trở nên khó khăn vì tôi phải viết nhiều hơn và nhiều khả năng hơn vào khu vực ("Hãy cho tôi một danh sách các thực thể không nằm trong khoảng cách X", "Hãy cho tôi một danh sách tất cả các thực thể có sức khỏe thấp hơn X "vv).

Điều tôi đang tìm kiếm là giải pháp kiểm tra thời gian cho vấn đề liên lạc giữa các đối tượng và về cơ bản cách thiết lập một khu vực. Tôi cho rằng nó sẽ cần một số loại hệ thống nhắn tin, mặc dù tôi không chắc chắn.

Cảm ơn bạn đã đọc.

+4

Wall of text là đáng sợ – Chad

Trả lời

4

Bạn có thể xem xét Mediator pattern. Nó sẽ cho phép bạn có khớp nối thấp, nhưng yeah, bạn sẽ có rất nhiều mã trong đối tượng hòa giải (s) để tạo điều kiện giao tiếp giữa các đối tượng khác. Nhưng tôi nghĩ nó là cái này hay cái kia. Và sau đó điều này là thích hợp hơn.Nó cũng sẽ cho phép bạn tự do hơn để thực hiện các thủ thuật, như xếp hàng các yêu cầu cập nhật nhất định và xử lý các yêu cầu vào các thời điểm thích hợp hơn hoặc thực hiện xử lý hàng loạt nhiều yêu cầu thay vì thực hiện từng bước một trên không.

4

Tôi nghĩ rằng lựa chọn tốt nhất cho loại thứ này là sử dụng rất nhiều mẫu Observer ... tạo sự kiện (quyết định cách chung hay bê tông là một thiết kế khác) và làm cho đối tượng của bạn đăng ký với những thứ họ cần.

Ví dụ: động cơ của bạn có thể kích hoạt các sự kiện thu hẹp hoặc lân cận khi 2 thực thể ở gần, nhưng những đối tượng đó sẽ chỉ được nhận bởi các thực thể quan tâm. Bạn có thể thực hiện một số tối ưu hóa để chỉ kiểm tra những điều kiện mà các quan sát viên đã mắc phải.

Tôi không biết đây có phải là điểm chung trong trò chơi hay không và tôi chưa bao giờ sử dụng nó trong trò chơi nào, nhưng tôi đã nghĩ nhiều lần về nó và đó là tùy chọn tôi thích nhất.

+1

Vấn đề với mặc dù đó là động cơ có trách nhiệm để theo dõi tất cả những điều đang xảy ra và kích hoạt các sự kiện khi cần thiết, trái với các thực thể tự duy trì. –

3

Vâng một aproach sẽ là thiết lập kiến ​​trúc máy khách/máy chủ. Vì vậy, máy chủ sẽ xử lý tất cả các bản cập nhật thế giới trò chơi và logic nội bộ và máy khách sẽ chỉ hỏi máy chủ nếu nó có thể thực hiện một số hành động nhất định. Sau đó, máy chủ sẽ phản hồi và khách hàng sẽ chỉ vẽ và cập nhật màn hình trò chơi. Các thực thể không phải người chơi sẽ làm như vậy. Sự khác biệt duy nhất sẽ là khách hàng là con người được kiểm soát và các thực thể khác được điều khiển bằng máy tính. Điều này sẽ cho phép bạn tách riêng các thiết lập và sự kiện và cập nhật thế giới trò chơi từ logic thực thể.

"Hệ thống tin nhắn" bạn đã đề cập được gọi là giao thức ứng dụng và có thể là hệ thống nhị phân bí truyền phức tạp hoặc chuỗi đơn giản có thể đọc được mà tôi muốn giới thiệu. Khi người chơi di chuyển máy chủ sẽ gửi cho nó một danh sách các thực thể nằm trong tầm nhìn của khách hàng. Các thực thể không phải người chơi sẽ hoạt động theo cùng một cách. Đó là bằng cách yêu cầu máy chủ cho phép thực hiện mọi thứ hoặc thông tin về một thực thể khác mà máy chủ đã gửi trước đó và di chuyển đến chế độ xem của đối tượng và máy chủ phản hồi bằng câu trả lời hoặc thông tin thích hợp.

Nếu bạn đã thực hiện điều này với ổ cắm, bạn sẽ có lợi ích rõ ràng của việc chơi mạng nội tại vì máy chủ sẽ không quan tâm nếu máy khách đang kết nối trên cùng một máy chủ đang chạy hoặc máy khách ở trên lục địa . Điều này có thể không trả lời câu hỏi của bạn cụ thể với mã nhưng tôi hy vọng nó ít nhất là thức ăn để suy nghĩ.

+1

Thức ăn cho ý nghĩ. :) –

2

Điều này thường dễ dàng hơn nhiều nếu bạn có đối tượng phía trên thực thể thực hiện việc quản lý. (ví dụ: 'thế giới' hoặc 'trò chơi'.) Có thể dễ dàng thấy các thực thể nào ở gần người khác và gửi các sự kiện và thông báo cho phù hợp.

Nếu các thực thể cần bối cảnh nhiều hơn một chút để đưa ra quyết định có ý nghĩa khi chúng được cập nhật, bạn luôn có thể vượt qua thế giới trong ngữ cảnh đó dưới một số dạng. Nhưng hãy để thế giới quản lý việc phân vùng và sắp xếp các thực thể thay vì cần các thực thể để lo lắng về điều đó một cách trực tiếp.

(Ngoài ra, tại sao một quadtree? Đối với một 2D rpg một lưới thô có lẽ sẽ đơn giản hơn nhiều để thực hiện và không kém phần hữu ích.)

Các vấn đề liên quan