Jewel-mmo開発日記

RubyでMMORPGを作る過程を記録する日記。 Yokohama.rb 発起人。
2007-10-31

[アイデア]武器の成長〜魔法のアイテム〜

武器や防具はまれに魔法のアイテムに生まれ変わる。 魔法のアイテムが生まれるには、そのアイテムがある程度使いこまれる必要がある。

アイテムを装備したキャラクタが消滅するとき、稀に魔法のアイテムが生まれることがある。 通常アイテムが魔法のアイテムに変わる確率は1%程度。

例えば通常アイテム「ロングソード」は魔法のアイテムになると「ロングソード+1」に変わる。 魔法のアイテムは精錬が可能で精錬に成功するとランクが上がる。 最低ランクが+1、最高ランクは+10。

「+10」のアイテムは数十万個に一個しか出現しない。

精錬は町の鍛冶屋(NPC)に頼むとやってくれる。 代金が必要 (無料だと単に+1の原価だけ払えばいいことになってしう →数多くやる手間が面倒 →目標レベルを選択できればいいか →その場合代金と成功率をあらかじめ表示)。 精錬に失敗するとそのアイテムは消滅する。

精錬の成功率

  • +1→+2 …… 90%
  • +2→+3 …… 70%
  • +3→+4 …… 50%
  • +4→+5 …… 30%
  • +5→+6 …… 15%
  • +6より上は10%
2007-10-31

[アイデア]アイテムの寿命

もし新しいアイテムを作り出す(敵を倒す等で入手する)手段があるのに、 アイテムの寿命が無限で永久に消滅しなかったら、 アイテムの絶対数は増える一方でその価値は時間とともに下がり続けてしまう。

ポーション等の消費系アイテムに寿命は不要だが、 武器や防具等の装備品に寿命がないと世の中が武具であふれてしまう。 オフラインのゲームならモンスターから奪い取ったアイテムを お店に売ることで生計を立てるというシステムもありだが、 MMOでこれをやると今度はお金が増え続けてインフレが起きてしまう。 (継続的にお金をNPCに支払う仕組みを用意する手もあるけど、どうせならお金はプレイヤー同士の取引の道具にしたい。)

だからアイテムに寿命を設けたいわけだけど、どうするのがいいか。 簡単なのは武具に精錬システムを設けて、 高レベルの武具ほど精錬の成功率を下げてゆくというもの。 精錬に失敗するとその武具は消滅する。 この方法だとハイレベルの武具を作り出すには多くの素材を消費しなければならず、 自然とバランスが取れる。

その他のアイデアを列挙しておく。

  • キャラクタが死ぬと一部(または全部)の装備品または精錬効果が消える(シレン方式)
  • 一度装備したアイテムは外すことができない(本企画特有)
  • キャラロストとともに装備品も消滅する(本企画特有)
  • 武器に使用回数がある(FE方式)

お金についてもう少し書いておく。 そもそも世界に一定量のお金が用意されていて、 その一定量のお金がプレイヤーの間をぐるぐる回っていれば極端なインフレは起こらない。 アイテムの流通量に応じて自然に相場が変動するだけだろう。 だからNPCを通じて(時間をかければ) 無限にお金を稼げてしまうような仕組みは用意すべきでない。

とは言っても、あくまでお金はプレイヤーの支払ったコストに対して支払われるべき。 時間と手間をかけてモンスターを倒し続けた対価であるとか、 特産品を別の遠い土地に運んで売ったときの差額とか。 モンスター狩で得られるものは、直接的な現金ではなく、 他プレイヤーに売却できる素材アイテム等であるべき。 プレイヤーの労働から得られたものとお金を交換する。

あとワールド内のお金の総量を調節する仕組みがほしい。 うまくNPCに放出させたり回収させたり。

2007-10-30

[アイデア]チュートリアルステージ

最後にボスがいる。 最初から行けるところにいるとか。→ゴーストダンジョン

  • ゴーストダンジョン
    • バトル好きなゴーストたちが作り出したダンジョン
    • フロアマスターのゴーストを倒せば、そのゴーストを仲間にできるようになる
  • 戦闘前にそれぞれセリフが出る。FFぽい
  • BF2 …… 弱い。あほごーすと
  • BF3 …… ちょっとだけ強い。レベル3で倒せる
  • BF5 …… 強め。BF4のほうが弱い
  • BF4 …… 属性攻撃で倒せる
  • BF6 …… 超強い。弱点がなくがちでやるしかない。最初はスキップするしかない
  • BF7 …… 属性攻撃で倒せる
  • BF8 …… 以降未定

もうひとつはやさしいダンジョン。BF10まで。

  • たまに強い敵がでる程度
  • 経験値の効率がいい
  • レベルが上がりやすい反面、アイテム探しやお金稼ぎの効率はすごく悪い
    • →ステージ1にとどまるのは損
  • チュートリアル系のカードが出る
  • デスペナなし?

クリアすると町外れのメニューから「やさしいダンジョン」が消えて、 普通のダンジョンに入れるようになる。

  • ミッションクリア条件はフレンドゴーストの数。
2007-10-30

[アイデア]ステージ1〜チュートリアルステージ〜

  • ステージ1はチュートリアル
  • 最初のミッション。クリア条件は6人のゴーストに認められること
  • ステージ1は絶対時間に縛られない
    • この期間限定で成長のスペルカード→時間進行(life消費)
  • 成長のタイミング
    • 定時成長
    • コマンド成長
  • 成長の要素
    • str …… +1〜+2
    • mag …… +1〜+2
    • agi …… +0.1〜+0.2
    • ジョブレベル …… exp 50〜100

ステージ1の 成長はスペルカードで。 より具体的に。

  • 案1. 育成コマンドを実行できるスペルカード。もしくは育成コマンド回数を増やすカード
    • 既存のdayコマンドの回数を増やすだけ。
  • 案2. 育成コマンドと同じ働きをするスペルカード。育成コマンドの種別に応じたカードを用意
    • strアップ、agiアップ, magアップ、レベルアップのカード
    • それぞれが簡単に入手可能。敵を倒すとか
    • これダンジョンの中でも使えるのか?→許可してしまえ

どっちにしても結局スペルカードを使うのだから、2の方が手順が少なくてよいか。 でも1を持っているだけで自動的に使われるする手もある。 しかし、勝手にカードが減るとUI的に不統一感が出てしまう。

まとめ。

  • 育成のカードはチュートリアルダンジョンの敵がドロップする。ただしステージ1にいないと使えない
  • 育成カードには、育成コマンドに応じたカードが用意されていて、使用するとその場で育成コマンドが実行される
  • 育成カードはlifeを5ポイント消費する
  • 育成カードを使用するとインフォメーション画面に遷移する
  • コアカードに変化するレプリカカードがある。これも敵がドロップし、使用するとlifeが減る
  • ×レプリカカードから複製したカードは売買できない
  • レプリカはCランク以上のカードには変化しない
2007-10-30

売れ筋

え、なんかすごい勢いで売れてるんですが……。

都会っ子 純情

2007-10-30

bakagaiku on rails

もちろん、そういう外部のアーカイブの中身にまで責任は
持てませんけどね。こっちで消した内容がそっちに残って
るとか、そういうのは自分の関知するとこじゃないわけで。

たまにドキッとさせられる内容があったりするけど、自分の所のやつはRSSで見てるから一応一度は目を通しているはずだよな……。 本家で最新のエントリが書き換えられたときには、それに上書きする仕組みを入れてあるので、古いエントリを修正されない限りはちゃんと同期するはず。 どうあれ責任取れなんてことは言わないけど。

主に自分の利便性とあとネタとして作ったもので、公開するときにあんまり考えていなかったんだよね……。

2007-10-30

[Rails]Integration Test

先日からIntegration Testに挑戦(いまさらだけど)。噂には聞いていたけど使うのは今回が初めて。これまで結局テストはほとんど書いてなかったけど、これはいい。 こんなのがほしかった。

ひとつの流れの中で、ログイン失敗→サインアップ→ログイン→ログアウト→ログイン→ホーム画面表示→キャラクター表示→他人のキャラクター表示失敗、みたいのが書けちゃう。

2007-10-23

[イラスト]ぱっつん

画像の説明

うーん、これはまだラーニングには程遠い。 たぶんまた当分の間、絵を描かないと思うので無理やりアップできる形にまとめたけど、 まだいろいろ見ながらでないと、まともに目や口が描けない。でもこういうラクガキを繰り返していればいろんなパタンを習得できそうな気はする。

よく見ると左右のバランスがおかしい(結局この狂いが下手に見えちゃうんだよね)。あーあと、前髪がうまくセットできなかったのでかなりおさえめにした。アホ毛は一本に戻した。髪の毛の練習も別に必要だな。とりあえずは目、鼻、口をもっと勉強したいし、他にもいろんなタッチのぱっつんを描いてみたい。

あー、えっと今回ラーニングを試みてたのはネギま!4巻の……えっと誰だろ名前はわからない。ネギとこのはのデートを追っかけている娘。

2007-10-23

[イラスト]ラーニング失敗

画像の説明

なんかこうやって描いているとさっき生まれたばかりのキャラクターにだんだん愛着がわいてくるから不思議。名前はぱっつんにしよう。あ、アホ毛が増えた。

普通に描くのがうまくいかないのでちょっと違うのを描いてみたけど、なにはともあれひとつのパタンをラーニング成功。

2007-10-23

[イラスト]ラーニング

とりあえずポーズ描写の目処は立ったので(はやっ)今度は人物の顔に挑戦。

家にあるマンガ本を見ながら人の顔を描いてみる。 あれ、あんまりうまくかけない。 子供のころはマンガの絵とかはそっくりそのまんま描けたはずなのに……。十数年の間に腕が落ちたのかなあ。

とりぜず、目と輪郭の描き方とひとつラーニングしたい。

2007-10-23

[イラスト]人物を描く(2)

画像の説明

今回は前回よりもっとマシな絵が描きたいということで、ちょっと工夫。

フィギュアっぽい人形買ってきて→写真にとってシルエットをトレース→体のラインを修正→顔と髪の毛は自力で描く

という手順で作成。髪型、特に前髪に苦労の跡が見える。眉毛を隠したくなかったので(隠すと眉毛の練習にならないから)前髪はぱっつん。あとアホ毛を入れてみたらなんとなくそれっぽく見えるようになった。

顔はてきとーなんだけど、とりえあえず実験なので細部は深く追求しない。

今回の人形はデフォルメされてて、これでもだいぶ手足を細くしたり関節辺りを太くしたりしてちょっとリアルにしたつもり。今回の手法はよさげなので今度はもっと頭身の高い人形で挑戦してみたい。

ちなみに今回使った人形はこれ↓。680円で購入。

ピンキーストリート #14 PK-014

2007-10-22

ポジションペーパー

昨日の勉強会で次のポジションペーパーが配られてました。

都会っ子 純情

2007-10-22

第1回Jewel-mmo会議に行ってきた

夜はメンバーを恵比寿に呼んで会議。

構想をいろいろ話したんだけど、既存のゲームからかけ離れたアイデアが多いせいか、いまいち伝わらないことがしばしばあった。

会議で話した主要事項。

  • ゴーストのセリフ案の発表
  • ロードマップ
    • 2008年4月1日 …… α版リリース
    • 2008年7月1日 …… ベータ版リリース。キャラクターデザイン発表
    • 2008年7月〜12月 …… 販促キャンペーン第1弾を展開(←これ言い忘れた)
    • 2008年末 目標プレイヤー数200人(登録ユーザー数1000人)
    • 2009年 …… 販促キャンペーン第2弾を展開(←これ言い忘れた)
    • 2009年末 …… 目標プレイヤー数1000人(登録ユーザー数5000〜10000人)
  • その他アイデアを語る
    • 吟遊詩人システム、シナリオブログ
    • デザイナ超重要
    • 投票システム、投票によるアカウント停止
    • 小回りの利く開発で他にないサービスを(自分で特殊能力を作り出せる夢のスペルカードとか)
    • ユーザーと一体感のある開発と運営
    • 大人が知らない携帯サイトの世界

※キャンペーンの詳細は未定だけど例えば、iPod touchプレゼントとか。アイデア求む

2007-10-22

[Raisl]Rails勉強会@東京第23回に行ってきた

昨日のRails勉強会に行ってきた。

朝、娘を模試会場に送り出した後、恵比寿へ。初のランチ会があったため、11時30分に会場(ドリコム様)入り。

前半はYuumi3さんの初心者セッションへ。初心者ネタはメタ的な興味からなるべく参加するようにしている。Yuumi3さん、継続的に初心者セッションをやっているようですばらしい。その場で何か手伝えといいのだけど。

後半は瀧内さんのプロファイルのセッションに参加。 なひさんとゆうぞうさんがいらっしゃって、なんかすげー濃い内容になっていた。 まったく使ったことのないRubyのプロファイルの話とか、濃すぎて意味がわからないんだけど、こんなこと出来るんだ!って感じでひさびさにすごく楽しかった。

ランチやふりかえりのときの話とか、いろいろ楽しかった。 最後に瀧内さんと会場を提供してくれたドリコムさんに感謝。

2007-10-20

ホワイトボード購入

先週ホワイトボードを購入した。 図形問題の学習用に買ったのだけど、うちの家族はみんな絵が好きなのですぐに落書きが描かれる。長男は数字が大好きで数字ばっかり、どうぶつ達の絵は娘が、人間犬は……。

ホワイトボード楽しい。

ラクガキ

画像の説明 画像の説明 画像の説明

2007-10-20

・・・

to

2007-10-20

[Rails]helperとcontent_tag()で書き直してみた

もろはしさんからコメントを頂いたのでさっそくヘルパーとして実装してみた。 content_tag()は知らなかったので今まで使っていなかったよ……。

module ApplicationHelper
  def action_help
    html = begin
             render :partial => "helps/#{controller_name}_#{action_name}"
           rescue ActionView::TemplateError
             $!.to_html
           rescue ActionView::ActionViewError
             nil
           end
    html ? content_tag(:div, html, :class => :help) : ''
  end
end

ビューからの呼び出しは次のようになる。

<%= action_help %>

これまでヘルパーはあまり使ってなかった。というのはERBにガンガンロジック書くのが気にならないので。自分しか編集しないと割り切ってしまえば、ERBに何が書いてあってもいいかなと。でも今回の件はわざわざrhtmlを作るより、ヘルパーにメソッドとして定義するのが正解だと思う。

to_htmlというは、独自の拡張で、application_helper.rb(ここでいいのか?)に次のように書いてある。

class Exception
  def to_html
    "<h2>#{self.class}</h2>\n#{message}\n<pre>#{backtrace.join("\n\t")}</pre>"
  end
end

ちなみにビュー好きになったのは、勉強会でもろはしさんが「表示に関することならビューでやってしまう」おっしゃっていたことにインスパイやされた結果です。

2007-10-20

[Rails]ビューに書くのが好き

最近のオレはなんでもビューに書く傾向がある。 コントローラを書くのはDBに書き込むときだけで、ただ表示物を表示するだけの場合はビューで直接findしてしまう。 するとコントローラがすごく小さくなった。 とうぜんビューは大きくなるんだけど、今はゲームデザインの過程であれこれ悩んでUIを実装してみる作業ばっかりだから、 編集がビューに集中すると楽。

partialを多用してて細切れのrhtmlがたくさんできてるけど、気にしない。 次のような形でpartialを使う機会も増えている。

<%=
  html = begin
           render :partial => "helps/#{controller_name}_#{action_name}"
         rescue ActionView::TemplateError
           $!.to_html
         rescue ActionView::ActionViewError
           nil
         end
  html ? %Q!<div class="help">#{html}</div>! : ""
%>

help文をpartialで定義すると自動的にページに埋め込んでくれる仕組みなんだけど、 このテンプレート自体もpartialでlayoutから呼び出される。 こういうロジックをいっぱいビューに書いちゃう。

2007-10-20

[開発ログ]UIのアイデアをビューにメモしておく

まとまった時間が取れないので、電車の中とかで思いついたUIのアイデアをメモする形でビューを書いている。表面上の見た目を作るだけで、アクションは機能しないんだけど。細かい仕様は単に文章でボタンの横とか直接に書いておく。

あとはゴーストのインストールとアンインストール、 ユニットのフォーメーションのUIを考えれば、 基礎的なデザインが一通り決まる。

  • ゴーストのインストール
  • ゴーストのアンインストール
  • ユニットのフォーメーション
2007-10-18

[アイデア]ヘルプメッセージ案

このページがゲーム世界のホームです。ここからキャラクターやアイテムなどのデータを確認したり、ショップやダンジョンの入り口に移動することができます。また下のチャットでは同じ町やダンジョンにいるプレイヤーと会話をすることができます。 →最初に何をすればいいの?

2007-10-18

[開発ログ]シナリオ担当者と打ち合わせ

昨日は秋葉原に用事があったのだけど、時間に余裕があったから飯田橋の職場から秋葉原まで歩いてみた。 すりとシナリオ担当者がついてきてくれて、歩きながら打ち合わせ。 じゃんがららーめんを食べて、さらに時間的余裕があったので、 キャラクター系グッズを眺めながらあれこれ打ち合わせした。

キャラクターの方向性とか抽象的な話が多くなったけど、狙ったものをちゃんと実現できるといいな。

見えてきたコンセプトは「外見的属性×内面的属性」を 自由に組み合わせることができるキャラクター作り。

2007-10-18

[開発ログ]UIに手を入れる

Railsベースで開発を進めているわだけど、現状でもそこそこ動く形にはなってきている。 ただUIがいまいち気に入らない。 まず表現したいのはデータ観覧の楽しみなんだけど、 今のデザインはどうも発想が既存のゲームのUIに縛られている気がする。

というわけで、いろいろ考えながら手を入れているんだけど、 ガタガタになっててショップとか操作できない状態。

これまではmixi見たいなトップページを考えたんだけど、 トップはチャット画面のみでいいような気がしてきた。

2007-10-18

[アイデア]ゴーストの好きな食べ物

  • 好きな武器

さらに。

  • 好きな食べ物

その他メモ。

  • 性格は女性型なのに男性型のモデルをなんなく乗りこなすタイプ
  • 性格やセリフは易しいけど、かといって女性型には決して乗れない男系ゴースト
  • 最強、完ぺき、高潔なモデルに、最弱でへろへろのどじっこゴーストを乗せたり
2007-10-18

[アイデア]楽しみ

以下メモ。

  • データ観覧
  • 更新情報チェック
  • 戦闘/アイテム探し
  • 会話
  • 開発参加
  • 世界観のカスタマイズ

データ観覧の楽しみ

  • キャラクターデータ
  • アイテム一覧
  • カード一覧
  • クリアクエスト一覧

静的なHTMLが望ましい。

更新情報確認の楽しみ

毎日数個から数十個のエントリがRSSで配信される。

  • 公務(オートバトル)の結果
  • トレード情報
  • 世界の動向
    • たとえば天気→農作物に影響
    • 中ボスモンスターの登場
    • セーフレベルの変化
  • バージョンアップ情報
  • 他プレイヤーの発言

RSS, メール。

リアルタイムコミュニケーション

  • チャット
  • トレード
  • プレイヤー対戦
2007-10-07

ニンテンドーDSブラウザー

ニンテンドーDSブラウザーに対応させてみるというのはどうか。 実物を見たことないので買っておこう。 自分の作ったゲームの画面がお手軽にDSの画面に描画できるというのは面白いかも。

ニンテンドーDSブラウザー(ニンテンドーDS Lite用:DS Liteメモリー拡張カートリッジ同梱)

2007-10-07

[アイデア]ダメージ計算その他戦闘に関わることのメモ

キャラクターの能力・スキル等を決めたいので、ダメージ計算方法を中心に戦闘システムに関するアイデアを思いつくままにメモ。

プレイヤーの数値を把握させてあれこれ考える余地を与えたいから、 ダメージ計算のロジックは人間が頭で計算できるほど単純なものがいい。

戦闘に関わる基本要素

  • STR
  • 武器
    • 定数
    • 乱数 0-x
  • Jobスキル
  • 後方支援
  • STR
  • 装備
  • Jobスキル
  • 後方支援

攻撃力

攻撃力はSTRと武器攻撃力の合計値。 武器によってはボーナス値を持っていてランダムな値をダメージに加算する。

攻撃力 = STR + 武器の攻撃力
攻ボーナス = 武器の攻ボーナス

防御力

キャラクターの防御力は防具でのみ決まる。 防御力は装備品の防御力の合算値となる。 ただし盾の防御力は初弾にのみ有効。

防御力 = 装備品の防御力の合計

AGI値を防御力に加算する手もあるが、 AGI値は攻撃順序を決定する重要なパラメータとなっているので ここでは影響させないことにする。

ダメージの計算方法

ダメージ = 攻撃力 + rand(攻ボーナス) + 攻撃支援 - (相手の防御力 + 相手の防御支援)
(ダメージは最低1)

最大HPの計算方法

HPをSTRに比例させればSTRを防御力に影響させる必要はない。

hp = str * 5

防具

  • 盾 …… 初弾のみを防ぐ。効果は大きい
  • その他の防具 …… すべての物理攻撃を軽減する

戦士のスキル

戦士のスキルに物理攻撃にボーナス値を与えるスキルを用意する必要はない。 なぜならば物理攻撃に関してはジョブ毎の装備制限で同じ効果を作ることができるから。 つまり戦士にスキルは不要。 その場合、戦士の長所はあらゆる武器を使いこなせることである。

他のジョブとの組み合わせを考えると、 FFのように剣装備や斧装備、盾装備をスキルにするのも面白い。

後方支援

悩むのは、たとえばアーチャーに直接攻撃と後方支援の両方の能力を持たせるかどうか。 もし両方できるならその使い分け(UI)をどうするか。 UIを考えるとどちらかに固定したほうがいいいか。

アーチャーの役割は、直接攻撃を受けない中列から物理攻撃を行うことだ。 初弾をアーチャーに撃たせてシールドをはがすことができる。

単体モンスターには複数毎のシールドを持たせないとダメかも。

あと攻撃支援と防御支援、さらに初弾支援を分けると人数的に役者が不足するかも。 たとえば5人でPTを作るとすると、

  • A アタッカー1
  • B アタッカー2
  • C 後方支援1
  • D 後方支援2(シーフ)
  • E 回復1(後方支援?)

これが標準的なバランスPTになるのかな。 Cが攻撃支援して、Dが防御支援、Eは戦闘中の回復役に充てるとすると、直接支援は2つしかできない。 しかしたった2つしかできないということは、逆に支援1つの価値が高まり、 組み合わせ次第でパーティの戦闘力が大きく変わって面白いかもしれない。

スキル

スキルには2つの種類がある。 ひとつはアクションスキル。もうひとつは状態スキル。

支援系にAGIの意味を持たせるか悩むのだけど、 アタッカーAGI依存でもAGIの意味は十分に出せるので、支援者のAGIは無視で。 そのほうが楽だし。

アクション

  • 追い討ち …… 攻撃支援。AT
  • ? …… 攻撃支援。MAG
  • 後方支援A …… メイジによる攻撃/防御支援。MAG*2
  • 後方支援B …… 僧侶による防御支援。MAG*2
  • 影縫い …… ターゲットのAGIを-1する
  • ? …… 防御支援。AGI*2
  • 残像剣
  • 分身攻撃 …… 攻撃回避効果。防御支援は受けられない
  • 遅延攻撃(ディレイアタック) …… ターンの最後に攻撃。もっともHPの少ない相手を狙う
  • 弓攻撃 …… アーチャー専用。他のジョブは弓を装備できないから

状態

  • 変わり身の術 …… 物理的な致死攻撃を100%防ぐ。戦闘中1回のみ有効

前列からの遠距離攻撃

前列に遠距離攻撃のユニットを置くと中列への攻撃が可能になる。 その場合ターゲットは前列と中列の中からランダムで決まる。 ただし中列への攻撃はダメージが1/2になる。 中列の被弾はまれなので、中列のユニットに防具をつけないプレイヤーも多い。

ちなみにメイジの落雷攻撃は全ユニットの中からターゲットがランダムで決まる。

スペルカードによる状況改善

クリティカルヒットや中列被弾で不意に発生したダメージから立て直すために スペルカードを使うことになるだろう。 不運な被弾はスペルカードによって回避できるが、 それが多く発生する場合は戦力差が少ない状態であり、スペルカードの消費頻度で戦力差が把握できる。 スペルカードの使用頻度でバランスがとられる。

アライアンス

課題はパーティ間の支援関係。 4つのパーティでひとつのアライアンスが作れるとする。

  • トップ
  • 左サイド …… トップに対して支援可能
  • 右サイド …… トップに対して支援可能
  • バック …… トップ・サイドに対して支援可能。前キャラクタを回復ターゲットにできる

サイドからの支援

サイドのパーティのユニットは通常は自ユニットへの支援を行う。 ただし、自パーティ内に支援対象が見つからない場合はトップのユニットを検索する。

バックは前列が他パーティの中列に位置する。

上記は1トップのダイヤ陣形。 2トップの場合はスクエア陣形となる。

  • 左トップ
  • 右トップ
  • 左バック …… 左トップに対して支援可能。回復ターゲットも左サイドのみた対象
  • 右バック

戦闘回数

余談。

アイテムのランクを向上させる幸運のお守りの効果のひとつに、 アイテムのドロップをスロットのストックのように特定の期間だけ大量放出するタイプがある。 天井もあったりするので、ある一定数以上の連続戦闘が可能なPTを組むという方針もありえる。 MP切れをスペルカードで補う方法もある。 つまりPTを編成するときには瞬発力とスタミナのバランスを考える必要があるということ。

2007-10-02

ツッコミをRSSに含まないようにした

スパムが多いので……。

2007-10-02

しょうがない

毎日仕事に追われていやになるのだけど、 でも今が楽しければいいという生き方にはまったく魅力を感じないので、 毎日ストレスを感じながら頭を悩ませて前進するしかないんだな。 ものを作っていると長期間こういう状態が続くけどこれはもうしょうがない。 仕事をスルーしてだらだら過ごした先には結局不快感が待っているのだし。

あれだよ、水に落とされて、ずっと手足をばたばたさせて顔を水面に出し続けてないといけない感じ。

2007-10-02

[アイデア]戦闘システム詳細

  • speedの成長は0.1単位
    • 小数第一位はキャンセル可能
  • アクションは完全にspeed順。同じときは同時にアクション
  • アタッカーが多いと死人が出やすい
    • ⇔ 1人だとダメージに無駄が出る
  • ヒールはバトル後にHP一定値回復
    • 死人蘇生
    • 全員回復
    • 最も減っているものを回復
    • 蘇生はlifeが0.1ダウン
    • speed順に実行
    • バトル中の回復もあり
    • バトル中の蘇生はない
    • 複数プレーヤーによるPTはヒール力増大
  • ミッションは勝ち抜き戦
  • スペルカード
    • ヒール
    • speedアップ/ダウン
  • レベルはジョブアビリティ
  • 戦闘中の操作
    • スペルカードを使う
    • 逃げる(これもスペルカードにすれば、インターフェース統一)