阿部和也のレビュー一覧

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

[Vine]

面白いので頭にすっと入ってくる

UnityのC#で参考になるかと思い購入。
記載されているコードはC++だが、どの言語でも通じるように抽象的に書いてあるので問題なく理解できる。
実際によくある状況をデザインパターンで解決する、という内容が、ただパターンが羅列されている説明と比べると非常にわかりやすい。

＃タメになる

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

Webフロントエンドの複雑化に伴い、フロントエンドの設計手法の整備は現代の重要な課題だ。
そんななか、複雑なフロントエンドを何十年も構築してきたのは『ゲーム』の世界だ。
つまり状態をUIに変換していくにあたりどうモデリングするか、ゲームプログラミングからこそ学ぶ点があると思い、本書を手に取った。

この本は、いわゆるデザインパターンをどう道具としてフロントエンドで使っていくかを表したものである。
特定の技術スタックに依存した内容でないため、普遍的な知識を学ぶことができた。
特にコマンドパターンは見方を変えればFluxであり、現代Webフロントエンドにも繋がってくる考え方だ。
やはりこうした自分の領域にとらわれないすぎない知識収集が、最先端を歩んでくためには必要になってくるだろうと再確認した。

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

ゲーム開発者の視点で、「ゲーム開発で使われるアーキテクチャ、デザインパターン」にフォーカスして解説がなされている本。

GUI や アプリケーションフレームワーク に共通する部分が多く、「自分の中で今までパターンと意識していなかったもの」がパターンとして解説されていたこともあり、とても良い頭の整理になった。

また、それぞれのパターンの「なぜ？」が、ゲーム開発の生々しい実例と共に書かれていたので、面白かった。

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

■ 感想
いい本でした。知っていることもあるものの、知らなくて勉強になったことや、次にコード書くときにもう少しうまく書けそうな気がする本でした。

Unityを使ったことがあれば、すでに利用しているパターンもあるので、Unity使っている人であれば入りのいい本でもあると思います。すでに利用していたパターンでも他との対比もあり理解が深まったり、どういう意図で作っているのかがわかるようになるので、より利用しやすくなります。

難易度的が低い本と言えず、ある程度の期間、ある程度のサイズ感の開発したことがないと理解しきれないと思います。Unity触って3〜5年目ぐらいで、書いてるコードがこんがらがってきて、うまく整理できないみたいな悩みがある人は一度読んでみるのもいいかもなと感じました。

パターンとしてコードの抽象化（分離）の話もありますが、データの最適化の項目もあり、そういう方向が好みの人にも合うと思います。

■ 抜粋

- よいソフトウェアアーキテクチャの本領が発揮されるのは、コードを読んで理解するときだと思っています。コードを脳に読み込むのは非常に時間のかかる処理なので、読み込む量をへらす方策を見つけることに意義があります。（P.12）
- 「分離」の定義はさまざまですが、2つのブログラムが「分離できていない（結合している）」というのは、一方を理解しないと一方も理解できない状態だと私は考えています。（P.12）
- ソフトウェアアーキテクチャを考える主要な目的は、この「次に進む前に頭に入れておかなければならない知識を最小にすること」です。（P.12）
- 面白いゲームを早くすることのほうが、早いゲームを面白くするより簡単です。（P.15）
- 「単純なコードは、書く時間も短くなる」とは言ってはいないことに注意してください。全体のコードの量が減れば、それを書く時間も短くて済むと考えるかもしれませんが、良いコードは蓄積によって得られるのではなく、精製によって得られるのです。（P.17）
- 抽象化と分離により、プログラムの改良は早く簡単にできるようになりますが、取り組んでいるコードがそのような柔軟性を必要としていると確信できるまでは、抽象化と分離に無駄な時間を割くべきではありません。（P.18）
- （メモ）AvatarAdjusterがInputHandlerをCommandとして受け取ることで実行する。この形を取れば、avatarの生成のタイミングか、画面遷移のタイミングだけに絞れる？（P.26）
- 原則は「変数のスコープは、処理に支障のない範囲で可能なかぎり狭くする」です。（P.93）
- 常にバグのないコードを書いているように思える憧れのコーダーたちも、別に超人的なプログラマーなわけではありません。彼らは、どんなコードにバグが入りやすいか本能的に知っているので、そのようなコードを避けているだけなのです。複雑な分岐と、変更可能な状態—時間経過とともに変化するフィールド—はそのようなバグの入りやすいコードのうちの2つです。（P.101）
- 可変更新間隔
私の知っているゲーム開発者のほとんどがこの方式を推奨しないことをわかった上で、ここに挙げています。なぜよくないないのかを知ることも意味があると思うからです。
- 早すぎる場合にも遅すぎる場合にも対応しています—ゲームが実時間に追いつけない場合は、追いつけるまで更新と描画の時間感覚を延長します。
- ゲームは非決定論的になり、不安定になります—先に述べたとおり、これが非常にやっかいな問題なのです。この方式では、物理シミュレーションとネットワーク通信がとりわけ扱いにくくなります。（P.153-154）
- 間違いは誰もが犯すものであり、創造的なプロセスのk塩となるものです。「取り消し（アンドウ）」を可能にするなどしてエラーをさりげなく処理することで、ユーザーの創造性は高まり、より良いものを作れるようになります。（P.192）
- 言語設計者はプロもアマも文法の定義を甘くみすぎています。パーサに楽をさせる文法を定義するのは簡単です。ユーザーに楽をさせる文法を定義するのは難題です。（P.197）
- （P.202）サブクラスサンドボックスパターン（強い継承を使いたい場合）
- パターンの適用条件
- 派生クラスの多い基底クラスがあるとき。
- 派生クラスが必要としている操作や処理を、基底クラスですべて提供できるとき。
- サブクラス間に共通するビヘイビアがあり、同じコードを使ってコードを簡略化したいとき。
- 派生クラスとシステムプログラムの結合を最小化したいとき。
- 派生クラスは、基底クラスを介してコードベースの他の部分にアクセスするのですから、必然的に基底クラスは派生クラスがアクセスする必要のあるシステム内のあらゆる箇所と結合することになります。（P.202）
- 最近ではオブジェクト指向言語の継承に対する批判を目にすることが多くなりました。継承は問題を起こすことが多く、基底クラスと派生クラスの結合ほど強い結びつきはありません。（P.202）
- ゲームのビヘイビアを定義するのに、スクリプト言語やその他の高レベルの手段を利用すると、実行時の効率はいくぶんか低下しますが、生産性はめざましく向上します。ハードウェアは進歩し続けますが、人間の脳のほうはそうはいきませんので、生産性の向上に重きを置くことがますます重要になってきます。（P.220）
- どんなプログラミング言語を使っていても、コツをつかんでしまえば、思いどおりにコードを書くのはそんなに難しいことではありません。難しいのは、実行させたいことが変わったときに簡単にそれに合わせられるコードをあらかじめ書いておくことです。（P.231）
- UnityフレームワークのクラスGameObjectはすべてコンポーネントでデザインされています。（P.254）
- Data-Oriented Design（P.298）
- 最適化を適用する第1の条件は、実行速度に問題があるときというのが普通です。データ局所化パターンも同じです。コードベース内のあまり実行されない部分にこのパターンを適用することで時間を無駄にしてはなりません。最適化すると、コードは複雑になり柔軟性が低くなるので、不必要な最適化を行うと後の作業が面倒になります。（P.299）
- Cachegrind（P.299）
- AngularなどのブラウザサイドのWebフレームワークでよく見られます。ブラウザ内で変更され、サーバに送信する必要が生じたデータを管理するのに、ダーティフラグが使用されます。（P.332）