OpenGL cung cấp những lợi thế gì cho các khung / công cụ cho các nhà phát triển nhỏ? [đóng cửa]

Tôi đã nhận thấy xu hướng của các nhà phát triển độc lập tránh xa các khung và công cụ và chuyển sang sử dụng OpenGL trần hoặc sử dụng kết hợp với SDL / SFML2. Là một nhà phát triển độc lập, tôi không thể thấy OpenGL cấp thấp nào có thể cung cấp trên các công cụ hoặc khung riêng biệt.

Hầu hết các công cụ và khung công tác tốt cung cấp các chức năng mà bạn cần, và không bao giờ cản trở bạn. Họ cũng có thể mở tùy chọn để đối phó trực tiếp với OpenGL. Một số thậm chí cung cấp các chức năng để biên dịch đa nền tảng!

Tôi hiểu được khát vọng tìm hiểu những gì đang diễn ra bên dưới mui xe, nhưng tôi không thể thấy bất kỳ sự cải thiện nào mà OpenGL có thể cung cấp cho các nhà phát triển độc lập qua các công cụ hoặc khung.

Bạn có thể giải thích lý do đằng sau việc xây dựng các trò chơi từ đầu bằng cách sử dụng OpenGL không?

Đây phần lớn là một câu hỏi / câu trả lời dựa trên ý kiến, vì vậy nó thực sự không nhất thiết phải lý tưởng cho nền tảng này, nhưng dù sao đi nữa:

Tại sao không có khung / động cơ như một indie? Đây là hai xu của tôi:

• Thiếu ngân sách: Đây có lẽ là điểm lớn nhất đối với hầu hết các nhà phát triển nhỏ / độc lập. Nhiều khung hoặc động cơ sẽ không cho phép bạn xuất bản sản phẩm của mình mà không cần mua phiên bản đắt tiền hơn (giả sử có sẵn phiên bản giá rẻ hoặc miễn phí) và / hoặc trả tiền bản quyền, điều bạn sẽ luôn phải xem xét cho các dự án nhỏ. Đôi khi bạn thậm chí phải trả tiền một lần cho mỗi nền tảng.
• Độ phức tạp: Hầu hết các công cụ hoặc khung thuộc một trong hai loại:
  • Chúng hoặc rất hạn chế cho một thể loại đặc biệt ( RPG Maker là một ví dụ điển hình).
  • Hoặc đơn giản là quá chung chung với nhiều thứ mà bạn hầu như sẽ không sử dụng (như Unity ).
• Mã độc quyền: Hầu hết các công cụ không phải là nguồn mở và để có được nguồn thực tế, bạn sẽ phải trả nhiều hơn (thậm chí có sẵn). Nếu không có mã nguồn thực tế chuyển sang các nền tảng khác có thể khó hoặc thậm chí là không thể (một lần nữa, RPG Maker sẽ là một ví dụ hoàn hảo).
• Clunkyness: Đây là ý kiến ​​cá nhân của tôi, nhưng ít nhất với tôi đây thường là một sự thất vọng khá lớn khi xem xét các công cụ và khung công tác tiền chế, đặc biệt là khi bạn chỉ xây dựng một trò chơi nhỏ. Ai muốn chơi một trò chơi giải lao nhỏ có kích thước 200 KB nhưng mang lại thời gian chạy 50 MB với nó?
• Lựa chọn ngôn ngữ: Một số công cụ và khung không cung cấp thư viện để sử dụng mã của riêng bạn. Thay vào đó, họ cung cấp một khung hoặc thời gian chạy sẽ sử dụng ngôn ngữ kịch bản lệnh riêng hoặc một số ngôn ngữ được đặt (như Javascript hoặc C #). Nếu bạn đang viết công cụ tùy chỉnh của riêng mình, bạn có thể sử dụng bất kỳ ngôn ngữ nào bạn chọn.
• Bảo vệ công việc của bạn: Nếu bạn đang sử dụng một công cụ tiền chế hoặc framwork, nhiều khả năng những người khác có thể có thời gian dễ dàng hơn để thay đổi hoặc dịch ngược mã hoặc tài sản của bạn, điều gì đó bạn có thể muốn tránh (ngay cả khi chỉ để giữ điểm cao của bạn dọn dẹp). Xử lý mã và tài sản tùy chỉnh thêm một trở ngại lớn hơn nhiều, đặc biệt là khi được biên dịch thành mã gốc.
• Xây dựng thương hiệu: Điều này có thể là nhỏ đối với nhiều người, nhưng một số công cụ và khung buộc bạn phải hiển thị logo của họ hoặc thậm chí có thể là quảng cáo, về cơ bản lấy quyền tự do của bạn để chọn ai / quảng cáo. Tất nhiên, điều này thường phụ thuộc vào giấy phép thực tế, phí giấy phép, v.v.
• Không tương thích với giấy phép: Đây là điều mà nhiều người thậm chí không cân nhắc khi chọn một động cơ, nhưng tùy thuộc vào những gì bạn muốn làm, đây có thể là một yếu tố chính. Ngay cả khi bạn mua một số động cơ, bạn có thể bị hạn chế tiết lộ bất kỳ nguồn hoặc tài liệu liên quan. Một cái gì đó như thế này có thể làm cho việc sửa đổi là không thể, ngay cả khi bạn muốn người dùng có thể. Lấy công cụ Nguồn của Valve ( Half-Life 2 , Team Fortress , v.v.) làm ví dụ: Họ cho phép các modder sử dụng công cụ của họ cho các dự án của riêng họ. Nếu những trò chơi này dựa trên (ví dụ) Unreal Engine, thì điều này sẽ không thể xảy ra, do những hạn chế được quy định trong các điều khoản cấp phép.

Hầu hết các công cụ và khung công tác tốt cung cấp các chức năng mà bạn cần, và không bao giờ cản trở bạn.

Họ có làm không? Điều đó khá phụ thuộc vào chính xác những gì bạn đang làm, nói một cách đồ họa.

Đối với nhiều loại trò chơi, có câu trả lời tiêu chuẩn cho câu hỏi đồ họa. Ví dụ, trò chơi 2D trung bình có thể được xử lý tốt với khả năng 2D, ví dụ, XNA / MonoGame. Nó chỉ là các sprite, có thể đi theo đợt cho địa hình, có thể được xoay, v.v.

Nhưng điều gì sẽ xảy ra nếu trò chơi của bạn từng là trò chơi 2D trung bình, sau đó bạn đọc về một số kỹ thuật thú vị, chẳng hạn như sử dụng bản đồ chiều cao để xây dựng một kẻ mạo danh có chiều sâu so với màn hình. Và bạn muốn làm điều đó.

Bây giờ bạn đang sử dụng ánh xạ bình thường và thậm chí có thể là ánh xạ thị sai. Tất cả trong cùng một bối cảnh của "họa tiết kết xuất", nhưng đòi hỏi nhiều hơn rất nhiều công cụ 2D thuần túy có thể xử lý. Cụ thể, nó đòi hỏi "sprite blits" đa điểm, đây không phải là điều mà nhiều công cụ 2D có thể làm.

Bạn sẽ làm gì nếu động cơ của bạn không thể thích nghi với bạn? Vì vậy, điều đó có nghĩa là bạn phải thực hiện nhiều đường chuyền, một cho màu sắc và một cho ánh sáng thông qua bản đồ bình thường. Nhưng điều đó không hiệu quả, bởi vì bạn cần trường chiều cao của bản đồ bình thường để sử dụng ánh xạ thị sai cho việc tra cứu màu. Thế bây giờ thì thế nào? Bạn cần alpha để minh bạch, vì vậy bạn không thể đánh cắp alpha. Và động cơ không hỗ trợ đa điểm.

Vì vậy, bạn phải chọn một trong những điều sau đây:

1. Từ bỏ ý tưởng. Điều này có nghĩa là trò chơi của bạn bị giới hạn chức năng bởi công cụ của bạn.
2. Hack động cơ để có đa điểm. Giả sử bạn có quyền truy cập vào mã nguồn, bây giờ bạn đang tự mình lấy nó để chọc vào mã của người khác. Điều này cũng có nghĩa là bạn cần duy trì nó và không phá vỡ nó với vấp ngã của bạn.
3. Làm tốt nhất có thể, trong giới hạn của động cơ. Vì vậy, bạn có thể có thị sai trên các bản đồ bình thường, nhưng không phải trên màu sắc. Nó có thể không chính xác như những gì bạn muốn, nhưng tốt hơn là không có gì.

Chỉ là một ví dụ, lấy Geometry Wars. Hầu hết các công cụ 2D sẽ hút các loại hình ảnh này, vì hầu hết chúng được xây dựng xung quanh vẽ các họa tiết, không phải đường kẻ. Đó là một trò chơi cần một loại trình kết xuất rất chuyên dụng.

Vào cuối ngày, bạn cần chịu trách nhiệm về các yếu tố của trò chơi quan trọng đối với nhu cầu của trò chơi. Nếu giao diện trực quan của trò chơi của bạn chủ yếu được phát triển bởi phong cách nghệ thuật của hình ảnh và mô hình bạn sử dụng, thay vì hiệu ứng cụ thể, thì sử dụng giải pháp đóng gói sẵn là ổn. Nhưng nếu phong cách hình ảnh của trò chơi của bạn được xác định đáng kể bằng mã kết xuất tùy chỉnh, tỷ lệ cược tốt là một công cụ tiêu chuẩn có thể trở thành một giới hạn nghiêm trọng nếu bạn quyết định làm những việc bên ngoài hộp.

Hơn nữa, có một vấn đề rất thực tế: không phải tất cả các công cụ trò chơi đều có thể di động như nhau.

Với sự phát triển gần đây của các nền tảng di động, thị trường trò chơi được trải rộng trên nhiều thiết bị giao diện người dùng và hệ điều hành. Không phải tất cả các động cơ làm việc trên tất cả các thiết bị. Và nếu công cụ của bạn không hoạt động trên nền tảng, bạn chắc chắn sẽ không dành thời gian để làm cho nó hoạt động trên một nền tảng . Rốt cuộc, đó là lý do tại sao bạn sử dụng một động cơ ở nơi đầu tiên, phải không?

Nếu điều quan trọng với bạn là trò chơi của bạn hoạt động trên một nền tảng cụ thể, thì bạn lại cần phải chịu trách nhiệm về nó. Và cách "dễ nhất" để đảm bảo thành công với việc này là tự làm. Để xây dựng một công cụ có thể hoạt động trên nhiều nền tảng, có lẽ sử dụng các khung cụ thể nền tảng đơn giản hơn khi cần xử lý một số chi tiết cấp thấp. Theo cách đó, nếu nó bị hỏng, đó là mã của bạn; bạn là người tốt nhất để có thể sửa nó.