Bản đồ ngục tối đệ quy như được biểu thị bằng một mảng 2d đàn hồi


8

Tôi đã đưa ra một phương pháp để tạo đệ quy các bản đồ ngục tối đơn giản bằng cách bắt đầu với một phòng và kết nối đệ quy các phòng liền kề mới một cách ngẫu nhiên với nó.

Bản đồ được biểu diễn dưới dạng mảng hai chiều trong đó mỗi ô chứa giá trị 0-15. 0 đại diện cho không có phòng trong khi mỗi hướng được đại diện bởi bắc = 1, đông = 2, nam = 4, tây = 8.

Tôi muốn bắt đầu với một phòng không duy nhất ([[0]]) và sau đó mở rộng mảng 2d khi cần thiết để phù hợp với bản đồ được tạo. Khó khăn mà tôi gặp phải với cây này như đệ quy là nếu các mảng phải được dịch chuyển để thêm các hàng và cột ở bên trái và trên cùng của bản đồ, tôi phải điều chỉnh vị trí hiện tại của hàm, hàng và cột đó ở đâu . Điều này làm cho nó để các nhánh riêng biệt không biết điều chỉnh chỉ số mảng từ các nhánh khác, chỉ các hàm con của chúng sẽ biết vì chúng có vị trí được điều chỉnh được truyền cho chúng dưới dạng đối số hàng và cột.

Có cách nào để làm việc này không? Tôi đã thử lưu trữ giá trị bù hàng và cột bên ngoài đệ quy, nhưng nó không hoạt động vì một số lý do.

Câu trả lời:


5

Có một lý do nào đó bạn phải sử dụng một mảng 2D, hoặc một số bảng băm hoặc loại bản đồ khác sẽ hoạt động? Sau đó, các chỉ số x, y chỉ tiếp tục vào không gian âm, nhưng không thành vấn đề.

Nếu bạn lo lắng về bộ nhớ hoặc tốc độ CPU, 1) Đừng, bảng băm rất hiệu quả ở những thứ như cặp số nguyên dày đặc, 2) bạn có thể xây dựng cấp độ trong bảng băm và sau đó xử lý nó thành một bảng mảng một khi bạn biết kích thước cuối cùng.


vì vậy hàm băm sẽ chấp nhận một đối số x và ay và điều này sẽ được ánh xạ tới một mảng kết hợp với các khóa như 1x1, -1x3, v.v.?

Vâng. Trong C ++, tôi chỉ sử dụng một std :: cặp <int, int>; trong Python, một lệnh với (x, y) bộ dữ liệu cho các khóa. Tôi không chắc bạn đang sử dụng ngôn ngữ nào.

2

Tôi đang làm một điều tương tự, trong Python. (Hoặc ít nhất là phần đàn hồi).

Tôi có một từ điển của (x, y) tuples ánh xạ tới các ô. Trong mã giả:

map = dictionary( (0,0) : cell at (0,0), (1,0) : cell at (1,0) ... (2, 2) : cell at (2,2)
getCell(x,y):
    return map[(x,y)]
    catch error if out of bounds:
         map[(x,y)] = new cell and return

Một bảng băm sẽ rất tốt cho loại điều này.


1

Giải pháp nỗ lực tối thiểu là chọn kích thước tối đa (phạm vi X và Y) mà bạn muốn ngục tối đạt được, đặt điểm xuất phát của bạn ở trung tâm đó và không cho phép phát triển bên ngoài nó. Không cần phải làm bất kỳ thay đổi. Tất nhiên phụ thuộc vào một mức độ cố định được chấp nhận.


-1

Bạn sẽ muốn sử dụng biểu đồ thay vì mảng 2D.

Mỗi phòng sẽ là một nút trong biểu đồ và biết những phòng nào khác liền kề với nó:

Room {
    long x;
    long y;
    List adjacentRooms;
}

Bằng cách đó, bạn không phải xác định bản đồ của mình có thể lớn đến mức nào.

Các tọa độ x, y có thể được sử dụng làm khóa duy nhất trong hàm băm để truy cập nhanh vào từng phòng. Thêm một phòng mới sẽ chỉ cần thêm các mục vào danh sách liền kề của các phòng gần nhau.

Biểu đồ cũng tuyệt vời cho các thuật toán tìm đường, nếu bạn cần chúng.


Điều này sẽ thực hiện kém và đòi hỏi nhiều sổ sách hơn so với bảng băm hoặc mảng. Không có lợi ích trong các phòng có cả khóa băm X, Y tạo thành biểu đồ có hướng.

Làm thế nào bạn có thể truy cập nhanh các phòng chỉ với biểu đồ được định hướng? Làm thế nào bạn có thể tìm đường dẫn chỉ với khóa băm X, Y? Điều này sẽ yêu cầu logic bổ sung để xác định các phòng liền kề. Khóa băm thực sự chỉ là một góc nhìn khác của thế giới trò chơi. Tôi đồng ý rằng việc xử lý một biểu đồ sẽ rắc rối hơn, nhưng sẽ có lợi cho các thuật toán sử dụng biểu đồ. Hiệu suất phụ thuộc vào kích thước của thế giới trò chơi. Vì vậy, điều này đã được nguyên mẫu. Thx cho phiếu bầu xuống. Chúc mừng!
Stephen

Không có gì trong ngăn chặn tìm đường bằng cách sử dụng hàm băm của các cặp X, Y. Các trạng thái kế tiếp là các trạng thái kế tiếp, không thành vấn đề nếu bạn duy trì biểu đồ điên hoặc tìm kiếm nó trên bảng băm, ngoại trừ bảng băm nhanh hơn và sử dụng ít bộ nhớ hơn.

Các giải pháp khóa băm là ít trừu tượng. Như tôi đã viết trước khi tìm đường phải biết các phòng nào liền kề nhau, cách tính khoảng cách đến phòng mục tiêu, v.v. Bạn sẽ đưa kiến ​​thức về thế giới trò chơi vào thuật toán tìm đường. Nếu thiết lập thế giới trò chơi thay đổi, ví dụ như chuyển động từ các phòng có đường chéo với nhau hoặc được thêm vào chiều thứ ba, bạn sẽ cần thay đổi mọi thuật toán truy cập vào thế giới trò chơi. Đồ thị trừu tượng này đi. Không có gì điên rồ về nó. Luôn có nhược điểm cho mọi giải pháp.
Stephen

1
"Đồ thị trừu tượng này đi." Bất kỳ phương pháp lặp, tạo, coroutine hoặc xây dựng danh sách nào cũng vậy, và chúng không yêu cầu phình to cấu trúc O (n) cũng như ghi sổ thời gian xây dựng nhiều hơn.
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.