North Tyris

この新公式はかなり重いですね。前のサイトと違いJoomlaで運営しているというのもありますが、海外の安いShared hostingサービスを使っているのが一番の原因かな。仕事用にx serverを一年契約で借りており、その後amazon ec2に移行したため、x serverの方は全く空いているのですが、サイトを移転したとして一年後にどうするかというのが。

それにしてもamazonのクラウドはただいじってるだけでも面白いです。全くエロナやゲームとは関係ない件で稼働させているのですが、作業の合間とか、いろいろとElinに応用できないか妄想してしまいます。

イルヴァ資料館のほうでだいたいの質問に答えてしまっため、正直なところ10も書くネタないのですが・・・
Elonaのクトゥルフ要素に関することをちょっと。

わたし自身はあまりクトゥルフに詳しくなく、Elonaに登場するクトゥクリーチャーはだいたい他のローグライクからとってきたものや、ググって適当に出てきたものです。野プリンさんのモンスター素材にちょうどそういう系の画像が多かったのも、導入のきっかけでしたね。

たまに混乱を招く原因となっている、ElonaのSAN値が正気度(sanity)ではなく狂気度(insanity)であるのは、単に正の値で増えていった方が処理が楽そうだったからです。

そして、elonaの魔導書の中で、他のクトゥルフ魔導書を差し置いて金枝篇が上位に位置しているのは、前回の記事でお察しの方もいるかと思いますが、エウレカの影響です。

それにしてもAOはがっかりでした。

ウミキョンチュ（笑

まあエウレカさえかわいければいいです。

できた、本当にできたんだ。カットバックドロップターンが、俺にもできたんだ。君のおかげだ。君がいたからできたんだ。君最高だ。俺は君が好きなんだ。君だからできたんだ。君じゃなきゃダメなんだ。俺は、君が大好きだ～！！

レントンのモデルというか元ネタです。元ネタがわかる方もいったいどういうことかわからないと思いますが・・・

補足

メインはscalaで書いていますが、外部ライブラリなどはほとんどjavaで書かれており、実際にはjava・scala半々みたいな感じです。javaのコードをそのまま使えるのがscalaのいいところですね。IDEの対応などもあるので、メインで書く言語は統一したほうがいいとは思います。

groovyはoo作者様の推測通り、mod・拡張機能のために使用しています。

一度オープンソースのプロジェクトを起ちあげて、実際に見てもらう（だめだししてもらう）のが一番わかりやすいでしょうね。ただ、プロジェクト管理とかレポジトリの利用をしたことがほぼないので、やり方がわかりません（笑）時間をみつけてちょっとずつ調べていきたいと思います。

また、プログラム以外での参加ももちろん歓迎します。

ご無沙汰しています。最近Elinのオープンソース化に気持ちが傾いているのですが、開発にかかわってもいい・興味がある方はいますか？

開発言語はscala+java+openGL+groovy です。ただ、elonaと同じく多人数での開発を想定せずに作っており、コードもあれなので、要望が多ければ他の言語で書き直すのもありです。

オープンソース化した場合は、もちろん完全にフリーのゲームとして、わたしも一開発者として参加する予定です。おそらく設定部分やゲームデザインの方での参加が多くなると思いますが。

世界設定の方は、開発初期から数人の方に協力してもらっており、なかなか良い感じに出来上がってきています。現時点では、elonaのストーリーの延長ではなく、ナーク・ドマーラを舞台にした新しい物語の設定ですね。

ちょっと古いですが、ゲームのスクリーンショットもギャラリーにあります。

オープンソース化に興味のある方は、フォームメールやこのブログのコメント、ツイッターなどでコメントをお願いします。質問も歓迎です。特に参加の意志はなくても意見だけでもかまいません。

それではまだまだ残暑も厳しいですがお体に気をつけて。

久しぶりの記事、というか独り言です。最近はJoomlaのモジュールとかを作ってみたりしています。ただ、最新の2.5のチュートリアルとか解説があんまりないんですよね、Joomla。1.5の頃から開発してるデベロッパは問題ないんだろうけど、2.5から初めると一苦労です。公式wikiに日本語の開発ドキュメントがないので、それも日本であまり盛り上がらない原因の一つかな？あと昔から激重でしたしね。それは2.5でも変わっていません。新公式も重いです

Elinの方はしばらく触っていませんが、今の開発環境だと、HSPでやっていた時のように少しブランクが空くと全くコードが読めないみたいなことがないので気が楽です。Elonaの頃は、少し昔に書いたコードをいじるのは相当勇気が入りました。ヴァリアントの作者さんがどうやって開発しているのか、時々不思議に思いますo.o

さて、もう書くネタがない。JoomlaをつかったCMSとかサイトのデザインとか、環境をセットアップしてる時が一番楽しいですね。更新と管理がしやすいよう時間をかけてを作ったのはいいものの、記事を書く気力はあまりないという　まあ、生存報告も兼ねて、適当に書いていきます！

そうそう。遅くなりましたが、リンク登録していただいた各サイトの作者様、ありがとうございました。今回はツイッターで募集したので、ほとんどエロナクラスタの方々でしょうか。恥ずかしいしソーシャルなタイプではないので、ほとんどツイッターの方では発言してませんが、スイカの絵は全部収集させていただきました。yum

Elinで使用予定のフィールド音楽の一つ、Dreaming of Flying。 Listenボタンをクリックすると再生できます。

もうだいぶ前から、ローグライクゲームとして有名なToME(旧pernband)の作者darkgodさんがTales of Maj’Eyal という開発中のToMEの続編を公開しています。ToME、かなりの時間を盗まれました

この最新作に使われているt-engine4がなかなか素晴らしいできです。ざっと公式ページで公開されている特徴だけ並べても

• Windows, OSX, Linuxなどのクロスプラットフォームに対応。 Cで作られたコアライブラリとLuaにより稼働。
• OpenGLを使用した画面描画。
• グラフィカルなタイル表示の他に、懐かしいアスキー文字によるタイル表示も可能。
• 汎用的なセーブ・ロード機能。たいていのゲームオブジェクトは、特別なコードを組むことなく保存できます。
• オブジェクト指向に基づいた、Luaによる柔軟性のある設計。
• マップの管理。
• オブジェクトやプレイヤー、NPC、地形などに派生可能な基本エンティティの採用。
• キーボードとマウス操作を両方サポート。
• アクターにスキルやタレントなどの属性を持たせるための、バラエティ豊かなインタフェースクラス。もちろん自分でカスタマイズすることも可能です。
• ダンジョンや森、フィールドや街などに派生することができるベースZoneの採用。
• 保存可能なマップ（階層）と、常に再生成されるマップ両方ともサポート。
• 柔軟性のあるデータ構造。
• 拡張可能なダイアログ・ウィンドウ。
• チート、店、キャラ生成など多くの汎用的なユーティリティクラスを登載。
• キーバインド機能。
• ダウンロードセンター。作成したゲームをte4.orgに参照させると、t-engine4のゲームリストに表示されます。
• パーティクルを使ったグラフィックエフェクト。
• 効果音とBGMのサポート。
• その他たくさん。

などなど。実際に触ってみると、ここであげた特徴以上に魅力的なエンジンであることがわかります。
まだいくつかバグやグリッチがあるようですが、画面サイズやフォントサイズ、タイルの大きさの任意の変更など基本的な部分もしっかり作られています。fog of warの処理やマウス操作とかもいい感じです。

正直Elinの開発にあたって、一から作るかt-engine4を使用するか迷いました。これだけの機能をもつフレームワークがあれば、開発期間の中の1,000時間以上は軽く節約できそうですし、動作確認がある程度とれているというのも心強いです。

こんな素敵なエンジンをオープンソースで公開されているのには頭が下がります。

ちょっと面白い記事があったので、elinとは全く関係ないのですが、概要だけ言葉で紹介します。

80%のモバイルアプリの開発者は、事業として続けていけるだけの収益を得ていない

59%のアプリは開発にかかった費用さえ回収できていない

68%の開発者は、最も成功したアプリでも$5,000(40万円)以下しか収入を得ていない

63%の開発者は、最も成功したアプリでも50,000回以下しかダウンロードされていない

52%の開発者は、宣伝に総開発時間の5%以下しか費やしていない

52%の開発者のうち、91%は宣伝が大事だと認識しているものの、マーケティング費用に$0(0円)、つまり宣伝をしていない


12%の開発者は$50,000(400万円)以上の収益があるアプリを開発している

11%の開発者は、500,000回以上ダウンロードされたアプリを開発している

成功したアプリの開発者は、平均して総開発時間の14%をマーケティングにあてている

成功したアプリの開発者は、平均して$30,000(240万円)をマーケティング予算に設定している

これは2012年にapp-promo.comが開発者に対して行ったアンケート調査の結果です。

Groovy Script Engineを使用すると、実行中のscalaアプリケーションから動的にGroovyスクリプトを実行できるため、ゲームなどでのModの組み込みにも良い感じです。ただ、スクリプトのコンパイルにはある程度時間がかかります。同じインスタンスのアプリケーション内であれば、一度コンパイルしたあとは自動的にキャッシュされたクラスを読みこんでくれるのですが、アプリケーションを起動し直すとキャッシュはクリアされてしまいます。

変更のないスクリプトを起動のたびにコンパイルさせたくなかったので、どうにかGroovy Script Engineが生成したclassのキャッシュファイルを別の場所に保存しておいて読み込めないか試行錯誤しています。

Googleで検索してみると、どうやらCompilerConfigurationクラスのsetTargetDirectory(dir_name)メソッドで、コンパイル時に生成されるclassキャッシュの保存先が指定できるはずなのです。しかし、stack overflowで質問したところ、GroovyScriptEngineクラスのバグ(?)で、CompilerConfigurationで設定したtargetDirectoryが読み込まれていない・適応されていないとのこと。

そこで、下のようなコマンドのバッチファイルを実行し、groovycから予めclassファイルをコンパイルしておき、それをGroovyScriptEngineから読み込ませることにしました。

cmd /c groovyc -e -classpath .\groovy\ -encoding UTF-8 -d .\cache\ *.groovy

コンパイルされたクラスの名前をGroovyScriptEngineのGroovyClassLoaderに渡して、classファイルから直接クラスを読込みインスタンス化します。

var gse = new GroovyScriptEngine(classPath)
var scriptClass = gse.getGroovyClassLoader().loadClass("className", true, true)
var i = scriptClass.newInstance().asInstanceOf[GroovyObject]

loadClassメソッドの第三引数にtrueを指定することで、同名のクラスを持つGroovyスクリプトが存在しても、classファイルのクラスを優先的に読みこむようになります。

この方法だと、確かにscalaアプリケーションでの不要なコンパイルはなくなるのですが、スクリプトを変更した際にまたバッチを起動してclassファイルを作成しなければなりません。何かもっといい方法がないか模索中です

ツイッターのTLで一言懸念する声があったので、特に心配するほどではないですが書いておきます。ElinはElonaとはかなり趣や雰囲気の違ったゲームになると思います。意図的にElonaとの差別化を図っている部分も多いです。

Elonaの規模に短期間で追いつくのは大変なため、Elinではとりあえず特徴を出せる部分、例えばグラフィック面や雰囲気面などに手を加えています。またインタフェースなども少しカジュアルっぽくなるでしょう。旧来からのプレイヤーからすると、不満や違和感を感じる点が多くでてくるるだろうなと心配ではありますがｗ

そのあたりのプレイヤー層の食い違いはある程度仕方がないと思っています。たぶんElinリリース後もElonaの方をプレイし続ける、あるいは両方プレイする人も多いんじゃないかな。ともかく、Elonaもヴァリアントもある中で同じゲームを作っても仕方がないため、Elinは独立した新しいゲームにしようという開発スタンスです。

ということで、ElinとElonaの住み分けはたぶん問題ありません。

あと、ヴァリアントはわたしの作品ではなく、すでにヴァリアント作者の一個の作品だと思っています。世界観とかもElinに関係なく自由に拡張してください。ElonaはElonaとして、ヴァリアントの方で末永く発展していってもらえるとうれしいですね　

世界の中心でうみみゃぁを叫ぶ

Slickを使用していて、気をつけたいことなど。


* タイルベースのゲームを作るときは、Image.FILTER_NEARESTを使用する。

Slickで読み込まれたテクスチャには、デフォルトでLinerフィルタ(Image.FILTER_LINER)が適応されます。少しアンチエイリアスが効いたような画像でしょうか。普段は特に問題はないのですが、タイルベースなどきっちりとタイル状にイメージを敷き詰めたりする場合、画面のスクロール時にグリッチが生じます。この時は、image.setFilter(Image.FILTER_NEAREST)でNearestフィルタを使用すればグリッチを回避できます。

昔のSlickですと、フィルタを切り替えるたびにテクスチャが再度読み込まれていましたが、今では切り替えをしてもそういうことはないみたいです。


* drawEmbeddedには回転(setRotation)など一部の設定が適応されない。

これはSlickの仕様で、drawEmbeddedで描画されるイメージに一部の画像処理系の設定が適応されません。ただし、開発中のNightly VersionのSlickでは、回転に対応しているようです。


* Particle Editorのバグ。

ゲーム作成時に非常に便利なParticle Editorですが、エディタとパーティクル描画処理にいくつか既知のバグがあります。エディタの方では、64ビット環境では正常に終了しなかったり、特定のパラメータをいじると固まったり、alpha, scale, vectorなどをグラフを使って編集している場合、値が正常に読み込まれなかったりなど、結構細かいバグがいくつかあります。描画クラスの方では、パーティクル画像のパスの読込みがうまくいかなかったり、vectorの動的な値の変化がdelta値に依存していない（FPSが低い場合と高い場合でパーティクルのアニメが変わってしまう）など。

パーティクルはゲームでよく使用するため、このへんの修正が放置されているのは残念です。ゲームで実用するためには、エディタやパーティクルクラスをソースから直接修正する必要がありますね。


* Soundlyという外部ライブラリが良い感じ。

Slickに用意されているMusicやSoundクラスは、簡単に使えるものの機能面で少し物足りない面があります。SlickにはSoundlyというユーザー作成の外部ライブラリがあって、これがなかなか使えます。PanやVolumeの設定、フェード、クロスフェード、音源とリスナーの位置により自動的にpanやvolumeを調整するサラウンド機能、同時に再生できる音数の管理など、その他もろもろ、ゲームで使用するサウンド機能のほとんどが実装されています。

現在はすでに開発が終了しており、またプロジェクトのダウンロードページにあるライブラリは古いバージョンのため、リポジトリからソースをとってきてbuildする必要があります。その苦労の価値は十分あると思います。

生まれ変わったら　一緒になれるよね

さて、またまた前回からの続きでパフォーマンス改善のTipsです。

* 毎フレームごとに描画バッファをクリアしないようにする。 背景画面があったり、画面全体が再描画されるゲームでは、フレームごとに描画バッファを初期化する必要はありません。

GameContainer.setClearEachFrame(false)

このコードでバッファをクリアしないように設定することで、若干ですがFPSの向上を狙えます。また、Slickの毎フレームごとのバッファの初期化は、colorバッファとdepthバッファを同時に初期化する設定になっているため、もし初期化をする必要があった場合でも、graphics.clear()を使用したほうが効率がいいそうです。


* ブレンドを無効にする。 描画時にblend処理をする必要がない場合は、glDisable(GL11.GL_BLEND)でブレンドを無効にすることで速度を改善することができます。


* オブジェクトの生成や変数の宣言をメインループから排除する。これについては、Slickとは無関係です。特にアクション系のレスポンスが重視されるJava+OpenGLゲームでは常套手段で、メインループからはできるだけオブジェクトの生成や変数の宣言を排除するようにします。一時変数などはクラスのフィールドで宣言し、必要なクラスのインスタンスも予め作成しておき使いまわします。

コードが見づらくなるという弊害がありますが、速度面と、そしてJava環境ではGC対策として効果を発揮します。GC対策をしていないゲームでは、画面がかくついたり一瞬止まったりといった現象が起こります。


davedesさんによるSlickのTipsは以上です。

前回の続きでSlick 2Dのパフォーマンスを向上させるTipsです。

* テクスチャを読み込む際は2のべき乗のサイズのテクスチャを用意する。Slickでは2のべき乗(16x16, 32x32, 64x64など)でないテクスチャを読み込んだ際は、自動的に、読み込んだサイズがおさまるべき乗のサイズのテクスチャ領域が作成されます。例えば300x300のテクスチャを読み込んだ場合、512x512のテクスチャ領域が作成されてしまうため、リソースの無駄になってしまいます。


* Vertex Array Renderモード(頂点配列描画モード）を適用する。GameContainerを作成する前に、

Renderer.setRenderer(Renderer.VERTEX_ARRAY_RENDERER)

を指定することで、Vertex Arrayを使用したレンダリングモードに切り替えることができます。適用したからといって必ずしも速くなるとは限らず、指定することで逆に遅くなることもありますが、たった一行なので試しに一度は適用してみるべきでしょうね。


* Image.getGraphics()を多用しない。Image.getGraphics()は、単にイメージのテクスチャをGraphicsに変換するのではなく、新しいOpenGLテクスチャを生成します。なので、コスト的にもリソース的にも、一度作ったGraphics領域はgraphics.clear()メソッドを使用して初期化し使いまわすべきです。


* FBO(Frame Buffer Object)への直接描画を多用しない。FBOとは、Image.getGraphics()で生成されるオフスクリーンバッファなどのことですね。これらのバッファのグラフィックコンテキストが変更されるたびに、Slickは背景色やクリッピングの情報、サイズの情報といったすべての属性情報をpushします。そのためFBOへの描画は若干コストが高くなり、できるだけ控えるか、自前のFBOクラスを作成するののが理想的です。

以前Slickの公式フォーラムで、ElinのパフォーマンスチューニングのためにVertex Buffer Objectの導入について質問したところ、現在SlickのNightly versionを開発しているdavedesさんから、Slickを高速に動かすためのTipsを頂きました。せっかくなので、翻訳して順次掲載します。

JavaでOpenGLを使ったゲームを作る場合、大抵は既存のOpenGLライブラリを使用することになると思います。LWJGLとJOGLという二大OpenGLライブラリがあって、それをベースによりゲーム開発用に機能を増やした・使いやすくした多くのゲームライブラリがあります。ちなみにLWJGLはゲーム開発に使われることが多く、JOGLはアプリ系の印象です。

現在アクティブに開発されているゲームライブラリは3D系のものが多く、またandroidやiOSなどのプラットフォームに対応したライブラリが多いのも特徴です。さすがにJavaということもあり、たいていのライブラリはクロスプラットフォーム対応ですね。Java+OpenGLの組み合わせは、特に携帯端末用のゲーム開発で使われることが多いようです。

Elinのようなゲームを作っている例はあまり見かけませんが、もちろん本格的なゲームも作れます。MineCraftとかもJava+OpenGL。速度的にはもちろんC+OpenGL/DirectXの方が速いです。

Java+OpenGLで使える2Dゲームライブラリの現在の主流は、Slick2Dとlibgdx。その他にGTGEなどのライブラリもありますが、更新が途絶えていたり、機能的に見てSlick2Dとlibgdxが一歩抜きん出ている感じです。Elinでは、Slick2Dとlibgdxを試し、最終的にSlick2Dを使うことになりました。

Slick2DはOpenGL初心者でも手軽に使え、ライブラリとしての完成度・まとまりがとても高いです。速度的には、Slick2Dで使える基本的なクラスと、それに対応するlibgdxのクラスではあまり違いはないと思います。libgdxの方はあまり使っていませんが、とりあえずSlickをメインに簡単な比較や特徴をあげてみます。Slickの特徴や感想・Tipsについては、また別の記事で書きます。

OpenGLでの日本語の表示処理はなかなか面倒です。Elinでも最大の難関の一つで、現在も完全に納得のいく実装はできていません。

OpenGLの場合、テクスチャにフォントデータを読み込んで、それを一文字ごと描画していくのですが、アルファベットなど限られた文字数なら全く問題な いものの、日本語などでダイナミックに文字を表示させようとすると、５０００個以上の文字をメモリに読み込まなければなりません。最初から使う文字列がわ かっていれば、フォントを使用せずにそのまま文字列を画像に保存して表示させたほうが手軽でしょう。

ただチャットやRPG的なゲームを作ろうとすると、ダイナミックに日本語を表示させる処理が必要になってきます。一番手っ取り早いのは、マルチバイト文字 出力に対応したOpenGLライブラリを使用する方法です。しかし、Cにはそういったライブラリが豊富なようですが、Java + OpenGLの環境では選択肢が限られてきます。Elinの場合は2Dがメインなので、JOGL(+libGdx)か、LWJGL+Slick2Dのどち らかでした。

もうておくれ

日本語テスト

ふく

すう

ぎょう

welcome