Phát triển độc lập đa nền tảng


34

Cách đây vài năm, nếu bạn đã viết bằng C và một số tập hợp con của C ++ và sử dụng đủ số lượng trừu tượng nền tảng (thông qua SDL hoặc bất cứ thứ gì), bạn có thể chạy trên mọi nền tảng mà một phiên bản độc lập có thể có trên - Linux, Windows, Mac OS của các phiên bản khác nhau , những thứ tối nghĩa như BeOS và các bảng điều khiển mở như GP2X và Dreamcast sau khi chết. Nếu bạn có hợp đồng cho một nền tảng đóng tại một số thời điểm, bạn có thể chuyển trò chơi của mình sang nền tảng đó với các thay đổi mã "tối thiểu".

Ngày nay, các nhà phát triển độc lập phải sử dụng XNA để có được trên Xbox 360 (và điện thoại Windows sắp ra mắt); không được sử dụng XNA để làm việc ở bất kỳ nơi nào khác ngoài Windows; cho đến gần đây đã phải sử dụng Java trên Android; Flash không chạy trên điện thoại, HTML5 không hoạt động trên IE. Không giống như DirectX so với OpenGL hoặc Windows so với Unix, đây là những thay đổi đối với ngôn ngữ cốt lõi mà bạn viết mã của mình và không thể viết ra mà không có, về cơ bản, viết một trình biên dịch. Bạn có thể chuyển một số logic trò chơi thành tập lệnh và bao gồm trình thông dịch - ngoại trừ khi bạn không thể, vì SDK iPhone không cho phép và hiệu suất bị ảnh hưởng vì không ai cho phép JIT.

Vì vậy, bạn có thể làm gì nếu bạn muốn một trò chơi di động đa nền tảng thực sự, hoặc thậm chí chỉ là một cơ thể quan trọng của mã động cơ và mã logic?

Đây có phải là vấn đề không vì các nền tảng đã bị phân tán một cách cơ bản - thật không đáng để cố gắng nhắm mục tiêu cả iPhone và Xbox 360 với bất kỳ mã được chia sẻ nào vì một trò chơi như vậy sẽ rất tệ? (Tôi thấy điều này rất khó xảy ra. Tôi có thể dễ dàng thấy muốn chia sẻ một trò chơi giữa điện thoại Windows Mobile và Android, hoặc Xbox 360 và iPad.) Các giao diện có mức độ cao đến mức thời gian chuyển không đáng kể? (Tôi có thể tin điều này cho các ứng dụng kinh doanh, nhưng không phải cho các trò chơi có yêu cầu hiệu năng nghiêm ngặt.)

Điều này sẽ trở nên rõ rệt hơn trong tương lai? Là sự phân chia sẽ được, phần nào đáng sợ, vẫn xuống dòng nhà cung cấp? Tất cả chúng ta sẽ dựa vào phần mềm trung gian cấp cao như Flash hay Unity để hoàn thành mọi thứ đa nền tảng chứ?

tl; dr - Có phải là một vấn đề, nó sẽ là một vấn đề lớn hơn trong tương lai, và nếu vậy làm thế nào để chúng ta giải quyết nó?


2
Mục 3.3.2 của Thỏa thuận cấp phép chương trình dành cho nhà phát triển iPhone cho phép tạo kịch bản trò chơi ngay bây giờ, mặc dù nó vẫn hơi phức tạp. - "Mặc dù đã nói ở trên, với sự đồng ý trước bằng văn bản của Apple, Ứng dụng có thể sử dụng mã được giải thích nhúng theo cách hạn chế nếu việc sử dụng đó chỉ nhằm cung cấp các tính năng hoặc chức năng nhỏ phù hợp với mục đích được quảng cáo và dự định của Ứng dụng."
Bachus

3
Apple đã thay đổi thỏa thuận cấp phép một lần nữa vào ngày hôm qua và kịch bản trò chơi bây giờ hoàn toàn ổn. - "Mã được giải thích chỉ có thể được sử dụng trong Ứng dụng nếu tất cả các tập lệnh, mã và trình thông dịch được đóng gói trong Ứng dụng và không được tải xuống. Ngoại lệ duy nhất ở trên là các tập lệnh và mã được tải xuống và chạy bởi khung WebKit tích hợp của Apple."
Bachus

Tôi muốn nói rằng bạn đã gộp một loạt những thứ không thuộc về nhau - thiết bị di động, bảng điều khiển, PC trò chơi dựa trên web? Máy chơi game và PC, chắc chắn, có thể chia sẻ một cơ sở mã với một số điều chỉnh. Các thiết bị di động khác nhau rất nhiều về khả năng so với phần cứng máy tính chuyên dụng (về sức mạnh đồ họa thô, lưu trữ, luồng, v.v.), và do đó bạn thậm chí không thể sử dụng các giải pháp tương tự. Và các trò chơi web, bạn biết đấy, các trang web . Bạn muốn gì? Sự phân mảnh ở đây là trên các mô hình thiết bị, không chỉ là kiến ​​trúc tính toán.
ChrisE

Thật ra tôi không nói gì về game trên web. Tôi nghĩ thật hợp lý khi muốn chạy một số mã giống nhau trên tất cả các thiết bị - ánh xạ đầu vào hoặc API đồ họa trừu tượng hoặc hệ thống thực thể, phân tích tệp, mạng - tất cả đều là các mô hình cơ bản giống nhau bất kể nền tảng. Nhưng câu hỏi cũng đã được 8 tháng và xuất phát từ những lo ngại không được áp dụng nhiều vì NDK đã thu thập thêm hỗ trợ trên Android và Apple đã dừng các chính sách ngu ngốc của họ.

Ý tôi là, bạn đã đề cập đến HTML5 ... đó là loại dành cho các trò chơi web, phải không?
ChrisE

Câu trả lời:


14

Công cụ Unity giúp bạn có một đoạn lớn ở đó. Viết một lần và bạn đã dựa trên Mac / Windows Stand Độc và webplayer. Tinh chỉnh đầu vào của bạn và chú ý các cuộc gọi rút thăm của bạn và bạn đang ở trên iOS / Android.


12

Đối với một nhà phát triển độc lập nhỏ, với số tiền / thời gian hạn chế (và có thể tập trung nhiều hơn vào việc 'tạo ra thứ gì đó tuyệt vời' hơn là 'tạo ra thứ gì đó có lợi nhuận'), cố gắng đi đa nền tảng ngay từ đầu có thể phản tác dụng. Phải mất rất nhiều nỗ lực để thiết kế các công cụ và công nghệ đa nền tảng vững chắc (API đồ họa khác nhau, độ bền, thiết bị đầu vào và hơn thế nữa) - thời gian có thể dành cho khía cạnh sáng tạo hơn của phát triển trò chơi.

Nhưng bạn có thể muốn chắc chắn rằng bạn đã có một trò chơi tuyệt vời hoạt động thực sự tốt trên một nền tảng trước khi lo lắng quá nhiều về việc đưa nó lên càng nhiều nền tảng càng tốt! Nếu trò chơi là một flop, không có điểm nào lãng phí thời gian và công sức làm cho nó trở thành một flop đa nền tảng, phải không?

Nếu bạn đang mã hóa bằng C / C ++, chủ yếu là từ đầu, thì miễn là bạn giữ mã khá mô-đun và đưa ra quyết định hợp lý về định dạng dữ liệu và thư viện trung gian / thư viện, thì việc hỗ trợ các nền tảng khác sau này không quá đau đớn.

Nếu công nghệ / công cụ đa nền tảng của bên thứ ba (ví dụ Unity) là một tùy chọn cho dự án của bạn, thì chắc chắn nó đáng để xem xét.

Các 'nền tảng vấn đề' chính cho các game thủ dường như là Xbox360 Indie Games (chỉ C #, truy cập mạng hạn chế, v.v.) và có thể là Android (sự khác biệt lớn về hiệu suất thiết bị / kích thước màn hình / thiết bị đầu vào). Nếu bạn quyết tâm hỗ trợ những công việc này, hãy mong đợi một công việc chuyển mạng lớn hơn hoặc lên kế hoạch tập trung vào chúng một cách độc quyền.


Vâng, đá Unity3D. www.unity3D.com
BerggreenDK

Tôi đồng ý với @bluescrn - tốt hơn là biết hầu hết mọi thứ về hầu như không có gì, hơn là hầu như không biết gì về mọi thứ: Jack của tất cả các đặc điểm, chủ nhân của không.
Rodrigo-silveira

3

Bạn nói phát triển độc lập đa nền tảng . Rào cản lớn nhất sau đó là tài nguyên, và điều đó có nghĩa là hầu hết thời gian, nhưng cũng thiếu bí quyết và có thể là tài chính (phí giấy phép, mua thiết bị, v.v.).

Indie hay không, trở ngại lớn nhất thực sự là thiết kế. Như bạn nói, một trò chơi chạy trên Xbox360 và iPad có thể hoạt động, nhưng chúng cũng cần khác biệt về cơ bản về mặt thiết kế. 360 có bộ điều khiển, iPad có màn hình cảm ứng. Ngoài ra, việc phát triển 360 được thực hiện trong Windows bằng ngôn ngữ C #, iPad chỉ có thể được nhắm mục tiêu trên các máy tính Mac OS và sử dụng C, C ++ hoặc Objective-C. Hoặc Javascript, nếu bạn thích. Một số thứ không thể trộn lẫn bất cứ thứ gì bạn làm.

Những gì bạn nói về các nền tảng khác nhau giữ đúng ngày hôm nay. Sử dụng C / C ++ và SDL và bạn có thể viết chương trình đa nền tảng của mình trên các máy giống như PC, có thể trơn tru hơn nhiều so với nhiều năm trước. Tuy nhiên, nó luôn luôn là một vấn đề và sẽ luôn là một vấn đề đối với các game port từ PC sang console cho đến di động và ngược lại. Nó đã trở nên rõ rệt hơn trong những năm gần đây bằng cách cho phép các nhà phát triển Indie lập trình cho các hệ máy console (hoặc các nhà phát triển hack truy cập vào nó để tạo ra các trò chơi homebrew) và bằng sự phát triển của các thiết bị di động đủ mạnh để chạy các trò chơi.

Porting có những vấn đề tương tự như nó từng có, nhưng có nhiều thiết bị hơn để chuyển đến. Và một số cổng không có ý nghĩa nếu không thiết kế lại cốt lõi của trò chơi. Đây không phải là vấn đề có thể giải quyết được, đó là vấn đề bạn phải xem xét ngay từ đầu ngay cả trước khi bạn viết dòng mã đầu tiên. Sau đó, nó sẽ được quản lý, không hơn, không kém.


Trên thực tế, tôi muốn nói rằng thời gian để chuyển là một điều mà một nhà phát triển / nhóm độc lập có nhiều khả năng có hơn một studio do nhà xuất bản lớn điều khiển.

Có rất nhiều thiết kế trò chơi có ý nghĩa trên tất cả các nền tảng - ví dụ như trò chơi bảng ảo theo lượt, luôn là một điểm nhấn trên tất cả các nền tảng. Vì vậy, nhiều trò chơi câu đố khối rơi / phù hợp. Chúng thậm chí không thể được "chuyển" theo nghĩa truyền thống nữa - chuyển một trò chơi từ XBLIG sang iPhone là một bản viết lại được đảm bảo của tất cả các mã.

3

Một khung giao diện đơn giản, di động và mở là thực sự cần thiết, tôi nghĩ vậy. Một số suy nghĩ:

Hiện tại dường như có bốn loại phương thức nhập trò chơi phổ biến: Bàn phím, Chuột, Bộ điều khiển và Bề mặt cảm ứng đa điểm. (Bây giờ tôi sẽ đề cập đến các vấn đề về khả năng khác nhau giữa, ví dụ như gamepad và cần điều khiển, mặc dù điều đó cuối cùng sẽ được giải quyết.)

Lý tưởng nhất, nhà phát triển của chúng tôi sẽ có thể chỉ định một cách tổng quát một vài UI khác nhau có ý nghĩa cho loại trò chơi được viết. (Họ có thể quyết định cung cấp Giao diện người dùng Bàn phím và Chuột, Giao diện người dùng Chỉ Chuột và Giao diện người dùng Đa chạm, như một ví dụ tùy ý.)

Khung này sau đó chịu trách nhiệm trung gian IO giữa nền tảng và mã trò chơi, tương tự như cách các khung GUI đa nền tảng như chức năng QT và GTK.

Có một khung như vậy sẽ không giải quyết được vấn đề yêu cầu ngôn ngữ không tương thích, nhưng ít nhất sẽ gói gọn tất cả các cuộc gọi dành riêng cho hệ thống đằng sau một API chung, điều này sẽ giúp việc chuyển ngôn ngữ trở nên đơn giản hơn nhiều.

Chà, bây giờ tôi đã viết tất cả những điều đó: Có ai biết nếu một khung như thế đã tồn tại chưa?


3

Với các dự án như MonoTouch và XNATouch, có vẻ như XNA có thể giúp bạn có được hầu hết các nền tảng với một chút tinh chỉnh. Thật không may, Apple đã loại ngư lôi rằng khi họ thay đổi Điều khoản và Điều kiện để hạn chế ngôn ngữ nào bạn có thể sử dụng. Unity đi qua khá nhiều thứ bây giờ, mặc dù trên XBOX, nó sẽ giúp bạn có XBLA chứ không phải XBLIG, vì vậy không phải là một tùy chọn cho các indies nhỏ hơn.

Một cách tiếp cận có thể là tạo một khung sử dụng các quy ước giống nhau trên nhiều ngôn ngữ / nền tảng, sau đó chỉ là vấn đề điều chỉnh cú pháp cho các trò chơi cổng. Bạn có thể muốn khởi chạy trò chơi của mình trong Flash, có thể được phát triển nhanh chóng và tiếp cận được nhiều đối tượng, sau đó nếu nó thành công với iPhone, XNA, v.v ... Bằng cách này, bạn biết rằng bạn có một trò chơi thú vị trước khi tự mình cam kết.


Táo ngu, người hạn chế ngôn ngữ lập trình! NGƯỜI NÀO?!?!
FreshJays

2

Tôi nghĩ rằng đây là một vấn đề kinh tế, không phải là một vấn đề kỹ thuật. Các nền tảng như xbox360 có động cơ mạnh mẽ để loại trừ, bởi vì họ đang cố gắng để người dùng chọn nền tảng của họ thay vì một số nền tảng khác. "Chúng tôi có những trò chơi độc quyền thú vị này" thú vị hơn nhiều so với "chúng tôi cũng có thể chơi những trò chơi mà mọi người khác có". Hệ sinh thái bị chi phối bởi các nhà sản xuất phần cứng.

Tôi nghi ngờ điều này sẽ thay đổi khi trò chơi kết nối mạng xã hội trưởng thành, bởi vì có khả năng nhiều tiền hơn để đưa mọi người vào cùng một hệ thống chơi trò chơi xã hội hơn là tạo ra một đồ họa FPS khác với đồ họa gợi cảm.


2

Tôi mới phát hiện ra Haxe và NME . Nó tuyên bố là một ứng dụng đa nền tảng hỗ trợ tất cả các máy tính để bàn và thiết bị di động chính Flash, từ một cơ sở mã. Đáng xem.


1

Một công cụ phát triển đa nền tảng rất mới, tôi không nhất thiết phải giới thiệu nó là http://www.monkeycoder.co.nz/

Nó đánh vào mọi nền tảng mà bạn đề cập.

Mặc dù còn quá mới để thực sự phán xét, nhưng nó có một phả hệ tuyệt vời: trước đây, người tạo ra nó đã tạo ra Blitz3D và BlitzMax, những công cụ phát triển tuyệt vời cho các nhà phát triển game độc ​​lập.


0

Tôi đã gặp may mắn với SDK phát sóng - ít nhất là trên x86 và rõ ràng là nhắm mục tiêu tốt cho iPhone (mặc dù tôi vẫn chưa đưa ứng dụng lên iPhone).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.