Được rồi, vì vậy đây là một vấn đề tôi đã cố gắng tìm ra khá lâu. Mine là một trò chơi platformer 2D với một thế giới được tạo thành từ (thường) các ô bất động và các họa tiết di động, cả hai đều sử dụng AABB để thể hiện các hitbox của họ. Trò chơi này KHÔNG dựa trên lưới do một số biến chứng với việc di chuyển các lớp gạch.
Tôi có thể phát hiện va chạm và dễ dàng tìm ra độ sâu của vụ va chạm. Tôi sử dụng "phương pháp trục nông nhất" để xác định cách giải quyết va chạm giữa sprite và gạch. Nếu sprite sâu hơn theo chiều ngang so với chiều dọc, hướng để giải quyết là lên hoặc xuống. Nếu sprite sâu hơn theo chiều dọc so với chiều ngang, hướng để giải quyết là trái hoặc phải.
Điều này là đủ đơn giản, và nó hoạt động khá tốt. Đó là, cho đến khi bạn có một sprite va chạm với nhiều hơn một ô. Vì, về bản chất, mỗi va chạm phải được kiểm tra riêng, các va chạm khác nhau có thể có hướng giải quyết khác nhau. Ví dụ: nếu một sprite đang cố gắng đi qua một hàng gạch, đối với một khung hình, chúng sẽ giao nhau với ô tiếp theo như vậy độ sâu ngang ngắn hơn độ sâu dọc. Khi va chạm nói "giải quyết trái", nó sẽ bị đẩy lùi và bị kẹt ở góc.
Tôi đã nghiên cứu vấn đề này nhiều lần, trong một thời gian và một số giải pháp đã đến với tôi, nhưng tất cả đều có sai sót. Tôi có thể đánh dấu một số mặt nhất định là không thể truy cập được, nhưng không có động cơ dựa trên lưới, việc xác định "không thể truy cập" rất phức tạp, đặc biệt là với các lớp gạch di chuyển luôn là một khả năng.
Một phương pháp khả thi khác là dự đoán va chạm trước khi chúng xảy ra và "hoạt động trở lại" chuyển động đến điểm va chạm, tôi cho rằng, nhưng tôi không chắc toán học trên đó hoạt động như thế nào.
Tôi cảm thấy rằng tôi đang thiếu một cái gì đó cực kỳ rõ ràng, đặc biệt là vì các trò chơi từ những năm 80 đã giải quyết được vấn đề này.
