Làm thế nào một trò chơi có thể xử lý tất cả các nhân vật cùng một lúc?

Câu hỏi này chỉ là để có được kiến ​​thức về cách một trò chơi có thể xử lý nhiều nhân vật cùng một lúc. Tôi mới chơi game nên tôi xin thứ lỗi trước.

Thí dụ

Tôi đang tạo ra một trò chơi phòng thủ tháp trong đó có 15 khe tháp nơi các tòa tháp được xây dựng và mỗi tháp đều phóng ra theo một tốc độ nhất định; giả sử rằng mỗi giây, 2 quả đạn được tạo ra bởi mỗi tòa tháp và có kẻ thù diễu hành trên chiến trường, giả sử 70 (mỗi loại có 10 loại thuộc tính như HP, mana, v.v., sẽ thay đổi khi chúng di chuyển xung quanh chiến trường).

Tóm lược

Đếm tháp = 15 quả
đạn được tạo bởi mỗi tháp mỗi giây = 2
Tổng số lượng đạn được tạo mỗi giây = 30
đơn vị trong Đếm chiến trường = 70

Bây giờ, trò chơi xử lý 30 tên lửa và 70 đơn vị đó bằng cách xử lý chúng trên 100 luồng khác nhau (quá nhiều cho PC) hoặc 1 luồng di chuyển tất cả chúng, làm giảm giá trị của chúng, v.v. (sẽ chậm , Tôi nghĩ)?

Tôi không có manh mối về điều này vì vậy có ai có thể hướng dẫn tôi cách giải quyết vấn đề này không?

Bây giờ trò chơi xử lý 30 Projectile và 70 đơn vị đó bằng cách xử lý chúng trên 100 luồng khác nhau

Không, không bao giờ làm điều đó. Không bao giờ tạo một luồng mới cho mỗi tài nguyên, điều này không mở rộng trong mạng, nó cũng không cập nhật các thực thể. (Bất cứ ai cũng nhớ những lần bạn có một luồng để đọc trên mỗi ổ cắm trong java?)

1 chủ đề di chuyển tất cả chúng làm giảm giá trị của họ vv?

Vâng, đối với người mới bắt đầu, đây là con đường để đi. "Động cơ lớn" phân chia một số công việc giữa các luồng, nhưng điều này không cần thiết để bắt đầu một trò chơi đơn giản như trò chơi phòng thủ tháp. Có lẽ còn nhiều việc phải làm mỗi lần đánh dấu mà bạn cũng sẽ làm trong một chủ đề này. Ồ vâng, và hiển thị tất nhiên.

(đó sẽ là loại chậm tôi nghĩ)

Chà ... định nghĩa của bạn về chậm là gì? Đối với 100 thực thể, không nên mất hơn nửa mili giây, thậm chí có thể ít hơn, tùy thuộc vào chất lượng mã của bạn và ngôn ngữ bạn đang làm việc. Và ngay cả khi phải mất hai mili giây đầy đủ, nó vẫn đủ tốt để đạt 60 tps (tích tắc mỗi giây, không nói về khung trong trường hợp này).

Quy tắc số một của đa luồng là: Không sử dụng nó trừ khi bạn cần song song hóa trên nhiều lõi CPU để có hiệu suất hoặc khả năng đáp ứng. Yêu cầu "x và y phải xảy ra đồng thời theo quan điểm của người dùng" chưa đủ lý do để sử dụng đa luồng.

Tại sao?

Đa luồng là khó. Bạn không có quyền kiểm soát khi mỗi luồng được thực thi, điều này có thể dẫn đến tất cả các loại không thể tái tạo vấn đề ("điều kiện chủng tộc"). Có các phương pháp để tránh điều này (khóa đồng bộ hóa, các phần quan trọng), nhưng các phương pháp này đi kèm với bộ vấn đề của riêng họ ("khóa chết").

Thông thường các trò chơi xử lý số lượng đối tượng thấp như vậy chỉ vài trăm (vâng, điều này không có nhiều trong quá trình phát triển trò chơi) thường xử lý chúng theo cách nối tiếp mỗi lần đánh dấu logic bằng một forvòng lặp chung .

Ngay cả các CPU điện thoại thông minh tương đối yếu hơn có thể thực hiện hàng tỷ hướng dẫn mỗi giây. Điều đó có nghĩa là ngay cả khi logic cập nhật của các đối tượng của bạn phức tạp và cần khoảng 1000 hướng dẫn cho mỗi đối tượng và đánh dấu, và bạn đang nhắm tới 100 tick mỗi giây, bạn có đủ dung lượng CPU cho hàng chục nghìn đối tượng. Vâng, đây là một tính toán ngược quá mức, nhưng nó cho bạn một ý tưởng.

Ngoài ra, sự khôn ngoan phổ biến trong phát triển trò chơi là logic của trò chơi rất hiếm khi là nút cổ chai của một trò chơi. Phần quan trọng về hiệu năng hầu như luôn luôn là đồ họa. Vâng, ngay cả đối với các trò chơi 2d.

Các câu trả lời khác đã xử lý luồng và sức mạnh của máy tính hiện đại. Để giải quyết câu hỏi lớn hơn, những gì bạn đang cố gắng làm ở đây là tránh các tình huống "bình phương".

Ví dụ, nếu bạn có 1000 viên đạn và 1000 kẻ thù, giải pháp ngây thơ là chỉ cần kiểm tra tất cả chúng với nhau.

Điều này có nghĩa là bạn kết thúc với p * e = 1.000 * 1.000 = 1.000.000 séc khác nhau! Đây là O (n ^ 2).

Mặt khác, nếu bạn tổ chức dữ liệu của mình tốt hơn, bạn có thể tránh được rất nhiều điều đó.

Ví dụ: nếu bạn liệt kê trên mỗi ô vuông của lưới, kẻ thù ở ô vuông đó thì bạn có thể lặp qua 1000 viên đạn của mình và chỉ cần kiểm tra ô vuông trên lưới. Bây giờ bạn chỉ cần kiểm tra từng viên đạn so với hình vuông, đây là O (n). Thay vì một triệu kiểm tra mỗi khung hình, bạn chỉ cần một nghìn.

Suy nghĩ về việc tổ chức dữ liệu của bạn và xử lý nó một cách hiệu quả do tổ chức đó là tối ưu hóa lớn nhất mà bạn có thể thực hiện.

Không tạo chủ đề cho mỗi tài nguyên / đối tượng mà trên mỗi phần của logic chương trình của bạn. Ví dụ:

1. Chủ đề để cập nhật các đơn vị và tên lửa - chủ đề logic
2. Chủ đề để hiển thị màn hình - Chủ đề GUI
3. Chủ đề cho mạng (ví dụ: nhiều người chơi) - Chủ đề IO

Ưu điểm của việc này là GUI của bạn (ví dụ: các nút) không nhất thiết bị kẹt nếu logic của bạn chậm. Người dùng vẫn có thể tạm dừng và lưu trò chơi. Nó cũng tốt cho việc chuẩn bị trò chơi của bạn cho nhiều người chơi, bây giờ bạn tách đồ họa ra khỏi logic.

Ngay cả Space Invaders cũng quản lý hàng tá đối tượng tương tác. Trong khi giải mã một khung hình của video HD H264 liên quan đến hàng trăm triệu thao tác số học. Bạn có rất nhiều sức mạnh xử lý có sẵn.

Điều đó nói rằng, bạn vẫn có thể làm cho nó chậm nếu bạn lãng phí nó. Vấn đề không phải là số lượng đối tượng nhiều như số lượng thử nghiệm va chạm được thực hiện; cách tiếp cận đơn giản của việc kiểm tra từng đối tượng với nhau, bình phương số lượng tính toán cần thiết. Thử nghiệm 1001 đối tượng để va chạm theo cách này sẽ cần một triệu so sánh. Thông thường, điều này được giải quyết bằng cách ví dụ không kiểm tra các vật thể va chạm với nhau.

Tôi sẽ không đồng ý với một số câu trả lời khác ở đây. Các luồng logic riêng biệt không chỉ là một ý tưởng tốt, mà còn rất có lợi cho tốc độ xử lý - nếu logic của bạn có thể dễ dàng tách rời .

Câu hỏi của bạn là một ví dụ tốt về logic có thể tách rời nếu bạn có thể thêm một số logic bổ sung lên trên nó. Ví dụ: bạn có thể chạy một số luồng phát hiện lần truy cập bằng cách khóa các luồng vào các vùng không gian cụ thể hoặc thay đổi các đối tượng liên quan.

Bạn có thể KHÔNG muốn một luồng cho mỗi lần va chạm có thể xảy ra, chỉ vì điều đó có khả năng làm hỏng lịch trình; cũng có một chi phí liên quan đến việc tạo và phá hủy các chủ đề. Tốt hơn là tạo một số luồng xung quanh lõi của hệ thống (hoặc sử dụng một số liệu như cũ #cores * 2 + 4), sau đó sử dụng lại chúng khi quá trình của chúng kết thúc.

Không phải tất cả logic là dễ dàng tách ra, mặc dù. Đôi khi các hoạt động của bạn có thể tiếp cận trên tất cả dữ liệu trò chơi cùng một lúc, điều này sẽ khiến việc phân luồng trở nên vô dụng (thực tế là có hại, vì bạn sẽ cần thêm kiểm tra để tránh các vấn đề về luồng). Hơn nữa, nếu nhiều giai đoạn logic phụ thuộc nhiều vào nhau xảy ra theo các đơn đặt hàng cụ thể, bạn sẽ phải kiểm soát việc thực hiện các luồng theo cách để đảm bảo rằng không đưa ra kết quả phụ thuộc vào đơn hàng. Tuy nhiên, vấn đề đó không được loại bỏ bằng cách không sử dụng các chủ đề, các chủ đề chỉ làm trầm trọng thêm nó.

Hầu hết các trò chơi không làm điều này đơn giản vì nó phức tạp hơn so với nhà phát triển trò chơi trung bình sẵn sàng / có thể xử lý cho những gì thường không phải là nút cổ chai ở nơi đầu tiên. Phần lớn các trò chơi bị giới hạn GPU, không giới hạn CPU. Mặc dù việc cải thiện tốc độ CPU có thể giúp tổng thể, nhưng nó thường không phải là trọng tâm.

Điều đó nói rằng, các công cụ vật lý thường sử dụng nhiều luồng và tôi có thể đặt tên cho một số trò chơi mà tôi nghĩ rằng sẽ được hưởng lợi từ nhiều luồng logic (ví dụ như các trò chơi Paradox RTS như HOI3).

Tôi đồng ý với các bài viết khác rằng bạn có thể không cần sử dụng các chủ đề trong ví dụ cụ thể này, ngay cả khi nó có thể có lợi. Việc phân luồng nên được dành riêng cho các trường hợp bạn có tải CPU quá mức không thể tối ưu hóa thông qua các phương pháp khác. Đó là một cam kết rất lớn và sẽ ảnh hưởng đến cấu trúc cơ bản của động cơ; đó không phải là thứ bạn có thể giải quyết sau khi thực tế.

Tôi nghĩ rằng các câu trả lời khác bỏ lỡ một phần quan trọng của câu hỏi bằng cách tập trung quá nhiều vào phần xâu chuỗi của câu hỏi.

Một máy tính không xử lý tất cả các đối tượng trong một trò chơi cùng một lúc. Nó xử lý chúng theo trình tự.

Một trò chơi máy tính tiến triển trong các bước thời gian riêng biệt. Tùy thuộc vào trò chơi và tốc độ của PC, các bước này thường là 30 hoặc 60 bước mỗi giây hoặc nhiều / vài bước mà PC có thể tính toán.

Trong một bước như vậy, một máy tính sẽ tính toán từng đối tượng trò chơi sẽ làm gì trong bước đó và cập nhật chúng theo từng bước. Nó thậm chí có thể làm như vậy song song, sử dụng các luồng để nhanh hơn, nhưng vì chúng ta sẽ sớm thấy tốc độ không phải là một mối quan tâm.

Một CPU trung bình nên là 2 GHz hoặc nhanh hơn, có nghĩa là 10 ⁹ chu kỳ xung nhịp mỗi giây. Nếu chúng ta tính toán 60 timesteps mỗi giây, mà lá 10 ⁹ chu kỳ / 60 chu kỳ đồng hồ = 16.666.666 đồng hồ mỗi bước thời gian. Với 70 đơn vị, chúng tôi vẫn còn khoảng 2.400.000 chu kỳ đồng hồ trên mỗi đơn vị. Nếu chúng tôi phải tối ưu hóa, chúng tôi có thể cập nhật từng đơn vị trong ít nhất 240 chu kỳ, tùy thuộc vào độ phức tạp của logic trò chơi. Như bạn có thể thấy, máy tính của chúng tôi nhanh hơn khoảng 10.000 lần so với nhu cầu cho nhiệm vụ này.

Tuyên bố miễn trừ trách nhiệm: Loại trò chơi yêu thích mọi thời đại của tôi là dựa trên văn bản và tôi viết đây là một lập trình viên lâu năm của một MUD cũ.

Tôi nghĩ một câu hỏi quan trọng bạn cần tự hỏi mình là: Bạn thậm chí có cần chủ đề không? Tôi hiểu rằng một trò chơi đồ họa có thể sử dụng nhiều MT hơn nhưng tôi nghĩ nó cũng phụ thuộc vào cơ chế của trò chơi. . Nó cũng phụ thuộc vào cách bạn xác định 'tất cả các ký tự cùng một lúc'. Bạn có nghĩa là cùng một lúc? Bạn sẽ không có được điều đó vì Peter đã chỉ ra một cách chính đáng nên tất cả cùng một lúc là không liên quan theo nghĩa đen; nó chỉ xuất hiện theo cách này

Giả sử bạn sẽ đi với các luồng: Bạn chắc chắn không nên xem xét 100 luồng (và tôi thậm chí sẽ không biết liệu nó có quá nhiều cho CPU của bạn hay không; tôi chỉ đề cập đến các biến chứng và tính thực tế của nó).

Nhưng hãy nhớ điều này: đa luồng không dễ dàng (như Philipp chỉ ra) và có nhiều vấn đề. Những người khác có nhiều kinh nghiệm hơn (rất nhiều) so với tôi làm với MT nhưng tôi sẽ nói họ cũng sẽ đề xuất điều tương tự (mặc dù họ sẽ có khả năng hơn tôi - đặc biệt là không có phần thực hành của tôi).

Một số ý kiến ​​cho rằng họ không đồng ý rằng các chủ đề không có lợi và một số cho rằng mỗi đối tượng nên có một chủ đề. Nhưng (và một lần nữa đây là tất cả văn bản nhưng ngay cả khi bạn xem xét nhiều hơn một chủ đề bạn không cần - và không nên - xem xét nó cho từng đối tượng) khi Philipp chỉ ra các trò chơi có xu hướng lặp qua các danh sách. Nhưng nó không chỉ (như anh ấy gợi ý mặc dù tôi nhận ra anh ấy chỉ đáp ứng với các thông số của bạn về rất ít đối tượng) cho rất ít đối tượng. Trong MUD tôi là một lập trình viên cho chúng tôi có những điều sau đây (và đây không phải là tất cả các hoạt động xảy ra trong thời gian thực vì vậy hãy ghi nhớ điều đó):

(Số lượng phiên bản khác nhau tất nhiên - cao hơn và thấp hơn)

Điện thoại di động (NPC tức là nhân vật không phải người chơi): 2614; nguyên mẫu: 1360 Đối tượng: 4457; nguyên mẫu: 2281 Phòng: 7983; nguyên mẫu: 7983. Mỗi phòng thường có một ví dụ riêng nhưng chúng tôi cũng có các phòng năng động, nghĩa là các phòng trong một phòng; hoặc các phòng bên trong điện thoại di động, ví dụ như dạ dày của rồng; hoặc các phòng trong các vật thể, ví dụ như bạn nhập một vật thể ma thuật). Hãy nhớ rằng các phòng động này tồn tại trên mỗi đối tượng / phòng / điện thoại di động thực sự đã xác định chúng. Vâng, điều này rất giống với World of Warcraft (Tôi không chơi nó nhưng một người bạn đã cho tôi chơi nó khi tôi có một máy Windows, trong một thời gian) ý tưởng về các trường hợp ngoại trừ chúng ta đã có nó từ lâu trước khi World of Warcraft tồn tại.

Tập lệnh: 868 (hiện tại) (thật kỳ lạ, lệnh thống kê của chúng tôi không hiển thị số lượng nguyên mẫu chúng tôi có nên tôi sẽ thêm vào đó). Tất cả những thứ này được tổ chức ở các khu vực / khu vực và chúng tôi có 103 trong số đó. Chúng tôi cũng có các thủ tục đặc biệt mà Proc tại các thời điểm khác nhau. Chúng tôi cũng có những sự kiện khác. Sau đó, chúng tôi cũng có ổ cắm kết nối. Điện thoại di động di chuyển xung quanh, thực hiện các hoạt động khác nhau (ngoài chiến đấu), có tương tác với người chơi, v.v. (Các loại thực thể khác cũng vậy).

Làm thế nào để chúng tôi xử lý tất cả điều này mà không có bất kỳ sự chậm trễ?

• socket: select (), hàng đợi (đầu vào, đầu ra, sự kiện, những thứ khác), bộ đệm (đầu vào, đầu ra, những thứ khác), v.v ... Chúng được thăm dò 10 lần một giây.

• nhân vật, đồ vật, phòng, chiến đấu, tất cả mọi thứ: tất cả trong một vòng lặp trung tâm trên các xung khác nhau.

Chúng tôi cũng (triển khai của tôi dựa trên cuộc thảo luận giữa người sáng lập / lập trình viên khác và bản thân tôi) có kiểm tra tính hợp lệ của danh sách liên kết và kiểm tra con trỏ và chúng tôi có quá nhiều tài nguyên miễn phí nếu chúng tôi thực sự cần nó. Tất cả những điều này (ngoại trừ chúng tôi đã mở rộng thế giới) đã tồn tại từ nhiều năm trước khi có ít RAM, sức mạnh CPU, dung lượng ổ cứng, v.v. Và thực sự ngay cả khi đó chúng tôi không gặp vấn đề gì. Trong các vòng lặp được mô tả (các kịch bản gây ra điều này cũng như đặt lại khu vực / lặp lại cũng như các thứ khác) quái vật, vật thể (vật phẩm) và những thứ khác đang được tạo ra, giải phóng, v.v. Các kết nối cũng được chấp nhận, bỏ phiếu và mọi thứ khác bạn mong đợi.