2D platformers: tại sao làm cho vật lý phụ thuộc vào tốc độ khung hình?

Question

"Super Meat Boy" là một platformer khó mà gần đây xuất hiện cho PC, yêu cầu kiểm soát đặc biệt và nhảy pixel hoàn hảo. Mã vật lý trong trò chơi phụ thuộc vào tốc độ khung hình, bị khóa tới 60 khung hình/giây; điều này có nghĩa rằng nếu máy tính của bạn không thể chạy trò chơi ở tốc độ tối đa, vật lý sẽ phát điên, gây ra (trong số những thứ khác) nhân vật của bạn chạy chậm hơn và rơi xuống đất. Hơn nữa, nếu vsync bị tắt, trò chơi sẽ chạy cực nhanh.

Những người có kinh nghiệm lập trình trò chơi 2D có giúp giải thích lý do trò chơi được mã hóa theo cách này không? Sẽ không phải là một vòng lặp vật lý chạy với tốc độ không đổi là một giải pháp tốt hơn? (Trên thực tế, tôi nghĩ một vòng lặp vật lý được sử dụng cho các phần của trò chơi, vì một số thực thể tiếp tục di chuyển bình thường bất kể tốc độ khung hình. Nhân vật của bạn, mặt khác, chạy chính xác [fps/60] nhanh.)

Điều làm phiền tôi về việc triển khai này là mất sự trừu tượng giữa công cụ trò chơi và hiển thị đồ họa, phụ thuộc vào những thứ cụ thể của hệ thống như màn hình, cạc đồ họa và CPU. Nếu vì bất kỳ lý do nào, máy tính của bạn không thể xử lý vsync hoặc không thể chạy trò chơi với tốc độ 60 khung hình/giây, nó sẽ phá vỡ ngoạn mục. Tại sao bước dựng hình theo bất kỳ cách nào ảnh hưởng đến tính toán vật lý? (Hầu hết các trò chơi ngày nay sẽ làm chậm trò chơi hoặc bỏ qua khung.) Mặt khác, tôi hiểu rằng các platformer cũ trên NES và SNES phụ thuộc vào tốc độ khung hình cố định cho phần lớn khả năng kiểm soát và vật lý của chúng. Tại sao điều này, và nó sẽ có thể tạo ra một patformer trong tĩnh mạch mà không có sự phụ thuộc framerate? Có nhất thiết phải mất độ chính xác nếu bạn tách đồ họa khỏi phần còn lại của động cơ không?

Cảm ơn bạn và xin lỗi nếu câu hỏi khó hiểu.

Answer 1

Họ có thể cần phải hoàn thành trò chơi một cách nhanh chóng và quyết định rằng họ sẽ bao gồm đủ cơ sở người dùng với triển khai hiện tại.

Bây giờ, không thực sự là rằng khó để trang bị thêm độc lập, nếu bạn nghĩ về nó trong quá trình phát triển, nhưng tôi cho rằng chúng có thể đi xuống một số lỗ dốc.

Tôi nghĩ điều đó là không cần thiết, và tôi đã từng thấy nó trước đây (một số trò chơi 3d-hw đầu sử dụng cùng một thứ, nơi trò chơi diễn ra nhanh hơn nếu bạn nhìn bầu trời, và chậm hơn nếu bạn nhìn xuống mặt đất).

Nó chỉ hút. Bug các nhà phát triển về nó và hy vọng rằng họ vá nó, nếu họ có thể.

Answer 2

Không có lý do gì khiến vật lý phải phụ thuộc vào tốc độ khung hình và đây rõ ràng là thiết kế kém.

Tôi đã từng cố gắng hiểu tại sao mọi người làm điều này. Tôi đã xem xét mã cho một trò chơi được viết bởi một nhóm khác trong công ty, và tôi đã không nhìn thấy nó từ đầu nhưng họ đã sử dụng rất nhiều giá trị hardcoded 17 trong mã của họ. Khi tôi chạy các trò chơi trên chế độ gỡ lỗi với FPS hiển thị, tôi thấy nó, FPS là chính xác 17! Tôi nhìn lại mã một lần nữa và bây giờ nó rõ ràng: các lập trình viên giả định rằng trò chơi sẽ luôn có tỷ lệ khung hình liên tục 17 FPS. Nếu FPS là lớn hơn 17, họ đã làm một giấc ngủ để làm cho FPS được chính xác 17. Tất nhiên, họ đã không làm gì nếu FPS nhỏ hơn 17 trò chơi chỉ đi điên (như khi chơi ở 2 FPS và lái xe trong trò chơi, hệ thống trò chơi cảnh báo tôi: "Quá nhanh! Quá nhanh!").

Vì vậy, tôi viết một email hỏi lý do tại sao họ mã hóa giá trị này và sử dụng nó động cơ vật lý của họ và họ trả lời rằng cách này họ giữ cho động cơ đơn giản hơn. Và tôi trả lời một lần nữa, Ok, nhưng nếu chúng tôi chạy các trò chơi trên một thiết bị đó là không có khả năng của 17 FPS, công cụ trò chơi của bạn chạy rất buồn cười nhưng không như mong đợi. Và họ nói rằng sẽ khắc phục vấn đề cho đến khi xem xét mã tiếp theo.

Sau 3 hoặc 4 tuần tôi nhận được một phiên bản mới của mã nguồn vì vậy tôi đã thực sự tò mò để tìm hiểu những gì họ đã làm với FPS liên tục vì vậy điều đầu tiên tôi làm là tìm kiếm thông qua mã sau 17 và chỉ có một vài phù hợp, nhưng một trong số đó không phải thứ tôi muốn xem:

static static int FPS = 17;

Vì vậy, họ đã xóa tất cả giá trị 17 được mã hóa cứng khỏi tất cả mã và sử dụng hằng số FPS thay thế. Và động cơ của họ: bây giờ nếu tôi cần phải đặt các trò chơi trên một thiết bị mà chỉ có thể làm 10 FPS, tất cả tôi cần làm là để thiết lập rằng FPS liên tục đến 10 và trò chơi sẽ làm việc trơn tru.

Tóm lại, xin lỗi vì đã viết một tin nhắn dài như vậy, nhưng tôi muốn nhấn mạnh rằng lý do duy nhất tại sao mọi người sẽ làm một điều như vậy là thiết kế tồi.

Answer 3

Dưới đây là một lời giải thích tốt về lý do tại sao timestep của bạn nên được giữ không đổi: http://gafferongames.com/game-physics/fix-your-timestep/

Bên cạnh đó, tùy thuộc vào động cơ vật lý, hệ thống có thể được ổn định khi những thay đổi timestep. Điều này là do một số dữ liệu được lưu trữ giữa các khung là phụ thuộc vào thời gian. Ví dụ, dự đoán bắt đầu cho một giải quyết lặp (đó là cách các ràng buộc được giải quyết) có thể ở xa câu trả lời. Tôi biết điều này là đúng cho Havok (động cơ vật lý được sử dụng bởi nhiều trò chơi commericial), nhưng tôi không chắc chắn mà SMB động cơ sử dụng.

Cũng có một bài viết trong Tạp chí nhà phát triển trò chơi cách đây vài tháng, minh họa cách nhảy với vận tốc ban đầu giống nhau nhưng các dấu thời gian khác nhau đạt được độ cao tối đa khác nhau với tốc độ khung hình khác nhau. Có một giai thoại hỗ trợ từ một trò chơi (Tony Hawk?), Nơi một bước nhảy nhất định có thể được thực hiện khi chạy trên phiên bản NTSC của trò chơi nhưng không phải là phiên bản PAL (vì các khung hình khác nhau). Rất tiếc, tôi không thể tìm thấy sự cố vào lúc này, nhưng tôi có thể cố gắng giải quyết vấn đề này sau nếu bạn muốn.