何もない場所

以前書いた例のアレですが、試してみました。
ラブプラスで。

結論。

アリだわ。

ようやくクリアしました～。

428 ～封鎖された渋谷で～

では感想いきます～。
以下ネタバレ注意！
(続きを読む...)

はい前回に引き続きゲームの感想。

忌火起草 解明編

今回初めて、WiiによるADV（厳密にはノベルだけど）をプレイしたわけですが。

※ネタバレを含みますので、閲覧注意。
(続きを読む...)

はいはいたまにはゲームの感想でも書きますよ……っと。
いやーあのね、たまにじゃなく定期的に書きたいなとは思っとるんですが。
なかなかゲームやってる時間がとれず……。

TIME HOLLOW -奪われた過去を求めて-

このほど、ようやくクリア致しました。
以下、ネタバレ含みますので、未プレイの方はお気を付けて。
(続きを読む...)

あのね、遊びの幅が縮まるのよぶっちゃけ。
例えば、コマンド選択式のゲームの場合。下手な選択肢を選んだらゲームオーバーになるという前提で、セーブポイントから分岐点まで結構な距離があった場合、絶対に総当りしようとは思わないでしょ。
3Dとかのオブジェクトをクリックするタイプでも同じ。ゲームオーバーになりそうなポイントは避けます。

不正解の選択肢にお遊びのテキストやアクションを仕込んであったとしても、プレイヤーにはスルーされますよ？　全攻略するという前提で遊んでいる廃プレイヤー以外は。

じゃ逆に、なぜ制作者はゲームオーバーを仕込むのか？
恐らくひとつひとつの選択肢に重みを持たせるという事なんでしょうが、もうちょっと別の方法論もあると思うんですよね。
例えばサウンドノベル。分岐によってストーリーの内容ががらりと変わる、という事であれば、プレイヤーは慎重に選択肢を選ぶ事になりますし、総当りしてみようかというモチベーションにも繋がります。
DQ5の結婚イベントもそうですね。これはRPGですが。

ゲームオーバーがあるとモチベーションは下がるし自由度は下がるし、全然いい事無いんですよねー。
というわけでゲームクリエイターのみなさん、アドベンチャーゲームを作る際は、ゲームオーバーは仕込まないで下さい。

何を思ったのか妹が実況プレイ動画にはまってしまい、その場のノリで自分でもうｐする事に。
プレイしてるのは紛れも無く妹ですが、録画、動画編集、うｐまでKAYがやる羽目になりました。＾＾；
妹、KAY、お友達のきぃちゃんの3人で実況（？）してます。
ちなみにこのゲームを選んだのはKAYの趣味です。

Wiiのバーチャルコンソール経由で、NSFの再生とか出来るようにならないかなあ……。
どんな音が出るのか聴いてみたい。

http://blog.livedoor.jp/dqnplus/archives/1037943.html

ついに痛いニュースにも掲載きたー。
この調子でロミオ信者ファビョりまくろうぜ！！
これでロミオの知名度と評価が上がってC†Cがまた売れ始めてオクル開発再開ｳﾏｰ。

http://www.kajisoku.com/archives/eid1764.html

>>563>>605
やめてあげて！　物書きの中でもトップクラスの文章力を誇るロミオと比べられたら勝てるわけ無いやん！　むごい！

http://www.nintendo.co.jp/wii/vc/index.html

ついに来ましたーーーーーーーっ！！！！！
あの不朽の名作「はじまりの森」がWiiのバーチャルコンソールに配信決定ですーーーーーーー！！！！！！！１１１

あのな、とりあえず、何も言わずに買っとけ。そして、泣け。
つか、任天堂はやっぱタイミング計ってたんだろうなあ。夏といえばはじまりの森だもんなあ。

でさ、でさ、これってWiiでアドベンチャーゲームを出すための布石？
やっと気付いた？　Wiiリモコンが静的ゲームをプレイするために最適化されたデバイスだという事に。
忌火起草の発表でチュンソフトには心底がっかりさせられたからなあ……。
何やってんだよチュンソフト。こういうゲームこそWiiリモコン片手にごろんと横になりながらプレイさせろよ。つか、もちろんWiiにも移植するよな？

ようやくお披露目、前からちょくちょく話に出してた文字描画レイヤです。
KAGのMessageLayerは非常によく出来ているのですが、いくつか痒い所に手が届かない部分があったので、それなら自分で作ってしまえと。
……のはずだったんですが、シナリオ側の記述で結構フレキシブルに使えるんですよねMessageLayer。＾＾；
例えば、リファレンスを鵜呑みにして複数文字にルビを振ろうとすればこういう感じになるんですが……

[ruby text="ひ"]向[ruby text="まわ"]日[ruby text="り"]葵

実際はこんなやり方で均等にルビを配置する事が可能なわけで。
あと、KAGはベタテキストを1文字ずつに分解してchタグとして解釈するので、袋文字を利用している場合に罫線『──』のような、2文字以上がひと続きとなる文字が現れると、2文字目の縁取り部分が前の文字に重なってしまい、文字が途切れてしまうという問題があったんですが（Fateで顕著だった気がする）、これも[ch text="──"]と書いてやる事で簡単に回避できちゃうんですよねー。

というわけで、今回紹介する文字描画レイヤのアドバンテージは、FontクラスのプロパティやdrawText()の引数が全てシナリオファイル側の記述で制御できる、という点くらいに……。
このレイヤクラスは、chなどで文字が送られてきてもすぐに描画するわけではなく、一旦partsと呼ばれるバッファに溜め込み、描画したいタイミング（クリック待ちの直前など）でprint()メソッドを呼び出して一気に描画する、という方法を取っています。
エロゲをインストールしたら即効で文字速度を最速に設定してしまう人用。＾＾；
まあ、KAGParserがテキストを1文字ごとに分解して吐き出すので、タグハンドラの書き方次第で1文字ごとの描画も全然いけますが。

(続きを読む...)

ああなんて事。
KAGでこれが出来ると判ってたら、一からシステム作ろうとは思わなかったかも……。

KAGシステムのrubyタグは、タグが現れた次の1文字に対してルビが振られる、……とリファレンスには書かれています。
まあ間違いでは無いんですが。KAGParserはベタテキストを1文字ずつに分解してchタグとして解釈するので。
でも実際は、内部的には次の1文字ではなく、次に現れるchタグに対してルビが振られる、という挙動を採っています。
なので、こういう風に書いてやると……

[ruby text="ひ　ま　わ　り"][ch text="向日葵"]

あはは……ほら……3文字に渡ってルビが振られるじゃん……。
マクロ化するとこう。

;マクロ定義
@macro name=mruby
@ruby text=%r
@ch text=%text
@endmacro

;使用例
[mruby r="ひ　ま　わ　り" text="向日葵"]

ルビの文字間隔は半角スペースや全角スペースなどで調節する必要がありますが、これで少なくとも文字間隔が不揃いになるという事はなくなります。はぁ……。
近いうちにKAYの作った文字描画レイヤ紹介します。
複　数　文　字　に　渡　る　ル　ビ　を　振　る　こ　と　が　可　能
なやつ。

文法的に間違っていないにも拘らず、syntax errorが投げられてしまう例。

//2.28 stableにて確認
var regexp = //正規表現オブジェクト
    /[a-z]+/;

どうやら、行コメントを書いて、改行後すぐに正規表現リテラルが来ると例外が発生するようです。
前回のエントリと合わせて、公式の掲示板あたりに報告した方がよさそうかな？

（2007/03/28追記）

報告済み。修正済み。安定版は時期リリース版で対応かな？
http://kikyou.info/tvp/bbs/bbs.cgi?mode=&action=treeall&num=10082

2.28安定版での話です。
とりあえず、以下のテストスクリプトを実行してみて下さい。

class TestWindow extends Window {
    var timer;
    var primary;
    var counter = 0; 

    //コンストラクタ
    function TestWindow() {
        super.Window();
        borderStyle = bsSingle;
        innerSunken = false;
        setInnerSize(300, 300);
        visible = true; 

        timer = new Timer(createLayer, "");
        timer.capacity = 1;
        timer.interval = 50;
        add(timer); 

        primary = new Layer(this, null);
        primary.setPos(0, 0);
        primary.setSize(300, 300);
        primary.fillRect(0, 0, 300, 300, 0xffffffff);
        primary.type = ltAddAlpha;          //●
        primary.visible = true;
        add(primary);
    } 

    //デストラクタ
    function finalize() {
        super.finalize();
    } 

    function createLayer() {
        if(++counter > 100) {
            timer.enabled = false;
            return;
        }
        var layer = new Layer(this, primary);
        layer.setPos(0, 0);
        layer.setSize(150, 300);
        layer.visible = true;
        add(layer);
    }
} 

var win = new TestWindow();
win.timer.enabled = true;

↓こちらからダウンロードできます。
startup.tjs

50msごとにウィンドウの左半分にレイヤを1枚ずつ重ねていき、100枚になったら停止する、というだけのものです。
これは……バグなのかなあ。仕様？　まあ、プライマリレイヤなんだから完全不透明なレイヤタイプを使えという事ですかね。

（2007/03/28追記）

公式の掲示板でW.Deeさんよりご回答いただきました。

http://kikyou.info/tvp/bbs/bbs.cgi?mode=&action=treeall&num=10082

というわけで、演算誤差が原因との事でした。まあ、プライマリレイヤはltOpaqueで十分だと思うので、特に問題はない、かな？
プライマリ以外は……どうだろう。多分大丈夫だと思うけど。

以下のような感じで、外部からオブジェクトのスーパークラスのプロパティにアクセスする事が可能です。
TJS2おもろい。

//例えば、Layerクラスを継承したSubLayerというクラスからインスタンスを生成する
var layer = new SubLayer(window, parent);   

*(&Layer.width incontextof layer) = 100;                 //setterを呼び出す
System.inform(*(&Layer.absolute incontextof layer));     //getterを呼び出す

メソッドなんかだと、Dictionaryクラスのメソッドを呼び出すのにincontextof演算子はほぼ必須ですので、見慣れたもんですが、プロパティの方はあまりこういう呼び出し方はしないのではないでしょうか。
先に紹介した縦書きレイヤクラスなんかで威力を発揮すると思います。
実際に運用する際に、それが縦書きレイヤなのかそうじゃないのかわからない状態でオーバーライドしてしまったプロパティ（widthやheightなど）を参照したい場合。
スタンダードに行くなら、instanceof演算子を使って処理を分けるのが普通でしょうが、似たような処理を2回も書くのはめんどくさいですもんねえ。＾＾；

値が不定のものもあるので、ぴったりこの通りというわけではないです。まあ、参考程度に。
2.28 stableにて書き出しました。

(続きを読む...)