STL cho các trò chơi, phải hay không? [đóng cửa]

Mỗi ngôn ngữ lập trình đều có thư viện chứa các thuật toán, thuật toán và các công cụ hữu ích khác. Với các ngôn ngữ như C #, Java và Python, thực tế không thể sử dụng ngôn ngữ mà không có lib chuẩn.

Tuy nhiên, trên nhiều trò chơi C ++ mà tôi đã làm việc, chúng tôi hoàn toàn không sử dụng STL, sử dụng một phần rất nhỏ của nó hoặc sử dụng triển khai của chúng tôi. Thật khó để biết liệu đó có phải là một quyết định đúng đắn cho các trò chơi của chúng tôi hay chỉ đơn giản là do sự thiếu hiểu biết về STL.

Vậy ... STL có phù hợp hay không?

Quay lại khi tôi làm việc trong lĩnh vực phát triển game chuyên nghiệp, STL còn quá non nớt và bồng bềnh. Nhưng đó là> 10 năm trước.

Bây giờ tôi làm việc trong mô phỏng quân sự, có yêu cầu hiệu năng thậm chí còn khó khăn hơn (như tốc độ khung hình không bao giờ có thể xuống dưới một số FPS). Trong mô phỏng quân sự, STL được sử dụng ở mọi nơi.

Một số người nói với bạn không sử dụng STL sử dụng lập luận rằng nó không phải luôn luôn là giải pháp hoàn hảo hoặc thậm chí là tốt nhất cho vấn đề. Nhưng đó không phải là một câu trả lời cho câu hỏi. Câu hỏi nên là: Có điều gì đó vốn đã sai khi sử dụng STL trong các trò chơi? Tôi muốn nói là không, STL hầu hết thời gian là một triển khai tốt hơn so với những gì người dùng sẽ tự mình nghĩ ra.

Chỉ cần chắc chắn rằng bạn biết cách sử dụng STL và sử dụng nó trong trò chơi của bạn. Đọc một số sách và xem mã triển khai trong STL bạn đang sử dụng.

Tôi sẽ nói rằng, ngoài đỉnh đầu của tôi, tốt hơn là sử dụng STL trừ khi bạn biết chính xác lý do tại sao bạn không muốn sử dụng nó.

Đây là điều về STL: nó được phát triển bởi những người thông minh hơn bạn. Điều đó không có ý định gây khó chịu hay bất cứ điều gì, chỉ là STL được phát triển bởi những người có công việc thực sự xây dựng STL. Nó sẽ thực sự nhanh như nền tảng có thể cho phép và nói chung sẽ mạnh hơn nhiều so với giải pháp cuộn tại nhà (và điều này cũng đáng lo ngại nếu không phải lo lắng về tốc độ thô - vì nhu cầu trò chơi của bạn mạnh mẽ hơn một chút so với bạn cần tốc độ, cái sau là vô nghĩa nếu không có cái trước).

Những lời phàn nàn rằng STL thi hành một "cái nhìn hạn hẹp về thế giới" tấn công tôi như một chút ngớ ngẩn. Chúng là những container. Họ có một bộ hoạt động hạn chế vì các container có bộ hoạt động hạn chế. Bạn đang làm gì mà không đi đôi với điều này?

Tôi đã thấy rất ít lý do để không sử dụng STL cho các trò chơi.

Đối với các vấn đề cấp phát bộ nhớ, nhiều người không biết điều này nhưng bạn có thể viết các cấp phát tùy chỉnh cho các lớp chứa STL của mình. Phân bổ về cơ bản là các lớp chính sách bạn chuyển vào các mẫu của bạn để xác định cách phân bổ được thực hiện. Sử dụng những thứ này bạn thường có thể giải quyết mọi vấn đề về bộ nhớ có vấn đề trên nền tảng bạn chọn.

Tất nhiên, nếu bạn đang sử dụng STL và làm những việc ngớ ngẩn như ánh xạ các chuỗi thành các loại lớn, không phải con trỏ, thì bạn sẽ gặp vấn đề lớn hơn.

STL mặc định có một số vấn đề hợp lý gây khó khăn khi sử dụng với các trò chơi, đặc biệt là khi căn chỉnh bộ nhớ.

Một biến thể tùy chỉnh như EA STL được thiết kế đặc biệt cho các trò chơi và có thể giúp bạn có hiệu suất bộ nhớ và khả năng sử dụng bảng điều khiển tốt hơn nhiều. Nó đã trở thành mã nguồn mở vào năm 2016, theo điều khoản BSD-3, với kho lưu trữ trên GitHub .

Dưới đây là những gì Mike Acton (Giám đốc động cơ tại Insomniac Games of Spyro the Dragon, Ratchet & Clank và Kháng chiến nổi tiếng) đã nói về điều này khi được hỏi ở đây . Lưu ý rằng anh ta đã được hỏi về cả STL và Boost nói chung liên quan đến việc sử dụng trong nhà phát triển trò chơi.

STL / Boost, nó có thuộc về gamedev không? Nếu chỉ là một phần của nó, những cái nào?

Bạn đang hỏi về hai điều khác nhau ở đây, phải không? STL và Boost, riêng biệt. Nhưng thực sự, câu trả lời của tôi là như nhau: Không có gì sai với mỗi người, nhưng tôi không khuyến khích họ sử dụng. Sử dụng một trong hai khuyến khích mọi người phù hợp với giải pháp cho một vấn đề thay vì tìm giải pháp cho một vấn đề. Giải pháp phải luôn phù hợp với dữ liệu trong tay và các ràng buộc của phần cứng, v.v ... Cả STL và Boost đều có tầm nhìn cực kỳ hẹp về "thế giới" và việc sử dụng phù hợp của chúng bị hạn chế. Thực sự, tôi không khuyến khích họ vì họ dẫn các lập trình viên đi sai hướng ngay lập tức, tôi thường nói nếu bạn cảm thấy như bạn cần một trong những điều mà bạn có thể không thực sự hiểu vấn đề mà bạn '

Tôi cũng nhận thấy rằng hầu hết các nhà phát triển game chuyên nghiệp đều nỗ lực hướng tới C nhiều hơn C ++.

Nếu bạn thấy mình đang viết lại một cái gì đó đã tồn tại trong STL, vì bất kỳ lý do gì, hãy dừng lại . Sử dụng STL.

STL đã được tối ưu hóa qua nhiều năm phân tích và thời gian, và đó là một sự đánh cược an toàn có lẽ bạn sẽ không viết một cái gì đó hiệu quả hơn. Điều đó không có nghĩa là bạn nên sử dụng STL khi có thể có giải pháp đơn giản hơn (nghĩa là sử dụng một mảng khi bạn có số lượng vật phẩm đã biết, không phải là danh sách stl ::), nhưng nếu bạn đang viết bản đồ thực hiện của riêng mình ( cấu trúc dữ liệu cơ bản, không phải bản đồ thế giới trò chơi), bạn đang làm sai.

STL có phù hợp với game không? Chắc chắn rồi. Trò chơi là những phần mềm phức tạp, STL cung cấp các tính năng giúp quản lý sự phức tạp, vì vậy nó rất tốt.

Nó có phù hợp với nền tảng của bạn không? Không cần thiết. Nếu bạn đang viết cho một giao diện điều khiển thì bạn phải rất cẩn thận về việc sử dụng bộ nhớ và bộ nhớ cache. STL không làm điều này rất dễ dàng.

Tôi nghĩ rằng tất cả quá thường xuyên chúng ta nhầm "trò chơi" với "trò chơi thời gian thực hiệu suất cao chạy trên phần cứng nhúng hoặc bespoke", nhưng điều quan trọng là phải phân biệt. Nếu bạn đang viết một trò chơi Windows không cố chạy ở chế độ toàn màn hình với tốc độ 60fps không đổi thì không có lý do gì để tránh các công cụ mà thư viện chuẩn cung cấp cho bạn.

Tôi biết điều này là rất muộn cho bữa tiệc, nhưng thời gian thay đổi và câu trả lời vẫn ở xung quanh. C ++ 11 có những thay đổi khá lớn, nhiều trong số đó là để tăng hiệu suất của C ++ và thư viện chuẩn. Có vẻ như những người không sử dụng STL hoặc Boost, có xu hướng không theo kịp các tiêu chuẩn mới, khiến các giải pháp quay vòng tại nhà thiếu các cải tiến quan trọng, tất nhiên điều này không phải luôn luôn như vậy.

Tôi đã sử dụng STL cho mọi dự án từ giữa những năm 90 đến nay, ngoại trừ một thời gian ngắn tại EA. Tôi nghĩ rằng bên chống STL có một số lý do hợp lý để không sử dụng nó. Những thứ đó phần lớn đã biến mất. Phân bổ tùy chỉnh là một giải pháp, sử dụng dự trữ là một giải pháp khác và không vượt qua mọi thứ theo giá trị là một phần ba, nhưng những điều này khá đơn giản và bất kỳ lập trình viên nào cũng nên biết những điều này. Quan trọng hơn là việc sử dụng các thuật toán. Người viết trình biên dịch biết chính xác những gì một for_each () làm và có thể tối ưu hóa mã. Điều đó không thể xảy ra với một vòng lặp nhà. for_each () trên một đối tượng const thậm chí còn tốt hơn. Microsoft tối ưu hóa for_each theo nhiều cách bao gồm cả tuần tự hóa. Họ cũng có thư viện AMP cóallel_for_each (). Nếu bạn có cơ hội, hãy nói chuyện với các kỹ sư biên dịch về điều này. Trình biên dịch bảng điều khiển sẽ tối ưu hóa những gì được sử dụng, vì vậy nó ' sa một chút của một vấn đề gà và trứng. Microsoft đang rất nặng nề với C ++ 11 và XBox tiếp theo sẽ không khác. Tôi không biết gì về PS4, chúng tôi chưa có ai.

Cấp phát tùy chỉnh là một cách để xử lý vấn đề bộ nhớ, nhưng một tùy chọn khác (thường bị bỏ qua) là sử dụng lớp mới và xóa. Tăng hiệu suất rất lớn có thể có cách này.

Quan niệm rằng Boost và STL có quan điểm hạn hẹp trong việc giải quyết vấn đề là sự điên rồ thuần túy. Tôi choáng váng khi có bao nhiêu thứ trong STL và Boost có thể tùy chỉnh thông qua các đặc điểm và chính sách. Tìm trường hợp chuỗi độc lập so sánh làm ví dụ.

Về thời gian liên kết dài và phình mã, mẫu extern mới sẽ giúp với điều này. Nói chung tôi thấy thời gian biên dịch dài đến từ khớp nối thừa và lạm dụng pch.

Lý do thuyết phục nhất để sử dụng STL so với âm hộ là có hàng triệu người có thể giúp bạn với STL. Như mọi khi, không tối ưu hóa sớm và kiểm tra, thử nghiệm, kiểm tra.

Đây là một chủ đề nóng trong phát triển trò chơi. Cá nhân tôi không khuyên dùng nó, ngoại trừ EASTL như đã đề cập ở trên. Tôi có hai vấn đề chính với STL (về mặt kỹ thuật là "Thư viện chuẩn C ++", vì STL không còn là tên) trong các trò chơi. 1) Cấp phát bộ nhớ động thường lãng phí rất nhiều thời gian chạy trong các trò chơi khi sử dụng STL. 2) Việc sử dụng STL khuyến khích cách tiếp cận mảng cấu trúc trong kiến ​​trúc trò chơi, trong khi cách tiếp cận cấu trúc của mảng là thân thiện với bộ đệm hơn nhiều.

Nó phụ thuộc. Dự án lớn như thế nào, nền tảng nào và dòng thời gian là gì?

Nếu bạn đang làm việc trong một dự án lớn, trên các nền tảng có nguồn lực hạn chế, với thời gian và ngân sách đáng kể, thì bạn có thể tiết kiệm cho mình rất nhiều rắc rối bằng cách tránh địa ngục không thể tránh khỏi sẽ nhìn vào một nửa triệu cơ sở mã dòng xả rác với STL, không thể giữ tốc độ khung hình trên 30, ăn đủ RAM để phù hợp với nhiều tài sản hơn và mất 2 giờ để xây dựng.

Tuy nhiên, trong các tình huống khác, STL và thậm chí Boost có thể rất hữu ích khi được áp dụng phù hợp. Tôi đã làm việc với các tựa game sử dụng lựa chọn STL / Boost và là một giấc mơ tuyệt đối để mã hóa: ít lỗi / rò rỉ hơn và dễ duy trì mã có nghĩa là có nhiều thời gian mã hóa các tính năng mới thú vị hơn! Đối với các dự án sở thích đặc biệt, đó là một chiến thắng lớn trong bộ phận động lực.

Biết khi nào nên giao dịch hiệu suất cho thuận tiện!

IMHO Tôi muốn nói rằng nó phù hợp vì STL đã hoạt động tốt và được tối ưu hóa cho các nhiệm vụ được thực hiện. Bên cạnh đó, bạn đang làm việc trên một trò chơi vì vậy, hãy sử dụng các công cụ bạn có trong tay để giúp cuộc sống của bạn dễ dàng hơn và mã của bạn ít bị lỗi hơn.

Tại sao phải phát minh lại bánh xe khi bạn có thể làm việc trên một thứ khác như AI, trải nghiệm người dùng hoặc tốt hơn; kiểm tra và gỡ lỗi?

STL hoàn toàn tốt để sử dụng trong các trò chơi, miễn là bạn hiểu rõ về nó. Động cơ của chúng tôi sử dụng khá rộng rãi và nó chưa bao giờ là một vấn đề. Tôi không có bất kỳ kinh nghiệm nào về phát triển giao diện điều khiển, đây có thể là một câu chuyện hoàn toàn khác, nhưng nó được hỗ trợ tốt trên tất cả các nền tảng PC (Windows / Mac / Linux).

Điều quan trọng nhất là phải hiểu được điểm mạnh và điểm yếu của từng loại container là gì và chọn đúng container cho công việc bạn đang làm.

Chủ cũ của tôi đã chuyển từ sử dụng một tập hợp mạnh mẽ các lớp container tùy chỉnh sang STL. Thời gian xây dựng tăng lên và dễ dàng gỡ lỗi đi xuống, cả hai khá đáng kể. Nếu chúng tôi đã bắt đầu từ đầu, STL (có lẽ được sử dụng tốt hơn) có thể có ý nghĩa, nhưng tôi không bao giờ rõ ràng rằng chúng tôi đã đạt được bất cứ điều gì khi chuyển sang STL, điều đó sẽ biện minh cho việc loại bỏ mã hoạt động, nhanh, có thể gỡ lỗi.

Đối với các dự án cá nhân của tôi, việc STL có phù hợp hay không phụ thuộc vào dự án. Nếu tôi đang cố gắng thực hiện một số công việc được tối ưu hóa truy cập bộ nhớ, bộ nhớ và bộ nhớ cache theo kiểu dữ liệu của Mike Acton, thì ít nhất tôi sẽ nghĩ về việc cuộn các cấu trúc dữ liệu tùy chỉnh của riêng mình. Nếu tôi đang tạo mẫu một số thuật toán hoặc trò chơi và không quan tâm đến hiệu suất, khả năng mở rộng, nền tảng đích, v.v. Tôi sẽ tự động lấy STL.

2 xu của tôi về điều này là STL hoạt động tốt. Tôi đã phát triển một công cụ trò chơi 3D (không phải chất lượng AAA, nhưng đủ tiên tiến - các loại thực thể theo kịch bản, trình kết xuất hoãn lại, vật lý Bullet tích hợp) cho PC và tôi vẫn chưa thấy container trở thành nút cổ chai chính. Việc sử dụng API 3D không chính xác và các thuật toán kém là mục tiêu tốt nhất (được xác định bằng cách định hình!) Mỗi ​​khi tôi đi vào và cố gắng tăng hiệu suất hơn một chút.

Tôi đã xây dựng các trò chơi bằng STL và tôi thích nó, và nó dường như hoạt động tốt.

Câu hỏi hay! Một câu hỏi cụ thể hơn là một số yêu cầu phổ biến mà một trò chơi sẽ không thể đáp ứng với STL và Boost.

Theo kinh nghiệm của tôi, các giới hạn bộ nhớ chặt chẽ của phần cứng bảng điều khiển làm cho bất kỳ loại thùng chứa kích thước động nào trở thành một ý tưởng tồi cho dù bộ phân bổ tùy chỉnh của bạn thông minh đến mức nào. Các container không có giới hạn có chủ ý khuyến khích các lập trình viên viết mã không giới hạn các giới hạn của tập dữ liệu của họ. Tùy thuộc vào vô số biến khó theo dõi, bạn có thể vượt quá giới hạn bộ nhớ. Tôi có linh cảm rằng đây là một trong những nguyên nhân chính gây mất ổn định trong các trò chơi hiện đại.

Ngoài ra, việc sử dụng quá mức các mẫu có thể dẫn đến thời gian biên dịch rất dài trong một cơ sở mã lớn và sẽ làm tăng kích thước của tệp thực thi của bạn để nó không còn vừa trong bộ đệm của, ví dụ, lõi phụ trên ps3.

Tuy nhiên, đối với sự phát triển chỉ dành cho PC tôi nghĩ STL và Boost rất tốt. Trong khi các giải pháp trường hợp chung không phải lúc nào cũng lý tưởng, chúng thường đủ tốt. Giải pháp đầu tiên của bạn cho một vấn đề gần như không bao giờ lý tưởng, và bạn cải thiện hoặc thay thế những bất cập cho đến khi nó đủ tốt.

STL phù hợp với trò chơi của bạn nếu STL phù hợp với trò chơi của bạn.

Như với tất cả các lựa chọn công nghệ được thực hiện trong quá trình phát triển, bạn cần cân nhắc những ưu và nhược điểm - liệu thư viện của riêng tôi có mang lại cho tôi việc sử dụng bộ nhớ, hiệu suất và năng suất hiệu quả hơn so với việc sử dụng STL không? Có khả năng; mặc dù thật dễ dàng để tạo ra một vectortriển khai sử dụng nhiều bộ nhớ hơn, chậm hơn và đòi hỏi một lượng lớn bảo trì để duy trì chức năng so với những gì đã tồn tại.

Mọi người không nên tránh sử dụng STL trong các trò chơi của mình vì những người khác tránh sử dụng STL trong các trò chơi; họ nên tránh sử dụng nó nếu họ đã cân nhắc tất cả các lựa chọn của mình và họ thực sự tin rằng việc thực hiện khác sẽ cải thiện chất lượng sản phẩm của họ.

Như với hầu hết các câu hỏi, câu trả lời không bao giờ là "yea hay nay", đen hay trắng. STL phù hợp với một số vấn đề, sử dụng nó cho những vấn đề đó sẽ ổn. Thật sai lầm khi cho rằng nó vô dụng, nhưng cũng là một sai lầm khi cho rằng nó phù hợp để sử dụng trong mọi tình huống.

Vấn đề lớn nhất cần chú ý khi sử dụng STL trong phát triển trò chơi là phân bổ bộ nhớ. Các nhà phân bổ mặc định của STL dường như không phù hợp với các chiến lược phân bổ ưa thích để phát triển trò chơi. Tất nhiên các cấp phát tùy chỉnh có thể được sử dụng, nhưng điều này làm cho toàn bộ ý tưởng bớt hấp dẫn hơn nếu bạn đang cân nhắc có nên thêm STL vào một cơ sở mã không STL hay không.

Thêm vào đó là nếu cơ sở mã của bạn không phải là STL, bạn có thể không có ai đủ quen thuộc với STL hoặc các khái niệm mẫu để triển khai các cấp phát tùy chỉnh một cách chính xác.

Tôi nghĩ rằng cuộc thảo luận này có thể được tóm tắt như sau:

mã ứng dụng được viết một cách tầm thường <mã mục đích chung được viết tốt <mã dành riêng cho ứng dụng được viết tốt

Bất cứ ai có giải pháp trồng tại nhà sẽ rơi vào loại 3 chắc chắn biết câu trả lời cho câu hỏi ban đầu cho vấn đề cụ thể của họ. STL rơi vào loại 2. Vì vậy, đối với người cần đặt câu hỏi, " tôi có nên sử dụng STL không", câu trả lời có lẽ là có.

STL hoàn toàn phù hợp để sử dụng trên PC, bởi vì hệ thống bộ nhớ ảo tiên tiến của nó cho thấy nhu cầu phân bổ bộ nhớ cẩn thận ít quan trọng hơn một chút (mặc dù người ta vẫn phải rất cẩn thận). Trên bảng điều khiển, với các thiết bị bộ nhớ ảo bị hạn chế hoặc không có bộ nhớ cache cắt cổ, bạn có thể không muốn viết các cấu trúc dữ liệu tùy chỉnh có thể dự đoán và / hoặc hạn chế phân bổ bộ nhớ. (Và bạn chắc chắn sẽ không đi quá xa khi làm điều tương tự trong một dự án trò chơi trên PC.)

Tôi nghĩ rằng câu hỏi này thực sự là một câu hỏi không có nội dung lớn hơn - tôi có nên sử dụng X trong Y của mình không? Và cách duy nhất để thực sự trả lời đó là thử nó cho chính mình. Đối với mọi người bạn thấy rằng X hoạt động rất tốt, bạn sẽ tìm thấy ai đó nói điều đó thật kinh khủng. Và cả hai đều đúng - cho dự án của họ.

Điều tuyệt vời về phần mềm, không giống như hầu hết các ngành khác, là bạn luôn có thể thay đổi mọi thứ sau này nếu bạn thấy nó không hoạt động theo cách bạn muốn. Sau này bạn phát hiện ra rằng STL không hoạt động cho bạn trong dự án này? Xé nó ra, đặt một cái gì đó khác vào vị trí của nó. Không thích cách bạn phân chia nhiệm vụ giữa các đối tượng của bạn? Cấu trúc lại. Đừng như thế mà bạn đã sử dụng các đối tượng? Thay thế chúng bằng các phương pháp C thẳng. Không thích mọi thứ được lưu trữ trong các cấu trúc và phương pháp để thao túng chúng? Thay thế chúng bằng các đối tượng C ++.

Tôi nói điều này với STL. Lý do của tôi khá đơn giản:

1. Bạn không cần STL để viết trò chơi. Thậm chí không lớn.
2. STL làm tăng đáng kể thời gian biên dịch của bạn.
3. Thời gian biên dịch lớn dẫn đến ít lần lặp hơn so với sự phát triển của bạn.

Tôi giữ số lần lặp là quan trọng nhất, vì vậy tôi chỉ cần tránh xa STL và bất kỳ kỹ thuật phát triển nào khác làm chậm các lần lặp (như kiến ​​trúc vì lợi ích của nó, hoặc các ngôn ngữ kịch bản cần được biên dịch).

Lặp đi lặp lại tốn kém dẫn đến các nhóm phát triển khổng lồ của những người đang cố gắng hoàn thành công việc với rất ít thực sự xảy ra. Tôi đã nhìn thấy nó và nghe thấy nó, và một trong những thủ phạm dường như là thời gian biên dịch cho các thư viện mẫu.