Làm thế nào để videogames lưu trữ thông tin ngoài màn hình?


16

Tôi đang cố gắng tạo một trò chơi điện tử từ đầu, nhưng tôi thực sự mới với điều này và tiếp tục gặp phải các vấn đề cơ bản. Quan trọng nhất, làm thế nào để trò chơi video lưu trữ thông tin ngoài màn hình? Ý tôi là, làm thế nào để chương trình biết những gì sẽ hiển thị tiếp theo trên màn hình? Hoặc thậm chí, nếu người chơi thay đổi môi trường, làm thế nào để thay đổi này duy trì cho lần tiếp theo nó tải lên màn hình?

Ví dụ: trong New Super Mario Bros, nếu bạn nhấn a? chặn và sau đó tắt màn hình, và quay lại, nó vẫn còn trúng. Làm thế nào thông tin này được lưu giữ và sau đó thực hiện trong lần tiếp theo người chơi tải khối? Tại sao nó không được thiết lập lại?


24
Pedantry: Trong Super Mario Bros, nếu bạn đánh a? chặn và sau đó tắt màn hình, bạn không thể quay lại - trò chơi chỉ cuộn theo một hướng và tất cả các ống dọc đều là một hướng.
Trevor Powell

61
Khi bạn đọc một tài liệu văn bản và bạn cuộn xuống, trình xử lý văn bản của bạn có xóa phần đầu của tài liệu không?
Philipp

31
Màn hình hiển thị một cửa sổ vào thế giới game. Thế giới tồn tại bên ngoài cửa sổ của bạn - bạn không nhìn thấy nó.
Felsir

11
Câu hỏi lập trình cho người mới tiêu biểu hơn nhiều là: "Làm cách nào để hiển thị thông tin của tôi trên màn hình?". Làm việc thông qua bất kỳ hướng dẫn lập trình nào và khi bạn đến câu hỏi đó, bạn đã có câu trả lời cho câu hỏi của mình.
Peter - Unban Robert Harvey

4
Tôi tự hỏi loại môi trường phát triển nào bạn đang làm việc với việc giữ mọi thứ khỏi màn hình nghe có vẻ phức tạp hơn so với việc đưa chúng lên màn hình :) Hay đây chỉ là một câu hỏi lý thuyết đơn thuần?
Luaan

Câu trả lời:


60

Thông thường bạn nên tách trạng thái logic của môi trường trò chơi của bạn khỏi biểu diễn trực quan.

Người chơi có thể chỉ nhìn thấy một phần nhỏ của nó trên màn hình của họ, nhưng bạn vẫn giữ trạng thái của toàn bộ cấp độ trong bộ nhớ và thường tính toán cơ chế trò chơi cho toàn bộ cấp độ. Khi thế giới của bạn quá lớn đến nỗi điều này sẽ đòi hỏi quá nhiều ram và / hoặc cpu, bạn có thể tạm dừng các khu vực xa hơn với ổ cứng.

Chương trình con kết xuất của bạn kiểm tra phần nào của cấp độ hiện trên màn hình và sau đó chỉ vẽ những phần đó. Bất cứ thứ gì ngoài màn hình đều không được vẽ, nhưng điều đó không có nghĩa là nó không được cập nhật.


37

Bạn đang đi về phía sau nó.

Bạn bắt đầu với trạng thái logic của trò chơi của bạn và mô hình đó. Toàn bộ trạng thái logic của toàn bộ thế giới gần như chắc chắn sẽ có quá nhiều thứ được lưu giữ trong bộ nhớ cùng một lúc, vì vậy bạn chia nó thành các phần nhỏ hơn có thể được tải và lưu độc lập. Những phần này thường được gọi là chunk . Các khối này có thể tạo thành một thế giới liên tục, nhưng chúng cũng có thể là các cấp / trường hợp riêng biệt. Thuật ngữ thay đổi rất nhiều tùy thuộc vào thể loại và kỹ thuật bạn muốn sử dụng.

Sau đó, bạn tải những phần đáng quan tâm - đó là các đoạn nằm trong vùng lân cận của người chơi. Các đĩa quá xa được lưu vào đĩa / bộ nhớ vĩnh viễn và được tải khỏi bộ nhớ.

Và sau đó, như bước cuối cùng, bạn xác định những gì thực sự hiển thị và tạo biểu diễn trực quan của trạng thái trò chơi hiện tại và hiển thị nó trên màn hình.

Tất nhiên bạn sẽ cố gắng không xây dựng lại toàn bộ biểu diễn trực quan mỗi lần mà lưu vào bộ đệm và sử dụng lại nếu bạn có các phần đã được xây dựng, nhưng đó là nguyên tắc chính.


Điều này đúng cho bất kỳ chương trình có đầu ra. Nếu bạn viết chương trình với GUI bình thường, như trình soạn thảo văn bản, bạn có thể sẽ lập mô hình tài liệu và sau đó GUI sẽ xác định trạng thái và các phần hiển thị của tài liệu và hiển thị nó ra màn hình. Hoặc điền vào các trường mẫu một cách thích hợp, hoặc cách khác.

Ý chính là: Hãy suy nghĩ về vị trí và cách bạn lưu trữ dữ liệu trước tiên (có thể cùng với cách thể hiện dữ liệu đó). Hầu như mọi chương trình đều phải đối phó với việc lưu trữ dữ liệu. Chỉ có rất ít trường hợp bạn không lưu trữ bất kỳ dữ liệu nào.


7
miếng, mảnh nhỏ? Tôi sẽ gọi những cấp độ nhỏ hơn .
gbjbaanb

3
Điều này là tốt, ngoại trừ "vì vậy bạn chia nó thành các phần nhỏ hơn có thể được tải và lưu độc lập. Những phần này thường được gọi là khối", dường như là dành riêng cho các trò chơi có thế giới rất rộng lớn. Nhiều trò chơi không cần phải làm như vậy. Tôi sẽ không ngạc nhiên nếu bạn có thể phù hợp với bộ nhớ tất cả các dữ liệu cấp độ cho mọi trình điều khiển bên 2D từng được tạo.
dùng253751

3
@gbjbaanb 'Cấp độ' là một thuật ngữ ngày và 'chunk' là toàn diện hơn nhiều và là một khái niệm phân biệt rõ ràng. Không phải tất cả các khối là cấp độ và không phải tất cả các cấp độ là khối.
Lilienthal

3
Tôi nghĩ rằng một cách hữu ích để suy nghĩ về nó là về mặt kỹ thuật có thể chơi toàn bộ trò chơi mà không có một pixel nào được hiển thị, nghĩa là toàn bộ trò chơi tách biệt với biểu diễn trực quan.
Nathan K

1
@Lilienthal chắc chắn, nhưng tôi nghĩ rằng cấp độ vẫn được sử dụng phổ biến và nhiều trò chơi vẫn có khái niệm - Tôi không chắc bất kỳ ai trong số họ bật màn hình "nạp chunk" khi tìm nạp một "đấu trường" mới sau đó người chơi đi ngang qua chúng. Do đó, có thể dễ hiểu hơn, đặc biệt đối với OP, người mới chơi game hơn là một thuật ngữ tương đối kỹ thuật mà anh ta chưa từng thấy trước đây.
gbjbaanb

6

Như những người khác đã nói, bạn giữ một bản đồ (ví dụ trong một mảng) và vẽ phần hiển thị của nó lên màn hình và không đọc lại từ màn hình.

Nhưng trong một số hệ thống cũ, bạn thực sự sẽ giữ dữ liệu ngoài màn hình. Giả sử, bộ nhớ video 400x300 pixel cho màn hình 320x200 và bạn sẽ xác định chế độ xem vào đó ("bắt đầu tại X = 10 Y = 30"). Vì vậy, bạn có thể cuộn màn hình bằng cách điều chỉnh một thanh ghi. Bạn sẽ không phải mất hàng trăm nghìn chu kỳ cần thiết để di chuyển các byte xung quanh, bạn chỉ cần thay đổi nơi phần cứng video bắt đầu đọc chúng.

NES có điều này, kết hợp với một hệ thống dựa trên gạch: http://wiki.nesdev.com/w/index.php/PPU_scrolling

NES không bao giờ xây dựng hình ảnh đầy đủ trong bộ nhớ, vì nó không có đủ RAM. Thay vào đó, có một mảng RAM xác định một tập hợp các ô rộng hai màn hình. Một byte cho mỗi loại gạch. Phần cứng video tra cứu tọa độ gạch và X / Y để quyết định pixel nào sẽ xuất hiện tại bất kỳ điểm nào.


6
Mặc dù đúng, đó là một chi tiết triển khai - nguyên tắc chính vẫn là bạn có một số trạng thái logic và hiển thị nó (và như tôi đã nói lưu trữ một số phần của nó, đã chuẩn bị một số thứ sẽ đi vào quan điểm tiếp theo, v.v.).
Polygnome

2
@Polygnome Vâng, tôi đã viết rất nhiều trò chơi trong đó màn hình trạng thái trò chơi. Thật tuyệt vời với những gì bạn có thể làm với 4.000 byte VRAM! :)
Luaan

1

Chà, nếu bạn đang hỏi loại câu hỏi này, bạn sẽ có một con đường dài để đi đến điểm mà bạn có thể làm một trò chơi. Nhưng, đi vào trọng tâm của câu hỏi của bạn, chương trình có thể lưu trạng thái của nhiều thứ khác nhau trong các biến nằm ở phía sau của chương trình của bạn. Hãy xem xét một vài ví dụ.

Mario Brothers (hoặc tương tự) lưu trạng thái của cấp độ bạn đang ở. Điều đó có thể bao gồm bạn đã đi bao xa trước khi chết, nếu một khối bị bắn trúng hay không. Trong một số ý nghĩa hướng đối tượng hơn, trò chơi chỉ nói "hãy là một khối ở đây" và khối tồn tại. sau đó khi bạn nhấn khối, khối sẽ thay đổi trạng thái bên trong của chính nó thành "Tôi đã bị bắn". Dữ liệu như thế có thể được lưu trữ theo nhiều cách khác nhau.

Trình xử lý văn bản của bạn lưu dữ liệu của nó trong một cấu trúc dữ liệu. Bây giờ có rất nhiều trong số này và nhiều cách chúng có thể được thực hiện, nhưng có lẽ nó sử dụng một số dạng của cây. Trong một cây bạn có ít nhất một nút. Bất cứ điều gì thêm vào trước khi nó đi bên trái. Bất cứ điều gì thêm vào sau nó, đi bên phải. Sau khi bạn thêm ba nút, bạn có hai trong số chúng treo ở nút giữa. Và cây có thể phát triển lớn hơn nữa với những mảnh mới được thêm vào bất cứ đâu và cây sẽ tự xây dựng lại. Ví dụ về cây Hoặc suy nghĩ về các game bắn súng nơi kẻ thù của bạn lang thang xung quanh. Mỗi người trong số họ có các biến theo dõi vị trí, cuộc sống của họ, v.v ... để khi bạn bị thương, họ sẽ nhớ rằng nó bị tổn thương.

Tất cả những điều này đòi hỏi một kiến ​​thức về cấu trúc dữ liệu. Nó vượt xa những gì bạn thấy trên màn hình. Tôi sẽ đề nghị đọc về mảng, danh sách, băm (đôi khi được gọi là từ điển hoặc bản đồ) và sau đó quay lại vấn đề của bạn.

Dưới đây là một số tài liệu khởi đầu tốt:


0

Ở một mức độ nào đó, đây là một chức năng về cách hiển thị 3D. Ví dụ: OpenGL sẽ tự động loại bỏ hình học bên ngoài phạm vi -1.0, +1.0 trong không gian màn hình XY (Z phức tạp hơn nhưng tương tự). Hình học Culled không bao giờ tạo ra các mảnh (xấp xỉ pixel) và do đó không bao giờ được chuyển thành hình ảnh thực tế, mặc dù được gửi đến hệ thống để kết xuất. Trong mọi trường hợp, không thể ghi vào không gian bên ngoài cửa sổ kết xuất (nếu mọi thứ đều hoạt động như bình thường).

Trong một số bối cảnh, nó đủ để dựa vào hành vi này như một sự tối ưu hóa. Tuy nhiên, bạn vẫn phải chuyển tất cả dữ liệu trò chơi của mình qua ít nhất một giai đoạn kết xuất (trình tạo bóng đỉnh) trước khi thẻ video có thể biết nội dung có thể nhìn thấy. Trong một cái gì đó như, nói, Skyrim, điều đó sẽ không thực tế. Bạn không chỉ phải gửi mọi đỉnh trên thế giới thông qua đường truyền kết xuất mà còn phải tải mọi đỉnh vào bộ nhớ hệ thống / video. Đó là không hiệu quả, thậm chí nếu có thể.

Vì vậy, nhiều trò chơi sẽ sử dụng loại bỏ dựa trên CPU. Thông thường, họ sẽ triển khai một số loại hệ thống LOD (mức độ chi tiết), trong đó chất lượng và sự tồn tại của tài sản bị ảnh hưởng bởi mức độ quan trọng của chúng được đánh giá trong bối cảnh nhất định. Một lưới kim tự tháp có thể là một xấp xỉ chấp nhận được cho một ngọn núi nếu bạn 50 dặm từ nó. Nếu bạn hoàn toàn không thể nhìn thấy nó (như bị chặn bởi những ngọn núi khác), thậm chí không cần phải tải nó. Có một số phương pháp phức tạp hơn để làm điều này đó là chủ đề tôi không cảm thấy có liên quan trực tiếp đến độ sâu yêu cầu của câu hỏi này, nhưng nhìn vào tessellation cho một trong những ví dụ phổ biến nhất.

Ý chính của việc này là hình ảnh chỉ là sản phẩm của trò chơi. Dữ liệu thực tế không liên quan gì đến những gì bạn đang thấy hoặc không nhìn thấy hầu hết thời gian và dữ liệu được lọc theo nhiều giai đoạn khác nhau để xóa thông tin không liên quan trước khi nhấn vào điểm mà hình ảnh được ghi lên màn hình. Tùy thuộc vào thiết kế động cơ, hình ảnh có thể được tách rời khỏi logic trò chơi thực tế, cho đến khi một cái gì đó giống như có giao diện 2D và 3D cho cùng một trò chơi là một khả năng. Thậm chí nhiều công cụ trò chơi có thể chạy mà không có đầu ra như vậy; đôi khi điều này được sử dụng để thử nghiệm trò chơi AI.

Đó là nơi mọi thứ có thể trở nên phức tạp, mặc dù. Trong một thứ đơn giản như trò chơi Mario, không quá khó để tính toán chuyển động của tất cả kẻ thù trong cấp độ, ngay cả khi chúng không nhìn thấy được. Trong bối cảnh hiện đại, những gì đang diễn ra ngoài màn hình là một câu hỏi thực sự được xem xét nghiêm túc. Nếu có nhiều thành phố của NPC, làm thế nào để bạn xử lý cách chúng cư xử khi chúng bị loại bỏ hoàn toàn - như khi người chơi ở một thành phố khác? Bạn có thực sự muốn tính toán hàng trăm quyết định của NPC trên toàn bản đồ không? Câu trả lời thường là không, nhưng cách tiếp cận chính xác để thực hiện không làm như vậy có thể khác nhau, và nó có thể có một số tác động đến trò chơi.

Điều quan trọng cần lưu ý rằng đây là cách làm việc hiện nay . Bản thân các trò chơi Mario cũ có thể được lập trình theo những cách rất khác nhau (tôi không thể nói theo những cách chính xác), với những hạn chế về phần cứng cực kỳ vào thời điểm đó. Khái niệm 3D không tồn tại trước đó; nhưng ngày nay hầu như tất cả các trò chơi, ngay cả những game hoàn toàn 2D, đều sử dụng kết xuất 3D ở một số hình thức, ngay cả khi chúng không biết chúng làm. Phần cứng video hiện đại là 3D đầu tiên và kết xuất 2D (ít nhất là khi nó sử dụng phần cứng đúng cách) chỉ bỏ qua chiều thứ 3.


Ngoài các kỹ thuật LoD, sẽ tốt hơn nếu thêm một khung cảnh vào câu trả lời này - nơi một thế giới có thể được giữ trong bộ nhớ và 'CPU bị loại bỏ' dựa trên những gì trong tầm nhìn.
gbjbaanb

0

Để trả lời câu hỏi của bạn: trò chơi video giữ trạng thái của thế giới trò chơi trong một số cấu trúc dữ liệu trừu tượng không liên quan gì đến màn hình. Điều này sau đó được hiển thị ra màn hình khi cần thiết (nghĩa là tùy thuộc vào vị trí của người chơi).

Các trò chơi sử dụng RAM video trực tiếp cho các mục đích nhà nước đã xuất hiện vào khoảng thập niên 80 trong 8 bit, thậm chí có thể trong kỷ nguyên 16 bit, nhưng trừ khi bạn đang phát triển cho nền tảng đó hoặc cho một số ThayC mà điều khiển RAM của nó trong KB thay vào đó GB, hãy quên nó đi.

Điều đó nói rằng, bạn dường như rất mới đối với mọi thứ liên quan đến lập trình, hoặc câu hỏi sẽ không được đưa ra. Tôi đề nghị đi từng bước một, lập trình những thứ rất dễ dàng trước tiên; có thể một cái gì đó chỉ có đầu vào / đầu ra văn bản (lời nhắc đơn giản và tất cả những thứ đó). Thành thật mà nói, thời gian tôi làm điều đó là khoảng 30 năm trước, vì vậy tôi không có tài nguyên thực sự tốt cho bạn, nhưng thư viện địa phương của bạn thể tốt hơn internet để cung cấp cho bạn một khởi đầu thực sự tốt trong lập trình.

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.