Viết công cụ trò chơi từ đầu với OpenGL [đã đóng]

Đóng cửa. Câu hỏi này không đúng chủ đề . Nó hiện không chấp nhận câu trả lời.

Bạn muốn cải thiện câu hỏi này? Cập nhật câu hỏi để nó thuộc chủ đề cho Trao đổi ngăn xếp phát triển trò chơi.

Đóng cửa 6 năm trước .

Tôi muốn bắt đầu viết công cụ trò chơi của mình từ đầu cho mục đích học tập, điều kiện tiên quyết là gì và làm thế nào để làm điều đó, ngôn ngữ lập trình và những thứ bạn giới thiệu cho tôi là gì? Ngoài ra nếu bạn có những bài báo và sách hay về điều đó thì sẽ rất tuyệt. Cảm ơn trước!

Các ngôn ngữ và công cụ lập trình của tôi là:

C / C ++ có tốt không khi chỉ sử dụng C?
Con trăn
OpenGL
Git
GDB

Những gì tôi muốn học hỏi từ nó:

Công cụ trò chơi cốt lõi
Kết xuất / Đồ họa
Chơi / luật chơi
Đầu vào (bàn phím / chuột / bộ điều khiển, v.v.)

Trong kết xuất / Đồ họa:

3D
Bóng
Thắp sáng
Hoạ tiết

c++ c

— Wazery
nguồn

Hai điểm: câu hỏi này, vì nó là, quá rộng. Bạn muốn hỗ trợ những tính năng nào, bạn muốn hỗ trợ nền tảng nào, bạn muốn khám phá những mô hình nào, bạn muốn đặt bao nhiêu trách nhiệm vào một ngôn ngữ kịch bản (nếu có) và một loạt các điều khác tôi m sẽ không bận tâm tiếp tục liệt kê ra.

— Tetrad

Hai: Có một sự khôn ngoan phổ biến rằng những người khác sẽ nói rằng bạn không nên tập trung vào việc tạo ra một động cơ mà không có trò chơi. Một công cụ không có trò chơi có nghĩa là bạn không thể chứng minh công cụ của mình hữu ích . Động cơ tốt đòi hỏi mọi người phải ăn thức ăn cho chó của họ, như nó đã được. Một thường liên kết đến blog đi vào chi tiết của lập luận này là ở đây: scientificninja.com/blog/write-games-not-engines

— bộ bốn

^ Không chỉ vậy, nhưng việc viết một công cụ không có trò chơi để thúc đẩy các yêu cầu tính năng dẫn đến tính năng creep và thiết kế API xấu. Cho đến khi bạn biết những gì bạn cần, được gợi ý bởi các yêu cầu trò chơi, bạn có thể không đưa những thứ hữu ích vào công cụ của mình. Tương tự như vậy, nếu bạn không phải sử dụng công cụ để lập trình, bạn có thể thấy một số quyết định của mình thực sự khó hiểu.

— ChrisE

Tôi không thấy điểm trong danh sách của bạn. Thực tế bạn biết C / C ++ và Python giúp chúng tôi, nhưng tại sao lại liệt kê rằng bạn có thể sử dụng kiểm soát phiên bản và trình gỡ lỗi?

— Vịt Cộng sản

@TheCransistDuck: Này, tốt hơn một số nhà phát triển. :)

— ChrisE

Câu trả lời:

Bạn có thể viết một công cụ trò chơi bằng thực tế bất kỳ ngôn ngữ nào bằng cách sử dụng thực tế bất kỳ phương pháp kết xuất nào. Bạn có thể viết một công cụ trò chơi trong bash bằng cách sử dụng đầu ra giao diện điều khiển chẳng hạn.

Vì vậy, tôi nghĩ sẽ tốt nhất khi xác định chính xác những gì bạn muốn học bằng cách viết công cụ của riêng bạn. Có rất nhiều "lĩnh vực" trong phát triển trò chơi.

Công cụ trò chơi cốt lõi
Kết xuất / Đồ họa
AI
Mạng
Chơi / luật chơi
Âm thanh
Đầu vào (bàn phím / chuột / bộ điều khiển, v.v.)

vv .. Từ đó bạn thậm chí có thể có chủ đề phụ. Trong kết xuất / Đồ họa

2d hay 3d?
Làm người mẫu
Bóng
Thắp sáng
Hoạ tiết
GUI / Huds / Giao diện.
Vân vân

Chỉ cần một trong những chủ đề phụ đó có thể ăn hết nhiều giờ (hoặc nhiều năm!) Của nghiên cứu!

Vì vậy, trước tiên hãy xác định những gì bạn muốn học. Bắt đầu đơn giản.

Sử dụng bất kỳ ngôn ngữ nào bạn cảm thấy thoải mái - mặc dù một số ngôn ngữ phù hợp hơn cho một số nhiệm vụ nhất định. Ví dụ, công cụ cốt lõi và kết xuất có thể được thực hiện tốt nhất với ngôn ngữ cấp "thấp hơn" như C / C ++ (nếu bạn cần hiệu suất đó); nhưng một cái gì đó như AI hoặc Quy tắc trò chơi có thể được thực hiện tốt hơn bằng ngôn ngữ cấp cao hơn. Không có gì nói rằng bạn không thể trộn và kết hợp. Bạn có thể viết công cụ của mình bằng C ++, kết xuất của bạn bằng C (vì nó hoạt động tốt với OpenGL) và sau đó sử dụng LUA để viết kịch bản Quy tắc trò chơi của bạn, v.v.

Theo như ví dụ, có một công cụ trò chơi tên là Slick2D. Nó được viết bằng Java và là nguồn mở. Đây là một ví dụ về động cơ 2d đơn giản được viết và thiết kế thực sự tốt. Bạn có thể tìm hiểu các khái niệm cơ bản từ đó, như vòng lặp trò chơi, quản lý trạng thái trò chơi, v.v.

Nếu bạn cảm thấy thoải mái với C / C ++; Tôi sẽ đề nghị xem qua SDL / OpenGL. Nó xử lý một số công việc vệ sinh như đầu vào, âm thanh, tạo cửa sổ, vv và có thể tập trung vào những thứ khác.

— người dùng697111
nguồn

Ahh những ngày khi tôi học C ++ và các trò chơi trên console rất thú vị ... [tạo dự án giao diện điều khiển mới ...]

— Nick Bedford

Tôi đã cập nhật câu hỏi của mình, hy vọng sẽ cung cấp cho tôi nhiều tài nguyên tuyệt vời :)

— Wazery

SDL + OpenGL là một lựa chọn tuyệt vời để khởi động một công cụ trò chơi tùy chỉnh.

Cá nhân tôi sử dụng phiên bản C-ish của C ++ vì tôi phát hiện ra rằng nó hoạt động tốt nhất với tôi. Điều đó có nghĩa là tôi không sử dụng bất kỳ trường hợp ngoại lệ. Có hai lý do cho điều đó: ngoại lệ đầu tiên và quan trọng nhất yêu cầu mã an toàn ngoại lệ trong suốt quá trình mà với OpenGL và SDL không thực sự dễ dàng đạt được. Tuy nhiên, quan trọng hơn là cách này rất dễ để lộ các đối tượng C ++ qua C ABI, điều này rất hữu ích nếu bạn cố gắng đưa một ngôn ngữ kịch bản vào hỗn hợp.

Tôi ở trong một chiếc thuyền tương tự như bạn và tôi đã viết ra một số cuộc phiêu lưu của mình với SDL và OpenGL trong một blog ( imersedcode.org ) trong trường hợp người khác quan tâm.

Đối với kiến trúc chung, tôi có hai gợi ý: nếu bạn muốn có một công cụ 3D, hãy xem cuốn sách "Kiến trúc công cụ trò chơi" của Jason Lander. Nếu tất cả những gì bạn muốn là 2D, hãy giữ thiết kế đơn giản nhất có thể và để bản thân truyền cảm hứng cho XNA hoặc các dự án khác.

Cuối cùng: không gọi OpenGL ở mọi nơi. Tự mình làm và tách nó thành một vài nơi để bạn có khả năng chuyển đổi giữa OpenGL / OpenGL ES trên máy tính để bàn hoặc thậm chí DirectX ở một thời điểm sau nếu bạn muốn.

— Armin Ronacher
nguồn

Không sử dụng C trừ khi một chi tiết triển khai giữ bạn ở vị trí đó. Mặt khác, sử dụng C ++, vì nó sử dụng ngôn ngữ có khả năng rộng lớn hơn và bạn luôn có thể chọn không sử dụng các khả năng đó sau này. Cá nhân tôi không có gì cho / chống lại Python, tôi chưa bao giờ sử dụng nó.

Tôi không khuyến nghị OpenGL chống lại DirectX vì DX có cách tiếp cận hướng đối tượng hiện đại, rõ ràng hơn và dễ hiểu hơn / ít bị lỗi hơn. Giao diện được cung cấp bởi OpenGL là cực kỳ kém so với.

Điều cuối cùng tôi nhận được là tôi đã nghe từ nhiều người Tôi tin rằng GDB hoàn toàn, cực kỳ tệ và trình gỡ lỗi Visual Studio là điều tốt nhất. Đây không phải là kinh nghiệm cá nhân của tôi vì vậy hãy dùng nó với một chút muối.

— DeadMG
nguồn

"OpenGL so với DX". Thực tế là DirectX nhiều OO không thực sự quan trọng. Theo như dễ hiểu hơn ... OpenGL (trước 3) cho thấy một giao diện khá đơn giản và một giao diện dễ quét vì tất cả đều theo phương pháp mệnh lệnh kiểu C. "Đặt ma trận chiếu thành này. Bắt đầu các tam giác. Đây là một đỉnh. Đây là một đỉnh. Đây là một đỉnh. Kết thúc các tam giác." Chuỗi API OpenGL 1.x rất tốt cho việc bạn bị ướt trong lập trình đồ họa và kết hợp với SDL (hoặc thậm chí GLUT ... khẩn cấp) cho phép bạn có được một ứng dụng với 30-50 dòng mã.

— ChrisE

@ChrisE: Chắc chắn rồi. Có một cái gì đó được gọi extern "C"và việc sử dụng phù hợp làm cho việc viết giao diện C trở nên tầm thường - đặc biệt đối với Python, nơi trình chuyển đổi tồn tại trong Boost giúp việc liên kết với nó trở nên dễ dàng. Làm thế nào về các tính năng ngôn ngữ C ++? Họ thật tuyệt . Việc sử dụng nhiều hơn các tính năng ngôn ngữ của C ++ làm tăng độ tin cậy của dự án và dễ dàng mã hóa ồ ạt để đánh đổi hiệu suất rất nhỏ có thể chấp nhận được. Các tính năng ngôn ngữ của C là thảm hại trong so sánh. Ví dụ, việc sử dụng đúng trình biên dịch C ++ hiện đại có thể đảm bảo không bị rò rỉ bộ nhớ. Làm điều đó trong C.

— DeadMG

@DeadMG: Nếu OOP thực sự là một vấn đề lớn, thì câu trả lời ở đây là Java hoặc C # chứ không phải C ++. Điều tôi không đồng ý là việc sử dụng các tính năng C ++ không làm cho mã của bạn trở nên tốt hơn, nhanh hơn hoặc thậm chí đáng tin cậy hơn; bạn phải biết cách sử dụng các tính năng đó và học một ngôn ngữ ngoài việc thiết kế một công cụ có thực sự sử dụng tốt thời gian của một người không? Không. Không phải cho ai đó làm điều này lần đầu tiên. Bạn có thể học tất cả C trong một hoặc hai ngày, một cách thoải mái, và không bao giờ tự hỏi ngôn ngữ đang làm gì. OpenGL, bộ cuộc gọi cơ bản hữu ích ở mọi mức giá, cung cấp độ trong suốt như nhau.

— ChrisE

OOP không phải là vấn đề lớn, không phải trong các công cụ trò chơi hiệu suất cao. Chắc chắn nó hữu ích, nhưng nó thường là sự trừu tượng sai. Có lưu lượng dữ liệu tốt, địa phương và bố trí bộ nhớ thường tốt hơn. Mặc dù nhiều đội đang sử dụng C ++, nhưng họ không sử dụng hầu hết các tính năng của C ++. Không có ngoại lệ, càng ít ảo càng tốt, không RTTI, không STL / Boost. Tại sao? Dự đoán và thực hiện nhanh chóng và mã nhỏ trên nhiều nền tảng. Tôi viết mã bằng C và chỉ có hai lĩnh vực mà tôi muốn sử dụng C ++: khóa có phạm vi và mảng chung. Không đáng để IMHO rắc rối.

— khoảng trống

Trên GL so với D3D: Không có ngăn xếp ma trận trong lõi GL3 / 4 và không có ngăn xếp attrib. Cả GL và D3D ánh xạ vào cùng một kiến trúc phần cứng, nhưng rất nhiều thời gian GL cảm thấy mỏng hơn. Chắc chắn máy trạng thái GL có một chút rắc rối, nhưng phần cứng thực tế cũng vậy;) Học bất kỳ trong số chúng là tốt, và miễn là bạn hiểu điều gì đang thực sự xảy ra, bạn có thể dễ dàng chuyển sang cái khác (hoặc API bảng điều khiển).

— khoảng trống