2010年3月30日火曜日

いい画面定義方法はないか

画面構造を指示する方法を考えてます。ここは作品のキャッチが絡むので大切なところです。キャッチという意味ではイベントよりはるかに重要です。

いつしか掲示板でも悩んでいましたが、いい方法はないかなあと。

以前、熊恭太郎雑記では、グラフィカルな戦闘画面や迷路画面を紹介してきましたが、ああいった画面を作ること自体は、ゲーム側については簡単なのです。

面倒なのが、シナリオ作者がどうやったらアレを指示できるかなのです。HPを表示するのにも書式がありますよね。横棒グラフを表示したいかもしれないし。顔グラフィックの横幅はどれほどなんでしょう。メッセージの表示位置をどこに置きましょうか。何行まで表示するんでしょう。

すべて数値が決まれば解決です。問題はその数値がシナリオ作者側の頭にあり、私が決めることではないということなのです。

ということで、画面編集の方法について、何かご意見があればよろしくお願いします。
See also:
以下は過去の記事。参考リンクです。

2010年3月28日日曜日

専門知識は操作しながら学習させたい

Desigeonを使うと多くの場合、キャラクタの能力値を活用するゲームができあがります。

数値に対するプレイヤーの興味は、その価値を意識させたときに生まれるのだと思います。言葉で説明したり、ゲーム的アクションが起こる前に表示しても価値が見えません。価値が見えないうちはゴミ情報ですから、見れば見るほど眠くなる、興味を無くす恐れがあります。

数値への興味がないところから始まる

ツールと向き合うシナリオ作者の目の前には、編集項目がありますから、値の設定を考えることにエネルギー注ぎます。そのことに疑問を抱きません。私はここが気になります。

思ったのは、能力値というのは数値であって、それ自体にはゲームプレイヤー側が興味を持っていないということです。シナリオ作者とは入り口が違います。

例えばジャンケンゲームに「勝率」というパラメータを作るとします。これが何を表すかは分かりますでしょうか。私は二つの意味を想像しました。
「勝率」パラメータの意味
  • ジャンケンに勝つ確率
  • ジャンケンに勝った確率
同じ勝率という名前のパラメータでも、上の二つの意味は違います。前者は今後の勝率に影響し、後者は実績を表すのみで今後の勝率には関係ありません。

Desigeonでは身近に設定項目があり、すぐに設定できますから、こういったことを考えて入力するだけで終わってしまいます。

ですが私は、勝率というパラメータを上のどちらの意味として使ったとしても、ジャンケンをするときのプレイヤーはそれについて興味を持たないと思います。特にゲーム開始直後はそういう傾向がありそうです。

興味を持ってもらえないことを序盤に提示して、プレイヤーにいい影響を及ぼすとは考えにくいです(※1)。

プレイヤーは操作することに興味がある

ジャンケンをするときのプレイヤーは、武器であるグー・チョキ・パーいずれを出すかを考えます。このとき、グー・チョキ・パーという情報に比べて、単なる「勝率」という数値は相対的にどうでもいいはずです。

では実際にジャンケンをするとき、以下のように表示されていたらどうでしょう。
  • チョキ:60%
  • グー:85%
  • パー:25%
今度はパーセント値を表示しました。

ですが注意です。ここでは「それが何の数値であるか」を伝えていません。

数値の意味は示していませんが、グーチョキパーを選ぶ際にこれが表示されていたら、プレイヤーとしては意味が気になりませんか?

数値の意味が気になったら、プレイヤーは自ら意味を調べるか、試行錯誤して数値の意味を理解しようとするはずです。興味を持ってもらえるなら、数値を表示する意味があるし、数値の詳細を作者が定義する価値が出てきます。

操作に必要な数値であるか

私が思うに、能力値というものは「操作に必要な(有用な)情報であるか」という見地が欠けると、プレイヤー向けの大事な目的を見失うのではないかと。

ゲームを象る「前提情報」として実装すると、あまり役に立たないのだと思います。

例えば、操作が絡まず失敗しやすそうな動機づけが以下の例です。
定義の時点で「操作」を意識しておらず、これだけ考えても失敗しそう
  • 戦士は筋力が高い
  • 盗賊は器用が高い
  • 魔法使いは知力が高い
戦士の筋力が高いことは、その通りなんでしょう。そう設定すればいいのだと思います。

ただ、戦士の筋力が高いことを伝えること自体は目的ではないですよね。作者の脳内世界を伝える場所はゲーム全体であって、事前のマニュアルやキャラクタ情報シートの中ではないと思います。

プレイヤーが戦士という駒を使って操作するとき、筋力の価値を実感させることができれば、「戦士=筋力」の印象が定着して、筋力を見たり育てたりすることが目的になりうるのです。

プレイヤーは操作に興味がある

ゲームを遊ぶ際にプレイヤーが興味があるのは、操作の概念だと思います。入り口に立ったプレイヤーの頭には、数値の価値にも育成にも興味がありません。

ゲームのどこかに「筋力」と表示されていることは知っていても、それが弓矢のダメージに影響があることを認識するのは、操作に慣れてからです。

まして、筋力5がどれほど大事な数値なのか、3じゃダメなのか、6あればゲームをクリアできるのか、学ぶことは不毛ですし無理です。

同じことは、固有名詞を割り当てるアイテムやコマンドにも言えると思います。剣がないと殴れないから、剣を買うわけです。ファイアボルトを撃たないと勝てないから、撃つわけです。剣やファイアボルトの存在を伝えること自体は、目的ではないわけですから、事前に伝える情報としては慎重になるべきだと思います。

ゲーム側の分かりやすいリード

おそらく、Desigeonのような数値論理ゲームにおいて、分かりやすいリードの仕方は以下のような感じになると思います。
オークが現れた!
  1. 行動を選んで下さい:「攻撃(筋力5)」「ファイアボルト(知力3)」「ポーション」
    • 「攻撃」を選びます
  2. 攻撃するには武器が必要です。どれを装備しますか?「剣(威力3)」「斧(威力4)」
    • 「剣」を選びます
  3. オークを剣で殴った。3ポイントのダメージを与えた!
何が言いたいのかというと、能力値も武器もコマンドも、操作ほど重要ではないということです。

ご覧の通り、筋力5はコマンドを選ぶときに知ることができれば充分です。武器も攻撃するときに選べればいいのです。事前に店で選んでもらう場合よりも、簡単に興味を持ってもらえそうです。

まとめ

専門性が高い能力値の仕様やコマンドの仕様は、操作しながら学習する形を選べるようにすべきだと思いました。プレイヤーが理解する前に表示すると、つまらなくなって眠気を誘う恐れがあります。

学習というのは、単にテキストを置いておくというだけのものではないのだと思います。必要なときに必要な情報を表示することを指すのだろうと。

プレイヤーが慣れてくれば、それ以降はアイテム収集やキャラクタ育成を能動的にやってくれるはずです。そこから先は、シナリオ作者の皆さんが趣向を凝らすダンジョン探索ゲームの本領が発揮されるんじゃないかと思います。
※1 私はツールを使って能力値の設定を考えるだけでも楽しいですし、データを弄ることを楽しむこともDesigeonの目的の一つです。ですがツールとして欲しいものは編集の娯楽性だけではないので、今回はプレイヤーに向けた表現という観点で能力値の位置づけについて考えてみました

2010年3月22日月曜日

Version 1.74の予定

以前からアナウンスしていた、計算手順の新仕様を何らかの形でスタートさせることを目標にしています。

一度にたくさん進めることができないので、いつできるかわかりませんが、全体としてやりたいことを詰めていくと、結局はこの辺の需要に行き着いてしまい、他にやれる機能があまりありません。



もうちょっと具体的に、どんなことを考えているかは2010年3月13日の記事「詳細イベント機能の開発」に書いたことがあります。

はじめは、その計算手順を実行できる箇所が少なく、それほど役に立たないのですが、これはイベント定義への基礎をなす部分なので、まずは動かしてみたいと思います。

いずれは以下の変化を見込んでいます。
  • 迷路イベントで細かい指示を出せるようになる
  • 迷路エリアの各率を計算手順化
  • コマンドの各要素を計算手順化
  • コマンドの各条件を計算手順化
  • コマンドの実行内容をイベント化
  • 戦闘の各場面でイベントを挟む
  • 街でイベントを実行する
  • 施設でイベントを実行する
新計算手順を実行できれば、上の要素について、既存の設定から置き換えていく作業は順調に行くはずです。

イベント命令自体の充実についてはまた別の課題があります。特に、メニューや画像に関する命令にどんなものを用意したらいいのかという点が課題です。

それに先だって、メッセージの表示形態も決めねばなりません。現在のようにプレーンテキストを固定サイズで表示するのみでは格好良く飾れないので、どんな風に画面指示すべきかと頭を抱えています。

他にも、ここ一年ちょっとのバージョンアップでなおざりになっていた編集ツール画面の見直し等も少しやりたいと思っています。機能を強化すると、その分、インターフェースも慎重に整理しないとかえって使いづらくしてしまいますね。

2010年3月20日土曜日

Version 1.73

コマンド習得条件の設定に関する変更

コマンド編集項目のうち、習得条件の設定の方法を変更しました。コマンド編集画面の習得条件ボタンを押すと、ダイアログボックスが起動するようになっています。

使い勝手が変わりましたが、機能はほとんど同じです。

また、これまで成長画面にあった習得条件の「他コマンドレベル」は、今回設けた習得条件のダイアログボックス側に移動しています。成長画面側にも残してありますが、古い方を使うメリットは特にありません。

コマンドの習得条件には、排他コマンドを指定できるようになっています。これを使うと、Aを覚えたときにBやCを忘却させることができます。

改修

  • マップ編集画面のイベント条件「19.アイテムを持っている(荷物&装備)」のアイテム数判定を正しく行わない
  • 宝箱の出現アイテム2設定に設定したアイテムについて、ゲームでは未鑑定で出現するはずのアイテムが鑑定済みで出現する
  • 宝箱の出現アイテム2に設定したアイテム候補が、ゲームではすべて出現する(本来はいずれか一つをランダムで選ぶ)

その他

最近、内部的にいろいろ変更しているので何か悪い影響が出ているかもしれません。試してみて気づいたことがありましたら、遠慮無く掲示板・メール等でレポートお願いします。

作り中の機能については少しずつ出していきたいのですが、動作検証が不足していて、設定をあえてマスクしているという状況です。どこかで出していきたいとは思っていますが、はっきりと予定を示すことが出できません。

さまざまな変更は、内部的にはだいぶ適用されています。それが既存の機能に影響を与えていないか、動作確認をすることも前進になるので、もし余力がありましたらいろいろお試し下さい。

2010年3月18日木曜日

メッセージをWebブラウザで表示するテスト

ゲームメッセージをWebブラウザで読んだらどうなるんだろう、という試みです。

ゲーム中に出てくる「説明」等の長文メッセージを、きれいなスタイルに置き換える一つの手になるかもしれません。以下はトラップ画面。



ここで「説明」を実行すると本来は「helptrap.txt」を表示しますが、かわりに「helptrap.html」を置いておき、それを表示してみました。中身は普通のHTML系文書です。



こんな風に、埋め込まれたIEがレンダリングします。IEの内包機能はほとんど使えるはずです。

フォントサイズや色設定をどう反映させるか、一発目の起動が遅い、といった課題はありますが、少ない仕事量でブラウザの表現力をそのまま利用できることには意味があるかもしれません。

プレイヤーに、ブラウザでマニュアルを開いてもらう手もありますが、フルスクリーンなら埋め込み式の方が使いやすいと思います。

どうにもならない問題として、プレイヤー環境におけるIEの設定をそのまま引き継ぐ点があります。カスタマイズしまくりのIEが入っていると、シナリオ作者が考えた通りに表示されないことがあります。

使えるかなあこの手。

2010年3月17日水曜日

つぶやき環境はTwitterの方向で

さほど重要ではない、短いコメントを垂れる場所としてはやはり、Twitterがいいかなあと。Desigeon専用のアカウントでやろうかなと。

Twitterは扱いづらい問題も含んでいるのですが、ユーザー数が多いことが選びやすい理由です。すでにアカウントをお持ちの方もいらっしゃると思います。

といっても読むだけならTwitterアカウントは必要なくて、最新の内容は公式サイトのトップにリレーして、埋め込みブログ的な使い方をしてみます。ですからTwitter側のブックマークは不要です。

今後、小さい発言はTwitterに回そうかなと。アカウント公開のおりには公式サイトで通知します。

Desigeonアカウント側が皆さんのつぶやきを受け取るかという点については未定にしています。Desigeonユーザーが多いわけでもないのでどちらでも良さそうな感じですが、既存のアカウント(kumakyotaroアカウント)で受信する手もありますし、あとで考えようかと。

候補としては他に、はてなハイク、Timelogなどがありました。

掲示板は引き続き必要です。意志のやりとりは主にそちらでやりたいと思います。メールでもOKです。

Twitterは聞き流せる程度の呟きとか、生存表明とかに向きますが、積極的なコミュニケーションには向かないので、そこは掲示板でやりたいと思います。

長い論述や、資料的な投稿は当ブログでやっていきます。

2010年3月15日月曜日

Version 1.72.01の予定

今考えている新機能(計算手順やイベント)については、何日か時間をかけたところで終わるようなものではないので、先に不具合を片づけて、次バージョンは新機能なしで行こうと思います。

イベント等はもともと、年単位で狙いを定めるつもりだったので、焦っても仕方がないかなあと。暇さえあれば作るぜ!の連続でできるようなものじゃないですな。

ここ何日か、新機能の仕様検討を行ったり、Diseardryのチェックをしたり、幼児の世話をしたり、方々にアカウントを作って各サービスを試したり、料理をしたり、ウェブサイトのページデザイン調整をしたりしていました。ろくにやれていないのが掃除と仕事です(ダメじゃん)。

あとネット関係ですが、ブログの次は、Twitter風のつぶやきorメモサービスの選定に入ろうと思っています。

2010年3月13日土曜日

Desigeonのキャッチーな紹介を考える

Desigeonの紹介キャッチを考えています。だいたい以下の要点を押さえつつ。

  • 紹介はわずかな画像とわずかなテキストで形成
  • 分かりやすくツボを得やすそうな紹介(主文において曖昧な言葉を避ける)
  • すべての特徴を語る必要はない

いい案ないかなあ。

能力値を計算しよう

能力値を増やしたり計算できることが強味みたいなので、その辺をちらっと見せる案。

コマンドのスペシャリスト

キャラクタには職業設けることができて、それぞれに専用のコマンドを割り当てるところ。

ばらまくアイテム

迷路のアイテムとかを定期的に入れ替えできるので、そのことを。

その他

あと、モンスターの思考と、迷路の簡便エディットについて言及するのがいいかなと思っているんですが、いい言葉が浮かばなくて。

詳細イベント機能の開発

イベント命令の体系を整理しようとしているんですが、いやはや、凄まじい分量ですのう。

方針を決めて作り始めると早い気はするのですが、どんな命令を用意すべきか考えるだけで相当な時間を食われるので、決めるまでが長そうです。

とりあえず、分類を大きく二つに分けて、実装段階も分けようと思っています。
  • OSリソースが関わらない命令(条件分岐、キャラクタデータ更新など)
  • OSリソースが関わる命令(画像表示、メニュー表示,BGMなど)

要は、画面とファイルが関係しないところから、命令を揃えていこうかなと。

テキストメッセージについては画面が絡みますが、これだけはないと何もできないに等しいので、さしあたり現在のメッセージと同じ形で、単行および長文の二通りは表示できるようにしたいと思います。課題は書式かなあ。メッセージ中に変数を埋め込めないと。

イベントプログラミングはフォーム入力で

イベントプログラミングはフォーム入力でやる形を考えています。

外部スクリプトと内部スクリプトも検討しましたが、シナリオ作者のデバッグの関係で、利用者的にもツール的にも荷が重いと感じています。

このあたりのことはアンケート結果も参考にさせていただきました。

ループと配列を避ける構造

ループと配列を意識しなくて済む仕様を目指しています。ということは、これらを使いたくても使えないことになります。

オブジェクト集団に対する処理は、選択と更新という二つの命令群でやるつもりです。例に挙げると、次のような感じです。
  • 選択命令:荷物からすべての“盾”アイテムを選ぶ
  • 更新命令:選んだものを荷物から消す

選択命令によって選び、更新命令によって反映させるという形をとります。

ループと配列がありませんので、あまり複雑なことはできません。例えばパーティ(キャラクタ配列)や荷物(アイテム配列)に対する反復処理ができないということです。「ア」という文字を名前に含むアイテムがいくつあるか、カウントできないわけです。

選択命令に用意されている方法以外の形では選べません。

迷路の自動生成をやりたかったり

個人的には迷路の自動生成をやりたいのですが、これをやるには外部スクリプトの力がいります。そこに辿り着く頃には老人になっているかも。

一人で作品を作るだけなら簡単なんですが、ここまで複雑化したDesigeonで外部IFを定義するのは作業量の都合で現実的ではなさそうです。やるなら新システムですね。

最後に、構造体を公開してDLLコールする手は残されています。これはC/C++を書くのと変わりませんが、実は開発環境を持っている人にとって一番安全・確実であったりします。IDE側のデバッガを使えるのが大きい。

迷路の自動生成なんて欲しがるのは私だけかもしれないし、自分専用でやってみようかとか。

独自のグラフィクス・システムを実現できる可能性が高いのもDLLですね。戦闘や迷路のレンダリング担当がDesigeonである必要はないわけで。まぁ、.NET Frameworkの時代に今さらという気もしますが。現実的な実現手段ではあると思います。

2010年3月12日金曜日

コマンド習得に関する仕様変更の予定

コマンドの習得を判定するタイミングに関する仕様変更の話です。

コマンドの習得タイミングは現在、ゲームロード時、キャラクタ作成時、成長ポイント割り振り時、レベル変化時、転向時、能力値やステートが変化した時に判定するようにしています。

能力値の変化時にコマンドの習得判定をせず、各ターンの最後で判定する

能力値やステートが変化した際に習得判定している部分については、判定を無くそうと考えています。

かわりに、各ターンの最後で判定を入れようと思います。

このように変更する主な理由は、動作パフォーマンスによるものです。今のままではHPを1減らすだけでも全コマンドの習得条件をチェックしなければならず、とても動作効率が悪いのです。今の動作水準を維持できるなら問題ないのですが、将来的に判定機能を強化することができません。イベントを複雑化できないことになります。

この結果、判定する箇所は以下の通りになります。
  • ゲームロード時
  • キャラクタ作成時
  • 成長ポイント割り振り時
  • レベル変化時
  • 転向時
  • 各ターンの最後(ステートの影響後)

この変更によって、既存シナリオの中ではDiseardryに微妙に影響が出るかもしれません。イベントでの能力値の変化によって習得判定しているため、若干、習得メッセージが表示されるタイミングがずれる可能性があります。

コマンドの習得を計算手順で判定

上の件とは別に、コマンドの習得は計算手順の計算結果によっても判定できるようにします。計算手順で判定することができれば、必要能力値の制限数が問題にならなくなったり、標準値以外の能力値(例えば最終値。ステート込みの能力値など)で習得を判定できるようになります。

計算手順のような動作コストへの影響が想定できない判定をするとなると、現状の動作パフォーマンスが問題になります。だから前述の対応を入れることになりました。

いずれ、詳細なイベントを指示できるようになった際に、「コマンドの習得を判定する」命令を盛り込もうと思っています。

コマンドの排他機能

ステートの排他機能と同様、コマンド習得時に他のコマンドを忘れる機能を足します。

今でもコマンド習得条件に「他のコマンドレベル必要値」を指定できるようになっていて、そのとき条件にしているコマンドを忘却させる機能があります。これを使うと、コマンドの世代交代(アップグレード)ができます。

現在は2世代までしか対応できないアップグレードですが、この機能をコマンド全体に広げるような感じです。条件の有無に関係なく、Aを習得するとBやCを忘れるような設定ができるようになります。

2010年3月10日水曜日

Version 1.73の予定

v1.73では、いくつかの問題対処の他、コマンド習得条件を編集画面から分離したいと思います。

現在、コマンド編集画面に貼り付けることができるWindowsボタンの数はあと1個です。コマンド編集画面の外に設定を追い出さないとどうにもならないので、整理を始めることにしました。

コマンド編集画面の整理は、客観的なメリットがほとんどない割に、私の作業量的には大きいのですが、どうにもならないコマンドの現状をなんとかするためは必要になってきます。

現在の想定では、この対応によってWindowsコントロールの空きが14個程度できるはずです。
14個空いても、追加できる機能はたかが知れてるんですが、やらないよりはいいかなと。

空いたら、その後のバージョンで、一部のコマンド設定に計算手順を足していこうと思っています。
  • 速度
  • 実行回数
  • 消費能力値量
  • 消費アイテム量
  • 威力B
  • 自動起動の発動率
  • 射程
  • 遅延時間
14個空いただけではとても無理。時間がかかりそうです。



この他、新計算手順仕様を発進させるかもしれません。埋め込む場所はアイテム称号の出現規則と、エリアの生成物件のところが候補で、まだ絞れていません。

外道な思いつき

以下は過去に、さまざまな経緯で思いついた機能です。欲しいなとは思いつつ、機能番外編という感じの存在で、作っている機能ではありません。

それぞれは面白そうなニオイはするんですが、汎用機能として入れるには特徴が出過ぎていると思いました。こういうものをカスタマイズできるスクリプトシステムとか、イベントシステムなりが備われば、作ってみたいです。

キャラクタのアイテム封印

エネミー等のキャラクタをアイテムに変換する、もしくはアイテムに封印する機能です。使い道は以下のような感じです。
  • あとで使うと、封じてあったモンスターが仲間になる
  • コレクターズアイテム。ドラゴンのカードやスライムのカードなど
  • 使うと、封じされているモンスターに応じて効果が変わる
  • 仲間を一時的にアイテムにして持ち歩く
細かく検討したことはありませんが、何かをアイテムに封印する行為自体はそんなに難しくないのだと思います。封印したエネミーの名をアイテム名に反映したり、価格や重量に反映する仕様を考えれば、すぐにでもできそうな感じです。

ただ、問題はアイテムに封印したあとの使い道です。上の用途はどれも、アイテム個体とは関係のないところで難しい都合を抱えていそうです。

かなり外道な使い道ですが、最後の用途だけは作るのが簡単そうです。

アイテムの時限変化

時間が経つとアイテムが別のアイテムに変わる機能です。機能としては、アイテムが別の存在に切り替わるというだけのシンプルな内容ですが、使い道はたくさんありそうでした。
  • 食べ物が腐る(アイテムの使い惜しみ防止)
  • 植木鉢から芽が出て、やがて実がなる(重くても辛抱強く持ち歩いた者勝ち)
  • 時間と共に強くなったり弱くなったりする武器(昼の顔、夜の顔)
  • 一時的にゴミに切り替わって、捨てて良いものか分からなくなる意地悪なアイテム
  • 時間が経つと装備者に吸収され、ステートになる
これはわりと良いところまで実装を考えたんですが、Desigeon的には、アイテムの寿命開始時期を厳密に定める取り組みが難しいので未定になっています。これは、床のアイテムや宝箱の中身はいつ作るのが正しいのかという問題です。対策として、店販売アイテムおよびモンスタードロップアイテム専用の機能にするなど、制限付きの機能にする手もあったんですがぱっとしないなあと。

装備アイテムへのステート付与削除

店やコマンドを通じて、装備アイテム側の提供ステートを増減することを考えました。

装備アイテムは現在、装備者にステートを提供することができます。これをあとから付け外しできないかなあと。

ステートは、キャラクタ(PCまたはエネミー)の体に付与する要素ということにしてあります。キャラクタ以外に付与する使い方を始めると説明が難しくなるので、アイテム搭載ステートはアイテム内には存在せず、装備中だけ主人の体内に作っておくというイメージで機能を作ってきました。

もし、ゲーム内の聖職者や鍛冶職人が、武器や防具にステートを封入したり剥がしたりできてしまうと、ステートの役割が曖昧になり、初見の利用者に対する説明が難しくなる恐れがあります。また、ステートの機能を流用すると、アイテム評価額や重量については加工することができず、使い道がかなり限定されます。そうした理由から避けてきました。

今後も、アイテム側のステート着脱は避けようと考えています。アイテムにはアイテム専用の加工方法を考えていきたいなあと思っています。

宿屋と病院の切り離し

宿屋病院などという、曖昧な名が付けられている施設がありますね。

私は以前から、ドラゴンクエスト型の簡易治療施設がないことが気になっていました。その内容は、ゲーム中に、施設を利用するかしないかを二択で決めて、それ以外の使い方をせず、利用した場合は一定の効果が出るというものです。

現在の宿屋病院は、ウィザードリィのカント寺院をモデルにしています。カント寺院をDesigeonのルールに照らして作るなら、ああいう風にするしかないと思いました。ただ、今のものは機能が複雑に感じます。

そこで、宿屋と病院を切り離して、病院は今の宿屋病院を引き継ぎ、宿屋というただ泊まるだけの施設を追加できればなあと思っています。

施設の増設は勇気が要ります。画面をデザインするのが面倒でのう……。

壁を壊す、壁を作る

壁を壊したり作ったりする機能です。できてもいいだろうなと。

でもDesigeonの迷路は一度壊すと、戻すメソッドを用意しない限り一生壊れたままです。つまり壊す一方だと、いつか壊す対象そのものが枯渇してしまうのです。

そこで最生成のファクターを提案する必要が出てきます。壊す機能を作るのは簡単ですが、迷路の最生成を指示する機能は大仕事になります。

壊す方も作る方も、作品としては過去に作ったことがあるので難しくはないのですが、そのときは迷路を自動生成するゲームでしたので問題にはなりませんでした。

売却アイテムを店に残す

店に売ったアイテムを店の商品として残すか、という話です。元ネタはウィザードリィです。

これは機能として考えたというより、機能に存在価値を見いだそうとした感じです。

剣や薬草を店に売って、それを陳列しっぱなしにしておくメリットにはどんなものがあるだろう、と。アイテムコレクションが目的なら、コレクション専用の機能を考えていった方が楽しいんじゃないか、とか。

そんなことを考えていたら、結局、売却品を店に在庫として残し続ける決定的な理由が見つかりませんでした。

ローグライクのElonaというゲームでは、売却したアイテムが店に陳列されますが、時間が経つと消えます。時間が経つと消えるからこそ、陳列する機能を実装した感じがします。Elonaでは実際にプレイヤーの私が買い戻すことはほとんどありませんでした。

時間が経つことで戦闘開始、あるいは定期的にエネミー来襲

持っているアイテムや持っているステートが、時間切れでエネミーパーティに変わり襲って来るというものです。

使い方としては、上で述べたアイテムの時限変化や、現在あるステートの時限変化を利用することになります。

時限変化を利用するため定期的に実行することもできるので、対処をしない限り何度でも主人公を襲うようなこともできるはずです。

この案は、戦闘中に発動した場合の仕様が課題になるのですが、その先を考えていません。

2010年3月8日月曜日

レベルアップ遅延と成長ポイント割り振り先のカテゴライズ

掲示板からの抜粋記録です。

細かいやりとりは手元のメモで済ませていますが、広い範囲をカバーする内容のときはメモとしての維持が難しくなるので、そのまま保存した方がいいかなあと。



No. 1184 - Re: v1.64をアップ
投稿者 : Tawres

更新お疲れ様です。報告などを。
成長ポイント割り当てを制限すると、プレイ中の成長ポイント割り当て画面にその項目が表示されません。バグかもです。

あと結構重大なことに気づきました。LVアップ時のボーナスポイントを制限できるようになったのはいいのですが、LVアップしたときに割り振らなかった分を後のLVアップで補填できてしまいますね。

例えばLVアップ時のボーナスポイントが10、制限値が5の状態だとします。戦士キャラなので「力」と「生命力」に毎回5ずつ割り振るような成長戦略を選択していたけど、意外と「素早さ」が重要だとあとから気づいた。などというときに次のLVアップで10ポイント全てを「素早さ」に割り振ってしまうことができます。これだとキャラ作成初期に成長の方向性を意図する動機付けが薄れてしまいます。

その時点での能力の上限値=LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。

こんなこと気にしてるのはぼくくらいかもしれませんが、検討してみてください。お願いします。

書き込み日時:2009/11/30(Mon) 22:44:06



No. 1187 - 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

こんばんは。お試しいただけたようで嬉しいです。

成長ポイントの割り当て制限機能については、基本能力値ボーナスのものとほぼ同じにしてあります。これはレベルアップごとに制限値を増やしていく(割り振っていない分は累積する)機能です。

あくまで低レベルキャラクタの能力値を一部に集中させないための機能ですので、高レベルになればどの能力値にもたくさん割り振れるということにはなっています。

あとでツールの中でも補足したいと思います。

> 成長ポイント割り当てを制限すると、プレイ中の成長ポイント割り当て画面にその項目が表示されません。バグかもです。

既存のセーブデータについては、すでに成長ポイントの余りを持っている場合でも、制限している項目に対する割り当て可能数はゼロです。一度レベルアップを果たして下さいませ。

キャラクタのレベルアップはデバッグメニューからできます。

そしてバグについても気づきました。キャラクタ作成直後のキャラクタには、制限付きの項目に成長ポイントを割り振れません……。この問題については、レベルアップ時と同じ制限値を適用してみます。上のご指摘はこちらの問題かもしれません。

> その時点での能力の上限値=LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。

分かりました、オプションで用意することを考えてみます。この件は解釈が二つあるのですが、以下のうちどちらになりますでしょうか。

1. キャラクタ作成直後およびレベルアップごとに最大Nポイントの割り振りを可能とする
2. キャラクタの生涯を通じて合計Nポイントの割り振りを可能とする

前者については、レベルアップごとに制限値にリセットをかける機能になります。

これを採用した場合、ゲームで成長ポイントの割り振りを先延ばしすると、プレイヤーに不利が生じることになります。

そしてポイントの割り振りを先延ばししすぎると、ポイントが余って割り振り先がなくなる恐れも出てきます。
レベルアップしたら忘れないうちに振っておかないとなあトカ(^^;
経験値を貰いすぎて、一気に10レベルとか上がってしまう場合は……ご愁傷様です(笑

後者については能力値自体に上限を設定できますので、必要性はあまりないかもしれません。上限に達した能力値やコマンドは、自動的に割り振りができなくなります。

成長ポイントだけで成長させる能力値については、能力値側で上限を設定する方が便利だと思います。
しかしアイテム・イベント・コマンドによる成長値アップダウン(いわゆるドーピング等)も同時採用する場合は有効、ということになると思います。

書き込み日時:2009/12/1(Tue) 21:11:07



No. 1188 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

> 既存のセーブデータについては、すでに成長ポイントの余りを持っている場合でも、制限している項目に対する割り当て可能数はゼロです。一度レベルアップを果たして下さいませ。

おお、データリセットしてレベルアップしたらできました。ありがとうございます。

> そしてバグについても気づきました。キャラクタ作成直後のキャラクタには、制限付きの項目に成長ポイントを割り振れません……。この問題については、レベルアップ時と同じ制限値を適用してみます。

なるほど、了解です。

> > その時点での能力の上限値=LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。
> 分かりました、オプションで用意することを考えてみます。この件は解釈が二つあるのですが、以下のうちどちらになりますでしょうか。
> 1. キャラクタ作成直後およびレベルアップごとに最大Nポイントの割り振りを可能とする
> 2. キャラクタの生涯を通じて合計Nポイントの割り振りを可能とする

2はおっしゃるとおり、能力の上限値の設定で可能ですね。ぼくが想定していたのは1です。それで

> これを採用した場合、ゲームで成長ポイントの割り振りを先延ばしすると、プレイヤーに不利が生じることになります。

これは「先延ばしはダメよ」と説明に書けばいいかと思ってたのですが

> 経験値を貰いすぎて、一気に10レベルとか上がってしまう場合は……ご愁傷様です(笑

これはシャレにならないですねえ(笑)。一応理想を言うと「現在の上限値=割り振り作業をしなかったレベルアップ回数×制限値」ということなんですが…。1ポイントだけ使って、残りボーナスを残した場合とかを考えると、ちょっとややこしいですよね。

で、ぼくが理想とするWiz8を久しぶりにプレイして思い出しました。Wiz8ではレベルアップ作業自体が「一回ずつ」なのです。一定経験値に達したら「能力値を上げる画面→スキルを上げる画面」という流れを「レベルアップボタン」をクリックすることで一つずつ行うという。二回分の経験値がたまってたら二回連続でレベルアップ作業を行うだけなので、制限値の問題は発生しないわけです。また、ボーナスポイントを残すと割り振り画面から出れません。Desigeonとはずいぶん違う仕様なのに、またワガママ考えてたもんです;

個人的には「絶対的」制限機能は欲しい、けど大量経験値で何度もLVアップ、というのもRPGの華だと思う。うーん…さすがに優先度が高いのは後者のような気がします…。

一応「ボーナスポイントに手をつけたかどうか」を判定することができたら、上記の「現在の上限値=割り振り作業をしなかったレベルアップ回数×制限値」が可能かもしれませんが。ややこしいハナシなので見送ってくださっても構いません。

書き込み日時:2009/12/2(Wed) 01:30:34



No. 1189 - Re: 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

> 一定経験値に達したら「能力値を上げる画面→スキルを上げる画面」という流れを「レベルアップボタン」をクリックすることで一つずつ行う

それならこれをそっくりそのまま、あるいは類似の機能を作るというのはいかがしょう。

今は成長ポイント割り振りのメニューが出ているところを、「レベルアップ」とかに変えればいいんですよね。

成長ポイントという概念はプレイヤーに示す必要はなくて、単に成長させる項目が示されて、選んでもらって、それを終えたら成長ポイントは残らない。繰り越しはなし。

経験値が10レベル分溜まっていたら、10回レベルアップの作業をしてもらえばいい、ということで。

手動でレベルアップ判定するなら経験値が溜まっていることを何らかの方法で、プレイヤーに伝える機能を考えたいところですね。

そういえば旧ウィザードリィではそこの所、あまり考えられていませんでしたが、宿屋に泊まるという誰でもやる行為の中にレベルアップ判定を組み込んで、ある程度解決を図ったんですよね。

書き込み日時:2009/12/2(Wed) 22:27:16



No. 1191 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

> それならこれをそっくりそのまま、あるいは類似の機能を作るというのはいかがしょう。
> 今は成長ポイント割り振りのメニューが出ているところを、「レベルアップ」とかに変えればいいんですよね。
> 成長ポイントという概念はプレイヤーに示す必要はなくて、単に成長させる項目が示されて、選んでもらって、それを終えたら成長ポイントは残らない。繰り越しはなし。
> 経験値が10レベル分溜まっていたら、10回レベルアップの作業をしてもらえばいい、ということで。

すごい、可能なら希望通りです。基本能力値グループのボーナスと、手動成長値のボーナス、いずれにもその作業ができればもはや言うことはありません。ただぼくの求めているものは少数派だと思うので、Desigeonのデフォルトにするのはマズイですよね。その仕様をスイッチできるようにするのは大変じゃないでしょうか。

> 手動でレベルアップ判定するなら経験値が溜まっていることを何らかの方法で、プレイヤーに伝える機能を考えたいところですね。

Wiz8では戦闘後に「レベルが上昇した」というメッセージが出て、ステータス画面のキャラの顔の端っこに+マークのアイコンが表示されるようになり、それをクリックするとレベルアップ作業画面に入るようになってます。Wiz6、7も似たような感じだったかな。
> そういえば旧ウィザードリィではそこの所、あまり考えられていませんでしたが、宿屋に泊まるという誰でもやる行為の中にレベルアップ判定を組み込んで、ある程度解決を図ったんですよね。

なんで馬小屋でレベルアップしなきゃなんないんだよ、とかも思ったもんですが、制作者の都合が伝統になった一例ですよね。でも肉体関係の能力値は超回復の概念にピッタリな気もします。

書き込み日時:2009/12/2(Wed) 23:55:03



No. 1194 - Re: 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

機能はオプション設定で考えています。既存の動きは阻害しないです。

レベルアップ時の動きについては意識あわせをしておきたいです。

レベルを上昇させるタイミングと、能力値アップの作業をするタイミングに違いがあるなら、違うことを決めておかねばなりません。

【A案】
1. 経験値が必要値ぶん溜まれば自動でレベルが上昇し、各種処理をする
2. ボタンを押すことで成長ポイント割り振りの作業をする(レベルアップ処理は1で済んでいる)

【B案】
1. 経験値が必要値ぶん溜まっても自動でレベルは上昇しない
2. ボタンを押すことでレベルを上昇させ、各種処理を走らせ、その続きで成長ポイント割り振りの作業をする

Desigeonからみると、両案に違いがあります。レベルだけ先に上がるなら、成長ポイントを割り振る以外の所にレベル変化の影響が現れます。

話を伺う限りWiz8はA案のような印象ですが、話を伺う前に私が考えていたのはB案でした。

「レベルアップ」ボタンというのは、その名の通りレベルアップさせるボタンのつもりでした。でも現在のように自動でレベルが上がってしまうなら、あとから押すボタンの方は概念の異なる機能になると思います。

いかがでしょう。

書き込み日時:2009/12/4(Fri) 00:50:43



No. 1197 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

なるほど、あまり気にしてなかったので説明が中途半端でした。確認したらWiz8はB案の方でした。「レベルアップした!」というメッセージが出るのですがレベル表記は変化せず、+印のアイコンを押すとHPなどの自動成長する値が上がっているのを確認できました。

ぼくの想定しているものではA案とB案でさほどの違いはありません。そもそも気にしてなかったのは自動成長と、LVを参照する手法を使ってないせいだと今気がつきました。

個人的な好みではB案ですね。メッセージは「レベルアップ可能になった」とかにすればいいですし。

書き込み日時:2009/12/4(Fri) 20:44:30



No. 1195 - 基本能力値グループのレベルアップ作業
管理人 : 熊恭太郎

今のところ基本能力値グループのレベルアップボーナスについては、一連の話の対象からは外させてもらっています。

現在、基本能力値グループのレベルアップボーナスと、成長ポイントの設定は同時採用できるようになっています。

ですが、シナリオ側が同時に採用して、プレイヤーが両者を同じように操作することは想定していません。

基本能力値グループのレベルアップボーナスは、過去の互換性のために残している機能で、機能的には成長ポイントで賄えるので、成長ポイントと同じように拡張していくことは避けています。

拡張が必要なら基本能力値グループではなく、成長ポイントの仕組みを拡張するか、あるいは新しい機能の追加を考えていきたいと思います。

もしその機能が複雑になりそうなら、拡張はやめて、イベント編集機能に流そうと思っています。

書き込み日時:2009/12/4(Fri) 00:52:29



No. 1198 - Re: 基本能力値グループのレベルアップ作業
投稿者 : Tawres

こちらの方も説明が不十分だったようで申し訳ない。Wiz6以降では基本能力値の上昇に使うボーナスと、技能値の上昇に使うボーナスを別枠でもらえるのです。それをやりたかったので、今のDesigeonの仕様が気に入っていたのです。ポイント割り振りによる上昇制限の一連の話は、基本能力値グループと手動成長(こちらをいわゆる技能値に使う)と、どちらにも欲しい要素だったのです。書き方がマズかったと思います、ほんとすみません;

まだ思考中ですが、かならずしも別枠にこだわることもないかとも思ってます。制限のシステムが理想どおりになれば、基本能力値と技能値のボーナスを統一しても問題ないかも、と。ですのでとりあえず手動成長のレベルアップ画面機能が追加されれば非常にありがたいです。

書き込み日時:2009/12/4(Fri) 20:50:13



No. 1233 - レベルアップ遅延と成長ポイント割り振り先のカテゴライズについて
管理人 : 熊恭太郎

まだできるかは分かりませんが、面白い機能だし、黙ってこっそりやるのも今さらという気がしますので、今の考えを示してみたいと思います。

関連して、表示に関するいろいろな機能が充実する話でもあるので、結構前向きに思ってます。

さて以前お話ししたとおり、基本能力値ボーナスと成長ポイントの機能は、同時に採用して同じように運用することは想定していません。成長ポイントの機能だけ一人歩きしていきます。

この他、レベルアップの判定をいつやるかというお話がありましたが、そちらの機能と合わせて考えてみました。

1. レベルアップ作業遅延 → 後述
2. 成長ポイント → カテゴリわけを求められる

ということで、両者はセットでできるようにする必要があると思います。

レベルアップ遅延については以下の通りです。

1. 経験値が溜まるとレベルアップボタンを押せるようになる
2. ボタンを押した瞬間、成長ポイント以外のレベルアップ機能が通常通り動く
3. その場で成長ポイント割り振り作業を行う。ポイントの余りは失効

経験値が溜まったことをプレイヤーに通知するメッセージを設定することになります。

これらは面白い機能だと思いますが、両者はセットで考えなければならないことと、カテゴリ分けをできるようにすることで、キャラクタ情報が複雑になり、表示に関する新たな課題を生みます。

能力値やステートの枠が不足する問題もさらに強まりそうです。

書き込み日時:2009/12/20(Sun) 14:55:28



No. 1234 - 実現までにやりそうなこと
管理人 : 熊恭太郎

ということで、やるならまず、外堀を埋めてからにしたいと思います。
具体的には以下の通りです。

・ステートに分類を設ける(※1)
・能力値に分類を設ける(※1)
・コマンドに分類を設ける(※1)
・ステートに単行説明を追加
・能力値に単行説明を追加
・成長の対象にステートをサポート
・成長の対象にキャラクタ変数をサポート
・【重要】独立したカスタム計算手順を搭載(※2)
・【重要】キャラクタ情報をページ分けして表示できるようにする(※3)
・【重要】コマンド編集画面重量化の対策
・【目的】レベルアップ遅延機能を付ける
・【目的】手動成長のカテゴリ分けを設ける

これらは、実装する順序はどうでもいいのですが、育成の機能を多機能化すればどのみち必要になります。

成長ポイントの分類ができても能力値の枠がないとか、表示スペースがショボイとかそういう話になることが目に見えてます(^^;

重要なポイントは示したとおり三点あります。

おのおのは独立して使える機能なので、ゆっくりやっていきたいと思います。

※1. 要素名の頭に、アイテムと同じような分類名を挿入するだけです
※2. 計算手順を能力値とは別に定義できるようにして、能力値の需要を減らします
※3. 多くのキャラクタ情報をシナリオ作者が指定して表示できるようにします

2010年3月7日日曜日

計算手順はアセンブラ

Desigeonの計算手順に関する、非常にどうでもいい話について。

あんな細かいプログラミング機構を使う人がどれだけいるんだろう、と思い付けてみた機能ですが、皆さんたくさんお使いのようで、今では無いと困る機能になっているみたいです。

実装当初は本当に迷いました。理由は元ネタがマニアックだからです。今でもチェックボックスを入れないと編集できないようになっています。能力値はもっと固定仕様的に運用するつもりでした。加算能力値と乗算能力値だけを指示できるようにして(v1.17より前の仕様)。

現状、気軽に使っている人が多いようですが、計算手順そのものはCPUのアセンブリ言語(マシン語)をベースに作られている低水準仕様というかオタク仕様になっています。

マシン語というやつは、ああいう単純な命令の羅列で動いていて、C言語とかをコンパイルするという行為は、実際にああいう命令に置き換えて保存することを指します。

mov eax, 100 // eaxに100を代入します
add eax, ebx // eaxにebxを足します

Desigeonだと「計算結果」「一時記憶の値」という形で十個程度の変数を扱えますが、インテルのCPUも同様です。32ビットCPUのi386仕様では名前がeax,ebx,ecx,edxという具合に、要はABCDの4個まで変数を使えることになっています。

命令名(ニーモニック)については、インテル系だと代入、加算、減算、乗算、除算がそれぞれMOV,ADD,SUB,MUL,DIVとなっていて、書式もDesigeonの計算手順と同じで、Desigeonではそれを日本語の言葉に置き換えているだけです。ANDやXOR等も同じです。

CPUのこれらの仕様は、MMXや64ビット化のような大きなバージョンアップでもしない限り、簡単には拡張されません。ソフトの仕様に「MMXが必要」と書かれている場合は、CPUの拡張仕様が使われています。

Desigeonの利用者は部分的にアセンブラを書いているようなものだと思います。

2010年3月6日土曜日

Version 1.72

機能

能力値一時増減コマンドが平時対応
コマンドタイプの「能力値一時増加・減少」は、編集ツール側、入力条件の設定で「平時」の設定ができるようになっています。ゲームでは、当該コマンドを平時に使用すると、次の戦闘終了時まで効果が持続します
可能な限りレベル上昇判定を繰り返すオプション
編集ツール側、特殊能力値編集画面の「レベル」のカテゴリに、経験値判定を繰り返し行うオプションが加わっています。従来は、経験値獲得の機会が訪れるごとに1レベルアップの判定を行っていましたが、オプションを指示することでゲーム中、必要経験値を満たす限り2回以上連続でレベルアップするようになります
システム資料の初期化(開発者向けゲーム環境)
デバッグメニューの初期化メニューに、システム資料の初期化機能が加わっています。ゲーム中にこれを使うと、資料のシステム情報をゼロクリアできます。一部の値についてはデフォルト値で再設定します

改修

  • [改修]標準MP3をBGM演奏するとループしない
  • [改修]エネミーの固有ドロップアイテムがスタックアイテムのとき、ゲームの戦闘終了時にスタック最大数をドロップする
  • [改修]キャラクタ作成時のエクストラボーナス割り振り画面の、能力値一覧メニューサイズが縦に長すぎる

2010年3月5日金曜日

独立した計算手順テーブル

計算手順独立の構想について。



能力値の枠が不足する問題

キャラクタ能力値の枠が不足する声があることは、私としては意外に感じるのですが、その原因について少し考えています。

今のところの結論は、「可変情報を能力値に頼りすぎる」ことにあるのだと思いました。

ゲーム中の情報を自由計算できる「計算手順」を搭載した部分が現在、能力値とコマンドの一部にしかありませんが、この自由計算の枠を増やす目的で、能力値を増やしまくっているのが理由かなと。

例えば、コマンドの「速度」は現在、能力値か定数かのどちらかを扱えますよね。もし速度を可変値にしたいなら、速度専用の能力値を採用することになります。能力値数が最低でも+1個、コマンドごとに速度を変えたい場合は、その都度能力値を増やすことになります。

この辺の問題が確かなら、真に不足しているのは能力値ではなく計算手順の枠、ということになりそうです。設定事項に計算結果を指定できればいいわけで、それが能力値である必要は無いわけです。

独立した計算手順テーブルを設ける

計算手順は、イベント機能の実装を踏まえて独立させ、自由に増やせるようにしようと考えています。

例えば「コマンドの速度」には、今のように能力値を割り当てる方法もありますが、計算手順そのものを「速度」に設定できるようにするわけです。「001:速度の計算手順」をコマンド速度に割り当てて、あらかじめその手順をプログラミングしておけば、速度の能力値枠を増やさなくても速度を自由に決めることができます。

計算手順は汎用の共通テーブルに自由定義できるようにして、いろいろな速度を計算したい場合には手順枠を増やすことになります。

他にも、エリアのエンカウント率・宝箱の出現率・店の商品価格なんかにも適用したりして、だいぶ可変情報を増やせるようになりそうです。

大きな効果を上げそうなのがイベント条件判定あたりです。計算結果がゼロ以外をOK、ゼロをNGとして判定をすることで、もう少し複雑な条件判定ができるようになるはずです。

もう一点のメリットしては、現在「特殊能力値」として定義してている能力値を、レベルを除き廃止できることがあります。特殊能力値にあたる部分は計算手順で代用できます。必要なら能力値を手で増やしてもらって、それを計算手順から参照すればいいのです。これで能力値の枠が150空き、動作速度が向上します。

計算手順の枠組みをさまざまな場所に適用するには内部的に工夫が要るのですが、能力値やコマンドの計算手順で手応えを感じたので、やってみようと思いました。

アイテム称号の出現規則も計算手順で

以前述べた「アイテム称号」についてですが、これも計算手順の拡張とセットでやっていこうと思います。

アイテム称号を指示するには多くの情報指示が必要で、出現規則をすべて固定乱数で指示するだけならすでにできているのですが、出現率や称号ランクの範囲を固定でやってしまうと、活用の範囲がとても狭いものになってしまいます。計算手順のような機構が頼りだと感じました。

そのままイベントテーブルになる

計算手順の定義システムは、やがてはイベントの定義システムになっていくと思います。

計算手順を割り当てる場所には計算命令だけを許可して、イベントを割り当てる場所には、計算命令も含めたイベント命令のすべてを許可するという感じです。

イベントについて今のところの課題は、以下の二点です。

  • モジュール化をどこまで許すか
  • ループ機能および配列機能を与えるか

ゲーム制作ツールのイベント機能というのは、実質プログラミングの機能になるわけですが、プログラミングといっても実装段階がありますので、どこまで細かく弄れるようにするか判断が難しいです。

機能が細かいと使いたがる人が増えて使える人の割合が減り、機能が粗っぽいと使いたがる人が減って使える人の割合が増えるのですが、私としては己の需要以外に、利用者の方とのやりとりを通じて居心地の良さそうな位置取りをしたいと思っています。

2010年3月3日水曜日

Desigeonの公式ブログとしてGoogleのBloggerをテスト中

我ながら無謀なのか野心的なのか分かりませんが。

日本国内ではマイナー勢力であろうGoogle Bloggerをテストしてみることになりました。

管理側としても読者側としても、はっきり言って「はてなダイアリー」より使いにくいです。

でもサーバのレスポンスは速いし、Google Chromeとの相性が良かったり、Googleが持つ他機能との連携など将来性については悪くない予感を感じさせてくれます。もっとも、Googleがいつまでこの分野を維持するつもりでいるのかは知りませんが。ダメそうならまた移転ですはい。

まだテストの段階なので正式にということではありませんが、何名かに見てもらわないと動くか分かりませんし、とにかく様子を見たいと思います。