Unity 5 日記 1 インストール - GameObject の操作
はじめに
超々久しぶりに Unity に触った。もうどの位久しぶりかというと、起動しようとしたら別ドライブに僅かに残骸だけが残っていてUnity自体がインストールされていなかった。
折角なので、自分自身の備忘録兼足跡として、日記をつけていく事にする。プログラムは書けるが Unity は初めてで右も左も分からない、という人の一助になれば幸いだ。
インストール
前回まで使っていたのが 4 系だったので 公式ウェブサイト から Personal 版をダウンロードしてインストール。インストーラ ( Unity Download Assistant ) に同時にインストールコンポーネントをどうするか聞かれるが、ざっと見た感じデフォルトで OK 。強いて言えば、 マニュアル に色々書かれていて参考になるかも。 Visual Studio 2015 との連携はあって損は無さそうだった。
新規プロジェクトの作成
新規プロジェクトの作成の際に、プロジェクトを 2D にするか 3D にするかを聞かれるが、 マニュアル によればゲームにより向き不向きがあるが、あとで切り替えられるらしいのでこのマニュアルを読みながら適当に決めれば良い。
真っさらな状態になった。うーんこの何もない荒野にほっぽり出された感。 UI が英語だし、そもそもどこからどう手を付けていいか分からない。もちろん 1 マス左に移動すると見えない村があるなどという事もない。
画面のレイアウト
#03 画面の見方を覚えよう | Unity入門 - プログラミングならドットインストール を見ながら色々と確認。
ウィンドウ内の各種タブはドラッグ & ドロップで移動する事が出来る。ウィンドウ外にドラッグ & ドロップする事で別ウィンドウに切り離す事も可能だ。また、レイアウトには各種プリセットが用意されており、右上のボタンから選ぶことが出来る。
動画でも Tall がオススメされていたので自分も Tall を選び、 Scene と Game が縦に並ぶようにした。
基本的に Scene の中に各種 GameObject を配置していく事になる。 Scene 内に配置された GameObject は Hierarchy タブ内に表示される。 Hierarchy 内の各種オブジェクトを選択すると、 Inspector タブにその GameObject の内容が表示される。 GameObject に Component を付加していく事で、オブジェクトに対する肉付けを行っていく。
操作モードとシーンビューの操作
ウィンドウ左上に並んでいる各種アイコンが操作モードを決定する各種ツールだ。手のアイコン、十字アイコン、その他諸々のツールはパン、移動、回転、拡大/縮小、 Rect Tool に対応する。パンはハンドツールとも呼ばれる。尚、各種操作モードにはデフォルトで Q W E R T キーが対応している。
ハンドツールを選択しる時、左クリックでドラッグする事で視点を移動する事が出来る。移動を選択している場合は GameObject を移動させる事が出来る。
ただ、ハンドツールを選択していてもミドルクリック ( ホイールクリック ) でドラッグすればどちらのモードでも視点の移動が出来るので、そちらが使える人はそれでいいかもしれない。
右ドラッグで視点をその場で回転させる事が出来る。また、 Alt+左ドラッグでクリックした地点を中心に視点を回転、 Alt+右ドラッグで視点の拡大縮小を行う。その他詳細はマニュアルを参照。
また Scene 右上に表示されているアイコン ( ギズモ ) の操作でも視点の操作が出来る。
#05 GameObjectの操作をしてみよう | Unity入門 - プログラミングならドットインストール
GameObject の操作
GameObject を選択すると、中央にギズモが表示される。このギズモを操作する事で、操作モードに応じてオブジェクトの各種操作を行う事が出来る。
Asset
File -> Save Scenes Ctrl+S で Scene を保存すると、 Assets に保存したシーンが表示される。 Asset の概念はまだ理解出来ていないが、たぶん Project に紐付いたファイル全般を Asset と呼ぶのだと思う。 Scene も Asset 、その他色々な物も Asset なのだろう、たぶん。
参考文献
Windows の解像度に思うこと
画素の密度
Apple が iPhone 4 向けに Retina ディスプレイを発表して以降、スマートフォン向けのディスプレイは高密度化し続け、その傾向はラップトップ PC やテレビにおいても同様である。しかし macOS のスケーリングは比較的綺麗に見える一方 Windows では従来のアプリケーションは UI がガタついたり、表示がボケボケになってしまう。
最新の MacBook Pro がフルサイズの USB ポートを廃止した事からも分かるように Apple は古い物を切り捨てる事に躊躇が無い。一方で Microsoft は ( サティア・ナデラの就任以降その傾向は変わりつつ有るものの ) 比較的後方互換性を重視する傾向にある。そのため、新しい高解像度環境において Windows では古いアプリケーションの表示に問題が発生してしまうのである。勿論、新しい開発環境で作成されたアプリケーションではスケーリングがほぼ上手く行われる。 Windows 10 では 25% 刻み 4 の倍数単位でスケーリングが行われるため Windows アプリ UX デザイン ガイドライン においても 4x4 のピクセルグリッドにデザインをスナップするようにと書かれている。
Windows でのアプリケーション側での対応については以下の記事に詳しい。
- 【4K修行僧】Windowsの4Kスケーリング環境を検証する ~文字表示は美麗。ただし、非対応アプリも多数存在 - PC Watch
- アプリの高DPI(High DPI)対応について 第2回 ~ アプリケーションの高DPIへの対応レベル ~ – 田中達彦のブログ
- WPF での高 DPI 対応 | grabacr.nét
- Windows 8.1 で加わった Per-Monitor DPI と WPF での対応方法 | grabacr.nét
しかしながら、結局の所 Windows では従来型の古いアプリケーションに有用な物が多く、その多くはバグフィックス等のメンテナンスは行われているものの UI を完全に刷新する程の対応が行われている物は殆ど無い。そのため、従来型のアプリケーションをピクセルパーフェクトにスケーリングするため 200% 表示に最適化されたディスプレイを搭載する事のアドバンテージが極めて大きい。
Microsoft もその問題を認識しているのか Surface Pro 4 や Surface Book の解像度は 200% スケーリングに最適な解像度になっている。
機種 | size | x | y | DPI |
---|---|---|---|---|
Surface Pro 4 | 12.3 | 2736 | 1824 | 267 |
Surface Book with Performance Base | 13.5 | 3000 | 2000 | 267 |
MacBook Pro (2016) | 15.4 | 2880 | 1800 | 220 |
EV2116W-A | 21.5 | 1920 | 1080 | 102 |
EV2451 | 23.8 | 1920 | 1080 | 92 |
古式ゆかしいコンピュータ用ディスプレイにおいては 72DPI または 96DPI がデファクトスタンダードとされてきた 。これはデスクトップ環境での利用を想定した数値であるから、より目に近い距離で使用されるラップトップ PC やタブレットにおいてはより高密度が好適である。現行の Surface デバイスの DPI は 267 であるから、 200% スケーリング環境では実質的なコンテンツの表示領域は 133.5DPI 相当となる。 Surface デバイスはラップトップ PC とタブレットを兼ねる 2-in-1 デバイスとしてのセグメントに属するので、その DPI もラップトップ PC とタブレットの中間であると考えられる。
現行のデスクトップ環境向けのディスプレイの解像度は 96DPI 前後が主流である事から、以下のようなディスプレイが望ましいと考える。
セグメント | DPI |
---|---|
デスクトップ | 192 |
ラップトップ | 240 |
タブレット | 288 |
アスペクト比
PC のディスプレイのアスペクト比は時代と共に 4:3 、 5:4 、16:10 、 16:9 とそのメインストリームの軸足を移してきた。一方で Surface シリーズはアスペクト比 3:2 を採用している。
x | y | アスペクト比 |
---|---|---|
640 | 480 | 4:3 |
800 | 600 | 4:3 |
1024 | 768 | 4:3 |
1280 | 1024 | 5:4 |
1280 | 720 | 16:9 |
1366 | 768 | 約16:9 |
2736 | 1824 | 3:2 |
3000 | 2000 | 3:2 |
PC 向けのディスプレイにおいて 16:9 が一期に普及した背景には、動画コンテンツの多くが視界全体の大きさを意識してそのサイズを採用した事にある。そのため PC で画面一杯に動画コンテンツを表示出来るようにするため、 PC においてワイドディスプレイが普及してきた初期に多かった 16:10 のアスペクト比が一気に駆逐されていった、という歴史的経緯がある。
一方で、縦に長いコンテンツを消費する事の多い PC においては縦の解像度のアドバンテージを支持する声も多く、 Surface シリーズのアスペクト比が 3:2 である事は、それらの揺り戻しであるとも言える。
デスクトップ PC においては、非常にワイドなコンテンツを表示したり、あるいはコンテンツを並べて表示する事に適した 21:9 の解像度を推す声もある。
私は、 3:2 の解像度は好ましいと考えるし、より小さなアスペクト比を採用し、また縦の値を共通化するという意味で、デスクトップ環境において 5:2 のアスペクト比もありなのではないか、と思う。
以下の表の x 及び y は既存の解像度と比較しやすくするため、半分の値にしている。
x | y | DPI | size | アスペクト比 |
---|---|---|---|---|
1260 | 840 | 240 | 12.6 | 3:2 |
1260 | 840 | 264 | 11.4 | 3:2 |
1260 | 840 | 288 | 10.5 | 3:2 |
1344 | 896 | 240 | 13.5 | 3:2 |
1344 | 896 | 264 | 12.2 | 3:2 |
1344 | 896 | 288 | 11.2 | 3:2 |
1440 | 960 | 240 | 14.4 | 3:2 |
1440 | 960 | 264 | 13.1 | 3:2 |
1440 | 960 | 288 | 12.0 | 3:2 |
1536 | 1024 | 240 | 15.4 | 3:2 |
1536 | 1024 | 264 | 14.0 | 3:2 |
1536 | 1024 | 288 | 12.8 | 3:2 |
x | y | DPI | size | アスペクト比 |
---|---|---|---|---|
2560 | 1024 | 192 | 28.7 | 5:2 |
2560 | 1024 | 216 | 25.5 | 5:2 |
2560 | 1024 | 240 | 23.0 | 5:2 |
1920 | 1280 | 192 | 24.0 | 3:2 |
1920 | 1280 | 216 | 21.4 | 3:2 |
1920 | 1280 | 240 | 19.2 | 3:2 |
3200 | 1280 | 192 | 35.9 | 5:2 |
3200 | 1280 | 216 | 31.9 | 5:2 |
3200 | 1280 | 240 | 28.7 | 5:2 |
2160 | 1440 | 192 | 27.0 | 3:2 |
2160 | 1440 | 216 | 24.0 | 3:2 |
2160 | 1440 | 240 | 21.6 | 3:2 |
3600 | 1440 | 192 | 40.4 | 5:2 |
3600 | 1440 | 216 | 35.9 | 5:2 |
3600 | 1440 | 240 | 32.3 | 5:2 |
5:2 のアスペクト比は昔の 5:4 のディスプレイを 2 枚並べた比率に相当する。意外とありなのではなかろうか?
iPhone 7 と次期 Nexus ( Pixel ) の狭間で
iPhone 7 が発売され、次期 Nexus ( Pixel ) に関するリーク情報も出揃ってきたので、このタイミングで所感をまとめる。
性能がずば抜けている
Android が登場してしばらくは、 Android は iPhone に対してパフォーマンス面で明らかに劣っていた。スクロールの追従性一つとってもそれは明らかであるし、ましてWEB回覧は言わずもがなであった。
Android 側のパフォーマンス面、それによって提供されるユーザエクスペリエンスがある程度対等になったと言えるのは Android 4.0 Ice Cream Sandwich 以降の事だ。この頃の iPhone は 4S 、 Android では Galaxy Nexus である。勿論体感的な話をしているのであるからその所感は人それぞれだろうが、 iPhone はシングルタスク、 Android はマルチタスクに注力している分、一長一短なのだ、と思える程度には収まっていたと思う。
これ以降の両陣営は基本的なユーザビリティの向上にその労力の多くを注力してきたように思う。個々の技術や機能を見ればそれなりに革新的と言える物も少なくはないだろうが、どちらかが強烈、あるいは一方的な優位性を持つ事は無く、私自身のスマートフォンに対する熱も徐々に冷めていった。
が、今回の iPhone 7 は久しぶりに強烈なインパクトを受けた。
iPhone は世代交代のサイクルの関係上、全世代と考えて数十パーセント、場合によっては倍近く性能が向上する事もあるが、それは iPhone 内での事だ。その発売タイミングでの各々のフラッグシップ端末との間で単純性能でこれ程の差がついたのは久しぶりであるように感じる。 A10 Fusion プロセッサの威力は大きい。 Qualcomm には対抗製品の開発を頑張って欲しい所だ。
高い防塵、防水性能
iPhone 7 が防塵、防水に対応し、その等級が IP67 である、というのはかなり大きなアドバンテージであるように思う。
次期 Nexus ( Pixel ) について防塵、防滴性能があるというリーク情報があるが、あくまで IP53 であり、防水ではなく防滴である。
【更新】PixelとPixel XLはIP53の防塵・防滴性能があるとの情報。本当なら雨で水没の心配もなさそうです⇒Google Pixel/Pixel XLのスペック情報まとめ https://t.co/Kguw796jfN pic.twitter.com/sguF1GtGPn
— アンドロイドラバー (@Android_Lover) 2016年9月22日
- Google Pixel(Nexus5 2016)/Pixel XL(Nexus6 2016)のスペック/発売日/価格情報まとめ
- Google's Pixel phones will be IP53 rated, meaning no dunking your Pixel or hosing it down
高機能なカメラ
残念ながら iPhone 7 Plus にしか搭載されていないものの、デュアルレンズのカメラの衝撃は大きい。広角レンズと望遠レンズをソフトウェアで合成する事で絵作りを行う、という方向性は非情に興味深い。
今までにもスマートフォンのカメラは HTC EVO 3D の3Dカメラや HTC One M8 のデュアルカメラ、 ZenFone Zoom の光学3倍ズーム等枚挙に暇がないが、 iPhone 7 Plus のカメラの方向性はバランスが良いアプローチだと感じる。
FeliCa 対応
最近になって、おサイフケータイもいいなぁ、等と思えるようになってきた。 iPhone のおサイフケータイ対応については、今まで何度も噂されてきたので眉唾であったし、 iPhone が日本のローカルな事情のためだけにハードウェアに特別対応をする事は無いだろうと思っていたので、非情に驚かされた。
持ち物が減るというのは良いことだ。可能であればスマートフォンに財布を統合するだけでなく、鍵も統合出来てしまえば良いのに、とすら思ってしまう。
ただ、それによって国際版と国内版とで様々な物事が分断されてしまうのは残念だ。 FeliCa が NFC を初めとする近距離無線通信の規格の中で、その応答性において高い優位性を持っているのであればこそ、 Secure Element 等の問題を解消し NFC-F が国際的に普及している規格の序列に NFC-A 、 NFC-B に続く形で加わって欲しいものだ。
Visual Studioと同時に立ち上がるVsHub.exeの挙動
作業中である事を明示するために Steam のマイライブラリに Visual Studio を登録した時、バックグラウンドで VsHub.exe
というプロセスが動いているために Visual Studio を閉じても継続状態になっている事に気がついた。
この VsHub.exe
は通常 C:\Program Files (x86)\Common Files\Microsoft Shared\VsHub\1.0.0.0
にある。 *1
VsHub.exe
は Visual Studio を閉じてもしばらくプロセスを残し続けるが、しばらく時間が経つと自動的に終了するようだ。ちなみに自動的に終了する直前に複数の子プロセスを立ち上げ一時的に CPU 負荷が高い状態になった。
*1: OS が 64 ビットの場合
VC++2013 で using 宣言を使うだけでコンパイラが強制終了するコード
以下のプログラムは VC++2013 で正しく動作する。
template< typename Head, typename... Tail > struct s; template< typename Last > struct s< Last > { void f( Last ) {} }; template< typename First, typename Second, typename... Tail > struct s< First, Second, Tail... > : s< Second, Tail... > { using s< Second, Tail... >::f; void f( First ) {} }; int main() {}
派生クラスで宣言、定義した関数 f
によって、基底クラスの関数 f
が隠蔽されてしまうため、 using 宣言によって名前をスコープに持ち込む。
ところが、以下のように書き換えるだけで VC++2013 ではコンパイラが動作を停止してしまう。
template< typename First, typename Second, typename... Tail > struct s< First, Second, Tail... > : s< Second, Tail... > { void f( First ) {} using s< Second, Tail... >::f; };
関数 f
と using 宣言の順番を入れ替えただけでコンパイラが動作停止。とても残念。 VC++2015 では動くのかもしれないが未検証。 *2 当然だが gcc と clang では動作した。
また、以下のコードも NG 。
template< typename Arg > struct impl { void f( Arg ) {} }; template< typename Head, typename... Tail > struct s; template< typename Last > struct s< Last > : impl< Last > {}; template< typename First, typename Second, typename... Tail > struct s< First, Second, Tail... > : s< First > , s< Second, Tail... > { using s< First >::f; using s< Second, Tail... >::f; }; int main() {}
これが出来ないので、再帰テンプレートによる構造部分と、関数を宣言する構造部分を分離することが出来ない。
辛い。
完全栄養食COMPレビュー 意外といける
偽サイトに注意!!
COMP公式を騙る偽サイトがあります。
URLが cooomp とかになってるので要注意。
2016.04.24 追記
cooomp.com は一応公式管理のサイトだそうです。
大変申し訳ありませんでした。
味について
そこそこ飲みやすいです。 が、失敗するとゲロまずなので注意。
- ぬるい水道水は不味いです。最低限冷やしましょう。
- コーヒーが安定して飲めます。無糖・加糖どちらでもOK。お求めはお近くのコンビニで。
- パイン水は甘ったるすぎてダメでした。
調理について
公式 の PDF にも書いてありますが、最初に少し水(または混ぜる飲料)を入れないと底に溜まった粉が混ざってくれません。私の調理法は以下のとおり。
- 専用シェーカーに飲料を少し入れる
- 粉を適量入れる。
- シェーカー一杯より少し少なめに飲料を入れる。
- 軽く振る。
- フタを開けて飲料を追加する。
- よく降って出来上がり。
飲料をちゃんと入れないと強烈に濃いマックシェイクみたいになります。 なので一度振って飲料を入れ直します。こうしないと飲料が足りない感じの出来上がりになってしまいます。
メリット
- 栄養のバランスが取れます。当たり前ですが。
- 調理が強烈に楽です。俺は面倒が嫌いなんだ。
- 意外とお腹にたまり満腹感があります。
デメリット
歯ごたえが無い
基本的に完全栄養食を標榜する食品は粉末を溶いて摂取する事になるので避けられない宿命と思われますが、歯ごたえがありません。 人間噛むことを一切しないと多分とても健康に悪いので、COMPだけでなくその他の食事も摂りましょう。 最近COMPばかり食べてたのでローソンでやみつき鶏ごまラー油買ってきたらめっちゃ美味しかったです。
粉がめっちゃ舞い散る
粉が非常に細かいので、かなり舞い散ります。 お前はベビーパウダーか!という感じ。 実際には小麦粉くらいかな……? 溶けやすくするため致し方無し。 袋から粉を取り出す時と、シェーカーに粉を入れる時はそっと扱いましょう。
その他気になった事
COMP9袋、81食ででっかいダンボール箱一箱分です。一ヶ月分の食事だから当たり前ですが、重いです。 最初は2袋からはじめましょう。
改善してほしい点
オリジナルシェーカーは分量調節に便利ですが、割とフタが緩いので下手に振ると飛び散ります。 とても持ち運べるものでは無いです。シェーカーとして使えて持ち運びにも適した容器が欲しいです。
疑問点
プロモーションムービーに出てくる容器はどこで入手出来るのだろう。 持ち歩きにすごい便利そうだから欲しいのだけど…
機工城アレキサンダー:律動編 ドロップテーブル他
必要個数
種別 | 対価となるアイテム | 必要個数 |
---|---|---|
頭防具 | ミダースレンズ | 2 |
胴防具 | ミダースシャフト | 4 |
手防具 | ミダースクランク | 2 |
帯防具 | ミダースチェーン | 1 |
脚防具 | ミダーススプリング | 4 |
足防具 | ミダースペダル | 2 |
アクセサリ | ミダースボルト | 1 |
各層ドロップテーブル
層 | 頭 | 胴 | 手 | 帯 | 脚 | 足 | ア |
---|---|---|---|---|---|---|---|
1 | * | * | * | ||||
2 | * | * | * | ||||
3 | * | * | * | ||||
4 | * | * | * |
- 各層のドロップは3種類と過程( 起動編準拠 )
- 起動編とドロップテーブルは同じっぽい
- 4層では各プレイヤー確定で
ミダースの歯車
がドロップ。週制限あり。
以下未整理メモ
各層で取得するアイテムはおそらく下記の感じ。 伝承装備は考慮していない。順不同。
- チェーン, ボルト, ペダル, ペダル, ボルト
- ボルト, ボルト, レンズ, レンズ
- スプリング, スプリング, スプリング, スプリング, クランク
- シャフト, シャフト, シャフト, シャフト, クランク
以下注釈
- クエスト報酬でボルトは今回は無し
- 残りのアクセ枠( 指 )は伝承で埋める。