Tôi có nên chia sẻ cùng một cấu trúc gạch để hiển thị và tìm đường không?


8

Tôi biết cách hiển thị bản đồ 2D bằng gạch.

Tôi biết cách tạo thuật toán tìm đường bằng A *.

Hai điều đó đòi hỏi một cấu trúc hoặc một lớp. Câu hỏi của tôi là: bạn có sử dụng cùng một cấu trúc để hiển thị và tính toán đường dẫn không? Cấu trúc nút cho nhu cầu tìm đường để thêm một số dữ liệu: vị trí x, vị trí y, F, G, H cộng với Nút cha. Cấu trúc ô để hiển thị có thể được tối ưu hóa thành hầu hết chỉ một thông tin: giá trị của ô.

Bạn có sử dụng một lớp lớn cho các ô của mình, xử lý cả hiển thị và tìm đường, hoặc bạn có sử dụng một phương pháp khác không? Cảm ơn lời khuyên của bạn!


Câu hỏi tuyệt vời, tôi thực sự cần phải học cái này nhưng tôi không biết phải hỏi gì.
DFectuoso

Câu trả lời:


6

Câu hỏi của tôi là: bạn có sử dụng cùng một cấu trúc để hiển thị và tính toán đường dẫn không?

Không, tôi không. Bạn có thể nhận được một số tối ưu hóa khi tính toán A * trực tiếp trên bản đồ ô vuông, nhưng sau đó bạn không thể dễ dàng sử dụng thuật toán A * của mình cho những thứ không ánh xạ trực tiếp vào ô. Ngoài ra, điều đó có nghĩa là bạn không thể chạy thuật toán A * đồng thời trong nhiều luồng khi chúng kết thúc việc chia sẻ dữ liệu bản đồ. Cuối cùng, một số phương thức di chuyển nhất định không cho phép tối ưu hóa ô = nút; một chiếc xe cần không gian để quay vòng có thể có khả năng đến cùng một ô từ các hướng khác nhau và có các tùy chọn khác nhau trong từng trường hợp - chúng không thể được hợp nhất thành một điểm.

Vì vậy, tôi đề nghị giữ dữ liệu riêng biệt.


Mặc dù thật thú vị khi tách chúng ra, nhưng bạn không cần sử dụng biểu đồ rõ ràng để tìm đường, bạn có thể có "tilemap" chỉ với thông tin va chạm / chi phí, tách biệt hoàn toàn với kết xuất và từ mô hình logic. Ví dụ: nếu bạn thêm một đối tượng vào thế giới không được lưu trữ trong tilemap, nhưng chỉ cần sử dụng (x, y), bạn vẫn có thể đặt nó vào bản đồ va chạm và sử dụng nó để tìm đường dẫn dựa trên lưới.
Trinidad

3

Từ quan điểm phát triển phần mềm, việc tách biệt những thứ khác nhau luôn luôn tốt .

Để có một giải pháp nhanh chóng và bẩn thỉu, hãy đặt mọi thứ lại với nhau và bắt đầu làm việc với các chi tiết cụ thể trong trò chơi.

Đối với một giải pháp có thể mở rộng, hãy tách biệt mọi thứ: bạn không muốn thay đổi các lớp gạch vì thuật toán tìm đường của bạn đã thay đổi! Giữ hai cấu trúc: một cấu trúc đại diện cho các ô trò chơi có thể nhìn thấy và một cấu trúc đại diện cho cấu trúc tìm đường. Lý tưởng nhất là thuật toán tìm đường được giữ ở mức thấp, vì vậy có thể một mảng x, y trỏ làm đầu vào cho thuật toán là một ý tưởng tốt hơn là cung cấp cho nó các lớp gạch của bạn. Thuật toán có thể thiết lập các mảng cho các giá trị F, G, H.

Tôi nghĩ trong trường hợp này (và tôi cho rằng bạn cố gắng trở thành một lập trình viên giỏi), bạn nên tìm giải pháp mở rộng, bởi vì nó sẽ không làm bạn tốn nhiều công sức hơn nhưng nó giữ cho mã của bạn sạch hơn và bạn sẽ có được thực hành tốt kinh nghiệm.


2

Tôi đã từng xây dựng một trò chơi tilebided trên Amiga 500 với các ô 512x512 nhưng người chơi chỉ có thể di chuyển 8 ô, vì vậy tôi đã tạo ra một bản đồ "tường" 9x9 "gạch". lính. Nếu tôi đã thực hiện điều này với bản đồ gốc, trước hết tôi sẽ phải "xóa nó đi" sau mỗi phép tính + lượng bộ nhớ cần thiết để có cả dữ liệu ô vuông + dữ liệu tìm đường sẽ khiến 512x512 trở thành một bộ nhớ begger nhiều.

Vì vậy, không, giữ mọi thứ nhỏ nhất có thể và tách biệt để bạn có thể tinh chỉnh chúng pr. đối tượng / lớp nếu cần. Một điều khác để suy nghĩ cũng có thể là một số đối tượng chuyển động của bạn MIGHT di chuyển khác nhau trên các phần nhất định của bản đồ. Ví dụ. chậm trong cát, có thể / không thể bơi, có thể mở cửa vv

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.