Quản lý danh sách các loại thực thể khác nhau - có cách nào tốt hơn không?


9

Tôi đang phát triển một trò chơi không gian 2D cho các thiết bị di động, nhưng nó thực sự phức tạp và giải pháp của tôi thực sự khó hiểu và tạo ra nhiều phân đoạn mã lặp đi lặp lại.

Tôi có một lớp thế giới trong đó tôi có nhiều danh sách các đối tượng khác nhau như:

List<Enemy> enemys;
List<Projectile> projectiles;
List<Collectable> collectables;
List<Asteroid> asteroids;
List<Effect> effects;
..

Mỗi danh sách được cập nhật bởi đẳng cấp thế giới. nhưng đó không phải là tất cả .. Mỗi kẻ thù có một danh sách các động cơ và danh sách các vũ khí được kẻ thù cập nhật. Giờ đây, mỗi động cơ sẽ thêm một số hiệu ứng lửa vào danh sách thế giới 'hiệu ứng' và mỗi động cơ vũ khí sẽ thêm đạn vào danh sách thế giới 'đạn'. Tất cả các lớp này có tham số khác nhau, vì vậy tôi cần cập nhật thêm VÀ chức năng kết xuất thêm cho mỗi lớp.

Ít nhất họ đều là con của 'GameObject', cung cấp cho họ những thứ cơ bản như vectơ vị trí, vận tốc và gia tốc, đa giác và các chức năng như áp dụngForce và một máy trạng thái hữu hạn

Có cách nào tốt hơn hoặc phổ biến hơn để làm điều này? giống như một lớp bắt tất cả có chứa tất cả các tham số và phương thức có thể cho tất cả các đối tượng khác nhau. (tôi nghĩ rằng điều này sẽ tạo ra mã khó hiểu hơn nữa)


Điều này tương tự với câu hỏi của tôi: gamedev.stackexchange.com/questions/22559/ nam Tôi đề nghị xem xét các câu trả lời mà nó đã được đưa ra.
Derek

Câu trả lời:


5

Có cách nào tốt hơn hoặc phổ biến hơn để làm điều này? giống như một lớp bắt tất cả có chứa tất cả các tham số và phương thức có thể cho tất cả các đối tượng khác nhau.

Vâng, nó được gọi là kiến trúc . Có một cái nhìn ở đây để biết chi tiết.

Điều này sẽ chỉ cho phép một danh sách các thực thể trong lớp thế giới của bạn:

List<Entity>

Đó là một ví dụ về Thành phần trên thừa kế .


3

Trong giới hạn của câu hỏi ban đầu của bạn, một tùy chọn sẽ là chia các danh sách thành Hành động thay vì Loại như những gì bạn có. Ví dụ: bạn có List<HasAI>và một cho List<Collidable>và khi bạn tạo một đối tượng mới, nó sẽ tự thêm vào bất kỳ danh sách hành động nào cần thiết, khi đối tượng bị hủy thì nó sẽ tự xóa khỏi danh sách đó. Một đối tượng có thể nằm trong nhiều danh sách.

Bước hai của tùy chọn đó là cấu trúc lại các lớp của bạn từ một hệ thống phân cấp thành một lớp sử dụng Giao diện, vì vậy loại HasAI của bạn là một lớp thực hiện giao diện IBrains làm ví dụ. Phù hợp với điều đó List<HasAI>chỉ yêu cầu các đối tượng phải có giao diện IBrains.

Điều đó sẽ giúp làm sạch một số phức tạp.


2

Tôi nghĩ những gì bạn cần làm là trừu tượng hóa kết xuất vào các lớp của chính nó, tôi nghĩ một cho người chơi và một cho kẻ thù (hoặc có thể chỉ một cho người chơi, sau đó tạo một ví dụ về nó cho người chơi và kẻ thù - không chắc chắn 100% thiết kế trò chơi của bạn.)

Bạn có thể sử dụng mẫu khách truy cập để cho phép trình kết xuất vòng quanh các đối tượng khác nhau và quyết định vẽ gì, điều đó có thể ít phức tạp hơn.


2

Sử dụng một lớp cơ sở và dựa vào đa hình là một ý tưởng rất tốt. Nhưng có một số cách tiếp cận thay thế. Có hai bài viết của Noel Llopis rất đáng đọc. Gần đây tôi đã nhìn vào Thiết kế hướng dữ liệu và nghĩ rằng nó có một số giá trị.

Các bài viết ở đâyở đây . Nó có thể đơn giản hóa mã của bạn hơn một chút sau đó là đa hình. Nhưng giống như bất cứ điều gì YMMV, hãy xem và xem nó có phù hợp với những gì bạn đang cố gắng đạt được không. Đa hình sử dụng tính kế thừa và DOD sử dụng tổng hợp cả ưu và nhược điểm vì vậy hãy chọn chất độc của bạn.


1

Bạn có thể bằng cách sử dụng OOP và đặc biệt là đa hình.

Về cơ bản, bạn phải tạo một lớp cơ sở, mà tất cả các thực thể trò chơi kế thừa từ đó. Lớp cơ sở này, càng trừu tượng càng tốt, nó sẽ chứa những thứ như hàm Sáng tạo, Cập nhật và Có lẽ là Hàm hủy.

Sau đó, bạn lấy được tất cả các đối tượng trò chơi khác của bạn từ lớp này. Bạn cũng có thể cần thêm một số loại phản ánh vào mã của mình nếu ngôn ngữ của bạn không hỗ trợ nó, để thực hiện một số điều nâng cao hơn, nhưng không thể tránh khỏi nếu bạn biết cách cấu trúc chính xác kế thừa của mình.


1
Anh ấy đã làm điều này - tất cả các lớp học của anh ấy là con của GameObject. Anh ta chỉ cần biến loạt danh sách của mình thành một danh sách duy nhất của GameObjects.
Một số
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.