2013年10月17日

Cocos2D と Sprite Kit の OpenGW による統合

cocos2d や KoboldTouch で有名な Steffen Itterheim 氏が開発を進めている OpenGW に関する記事を直訳してみました。 オリジナルはこちらです。 なお掲載にあたっては、Steffen Itterheim 氏の許諾をいただいております。

Unifying Cocos2D and Sprite Kit with OpenGW

On October 3, 2013, in idevblogaday, by Steffen Itterheim

Cocos2D と Sprite Kit の両方に関連するコードをどう書くか、 Kobold (2D/Touch/Kit) プロジェクトではそれに対してどう拡張しているか?

数ヶ月前に私は私の関心を Sprite Kit に移しましたが、それは Kobold Kit と付随する Starterkit を作るためでした。 Sprite Kit が皆の注目を集めているのは明白でしたが、一方で、私は cocos2d-iphone と KoboldTouch に背を向けたくはありませんでした。そこでポータブルな方法で可能な限り多くのコードを作成する必要がありました。

その結論が、 OpenGW という、世界で最初のゲームワールドシミュレーションエンジンであり、(11月か12月には)公に公開されます。これは、私が過去数年にわたって無意識的に探し続けてきた至高の目標です!

OpenGWとは?

OpenGW とは、 Open Game World を意味します。

それはデータドリブンであり、エンジン非依存で、クロスプラットフォームなゲームワールドシミュレーションエンジンです。

私は、あなたが OpenGW の情報をもっと得られるようなスタブページをセットアップしました。

なぜ OpenGW ?

ゲームプログラミングの要点は − これは何人かに対しては驚きかもしれません − スクリーン上にものを配置するようなことでは決してありません! あなたがスクリーン上で見ているものは、ゲームの現時点でのシミュレーション状態の結果にすぎません。すべてはデータとプロセスであり、ビジュアルではありません。すなわち、もし書くとすればそれは "プロパティ" なのです。

初心者にとっては、とにかく直接的、マジックナンバー、グローバル変数、シングルトン、コピペ、 "あなたが現在いるどんなクラス/メソッドにももっと中身を追加できる" といったアプローチのタイプは自然なことです。

あなたが経験してきたように、あなたのコードは、よりよく、より構造化され、よりモジュール化されています。しかし、あなたはいつも近道しようとしており(そして近道*することになり*)、そのうち後悔することになるようなことを手っ取り早くしてしまうのです。

どのようにして私はコードを愛することを学んだか

私にとって、"関心を切り離すこと" を会得するのは難しく、なぜそれがいつも重要なのかを理解することも難しいのです。 トリプルAのゲームタイトルのためのプログラミングは目を見開かせるようなことでした。しかし私が信じているのは、私がもっとも学んだ場所は、ゲームプログラミングする場と同時に、それとは異なる、ほとんど全体がセルフデザインされた内部アプリの開発だったのです。

ゲーム側では、我々ははっきりとモジュール化されたゲーム及びレンダリングエンジンを有しており、それはゲームシミュレーションをドライブする責任のある1つの大きなモジュールでした。それは完全にオーディオ、ビジュアルそしてネットワークが分離されていました。それは私に従事するフレームワークを与えてくれ、既存のコードを調べることで何をどうすればよいのかのガイダンスを作ってきました。ほとんど自然な形で私のコードは、モジュール化され、再利用可能で、柔軟性があり、拡張可能となっていました。

一方で私は、データベースフロントエンドアプリケーションを作れるか訪ねられました。.NET を使った C# と、 SQL データベースへの Hibernate を使った接続を考慮したユーザインタフェースのためのサードパーティのフレームワークで、一方で、データベースの設計と管理もでした。私は構築するためのものを持っていませんでした ー ゼロ、全くのゼロでした。 C# 、 .NET 、 Hobernate は私にとっては新技術であり、両方のエンドユーザを満足させる必要があった User Interface アプリケーションを設計したり書いたりしつつ、一方でありとあらゆる新しいテーブルやデータカラムをカスタムコーディングしなければならないような落とし穴を避けていました。

敢えて言うなら、これは良い意図にも関わらず私のベストなコードではありませんでした。いくつかの良い決定はデータベースもしくはユーザインタフェースレイヤでうまく機能しませんでした。いくつかの良くない決定はプロジェクトを長い間悩ませました。より悪かったのは、ハイバネとデータベースの設計とユーザインタフェースの設計がまったく正反対だったことです。これらの全てをハンドリングするためのテクニックはありましたが、設計図がなく、これを非常に難しくしていたはっきりと分離された異なるレイヤを維持できず、決して最適ではないコードベースでプロジェクトに重い負担を課していました。

このことは私に一つのことを教えてくれました:もしあなたが従事している、素晴らしく、確かなフレームワークが良いサンプルをたくさん提供してくれるのであれば、コードを書くことはより容易になるだけでなく、それはまたフレームワークのデザインによりよく自然にフィットするでしょう。もしフレームワークがうまくデザインされていれば、あなたは結果としてよりよいコードを書けるでしょう!

あなたのコードはエンジンのコードと同じくらいだけ良い

けれども、ということは、良くないエンジンの設計は良くないデベロッパコードへ導き、あるいは少なくとも良いコードを書くために非常に大きな努力が必要になります。

私がいつも cocos2d-iphone のデザインが気に入らなかったのは、それがそのユーザにすることと教えることのためです。それはエンジンの全体像からくる"そんなにすごくないけどとりあえず動く"というデザインの例です。Apple が混乱を晴らしてくれて私は嬉しいのですが、私が失望したのは、彼らのデザインが、ノード上で動作するコードを書くことを働きかけるよりむしろサブクラス化することに向かってそれ自身にまたも力を入れているということなのです(ところで Kobold Kit ではそういう振る舞いがされるわけです)。

良くないエンジンのデザインは、ユーザに間違った優先順位を教えます:すなわち、特定のビューをそこにあなたのゲームのコードを置くためにサブクラス化しても良い、とすることです。また、最初の場所に、そしてノードヒエラルキーの枝間で"格差"(接続ノード)への最悪のケースにて、シングルトンを使っても良い、とするのです。また、複数のノードが同じ入力イベントを処理することを、認めてしまうのです。そのアクションは、実際のゲームロジックに対する代わりのものとして使われ得るのです。そのコードはエンジンと常にタイトに結び付けられています。

あらゆるものの中で最悪なのは以下の通りです:ビジュアル、オーディオ、そして入力がゲームのロジックコードから分離されていない。この混同はすぐに問題になりますし、もっとも小さいプロジェクトにとってさえそうなります。

私は KoboldTouch で異なるアプローチを取り、 MVC フレームワークを構築し、そこでは cocos2d はビューに格下げされ、コントローラがヒエラルキーを生成し、そしてモデル(かつ/またはコントローラ)がゲームのロジックをホストします。一つの問題は、 cocos2d が反撃を続け、いつもフレームワークのデザインを浸透させようとし続けたことです。究極的には、分離は私がこうあるべきとそれに望んだのと同じようにはすっきりしていませんが、それは改良はされました。

やむを得ず、 Kobold Kit はわずかにデザインを変更し、そこではビュー(ノード)はヒエラルキーを形成し、コントローラはそれ自身をノードにアタッチし、かつオプションとしています。コントローラはまだモデルをホストしていますが、それはまたビヘイビアもホストしており、それは任意のノードのビヘイビアを変更するためのコードプラグインとなります(すなわち、スプライトを、タッチやクリックに反応するボタンに変化させます)。

コンポーネントベースのプログラミングは、非常にパワフルです。興味深いことに、 CBD に関する良い記事を探すまで知らなかったのですが、その記事で私が目にしたのは、 Ray Wenderlich 氏によるintroduction to component based developmentで、それは OpenGW が何を為すのかあなたが理解するのを助けになるであろう記事でした。そしてここに非常にタメになる記事があり、ここではサンプルによって、いかに頑強なクラスがコンポーネントを使うクラスにリファクタリングされ得るかを示しています。

いずれにせよ、 Kobold Kit のビヘイビアと Kobold Touch のコントローラの両方ともビューに強く接続されており、従って究極的にそれらは特定のレンダリングエンジンにて動作するだけとなるでしょう。2つのプロジェクト間でコードを共有することはむしろ意味がなくなってしまうように思われます。

OpenGW はどのようにして生じたのか

OpenGW を生み出すこととなったアイデアをトリガしたものが正確になんだったのかは確信が持てません。それは絶対的に Kobold Kit のための Platformer Starterkit を書くことの外側で生じました。おそらくパートナーとビジネスを走らすアイデア全体で、複数のゲームを生み出すことと、我々が作ろうとしているものを現実化することは、完全なチュートリアルを伴って基本をカバーする初心者用スターターキットというものには正確にはならないでしょう。

私がプロデュースしようとしていたものは、ゲームのコードとワークフローであり、それらはプロフェッショナルデベロッパのニーズを満たすもので、より高位の学習曲線を必要とするものでした。そして私が OpenGW で持っていたものを書き直し始める前はその学習曲線はより高く、まさしくなぜならそれはビジュアルを伴って織り込まれており、ユーザインタフェースとビジュアルレイヤを提供するだけのコードと、ゲームロジックを走らすコードの間で区別がなされていなかったためです。

この分離の欠如が問題となった一つのエリアが、 TMX オブジェクトモデルでした。それは、 TMX ファイルのすべての局面を完全に表現していました:それらは、マップ、そのレイヤ、タイル、タイルセット、 GID 、オブジェクト、プロパティです。それ自身において、タイルセットテクスチャを除いて、エンジン特有な何かからほとんど完璧に分離されています。

しかし TMX オブジェクトモデル上でゲームを走らせることは、 GID (タイル) をルックアップすることを意味し、 GID が為すことを伴ってそれらをクロスリファレンスすることを意味し、タイルセットやオブジェクトのプロパティをチェックすることを意味しており、そしてそれらのすべてを設定することを意味します。そのトップにて、座標は変換される必要があり、それは TMX がその原点を左上に持っており、左下ではないからです。これはパフォーマンスにとって実に良くなく、コードをダサく、肥大化させ、理解するのを困難にしていました。

プロセスのどこかで私は、どのようにしてゲームシミュレーションにおいてものごとを為してきたかを思い出しました。私はいつもそのようなシステムの中で再び仕事をしたかったのですが、私がそれをリライトし、大きなベネフィットを得ることは一度も私に起こりませんでした。

どのようにして物事を変えるか

例えばタイルマップに関して、情報は、タイル、タイルセット、オブジェクト、レイヤ、そしてそれらのプロパティに拡がります。私が今 OpenGW でしていることは、ロード時間においてタイルマップから私が必要としている全ての情報を収集することです ー GID 、オブジェクト、そしてプロパティからの情報の結合や、それぞれのタイルたのめのビットコード化された情報を含むシングルメモリバッファの作成などです。それは、 OpenGW の世界地図になります。

OGWMap と名付けられたクラスが実際に存在し、それはメモリバッファを "map" として管理し、ある矩形の中でタイルを順番づけるようなクールなことをあなたが行うのを可能にします。確実に、 Sprite Kit はそこにインプレーションがあったのです。

私が OpenGW 上でかつそれによって開発している一方で、私は実際に私のコード改善を調べることができます。 Platformer スターターキットのコードは、 Sprite Kit と強く結びつけられてきましたが、200行以下に落とし込むことができており、また OpenGW には現在数千行のコードがありますが、少なくともその半分がそれなりに汎用的(すなわち運動学的、衝突検知)であるため、それはどのようなゲームのタイプに対しても使われ得えます。このコードが全ての永続性のために現在保持されていることは重要な認識です − Sprite Kit や Cocos2D はできたりできなかったりしますが、このコードは、過去のこれらのエンジンあるいは複数のプロジェクトに対して関連性と有効性を維持し続けるでしょう。

私が正しい道を歩んでいると私に信じさせているのはこれらのような物事です。 OpenGW は KoboldTouch 、 cocos2d-iphone もしくは任意の Objective-C (後には C++) のゲームエンジンで動作し、さらに言えば、これらのエンジンの全てに対して同じ StarterKit を提供する機械を我々に与えるものです。

いつどうやって?

ゴールは、今年中に OpenGW を利用可能にすることで、11月か12月を考えています。それは有料プロダクトとなる予定です。

アイデアは、同じ船に乗った皆さんがもたらしたものです − OpenGW へのアクセスを入手するために一本購入すると、ボーナスとして KoboldTouch と Kobold Kit Pro へのアクセスをあなたにボーナスとして提供されます。 KoboldTouch のカスタマは OpenGW をエクストラコスト無しで既存のサブスクリプションを通して入手できます。 OpenGW がリリースされたら、新しいサブスクリプションプランと価格表を発行適用しますが、私はまだ詳しく検討していないというシンプルな理由により詳細を示すことができません。


FruitsFields - 寄付代わりに購入いただけると嬉しいです。
Icon-72.png as_available_appstore_icon_20091006.png

サポートページはこちら。
http://cbbandtqb.toypark.in/FruitsFields/index_jpn.html

posted by cbbandtqb at 00:14| Comment(0) | TrackBack(0) | 備忘録 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。