ファイル更新に耐性のあるテキストタグ手法を考える - .mjtの日記復帰計画
コンパイラの警告やシナリオのコメント、クラッシュレポートの処理等、"行の特定位置にタグを振りファイルが更新されても追跡したい"という需要がそれなりにある。...需要自体は有るんだけど、実装がバラバラになってしまっているので、ちゃんとモデル化し、フレームワークとして統一を図りたい。 行コンテンツとblame履歴によるアドレッシング 今回考えたタグのモデルは、ファイルを行に分割し、各行のコンテンツおよび初出現リビジョンのハッシュをアドレスとする。 このアドレッシングにより、ファイルが更新されたとしてもタグを頻繁に書き換える必要は無い。もちろん、行を書き換えた場合はハッシュ値が変わるためタグも"打ち直し"が必要になるが、それでも行番号を使用した場合よりも高い生存率が期待される。 これはblameにタグを付けるのと同じと言える。つまり、 VCS上の履歴を伴ったファイルにしかタグ付けできないし、タグ
TVコンテンツとしてのゲームの難しさ - .mjtの日記復帰計画
edit: 2ch強制が機能しない例を見つけられなかった。 prev: http://d.hatena.ne.jp/mjt/20150723/p1 ゲーム表現とARIB規格/TR テレビゲームはテレビに接続して遊ぶものなので、テレビの実装に表現は制約される。というわけで、それを正しく理解して運用することがプレーヤと製作者の双方にとって必要となっている。 ...もちろんプレーヤは何も意識せずとも遊べるのが理想ではあるが。。MSや任天堂はTVベンダでなく、Sonyは自社製品であればHDMI一本で基本的に間違いがないようにデザインしているのでなかなかこの辺がフォローされない傾向にある。 映像表示 映像表示は見た目に出るので音声よりも状況は良い気がする。 (セーフゾーン) https://twitter.com/kagring/status/573432615081910272 クロワルールΣ(P
Nintendo SwitchのUI戦略 - .mjtの日記復帰計画
というわけでNintendo Switchを発売日に(会社をサボって)入手した。 全体的に素晴しいデキで、ゲームコンソールのあるべき姿を提示したのではないかと思う。細かい変な仕様も散見されるが、実装面ではマルチユーザ型コンテンツプレイヤの模範と言って良いのではないか。 曖昧な"やめる": プレイ中であることが明示できないなら"キャンセル"など対にならない語にすべき まとめ ゲームは必要数のコントローラと形態(スティック2本必要等)をシステムに宣言するデザインになっていると考えられる ゲームは接続形態の変更に動的に対応する必要がある コントローラの組み合せによって操作不能になるシーンは許容されている(ユーザは何らかの方法でHOMEに戻って対処する必要がある) ライブラリ/抽象化層の提供側としては、これらの宣言を行えるAPIを提供した方がスムースに統合できるように見える。 据え置き機のような外
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
