クロスプラットフォーム独立開発


34

数年前、CおよびC ++のサブセットで記述し、十分な数のプラットフォーム抽象化(SDLなどを使用)を使用した場合、インディーが利用できるすべてのプラットフォーム(Linux、Windows、Mac OSのさまざまなバージョン)で実行できました、BeOSのようなあいまいなもの、GP2Xや死後のドリームキャストのようなオープンコンソール。ある時点でクローズドプラットフォームの契約を結んだ場合、「最小限の」コード変更でゲームをそのプラットフォームに移植することもできます。

今日、独立系開発者はXNAを使用してXbox 360(および今後のWindows Phone)にアクセスする必要があります。XNAを使用してWindows以外の場所で作業しないでください。最近までAndroidでJavaを使用する必要がありました。Flashは電話では動作せず、HTML5はIEでは動作しません。たとえばDirectXとOpenGL、またはWindowsとUnixとは異なり、これらはコードを記述するコア言語の変更であり、基本的にコンパイラを書かなければ書けません。一部のゲームロジックをスクリプトに移動し、インタープリターを含めることができます。ただし、できない場合を除きます。iPhoneSDKでは許可されないため、JITを許可しないためパフォーマンスが低下します。

本当にクロスプラットフォームのポータブルゲームが必要な場合、またはエンジンとロジックコードのかなりの部分さえ必要な場合は、どうすればよいでしょうか?

プラットフォームが根本的に分岐しているため、これは問題ではありません。共有ゲームでiPhoneとXbox 360の両方をターゲットにしようとするのは価値がありません。(これはめったにありません。WindowsMo​​bile電話とAndroid、またはXbox 360とiPadの間でゲームを共有したいということは簡単にわかります。)移植時間はごくわずかなので、インターフェイスは非常に高レベルですか。(私はこれをビジネスアプリケーションに信じているかもしれませんが、厳しいパフォーマンス要件のゲームには信じていません。)

これは将来さらに顕著になるでしょうか?分割は、いくぶん恐ろしく、ベンダーラインを下回りますか?クロスプラットフォームを実現するために、FlashやUnityのような高レベルのミドルウェアに依存するでしょうか?

tl; dr-移植は問題ですか、それは将来より大きな問題になるでしょうか?もしそうならどのように解決しますか?


2
iPhone開発者プログラム使用許諾契約のセクション3.3.2では、ゲームスクリプティングが許可されていますが、まだ少し複雑です。-上記にかかわらず、Appleの事前の書面による同意がある場合、アプリケーションの意図および宣伝目的と一致するマイナーな機能または機能を提供するためだけに使用される場合、アプリケーションは限定的な方法で埋め込み解釈コードを使用できます。
バチュス

3
Appleは昨日、ライセンス契約を再度変更し、ゲームのスクリプティングは完全に大丈夫です。-「すべてのスクリプト、コード、およびインタープリターがアプリケーションにパッケージされ、ダウンロードされていない場合、解釈されたコードはアプリケーションでのみ使用できます。上記の唯一の例外は、Appleの組み込みWebKitフレームワークによってダウンロードおよび実行されるスクリプトおよびコードです」
バチュス

モバイルデバイス、コンソール、PC、Webベースのゲームなど、所属していないものをまとめてまとめたと思いますか?確かに、コンソールとPCはコードベースを調整して共有できるはずです。モバイルデバイスの機能は、専用のコンピューティングハードウェアとは大きく異なり(生のグラフィックパワー、ストレージ、スレッド化など)、同じソリューションを使用することさえできません。そして、WebゲームはWebページです。なんでしょう?ここでの断片化は、単なるコンピューティングアーキテクチャではなく、デバイスパラダイム全体にわたるものです。
ChrisE

実際、ウェブゲームについては何も言いませんでした。すべてのデバイス(入力マッピング、抽象化されたグラフィックスAPI、エンティティシステム、ファイル解析、ネットワーク)で同じコードの一部を実行したいのは理にかなっていると思います。これらはすべてプラットフォームに関係なく同じ基本的なパラダイムです。しかし、この質問は8か月前のものであり、NDKがAndroidのサポートを増やし、Appleが愚かなポリシーを停止したため、あまり当てはまらない懸念から生まれました。

つまり、あなたはHTML5について言及しました...それは一種のウェブゲームを意図したものですよね?
ChrisE

回答:


14

Unityエンジンを使用すると、そこに至るまでの道のりが大きく広がります。一度書くと、Mac / Windows Standaloneとwebplayerベースになります。入力を微調整し、ドローコールを気にすると、iOS / Androidになります。


12

限られた資金/時間で(そして「何かを有益にする」よりも「何かをクールにする」ことに焦点を当てる)小規模なインディー開発者にとって、最初からクロスプラットフォームにしようとすると逆効果になる可能性があります。堅実なクロスプラットフォームツールと技術(さまざまなグラフィックスAPI、エンディアン、入力デバイスなど)を設計するには多大な労力が必要であり、ゲーム開発のより創造的な側面に費やすことができます。

しかし、おそらく、できるだけ多くのプラットフォームに搭載することを心配する前に、1つのプラットフォームで本当にうまく機能する素晴らしいゲームを手に入れたいと思うでしょう!ゲームがフロップの場合、マルチプラットフォームのフロップにするために時間と労力を無駄にすることはありませんか?

ほとんどがゼロからC / C ++でコーディングしている場合、コードをかなりモジュール化して、データ形式とミドルウェア/ライブラリについて賢明な決定を下す限り、後で他のプラットフォームをサポートするのはそれほど痛くないはずです。

サードパーティのクロスプラットフォームの技術/ツール(Unityなど)がプロジェクトのオプションである場合、検討する価値があります。

インディーの主な「問題プラットフォーム」は、Xbox360インディーゲーム(C#のみ、制限されたネットワークアクセスなど)、そしておそらくAndroid(デバイスのパフォーマンス/画面サイズ/入力デバイスの大きな違い)のようです。これらをサポートすることに決めた場合は、より大きな移植作業を期待するか、それらに専念することを計画してください。


ええ、Unity3Dは素晴らしいです。www.unity3D.com
BerggreenDK

私は@bluescrnに同意します-すべてについてほとんど何も知らないよりも、ほとんど何についてもほとんどすべてを知らない方が良いです。
ロドリゴシルベイラ

3

クロスプラットフォーム独立開発と言います。そのときの最大のハードルはリソースです。これは、ほとんどの場合時間の不足を意味しますが、ノウハウや財政(ライセンス料、デバイスの購入など)の不足も意味します。

インディーであろうとなかろうと、最大のハードルは実際にはデザインです。おっしゃるように、Xbox360とiPadで動作するゲームは動作するかもしれませんが、デザインの点で根本的に異なる必要もあります。360にはコントローラーがあり、iPadにはタッチスクリーンがあります。また、360の開発はC#を言語として使用するWindowsで行われ、iPadはMac OSコンピューターとC、C ++、またはObjective-Cを使用してのみター​​ゲットにできます。または、必要に応じてJavascriptを使用します。いくつかのことは、あなたが何をするにしてもそれをうまく混ぜ合わない。

さまざまなプラットフォームについてあなたが言うことは、今日も当てはまります。C / C ++とSDLを使用すると、PCのようなマシン上でクロスプラットフォームでプログラムを作成できます。おそらく数年前よりもはるかにスムーズです。しかし、これは常に問題であり、PCからコンソール、モバイル、またはその逆にゲームを移植することは常に問題のままです。近年、インディー開発者がコンソール用にプログラムできるようになった(または、自作のゲームを作成するためにそれをハッキングする開発者)ことを可能にし、ゲームを実行するのに十分な強力なモバイルデバイスが登場したことで、より顕著になりました。

移植にはこれまでと同じ問題がありますが、移植先のデバイスはさらに多くあります。また、一部のポートはゲームのコアを再設計しなければ意味がありません。これは解決できる問題ではなく、最初のコード行を書く前から最初から考慮しなければならない問題です。そうすれば、管理しやすくなります。


実際、移植までの時間は、独立した開発者/グループが大規模な出版社主導のスタジオよりも持っている可能性が高いことの1つだと思います。

すべてのプラットフォームで意味のあるゲームデザインがたくさんあります。たとえば、ターンベースの仮想ボードゲームは、すべてのプラットフォームで一貫してヒットしています。多くの落下/マッチングブロックパズルゲームも同様です。これらは従来の意味で「移植」することさえできません。たとえば、XBLIGからiPhoneにゲームを移動すると、すべてのコードが確実に書き換えられます。

3

シンプルでポータブルでオープンなインターフェースフレームワークが本当に必要だと思います。いくつかの黙想:

現在、キーボード、マウス、コントローラー、マルチタッチサーフェスの4つの一般的な種類のゲーム入力方法があるようです。(たとえば、ゲームパッドとジョイスティックの機能が異なるという問題については、現時点では説明しますが、最終的には対処する必要があります。)

理想的には、開発者は一般的な方法で、作成するゲームの種類に合ったいくつかの異なるUIを指定できるでしょう。(任意の例として、キーボードとマウスのUI、マウスのみのUI、およびマルチタッチUIを提供することを決定する場合があります。)

フレームワークは、QTやGTKなどのクロスプラットフォームGUIフレームワークが機能するのと同様に、プラットフォームとゲームコード間のIOを仲介します。

このようなフレームワークを使用しても、互換性のない言語要件の問題は解決されませんが、少なくとも共通のAPIの背後にあるシステム固有の呼び出しはすべてカプセル化されるため、言語の移植がより簡単になります。

さて、私はそのすべてを書いたので、そのようなフレームワークがすでに存在するかどうか誰にも分かりますか?


3

MonoTouchやXNATouchのようなプロジェクトでは、XNAを使用すると、ほとんどのプラットフォームで少し調整することができそうです。残念ながらAppleは、使用可能な言語を制限するために利用規約を変更したときに魚雷を使用しました。Unityは今ではほぼすべてのものに対応していますが、XBOXではXBLAではなくXBLIGであるため、小さなインディーズのオプションではありません。

1つのアプローチは、複数の言語/プラットフォーム間で同じ規則を使用するフレームワークを作成することです。それは、ゲームを移植するための構文を微調整するだけの問題です。ゲームをFlashで起動することをお勧めします。Flashは、迅速に開発され、多くの視聴者に届けることができます。iPhone、XNAなどへの移植に成功した場合は、この方法で、自分がやりすぎになる前に楽しいゲームがあることがわかります。


プログラミング言語を制限する愚かなリンゴ!誰?!?!
FreshJays

2

これは経済的な問題であり、技術的な問題ではないと思います。xbox360のようなプラットフォームは、ユーザーに他のプラットフォームではなくプラットフォームを選択させようとしているため、排他的であることへの強いインセンティブがあります。「これらのクールな専用ゲームがあります」は、「他の人が持っているこれらのゲームもプレイできます」よりもはるかに興味深いものです。エコシステムは、ハードウェアメーカーによって支配されています。

ソーシャルネットワークのゲームプレイが成熟すると、これは変わると思われます。なぜなら、誰もが同じソーシャルゲームシステムに参加するのは、もう1つのセクシーなグラフィックを備えたFPSを作成するよりも多くのお金があるからです。


2

私はちょうど発見しました HaxeとNMEをしました。1つのコードベースからすべての主要なデスクトップとモバイルデバイス、および Flash をサポートするクロスプラットフォームアプリであると主張しています。一見の価値があります。


1

非常に新しいクロスプラットフォーム開発ツールは、必ずしもお勧めしませんが、http://www.monkeycoder.co.nz/です

あなたが言及したすべてのプラットフォームにヒットします。

あまりにも新しいとはいえ、それは素晴らしい血統を持っています。それは、インディーズゲーム開発者向けの優れた開発ツールであるBlitz3DとBlitzMaxを以前に作成したクリエイターです。


0

少なくともx86でairplay SDKを使って運が良かったし、どうやらiPhoneをターゲットにしているようだ(まだiPhoneにはまだアプリを入れていないが)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.