Play Journal Entries

Super Mario Maker

マロ (10/29)zaretter

04/14/2017 7:53 AM ·Spoilers

マリメに関係あるけどマリメより一般論な話、フリーズやデータ破損といった深刻な事態というのはバグがあればちょちょいと起きるようなものじゃない。 「今のプログラムは昔より複雑になっているから、見落としやミスがそういう事態を招きやすい」という主張はむしろ逆で、「今のプログラムは昔より複雑になっているから、見落としやミスがそういう事態を招かないようセーフティが多重に用意されている」というのが正しい。 …もちろん、そういう設計をしていなければ起きることもあるけれど。バグがあろうと動くものにするだけでもそれなりのセーフティをクリアしないといけないんですよこれが。 そういう根本的な話。

Advertisement

Comment

This post has no comments.

  • プログラミング言語として主流な形式に、「手続き型言語」と「オブジェクト指向言語」の2つがある。手続き型言語とは一般的なプログラムのイメージに近い、上から下へ処理が進んで行く構造をしている。昔のプログラムと言ったらこれで、単純な構造なだけに処理が軽くメモリの消費も抑えられる。オブジェクト指向言語はプログラムを役割ごとに分割してまとめ、必要な時にそれらを呼び出すことで横へ横へと移動していく。最近の主流はこっちで、複雑な構造になってメモリを食いがちだけど、分業とテストが容易になるのがとても大きなメリットとなる。 この「役割ごとに分割してまとめ」たものをオブジェクト、オブジェクトをプログラム中で実際に生成したとき、その1つ1つのことをインスタンスという。 マリオのようにエネミー単位で動かし方を変える操作は手続き型言語でやるととても面倒で、オブジェクト指向言語だとすごくシンプルになる。

    Yeahs1
    Played
  • ほうほう

    Yeahs1
    Played
  • 私見でしかないけれど、マリメはオブジェクト指向言語で制御されているだろう。これを手続き型でやるとか頭痛くなる。 オブジェクト指向言語の構造的特徴として、異なるインスタンスの間の値の受け渡しは、あらかじめ定義しておいた形式「のみ」しかできないことが挙げられる。 これは何が良いかというと、インスタンスが格納する値は決まった形でしか取り出せないし、インスタンスには決まった形でしか値を入れられない。つまり、狙った場所以外に不自然な代入をすることがない。 昔のゲームには参照すべき位置を間違えて致命的な書き換えが起きてしまう、と言ったことが起きていたけど、そういうことが起きなくなる。 データ破損、フリーズが起きにくい理由の1つ目はこれ。

    Yeahs1
    Played
  • まあくん さん コメントありがとうございます。 ちょっと今日中には書き終わらないので、切りのいいところで続きを明日に回しますね。

    Yeahs0
    Played
  • ちょっと話は変わって、「エラー」の話。 エラーとはバグや不具合以前の話で、「実装作業上のミスにより、プログラムが稼働しない状態になる」こと。ファミコン時代みたいにメモリを直接編集するようなカツカツ運営をしていたころはさておき、今のプログラミングには「コンパイル」ないし「ビルド」と呼ばれる、作成したプログラムを機械が認識する言語に変換する過程が含まれる。 この過程が重要なのは、その変換過程において変換ができないパターン、例えば時間を扱うインスタンスが突然クリボーを扱うインスタンスに変わるとかのミスを検出してくれるということにある。 そもそもの変換ができないようでは、そのプログラムにはエラーが含まれている、というわけ。 こういうトンデモな代入が今のプログラムには防止する機構がある、というのもフリーズやデータ破損を起こしにくくさせている。

    Yeahs1
    Played
  • もっとも、これは完全にすべてのエラーを検出してくれるわけではない。例えば、本来それまでに値を持っていないといけなかったインスタンスが一切値を手に入れられずにいると、その時点でエラーが発生する。 値を持っていないかもしれない状態はコンパイル上の問題にはならないから。 ただし、そういうエラーが発生する箇所、パターンというのはそれぞれのオブジェクトの型、使う関数によって決まっていて、そういうエラーが発生した場合に別の処理を行う、いわゆる「エラー処理」というのを別に設定することができる。 エラーが発生しうる箇所にきちんとエラー処理を入れておかなくても、全プログラムの上位に1つエラー検出&処理の記述をしておくだけで、フリーズするエラーは起きなくなる(ただし、プログラムのバグを探すのにエラーが全部拾ってしまうと分かりにくいので、こういう処理は最後に付ける)。 でも、まだ全部は止められない。

    Yeahs1
    Played
  • 先にも言ったけど、エラーは発生した時点でプログラムが稼働しなくなる。一方で「フリーズ」というのは「プログラムが一切の応答をしない状態」のことで、エラー検出のない箇所でエラーが生じた場合にプログラムが停止、フリーズになるという発生のほかにも、処理が終了しない(できない)だけでプログラム自体は実行し続けている状態が発生するパターンもある。 これはコンパイルでもエラー処理でも検出できない。 こういうのは実際にテストをすることで検出するしかない。 開発上のテストは「単体テスト」「結合テスト」「システムテスト」「総合テスト」がある。開発するものの規模によってこれらのいくつかが統合されることもあるけど、よほど小規模でない限り単体テストと結合テストの2段階は行う。マリメレベルなら全部やってしかるべきだと思う。

    Yeahs1
    Played
  • 単体テストとは、オブジェクト単位でテストデータを用い、その中の変数や関数(処理)が正常に終了するかどうかを調べるテスト。この段階を突破できた時点で、フリーズを起こすプログラムになっているかどうかは分かる。 結合テストとは、オブジェクトが別のオブジェクトを利用するような処理において、その両方のオブジェクトを用意して正しくデータの受け渡しができているかを調べるテスト。このテストによりオブジェクトAがやって欲しい処理をBが一切持っていなかった、みたいな事態が無くなる。 もちろん、そういう事態が発覚したら単体テストをやり直し。追加した部分がフリーズを起こす構造の恐れがあるからね。 この「問題が分かった時テストの段階を巻き戻す必要性がある」というのが、手続き型言語とオブジェクト指向言語で手間を大きく変える。

    Yeahs1
    Played
  • 手続き型言語はプログラムがひとかたまりになっているから、一か所を変えると影響範囲が全体に渡る。オブジェクト指向言語の場合外のオブジェクトにデータを渡すのは決まった形でしかも結果のみだから、一か所を変えても影響範囲はそのオブジェクトのみに留められる。 つまり、差し戻しの際の単体テストのやり直しが少なくなる。 複雑化を増している昨今のゲームでは単体テストのパターンも膨大になるから、その範囲を狭められるのはとても大きいメリットなわけです。 結合テストが終わると、基本的にそのプログラム群はバグがあってもフリーズするようなものではなくなる。 システムテストでは、例えば「作る」機能とか「100人マリオ」機能とか、そういう機能単位でオブジェクトを集めて、その機能に必要なものがすべてそろっているかをテストする。この時点で大体完成品に近いものが出来上がる。

    Yeahs1
    Played
  • 運用テストは機能全てを集めて、実際の環境と同じ状態でテストを行う。マリメみたいにネット連携があるものなら、システムテストまではローカルネット、運用テストは外部ネットワークを介するみたいな違いもあるかな。クローズドβテストとか言ったらこの段階。 「マリメにはバグが多すぎる、デバッガー仕事しろ」みたいな主張もたまにあるけど、そういう人がイメージするテストっていうのはこの段階だけなんじゃないかな? 実際のテストというのは単体、結合テストで勝負はほぼ決まっていて、そこを突破していれば多少挙動が変でもゲーム的には問題がない状態になっている。 では、そこの正統性をどう保証するのか?

    Yeahs1
    Played
  • テストにはホワイトボックステストとブラックボックステストの2種類がある。 白箱テストはプログラム上の分岐をベースにテストケースを用意する方式で、命令網羅:プログラム上の命令のすべてを1回ずつ実行するだけのテストケースを用意する、分岐網羅:プログラム上の分岐の両方を1回ずつ実行するだけのテストケースを用意する、条件網羅:プログラム上の分岐の条件のそれぞれを真偽両方1回ずつ実行するだけのテストケースを用意する、などの方式を複合する。 黒箱テストはその仕様から定まる「同じ処理をしてほしいまとまり」を検証して、そのそれぞれのまとまりが適切な処理を行われているか調べる。 単体テストは白箱、結合テストは黒箱のイメージ。単体テストの白箱テストで条件/分岐網羅を担保しておけば早々致命的な事態にはならない。

    Yeahs1
    Played
  • じゃあマリメで色々見つかる不思議現象は何なのか、という話だけど、これは主にシステムテストレベルの検証事項になる。 マリメは圧倒的に組み合わせパターンが多いので、テストとしても結合テストレベルを担保するのが限界だと思うしそういうスタンスなのだろう。 そうして後から見つかった現象というのは「バグ」ではない。ただ、それを「不具合」とするか「仕様」とするかは運営の匙加減ということになる。 プレイヤー側からすれば判断できないことだから、この間に線引きをしたいなら運営側で告知してくれないと困るんだよね…。

    Yeahs1
    Played
  • さて、ここまでやってもなお残るフリーズの危険性…それは、「不具合」によるフリーズと、外部干渉を受けた場合のフリーズ。 前者はマリメでおなじみ処理落ちフリーズ。WiiUの処理能力を超えた演算を要求できてしまう設計上の大問題で、テストの中で見つけられなかったのは失敗と言わざるを得ない(ショートコースの限界配置を試さなかったのだろう)。後者はプレイ中にディスクを抜くとか停電とか磁石とか、とにかく本体が演算を行えなくなるような干渉を受けた場合で、これは完全に防ぐのは無理。 こういう時問題になるのは「記録データがロストしないか」という懸念だけど、オブジェクト指向言語においてその危険性は比較的低い。 なぜなら、記録データを関連を持つ部分もまたオブジェクトとして切り離されているため、その部分を結合テストレベルで完璧にしておけば、システム、運用レベルで処理が変わることはないから。

    Yeahs1
    Played
  • いったん中断。

    Yeahs1
    Played
  • WiiU本体自体、正規のアクセス方法でアクセスされた場合のみ要求されたデータのみを返す、あるいは要求されたデータを更新する、という処理をしていると思われる。 そして、ソフト側のプログラムにおいてはその機能を持つオブジェクトがWiiU本体側のプログラムを呼び出す、という形になる。 WiiU自体は電源喪失(停電/プレイ中の電源ボタン押し)に対応するため、記録処理が完全に完了する前に異常事態を検知したら、その記録を無かったことにする(ロールバックと言います)処理ができると思われる。 セーブデータの破損でイメージしやすいのはセーブ中の異常で変なデータになってしまうことだと思うけど、ロールバックができればそういう形にはならない。まあ巻き戻った形になってしまうけど、進行不可能なデータに変わることはない。

    Yeahs1
    Played
  • 長々と書いていったけれど、総括。 要するに、フリーズが起きるのはテストさえ十全なら設計上の問題に限られ、主に「本来できないはずだったことが出来てしまった」という事態に生じる。 セーブデータの破損が起きるリスクは基本的に物理的に障害を起こすような状態に限られ、万が一起きたとして最後のセーブ状態に巻き戻るところまでに抑えられる。 これらはファミコン時代には性能が足らず実現できなかった構造を持つことで達せられる多重のセーフティに起因する。 ゆえに、通常のプレイの範囲において、ゲームが停止しないような現象はたとえバグや不具合だったとしても、深刻な事態にはまず陥らない。 以上!お付き合いいただきありがとうございました。

    Yeahs1
    Played
  • なんか途中から趣旨から外れてお勉強な内容になっている感じですなw 私は専門外ですがビジュアルプログラミング言語なソフトのLabVIEWはかじった事あるので単語とか説明したい内容はなんとなくわかります。これら文章書けるってことは、この手の知識の教養ある人だろうな~ 結局、現在のゲームのほうが昔よりも深刻なバグが起きにくくなっているということかな。2DゲームだとTASさんが暴れやすいのはレトロゲームなほうが多いし。まぁ、ちょっと趣旨違うんだろうけどw 結局、マリメでBAN騒動などの根本は運営の判断で、さらに元を言うと日本人のバグ嫌いのノイジークレーマーの声に対して、運営がやっつけ対応しかしないという関係から生じている、裏技好きな自分にとってははた迷惑な、全然プログラムもなにもない結論だと私は常々思ってますw

    Yeahs1
    Played
  • etoxさん コメントありがとうございます。 いやあまあ本気でお勉強の内容のつもりで書きましたw バグっぽい挙動のものなら何でもかんでも「フリーズしたりデータが壊れたりするかもしれないから削除しろ!」ってうるさい輩にはそんなこと起きねえよ!とだけ返しても無駄でしょうから。正面から叩き潰します。 etoxさんのコメントには同意ですね。それを主張したいがために大量の文書を付けてあるので、話の中心はガチのお勉強ですがw ゲームの進行に影響を与えるような(強制イベントスキップみたいな)裏技はバグとしてあとから修正もやむなしですが、そうでもないならほっとけばいいと思うんですけどねー。

    Yeahs1
    Played
  • 余談 TASさんがレトロゲームで生き生きとしてるのは、データの吸出しなのかツールの適用なのか、その辺の干渉に対するセキュリティを突破しないといけないからですねw 全体に任天堂ハードの方が突破しやすくPSは突破しにくいようですが、詳しくは知りませんw マリメの中でお子様が良く使ってるTAS○○みたいな技は大半がTASの名を冠するに相応しくないなあとも思います。 お前Tool-Assistedなん?とか思っちゃいますし、自分でやって低確率でも成功するようなものはSuperplayでもないだろ、とか思いますし。 レトロゲームのTASさんのあらぶり方を見てるせいですかねw

    Yeahs1
    Played

Add a Comment

You must sign in to post a comment.

Sign in using a Nintendo Network ID to connect to users around the world by writing posts and comments and by giving Yeahs to other people's posts. You can create a Nintendo Network ID using your Wii U console or your system in the Nintendo 3DS family.

Use of Miiverse Details about Miiverse

Report Violation to Miiverse Administrators

You are about to report a post with content which violates the Miiverse Code of Conduct. This report will be sent to Nintendo's Miiverse administrators and not to the creator of the post.

Violation Type:

Post ID: 3DB-NBL7-EJ9-9E34-LA4-MRPP

Report Violation to Miiverse Administrators

You cannot report posts made automatically by a software title.

Edit Post

Select an action: