2014-11-20 23 views
9

Tôi là nhà phát triển trò chơi độc lập làm việc trên nền tảng Windows, nhưng tôi thực sự ít có kinh nghiệm với Linux và triển khai ứng dụng cho nó. Tôi đang đánh bóng trò chơi của mình được viết bằng C++ '11 dựa trên SDL 2.0 với một số phụ thuộc nền tảng khác (như AngelScript hoặc PugiXML) trên Windows và tôi cũng muốn phân phối nó trên Linux và có một vài câu hỏi về điều đó. Trò chơi là nguồn đóng thương mại, hiện đang có trên GreenLite của Steam, nhưng tôi muốn phân phối phiên bản alpha miễn phí có thể tải xuống từ trang web của tôi bất kể trạng thái GreenLite.Triển khai trò chơi C++ trong Linux

1.) Các bản phân phối Linux chính ABI (giao diện nhị phân ứng dụng) có tương thích không? Hoặc tôi có cần biên dịch trò chơi của mình trên mọi nền tảng/phân phối được hỗ trợ không?

2.) Nếu có, phân phối/nền tảng nào là lựa chọn hợp lý để hỗ trợ?

3.) Cách tốt nhất để cài đặt ứng dụng và phụ thuộc vào Linux là gì? Tôi đã đọc về các hệ thống deb và rpm, nhưng nó vẫn còn khó hiểu - có cách nào để tự động tạo các gói cài đặt cho các bản phân phối khác nhau không?

4.) Steam hoạt động như thế nào với Linux? Tôi nên chuẩn bị ứng dụng của mình để phân phối thông qua nó như thế nào?

Xin lỗi nếu tôi đặt câu hỏi sai, toàn bộ thế giới của Linux là khá mới mẻ với tôi và tôi đã bị mất đọc nhiều bài báo và trang hướng dẫn ...

Trả lời

2
  1. Điều này phụ thuộc vào phân phối từ. Nói chung, không cần phải biên dịch lại một chương trình trên một cái gì đó như Ubuntu dưới Fedora, miễn là mã vẫn không thay đổi. Vì Ubuntu và Fedora sẽ phải sử dụng cùng một thư viện (mặc dù ở các địa điểm khác nhau có lẽ) và bất kỳ thứ gì liên quan đến OpenGL sẽ là vấn đề trình điều khiển; do đó, nó không phải là một yêu cầu để biên dịch lại phần mềm của bạn. Tôi sẽ vô cùng ngạc nhiên nếu bạn phải biên dịch lại phần mềm của bạn vì tất cả các bản phân phối đều sử dụng khá nhiều thư viện/bash/sử dụng hạt nhân Linux nhưng có trình quản lý gói khác nhau. Phần cuối cùng là nơi nó trở nên phức tạp:

  2. Các bản phân phối nói trên có các trình quản lý gói khác nhau yêu cầu bạn đóng gói lại phần mềm của bạn cho phù hợp. Bạn có thể phát hành các tệp nhị phân được biên dịch trước dưới một tệp tar.gz và chỉ đơn giản là có các trình bảo trì phân phối gói phần mềm cho bạn; mặc dù nếu bạn muốn kiểm soát cách phần mềm của bạn được phân phối thì bạn nên tự làm điều đó tốt hơn. Vì vấn đề này bao quanh nhiều người quản lý gói, nên mọi người vẫn phải sử dụng để biên dịch lại mã nguồn thông qua một tệp tạo ra có thể được tạo ra thông qua cmake. Điều này chỉ xảy ra nếu một số phụ thuộc nhất định, vì bất kỳ lý do gì, 'đổi tên' trong trường hợp này vì một tên đơn giản thay đổi chương trình một cách kỳ diệu không tìm thấy sự phụ thuộc. Vì cũng không có quy ước đặt tên, nó thậm chí còn làm cho cuộc sống khó khăn hơn. Nhân đức quan trọng nhất ở đây là sự tin tưởng, và tin tưởng trong đó có các nhà phát triển theo các quy ước đặt tên để mọi người có thể tham khảo cùng một gói cùng tên.

Bản phân phối tốt nhất để hỗ trợ là những bản phổ biến nhất: Ubuntu và openSUSE sẽ là điểm khởi đầu tuyệt vời. Linux Mint, Fedora và Red Hat và Debian sử dụng các trình quản lý gói tương tự như trên.

  1. Trong khi đó, bạn nên biết rằng bạn không thể liên kết tĩnh mã GPL trong phần mềm của bạn mà không làm cho phần mềm của bạn cũng GPL. Một cách để làm việc vòng này là để giải quyết các phụ thuộc bằng cách: A. Bao gồm các phụ thuộc có liên quan trong cùng thư mục với tệp thực thi (giống như * .dll trên Windows) hoặc phụ thuộc vào hệ thống mà chương trình của bạn chạy để xem bên trong các thư mục tương tự mà chương trình của bạn xem xét trong khi biên dịch và liên kết. Cái thứ hai thực sự rủi ro hơn vì nó mang giả định rằng người dùng sẽ có các thư viện và chưa sửa đổi. Trước đây sẽ làm cho phần mềm tổng thể của bạn sử dụng ít dung lượng hơn, nhưng bao gồm các phụ thuộc sẽ chỉ có nghĩa là tăng kích thước của gói của bạn nhưng đảm bảo tính nhất quán trên tất cả các hệ thống.

Để cài đặt, bạn sẽ cần một tệp thực thi bash di chuyển nội dung của thư mục của bạn đến đúng vị trí. Nói chung, ứng dụng chính đi vào/usr/bin và mọi dữ liệu liên quan đến ứng dụng sẽ chuyển vào thư mục chính. Điều này một lần nữa phụ thuộc vào distro; tìm một .thư mục cục bộ hoặc bạn có thể tạo thư mục dành riêng cho ứng dụng bị ẩn. Thư mục ẩn được đặt trước bằng dấu chấm. Tại sao đặt công cụ này vào thư mục chính và cái gì? Lý do: vì thư mục chính cho phép đọc và ghi cho mọi người theo mặc định. Cái gì: bất cứ thứ gì cần được chạy với ứng dụng mà không cần người dùng phải ủy quyền nó. Do đó, các phụ thuộc nên được đặt trong thư mục chính, tốt nhất là trong thư mục riêng của bạn. Các công ước khác nhau tuân theo; một số có thể không đồng ý với tôi về điều này.

Bạn cũng có thể muốn sử dụng API của hơi nước mà phần lớn công việc này dành cho bạn. Dưới Steam, ứng dụng của bạn có thể nằm trong thư mục riêng của hơi nước và do đó hoạt động như một APP hơi nước với tất cả các chức năng trong đó.

http://www.steampowered.com/steamworks/

Để tìm hiểu thêm về cách để có được ứng dụng của bạn trên hơi. Tôi phải nói rằng tôi đã thực sự ấn tượng, và họ thậm chí còn bao gồm các mẫu mã. Phần tốt nhất là API này cũng có trên Linux. Tôi không biết nhiều hơn rằng hơi nước sẽ được xử lý việc thực hiện các ứng dụng của bạn thông qua các lớp riêng của mình. Trong đó, không cần phân phối độc lập ứng dụng của bạn các bước trước đó.

Lưu ý rằng bạn cũng có thể phân phối phần mềm của mình thông qua Trung tâm phần mềm Ubuntu nếu bạn quan tâm.

http://developer.ubuntu.com/apps/

Mặc dù, Ubuntu đã tập trung hơn vào việc ứng dụng đang chạy bất kể nền tảng.

Biết rằng Linux không có quy ước duy nhất, nhưng quy ước của nó đơn giản bắt nguồn từ chủ nghĩa thực dụng, không phải theo lý thuyết. Vào cuối ngày, cách bạn muốn phần mềm chạy trên Linux tùy thuộc vào bạn.

+0

Cảm ơn bạn, đây là câu trả lời hay nhất ở đây - chỉ một câu hỏi nữa: nếu tôi lưu trữ các phụ thuộc trong thư mục 'home', thì chúng có sẵn cho tất cả người dùng không? Nếu các tài sản được lưu trữ trong 'nhà' là tốt? – PiotrK

4

Tôi không phải là một nhà phát triển trò chơi và tôi đến từ cộng đồng nguồn mở vì vậy không thể thực sự tư vấn về việc phân phối các tệp nhị phân. Tuy nhiên, tôi sẽ cố gắng trả lời một số câu hỏi của bạn:

Van có thời gian chạy hơi nước mà bạn có thể nhắm mục tiêu trên linux (https://github.com/ValveSoftware/steam-runtime) - đây là cách tốt nhất để chuyển trò chơi của bạn. Tôi thấy nó được đề cập trong một trong các video dev của họ trên youtube, sự hiểu biết của tôi là nó bó một loạt các thư viện inclding SDL và nó được thiết lập để mô phỏng một phiên bản cụ thể của ubuntu. Vì vậy, nếu bạn viết trò chơi của bạn chống lại thời gian chạy hơi nước nó sẽ chạy trong bất kỳ distro Linux mà hơi nước đã được chuyển quá.

Đối với việc đóng gói nguyên bản, trò chơi của bạn cần phải xem xét nếu bạn gói nó thành deb hoặc RPM và hướng dẫn nó phụ thuộc vào bản phân phối được cung cấp. - những người khác ổn định hơn). Liên kết động với các thư viện hệ thống hoạt động tốt với nguồn mở vì mọi người có thể vá mã khi các thay đổi về libraies không lý tưởng cho các công cụ có nguồn gốc gần gũi.

Bạn có thể liên kết tĩnh nhị phân của bạn tại thời gian xây dựng, có nghĩa là bạn có một tệp nhị phân có kích thước lớn hơn. Nhưng hơn bạn không phải lo lắng về việc phá vỡ ứng dụng khi cập nhật lib.

Một số chương trình như Chrome bó libs riêng của chúng (điều này về cơ bản là nhánh của libs hệ thống) lại khiến kích thước tải xuống lớn hơn nhiều nhưng cũng có khả năng gây ra sự cố bảo mật, mọi người có xu hướng cau mày về điều này. (xem: http://lwn.net/Articles/378865/)

+0

Tôi không thể liên kết tĩnh mọi thứ, bởi vì một số phụ thuộc của tôi dưới GPL – PiotrK

+0

Bạn có thể gộp libs (Nhưng bạn cần cung cấp mã nguồn cho libs GPL'd mà bạn bó - hoặc ít nhất là liên kết vào nguồn). Hoặc bạn có thể tự động liên kết đến các hệ thống libs và chấp nhận vỡ có thể xảy ra tại một số điểm trong tương lai. Người hoài nghi trong tôi nghi ngờ sẽ dễ dàng hơn nhiều nếu bạn mở nguồn trò chơi của mình - bạn đã sử dụng các thư viện nguồn mở sau tất cả. – Matt

+0

@PiotrK nếu libs của bạn là GPL, mã của bạn bây giờ là quá; bạn có thể liên kết với mã LGPL mà không cần mở mã của bạn nhưng mã GPL * yêu cầu * mã của bạn cũng là GPL (hoặc bạn đạt được một thỏa thuận cấp phép thay thế với các tác giả của libs). –

1

1.) Không, ABI của bản phân phối Linux chính không hoàn toàn tương thích. Theo nghĩa hẹp, chúng là chủ yếu là tương thích. Nhưng theo nghĩa rộng hơn, có nhiều khác biệt trong đó một số yếu tố của hệ thống hoạt động, được cấu hình, vv .., OTOH, làm cho "gói" không phải là một vấn đề lớn trênse, chỉ một số công việc. Ngoài ra, những gì làm việc cho một phân phối "lớn" (như Debian) hoạt động (khá nhiều luôn luôn) trên tất cả các dẫn xuất (như Ubuntu, Mint ...).

2.) Danh sách bắt đầu tốt để hỗ trợ là: Debian (.deb), RedHat và Fedora (.rpm cả hai). Các định dạng và công cụ đóng gói của họ đã trưởng thành và nổi tiếng.Điều này sẽ "che" rất nhiều dẫn xuất.

3.) Có một số nhà xây dựng gói "phân phối chéo", nhưng chủ yếu là không làm nhiệm vụ. Viết một kịch bản định nghĩa cho hầu hết các định dạng gói không phải là khó, một khi bạn nhận được một hang của nó. Ngoài ra, một số công cụ thương mại có "Trình tạo tập lệnh cài đặt" cho Linux, công cụ này sẽ xử lý mọi thứ cho bạn (chúng không tạo ra .deb hoặc .rpm, thay vì tập lệnh shell phức tạp, tương tự như trình cài đặt Windows EXE)

4 .) Xin lỗi, tôi không biết nhiều về Steam. Vì vậy, từ kinh nghiệm của tôi, cách tốt nhất để làm điều đó là chấp nhận sự thật xấu xí mà bạn phải chọn một vài bản phân phối chính phiên bản của chúng (vì mọi thứ có thể thay đổi rất nhiều giữa các phiên bản). và làm các gói cho chúng, và kiểm tra thường xuyên trên tất cả chúng. Và vui mừng khi bạn không phát triển một số module/trình điều khiển hạt nhân tồn tại lâu dài, vì nếu bạn thêm các thay đổi API hạt nhân theo dõi vào toàn bộ hình ảnh ... :)

Các vấn đề liên quan