約 183,239 件
https://w.atwiki.jp/violasns/pages/5.html
仕様設計ではこんな感じで議論をすればよいだろうか アイディア段階 運用時の問題点を予想 仕様詳細 試験運用 再考 完成 特に最初問題点くらいまでは直接話し合うほうが良いかもしれないけれど、お互い忙しいのでメッセでもよいかも。 アイディア段階 「こんなことできたらいいよね」からはじめる。 そして、それを整理する段階。 少しでもよいと思ったアイディアをお蔵入りさせてしまわないこと!! 手間や欠点は度外視でアイディアを! 誰がどのように利用し得をするか?(+その必要度) 出されたアイディアからの応用の広がりは?(+その必要度) 他の機能との関係 新アイディアのコア部分は他アイディアの実装で代替が利くか?この段階ではどちらのアイディアもつぶさない. 新アイディアの応用部分は他の機能(の応用部分)とのオーバーラップがあるか? 他アイディアと比較して優先度を決める 運用時の問題点を予想 出てきたアイディアを運用する上での問題点を挙げ、手間も考慮して、試験運用に採用する機能を決定 機能ごとの問題点は? 記入の手間 検索のしやすさ 問題点をどのように克服するか? 解決できるものはその場でしてしまえ ちょっとくらい大変でも試験運用は行う 類似アイディア同士の比較 アイディアのコア部分が似ているものの比較 オーバーラップした応用部分はどの機能で実現するか? 余裕があれば「仮に自前で作るなら上で挙げた問題点は解決されるか?」もここで議論しておくと良いでしょう。 仕様詳細 採用する機能は決まったので そもそものアイディアから外れない機能を果たし なるべく運用コストのかからない ように、各機能の仕様を詳細に決定する。 試験運用 試験運用しているうちに思うことがあればじゃんじゃん感想を述べること そもそもの機能が果たされているか ではその機能は本当に必要だったのか必要とおもったものが意外と役に立たないことは多い 手間今のままだったら利用し続けたいか? 正式版なら楽になるかどうか? 新アイディアあ、こんなことできるわー 試験運用前と同様の議論をして、採用が決定した場合拡張が可能なら即試験運用に組み込む などなど. 再考 試験運用時のみんなの意見を参考に そもそもこのコミュニティの機能は役に立ちそうか?(続けるか否か) 機能を増やしたり減らしたり新アイディアで採用されたものは結局どうするか? 要らない機能は? では正式版は自前で実装するのか、そのままで行くのか ではその仕様を決めましょう 実装の分担も決めましょう環境準備(サーバ等) 機能実装(動作の実装) 見た目(デザイン,html,CSS等) 完成 今までの議論を元に詳細な仕様を設計し実装を行う 実装した人以外にも中身のこと分かっている人がいたほうが良い。
https://w.atwiki.jp/vipparty/pages/125.html
まだよく分かっていない仕様や転職条件などを報告してください。 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/fan_ws027sh/pages/13.html
★HYBRID W-ZERO3 主な仕様 「高音質通話」と「高速データ通信」がひとつに スマートフォンが快適な使いやすさを手に入れた 写真を撮るだけではなく、情報を録るカメラ 月額1,450円で利用できる専用新料金プラン 販売価格
https://w.atwiki.jp/sattisaba/pages/4.html
未決定…ただいま試験運用中につき 掲示板で意見とか聞いてるので投稿してください。 base exp所得倍率 3倍 job exp所得倍率 3倍 アイテムドロップ倍率 5倍 公平可能Lv差 10 PTボーナス なし パラメータ上限 99 VIT・AGIペナルティ 無し 転生・転生ボーナス 1回・ボーナス100 スキルツリー 無視 詠唱時間 100% ディレイ 100% 左手武器のダメージ補正を右手武器に 適用する アイテムドロップ 手動取得 カート重量 50000 自然回復しなくなる重量 90% 攻撃できなくなる重量 90% テコン・ケンセイ・ソウルリンカー・ガンス・忍者実装。 リヒタルゼン・タナトスアビス・フュゲル・オーディーン神殿実装。 今のところ本鯖になるだけ近い感じにしまする。
https://w.atwiki.jp/1ten/pages/17.html
いわゆるLAMPP的構成。 OS【確定】Linux系OS Webサーバー【確定】Apache2 メールサーバーsendmail? qmail? postfix? DBMS【確定】MySQL 開発言語【確定】PHP5
https://w.atwiki.jp/alloy/pages/14.html
まずは簡単な事例で、Alloy で仕様を記述/検査する一通りの流れを説明します。 1. 題材 今回は、単純な「ボタン」の仕様を題材にします。 以下のようなボタンの仕様を考えています。 ボタン上にカーソルがないときは、ボタンは Normal 状態です。 マウスカーソルが上に来たら、ボタンは Over 状態になります。 ボタンが押されたら、ボタンは Press 状態になります。 ボタンは自身の幅と高さを管理しています。 ボタンは以下のイベントを受け取ります。 これらのイベントはいつでも送られてくる可能性があります。 - mouse_move (x Int, y Int) //マウス移動 - mouse_pressL (x Int, y Int) //マウス左Press - mouse_releaseL (x Int, y Int) //マウス左Release ※ この仕様はかなり曖昧で不完全な仕様です。どういう曖昧さがあるのか、Alloy で形式的に仕様を書いていきながら確認してみましょう。 2. 状態空間の記述 では早速上記の仕様を Alloy で記述していきたいと思います。 Alloy に限らず形式的に仕様を記述する場合、まず最初に「状態空間」と「型」を定義します。 「状態空間」とは、対象のモデルが取りうるすべての状態の集合のことをいいます。 状態の集合は、変数の値の組み合わせで定義します。 「型」は、変数の値の取りうる範囲を定義するためのもので、集合で定義します。 このボタンの状態空間は、Alloy で以下のように記述することができます。 enum Type {Normal, Over, Press} sig Button { type Type, //ボタンの種類 width Int, //ボタンの幅 height Int //ボタンの高さ } 上から順番に説明します。 2.1. enum enum A {a, b, c, ...} と書くと、A という集合を定義することができます。 A の具体的な要素は a, b, c, ... になります。 今回はボタンの状態を表すために、具体的な要素が Normal, Over, Press の、Type という集合を定義しました。 この集合は Button のところで型として使います。 2.2. sig sig A {a, b, c, ...} と書くと、A という集合を定義することができます。 A の各要素は、a, b, c, ... というパラメータを持っています。 sig で集合を定義した場合、enum と違って具体的に要素を指定できません。 今回はボタンを表すために、type, width, height というパラメータを持っている Button という集合を定義しています。 この Button の集合で、ボタンの状態空間を表すことにします。 2.2.1. パラメータ sig のパラメータは 名前 型 というフォーマットで定義します。 type の型は先ほど定義した Type です。type は Normal, Over, Press のいずれかの値になります。 width と height の型は Int です。Int は整数の集合を表します。 Int はあらかじめ Alloy で用意されている型で、自分で定義しなくても使えます。 2.3. コメント 必要に応じてコメントを記述することができます。 一行コメント //コメント --コメント 複数行コメント /* コメント */ 3. 状態空間の検査 状態空間が定義できたので、定義した状態空間を Alloy で検査してみます。 状態空間について検査したい項目は、以下の 2 つです。 期待する状態が含まれているか? 期待しない状態が含まれていないか? 検査する方法はいくつかありますが、今回は愚直に「目視」で検査してみます。 目視で検査するには、Alloy の「指定した論理式を満たす例を探す」機能を利用します。 ボタンが取りうる状態の例を探してもらって、その例が期待しているものかどうかを目視で確認します。 3.1. 検査コマンドの記述 ボタンが取りうる状態の例を探してもらうには、以下のように書きます。 pred show {} run show これはどこに書いてもかまいません。適当に sig Button の下あたりに書いておくとよいでしょう。 pred A {論理式} と書くと、A という名前の論理式を定義することができます。 今回は特に探してもらう条件を指定しないので、論理式が空 (True) の show という名前の論理式を用意しました。 run A と書くと、A の論理式を満たす例を探してくれ。というコマンドを定義することができます。 今回は、何でもいいから例を見つけてくれ。というコマンドを定義しました。 3.2. 検査の実行 上記のように記述したコマンドを実行するには、メニューの [Execute] - [run show] を選択します。 選択すると、以下のように画面の右側に検査結果が表示されます。 Instance found. と表示されたので、何か例が見つかったようです。 3.3. 目視で検査 見つかった例を表示するには、画面上部の [Show] ボタンを押します。 以下のような画面が表示され、見つかった例が図で表示されます。 3.4. 表示のカスタマイズ 表示された内容の説明をする前に、表示を少しカスタマイズします。 enum で集合を定義すると、図で表示したときに enum の要素間に next, prev という矢印が表示されます。 この矢印はたいていの場合邪魔なだけなので、非表示にすることをお勧めします。 画面上部の [Theme] ボタンを押すと、以下のような画面になります。 ここで、左下の方の next と prev をそれぞれ選んで、左上の方の [Show as arcs] を 何度かクリックして off に変更してください。 それぞれ変更し終わったら、画面上部の [Close] ボタンを押してください。 これで邪魔な next と prev が消えます。 3.4.1. 表示内容の説明 表示された例が何を表しているのか説明します。 これは、Button0, Button1 という名前の、 Button 集合の要素が 2 個見つかったことを表しています。 Button0 の Type は Normal、width は 4、height は 7 です。 Button1 の Type は Over、width は 6、height は 3 です。 (Button とつながっていない Press は、とりあえずゴミだと思ってください。) つまり、ボタンの状態空間には、少なくとも「幅 4, 高さ 7, Normal」、「幅 6, 高さ 3, Over」という 2 つの状態が含まれているということです。 これらの見つかった状態は、特におかしな状態ではないので問題なさそうです。 3.4.2. 他の例を探す 確認した例が問題なかったので、他の例も見てみます。 画面上部の [Next] ボタンを押すと、別の例を探して表示してくれます。 何度か [Next] ボタンを押しながら出てきた例を目視で確認していきます。 3.4.3. 期待しない状態 何度か [Next] ボタンを押していくと、以下のような状態が出てきました。 Button0 と Button1 の高さが -3 になっています。 これは期待していませんでした。幅と高さは 0 以上を想定していました。 3.5. 状態空間の修正 状態空間に期待しない状態が含まれていた場合、期待しない状態が含まれないように状態空間を修正します。 3.5.1. 不変条件の記述 期待しない状態を含まれないようにするには、「不変条件」を書きます。 「不変条件」とは、すべての状態で常に成り立っていなければならない条件のことです。 状態空間に期待する状態だけが必要十分含まれるように不変条件を追加します。 不変条件は以下のように記述することができます。 sig Button { type Type, //ボタンの種類 width Int, //ボタンの幅 height Int //ボタンの高さ } { width = 0 height = 0 } sig の後ろに「{ 論理式 }」を追加すると、その論理式が不変条件になります。 今回は「width と height は 0 以上である」という不変条件を追加しました。 3.5.1.1. 論理式の記述 論理式は以下のような演算子を組み合わせて記述します。 演算子 使い方 意味 結果の型 && A && B A かつ B Bool || A || B A または B Bool => A => B A ならば B Bool ! ! A A ではない Bool <=> A <=> B A と B は等しい (A, B がBoolの場合) Bool = S = T S と T は等しい (S, T がBool以外の場合) Bool != S != T S と T は異なる (S, T がBool以外の場合) Bool > x > y x は y より大きい Bool >= x >= y x は y 以上である Bool < x < y y は x より大きい Bool <= x <= y y は x 以上である Bool + x + y x に y を足した値 Int - x - y x から y を引いた値 Int ※A, B の型は Bool、S, T の型は Bool 以外、x, y の型は Int です。 他にも色々な演算子がありますが、必要に応じて順次紹介していきます。 3.5.1.2. 論理式のシンタックスシュガー 論理式は改行して書くこともできます。 { width = 0 height = 0 } 改行して書くと、各行を で結んだ論理式と同じ意味になります。 3.5.2. 再度目視で検査 不変条件を追加したので、[Next] ボタンを何度か押しても先ほどのような期待しない状態が出てこなくなりました。 だいたい良さそうなので、状態空間はこれで完成とします。 4. 振る舞いの記述 状態空間が完成したので、この状態空間を使ってボタンの「振る舞い」を記述していきます。 「振る舞い」は、「どういう状態でどういうイベントを受け取ったら、どういう状態に変化するか」というように、事前の状態、イベント、事後の状態の 3 つの組み合わせで表現することができます。 このうち、事前の状態と事後の状態が何かを表す条件のことを、「事後条件」といいます。("事後"条件ですが、事前と事後の両方の状態に関わる条件です) Alloy では、イベントと事後条件の 2 つの組み合わせで振る舞いを記述します。 4.1. マウス移動の振る舞い まずは、「mouse_move (x Int, y Int)」イベントを受け取ったときの振る舞いを記述してみます。 4.1.1. 振る舞いの記述 Alloy で振る舞いを記述する場合、pred を使って以下のように記述します。 pred イベント名 (イベント引数, 事前と事後の状態) { 事後条件 } 今回のマウス移動の振る舞いの場合は、以下のようになります。 pred mouse_move (x Int, y Int, b Button, b Button) { 事後条件 } b が事前のボタンの状態、b が事後のボタンの状態を表すことにします。 事後条件は、pred の引数で定義した x, y, b, b を使って記述します。 4.1.2. 事後条件の記述 元の仕様を確認してみます。 ボタン上にカーソルがないときは、ボタンは Normal 状態です。 マウスカーソルが上に来たら、ボタンは Over 状態になります。 まずは 1 つ目の仕様を事後条件で記述してみます。 ボタン上にカーソルがないときは、ボタンは Normal 状態です。 とあるので、事後条件は「x, y が事前の状態のボタン上でなければ、事後の状態は Normal になる」と解釈します。 具体的には以下のようになります。 pred mouse_move (x Int, y Int, b Button, b Button) { ! ((x = 0 x b.width) (y = 0 y b.height)) = b .type = Normal } sig の要素のパラメータの値を参照するには、「.」を使います。 同じようにして 2 つ目の仕様を記述してみます。 マウスカーソルが上に来たら、ボタンは Over 状態になります。 とあるので、事後条件は「x, y が事前の状態のボタン上だったら、事後の状態は Over になる」と解釈します。 具体的には以下のようになります。 pred mouse_move (x Int, y Int, b Button, b Button) { ! ((x = 0 x b.width) (y = 0 y b.height)) = b .type = Normal ((x = 0 x b.width) (y = 0 y b.height)) = b .type = Over } 4.1.3. 振る舞いの検査 とりあえず元の仕様を Alloy で記述できたので、問題ないか検査してみます。 検査したい項目は以下の 2 つです。 事後条件に期待する事前と事後の状態の組み合わせが含まれているか 事後条件に期待しない事前と事後の状態の組み合わせが含まれていないか やり方はいくつかありますが、今回は状態空間の検査でやったように「目視」で確認してみます。 4.1.3.1. 目視で検査 例を見つける検査コマンド run を使って以下のように書きます。 run mouse_move Execute すると Instance found になったので、Show で表示すると、以下のようなインスタンスが表示されました。 表示されているものが何か説明します。 Button1 が b、つまり事前のボタンの状態を表しています。 Button0 が b 、つまり事後のボタンの状態を表しています。 カーソルの座標 x は 0, y は 7 です。 事前のボタンの状態は、幅 7, 高さ 4, Over です。 事後のボタンの状態は、幅 1, 高さ 4, Normal です。 まとめると「幅 7, 高さ 4, Over の状態で mouse_move (0, 7) を受け取ったら、幅 1, 高さ 4, Normal の状態になる」という振る舞いが、先ほど書いた pred に含まれていることを表しています。 なぜか幅が狭くなっています。これは期待していません。 なぜ突然幅が狭くなってしまったのかというと、事後条件に条件が足りないからです。 Alloy では、「変わらないものは変わらない」という条件も明記する必要があります。 先ほど書いた事後条件には、mouse_move を受け取っても、事前と事後のボタンの幅と高さは変わらない。という条件を書いていませんでした。 よって、Alloy は変わってしまう例を見つけて表示したという訳です。 4.1.3.2. 振る舞いの修正 というわけで、幅と高さは変わらない。という条件を追加します。 pred mouse_move (x Int, y Int, b Button, b Button) { ! ((x = 0 x b.width) (y = 0 y b.height)) = b .type = Normal ((x = 0 x b.width) (y = 0 y b.height)) = b .type = Over b .width = b.width b .height = b.height } 4.1.3.3. 論理式をまとめる ボタン上かどうか判定する論理式が 2 カ所あって冗長です。 pred でボタン上かを判定する論理式を用意して、それを利用してシンプルに書くことができます。 pred on_button (x Int, y Int, b Button) { x = 0 x b.width y = 0 y b.height } 「指定された x, y 座標は、指定されたボタン上である」という論理式を表す pred です。 pred mouse_move (x Int, y Int, b Button, b Button) { ! on_button[x, y, b] = b .type = Normal on_button[x, y, b] = b .type = Over b .width = b.width b .height = b.height } 用意した on_button を利用してシンプルに記述できました。 別の pred を使うときは、 pred名 [引数, 引数, ...] という構文です。 4.1.4. 再度検査 振る舞いを修正したので、再度検査してみます。 今度は以下のようなインスタンスが見つかりました。 これは「幅 7, 高さ 4, Normal の状態で mouse_move (4, 7) を受け取ったら、幅 7, 高さ 4, Normal の状態のまま変わらない」という振る舞いが、先ほど書いた pred に含まれていることを表しています。 今度は期待通りです。 なお、Button0 はゴミだと思ってください。 何度か Next を押して、他のインスタンスも確認してみます。 以下のようなインスタンスが見つかりました。 幅 1, 高さ 6, Press の状態で mouse_move (0, 4) を受け取ったら、幅 1, 高さ 6, Over の状態になるようです。 これは期待していませんでした。 Press 中にマウスを動かしたときの仕様を考慮していませんでした。 4.1.4.1. 振る舞いの修正 今回は「Press 中にマウスを動かしたとき、ボタン上であれば Press のまま、ボタン外に出たら Normal になる」という仕様にしたいと思います。 この仕様をもとに pred を以下のように修正しました。 pred mouse_move (x Int, y Int, b Button, b Button) { ! on_button[x, y, b] = b .type = Normal on_button[x, y, b] = (b.type = Press = b .type = b.type b.type != Press = b .type = Over) b .width = b.width b .height = b.height } 移動後の位置がボタン内だった場合、元の type に応じて事後の type が変わるようにしました。 再度 run コマンドでいくつかインスタンスを確認しても期待しないケースが出てこないので、mouse_move の振る舞いはこれで OK とします。 4.1.4.2 シンタックスシュガー on_button[x, y, b] = (b.type = Press = b .type = b.type b.type != Press = b .type = Over) この論理式は横に長くて読みにくいです。 A = (B C) のような形の論理式は、{} と改行を使って、以下のように記述することができます。 A = { B C } 今回のマウス移動の事後条件も、同様にして以下のように記述することができます。 pred mouse_move (x Int, y Int, b Button, b Button) { ! on_button[x, y, b] = b .type = Normal on_button[x, y, b] = { b.type = Press = b .type = b.type b.type != Press = b .type = Over } b .width = b.width b .height = b.height } ちょっと読みやすくなりました。 4.2. マウス左 Press の振る舞い 次は、mouse_pressL の振る舞いを書いてみます。 元の仕様は ボタンが押されたら、ボタンは Press 状態になります。 です。 マウス移動の振る舞いと同じように書いてみました。 pred mouse_pressL (x Int, y Int, b Button, b Button) { on_button[x, y, b] = b .type = Press b .width = b.width b .height = b.height } 4.2.1. 振る舞いの検査 run コマンドで確認すると、以下のようなインスタンスが見つかりました。 ボタン外を押したら、Over でかつ幅と高さがかわってしまいました。 これは、on_button[x, y, b] ではないときの事後条件が書かれていないためです。 何も書かれていないと、Alloy は何でもよいと解釈するので、このようなインスタンスが見つかります。 = で場合分けするときは、必ずすべての場合について考慮されているか気をつけなければいけません。 4.2.2. 振る舞いの修正 というわけで、「ボタン外を押されたときはNormalになる、かつ、幅と高さは変わらない」という仕様にしたいと思います。 pred mouse_pressL (x Int, y Int, b Button, b Button) { on_button[x, y, b] = b .type = Press ! on_button[x, y, b] = b .type = Normal b .width = b.width b .height = b.height } これで、期待しないインスタンスが出てこなくなりました。 4.3. マウス左 Release の振る舞い 最後に、mouse_releaseL の振る舞いを書いてみます。 元の仕様 ボタン上にカーソルがないときは、ボタンは Normal 状態です。 マウスカーソルが上に来たら、ボタンは Over 状態になります。 これまでと同様にして書いてみました。 pred mouse_releaseL (x Int, y Int, b Button, b Button) { on_button[x, y, b] = b .type = Over ! on_button[x, y, b] = b .type = Normal b .width = b.width b .height = b.height } run コマンドで確認しても、特に期待しないケースが出てこないので OK とします。 5. 完成 以上でボタンの仕様が Alloy で形式的に記述できました。 enum Type {Normal, Over, Press} sig Button { type Type, //ボタンの種類 width Int, //ボタンの幅 height Int //ボタンの高さ } { width = 0 height = 0 } pred show {} run show pred on_button (x Int, y Int, b Button) { x = 0 x b.width y = 0 y b.height } pred mouse_move (x Int, y Int, b Button, b Button) { ! on_button[x, y, b] = b .type = Normal on_button[x, y, b] = { b.type = Press = b .type = b.type b.type != Press = b .type = Over } b .width = b.width b .height = b.height } run mouse_move pred mouse_pressL (x Int, y Int, b Button, b Button) { on_button[x, y, b] = b .type = Press ! on_button[x, y, b] = b .type = Normal b .width = b.width b .height = b.height } run mouse_pressL pred mouse_releaseL (x Int, y Int, b Button, b Button) { on_button[x, y, b] = b .type = Over ! on_button[x, y, b] = b .type = Normal b .width = b.width b .height = b.height } run mouse_releaseL Alloy で仕様を書いて検査する過程で、以下のような元の仕様の曖昧な点が見つかりました。 ボタンの幅と高さは 0 未満にならないこと ボタンの幅と高さは変化しないこと Press中にマウスを動かしたときの振る舞い ボタン外でマウス左が押されたときの振る舞い このように、日本語で書いた仕様には曖昧な点が含まれることがあります。 しかも、がんばって日本語で仕様を書いても、人手によるレビュー以外に検査する方法がありません。 Alloy を使えば、仕様を記述- 検査を Alloy と対話しながら自分一人で繰り返すことができるので、よりバグの少ない仕様をより早く記述することが可能になります。
https://w.atwiki.jp/fan_ws027sh/pages/14.html
主な仕様 型名 WS027SH OS Microsoft Windows Mobile6.5 Professional 日本語版 液晶ディスプレイ 480×854ドット 3.5型 262,144色 モバイルASV液晶(タッチパネル/バックライト付 通信機能 W-CDMA 800/2100MHz、HSDPA 7.2Mlbps/HSUPA5.7Mlbps、PHS(W-OAM typeG対応W-SIM)、ワイヤレスLAN(IEEE802.11b/g準拠)、赤外線通信(IrDA 1.2方式/IrMC 1.1方式)、Bluetooth 2.0
https://w.atwiki.jp/1524/pages/41.html
【仕様ページを見るに当っての注意事項】 OKになってるところは仕様書き込み更新できてます。 えッ!?まだ全然できてないって? メモ張でデータにおこしたのはいいが【Wiki】に書き込むと罫線や半角スペースが全てズレる罠 XD ぶっちゃけ正直本当にかなーりメンドクサコトニナリマシタ^^^^ ・・・だが頑張って直が書きしてまs(´∀`) すぐに必要な仕様箇所あったらいってくださいまし、即変更いたします。 LOGO OK! ストーリー表示の仕様 OK! チームロゴ表示に関する仕様 TITLE OK! ログインの仕様 OK! 新規作成の仕様 NO! ゲーム終了の仕様 WORLD NO! ランキングの仕様 OK! ワールドマップの仕様 NO! ログアウトの仕様 NO! カメラ移動の仕様 NO! スタッフロール城の仕様 OK! 城選択の仕様 城クリックOK! Join クリックOK! StartクリックOK! Exit クリックOK! PLAY OK! プレイヤの移動の仕様 OK! プレイヤの通常攻撃の仕様 片手武器OK! 両手武器OK! 遠隔武器OK! OK! プレイヤの特殊攻撃の仕様 片手武器NO! 両手武器NO! 遠隔武器NO! OK! プレイヤのガードの仕様 OK! プレイヤの回避の仕様 OK! 敵戦力の仕様 NO! 味方戦力の仕様 NO! 拠点の仕様 NO! 敵のライフの仕様 NO! 味方のライフの仕様 NO! 自分のライフ,特殊ゲージの仕様 NO! 兵器使用時の仕様 OK! キャッスルマップの仕様 城の仕様 NO! レイ当たり判定用メッシュ フィールドの床OK! 城の床NO! 壁NO! 拠点NO! 兵器NO! 武器庫OK! NO! モデルオブジェクト スカイドームNO! 壁NO! 拠点NO! 兵器NO! 武器庫OK! NO! 兵器の仕様 OK!武器庫の仕様 RESULT OK!防衛成功 OK!防衛失敗
https://w.atwiki.jp/tamaserver/pages/21.html
基本仕様 Exp Base,Job 共に100倍 Drop 500倍 3次転職Lv Job65 公平圏内 15 MAXLv 通常99 3次150 MAXステ 通常99 3次120 最大Aspd 通常190 3次193 開放GMコマンド なし 計算式仕様 R前の旧仕様 罠巻き込み あり 無詠唱DEX 171 詠唱時間の比率%を100→92 首都 プロンテラ(各種NPC有り) ☆3次職に転職される方へ☆ 本鯖では3次転職時にステータスなどのリセットが 掛かりますが、この鯖ではリセットされないのが どうやら仕様…らしいので、転生後のステが そのまま3次職に引き継がれることをお忘れなく。
https://w.atwiki.jp/mrkk/pages/14.html
仕様 体験版等で判明している仕様を書くページです ※最終製品版では仕様が変更される可能性アリ 仕様Wii版から変更されていない仕様 Wii版から変更された仕様 7から追加された要素の仕様 新コース一覧 新コースについて 現時点で使用できるのが確認出来るキャラクター 現時点で使用できるのが確認出来るマシンパーツ 使用可能なアイテム 通信関連の仕様 カートをカスタマイズ Wii版から変更されていない仕様 キャラクターボイス ターボの溜め方 一部のBGM 一部のアイテムのSE(効果音) ジャンプアクション Wii版から変更された仕様 デフォでオートドリフトとマニュアルドリフトが両方使える ミニターボを溜まるのが早くなった DS版と同様にミニターボを決めてもキャラクターが声を発しなくなった コースアウトしてからの復帰が早くなった 7から追加された要素の仕様 3DSを傾けるとハンドル操作が可能 コイン取ると最高速度が上昇する アイテム攻撃を食らうとコインを落とす コイン無しで敵カートから体当たりを食らってもスピンしない 1週目に取っても2週目には復活している 上限は10枚 グライダーグライダー時の操作によって飛距離、スピードが変わる グライダー時にアイテムに当たると垂直落下する グライダー時でもアイテムが使える 水中滑りやすくなっている 下画面 DS版と同様にマップ、全員の順位、持っているアイテムが確認でき、今作ではラップ数、自分の持っているコインの枚数も確認できる 新コース一覧 キノピオのサーキットコース ピーチ城コース 渓谷コース 海コース ドンキーコングリターンズコース ウーフーアイランド カントリーコース アラビアンコース クッパコース ロゼッタコース 新コースについて DKリターンズコースに居るティキ族に当たると小スピン(Wii版のバナナと同じくらい) DKリターンズコースのところどころにSCに使えそうなジャンプ台アリ 現在判明しているレトロコース (SFC)マリオサーキット2 (64)カラカラさばく (64)ルイージサーキット (DS)DKスノーマウンテン (DS)ワルイージピンボール (DS)ルイージマンション (DS)キラーシップ (Wii)メイプルツリーハウス レトロコースの変更点や追加点等 メイプルツリーハウスのハナチャン地帯前のカーブのラストでジャンプアクションが可能 現時点で使用できるのが確認出来るキャラクター マリオ ルイージ ピーチ ヨッシー クッパ ドンキーコング ノコノコ キノピオ ワリオ デイジー ロゼッタ mii ヘイホー メタルマリオ New! ジュゲム New! 現時点で使用できるのが確認出来るマシンパーツ ホットラリーのマシンパーツ エッグワンのマシンパーツ スタンダードカートのマシンパーツ スーパーカイト ピーチパラソル パラフォイル 使用可能なアイテム バナナ スピンする時間が長くなった トリプルバナナ ミドリこうら トリプルミドリこうら アカこうら トリプルアカこうら キノコ トリプルキノコ ボムへい 上吹っ飛び→転倒に変更された。 ゲッソー 効果時間減少。 トゲゾーこうら 羽が消滅した。 スーパースター キラー サンダー パワフルキノコ ファイアフラワー New! ファイアボールを放てる。何発も撃てる。前後に撃ち分け可能。当たるとスピン スーパーこのは New! カートの後ろに尻尾が生える。 尻尾を振って近くの相手を攻撃できる。 7 New! 通信関連の仕様 いつの間に通信でゴーストデータを受け取れる すれちがい通信でゴーストデータを交換 ローカル8人、インターネット(Wi-Fi)でも8人対戦 3DS本体のフレンドリストからフレンドに合流したり、他の人のレート、対戦状況の確認が可能 カートをカスタマイズ 『フレーム』、『タイヤ』、『グライダー』を組み合わせ、自分の好きなカートにカスタマイズすることが可能。 レース中に登場する『コイン』を集めて、新しいパーツをゲットすることが出来る