SDXFrameWork 0.12 SDXFrameWork

- Main Page
- Related Pages
- Classes

All Classes Namespaces Functions Variables Enumerations Enumerator Pages
SDXとは？

SDXFrameworkはC++で自由ゲームを制作するための、クラスライブラリです。
以下のような特徴があります。

特徴
1.マルチプラットフォーム
内部でSDL2.0を使っているので、多くのプラットフォームで動きます。
機能的にはSDL2.0+α程度ですが、SDL2.0に比べるとかなり使いやすくなっています

2.日本語サポート
主に2つの理由で英語でなく日本語中心で開発を進めています。
一つ目は差別化のためです
公式ドキュメントが英語だけのライブラリは多くあるので、日本語のサポートを優先した方が特徴が出ます。
OSSに参加したいけど英語はあまり得意では無い人に対してアピール出来るとも思います。
世界規模で見れば英語話者が多いので、英語主体にした方が開発者が集まる可能性が高くなるのでは？と思う方がいるかもしれませんが、
そもそも最近はOSSが増えまくっているので、日本語だろうが英語だろうが簡単には共同開発者は集まりません。
二つ目は効率を上げるためです。
ライブラリ開発者が日本語の方が得意なので英語主体で開発を進めるのは効率が悪すぎます。
特に仮引数は日本語にするとIDEのヒント表示が見やすくなり、リファレンスを見る回数を減らせ、利用者にとってもメリットがあります。
万一、利用者が増えたので英訳したくなる可能性も一応考慮しており、
仮引数とドキュメント以外は英語風にしているので、英訳しようと思った場合も大きな問題は起こりません。

3.コピーレフトなライセンス
SDXはコピーレフトなライセンスであるGNU Affero General Public License Version 3を適用している、自由なライブラリです。
そのためライブラリを利用したソフトウェアを公開する場合、ソースコードの公開が必須となり、さらに配信業者との契約次第では配布が困難になる場合があります。
AGPLを適用すると緩いライセンスに比べて利用者が減るのでは？と思われるかもしれませんが、必ずしもそうでは無いと考えています
ライブラリを配布する場合のライセンスの方針は大きく3つに分ける事が出来ると思います。
[1.緩いオープンなライセンス]
例えばApache LicenseやMITライセンスは派生物に対してライセンス表記や特許のクロスライセンスしか求めません。
そのためライブラリを利用したコードを公開するかどうかは任意になります。最も多いパターンです。
企業に支援される事を目標とする場合、あるいは規模が極端に小さく著作権を主張する意味が無い場合、
ライセンスを確認せずに使えるようにしたい場合、特にこだわりが無い場合、
利用者同士でコードを共有せずに競争させて良い物が出来れば良いと言う考えの場合、
GitHubを無料で使うためにコードを公開している場合等はApache LicenseやMITライセンスを適用するのが良いと思われます
[2.利用料を要求するライセンス]
無料で利用するのは不可能、もしくは機能が制限される、あるいはサポート無しのコピーレフトなライセンスになるが、
利用料を払うと緩いライセンスで利用可能になり、サポートが受けられるライブラリがあります。
利用者が集まる目算があり、利用料で収入を得たい場合に選ばれる事が多いです
[3.コピーレフトなライセンス]
GPL等のコピーレフトなライセンスをライブラリに適用するのはユーザー同士が協力する事を強く推奨したい場合には良い選択です。
しかしながらライセンスが比較的ややこしかったり、権利を強く主張するので誤解されたり敬遠されがちでもあります
場合によっては緩いライセンスを適用した方が良いでしょう。
SDXがAGPL ver3を選択した理由は、以下です。
[1.ソフトを販売する上でのデメリットが少ない]
趣味で開発して無償で配布している人にとってはどうでも良いのでしょうが、
ソフトウェアを有償で販売したい場合、ソースコードから派生物を自由に作れたり再頒布が自由だと売上に響くので困ります。
販売以外で収益を得るのもなんやかんやで困難ですし、ソースコードの公開がダンピングになると言った懸念も有り得ます。
しかしながらゲームの場合、イラストやBGMやシナリオを別のライセンスで配布すれば、ソフトウェア単体ではほぼ動作しないので、
商業上の問題が抑えられます。またゲームとサントラの値段があまり変わらないと言った事があるように、ゲームの価格に対する影響も殆どないと思われます。
プラットフォーム事業者との契約によってはコードを公開するのとソフトを配布するのが両立できなかったり、広告外しやガチャをローカルで遊べる仕様に改造出来たり
デメリットがある場合もありますが、コード公開する事が経済的に非合理であるとは必ずしも言えません。
[2.公開によるメリット]
ライブラリ利用者が増えて、コードが公開されれば、開発コストが下がって、クオリティが向上し、デバッグ済みのコードを再利用出来るので、安定性も上がります
ライブラリ開発においては実際にどのような利用がなされているか調査したり取り込む事が楽になるメリットがあります。
普通のライブラリであれば、利用者数が増えてもユーザーが受けるメリットはそんなにありませんが、コピーレフトなライブラリであれば
利用者が増える事が利用者のメリットにもなります
自分しか持っていない独自技術がある場合でも公開した方が有利な場合もあります。
ゲームの場合、一番最初にそのジャンルを開拓したり新しい事をした場合、後続のゲームが登場する事は宣伝になる上、ファン層の拡大につながる事が多いです。
特にマイナーなジャンルは積極的に技術を公開する方がメリットが多いと思います。
また一からゲームを作るのに興味は無いが公開されてるゲームを自由に改造したい人は結構いるので、そういったユーザーに喜ばれます
バグ報告等の支援が起こりやすくなると思います、保守コストは馬鹿にならないため、それらも重要です
[3.教育機会と道徳]
上記のメリットは、緩いライセンスのライブラリを利用して個別にコードを公開しても生じます。
しかしながらライブラリがコピーレフトな場合の方がその効果は大きくなります。
個人でソースコードを公開しても、公開している人が少ないため、コードを探そうとする人も少ないです。
そのため、公開しても必要としている人が見つける可能性は低いです。
ライブラリをコピーレフトにすれば、それを共有するコミュニティが生まれ、開発者の横の繋がりが出来るでしょう。
そうなれば自分が欲しいコードがあるか探す人も増えるし、探しやすくなるのではないかと思います。
色んな所の質問掲示板で｢こういうゲームを作りたいが参考になるコードはないか？｣と言った質問を結構見かけるのでコードの需要はあるはずです
解説サイトを作るのは相当な手間ですが、コード公開はそこまで手間ではありませんし、教育機会の均等や公開ぐらいした方が良いのではないかと思います
コードの公開は道徳的でもあります。
このような理由でライブラリをAGPLにしています。
今まで、ゲームを一から実装しようとして多くの人が開発途中で挫折してきました。
ゲームを作るのに個人で一から実装する必要はありません、既にあるコードを利用出来る方が楽に決まっています。
何万行ものコードを個人で実装しなければいけない状況は正しいのでしょうか？
開発者同士が協力したり支援する事は決して難しい事でも面倒な事でもありません、コードを公開するだけで良いのです
ライブラリ開発等に興味がある人はSorceForgeの掲示板で気軽にお問い合わせ下さい。

対応開発環境
Windows7以降 + VisualStudio2013
MacOSX最新版 + Xcode最新版
GNU/Linux系のOS + Clang3.3以降
解説を書いていないだけでSDL2.0が動く環境では大体使えるはずです

機能一覧
機能別、クラス一覧