Developers summit 2012 1日目 参加メモ その1

[16-C-1] HTML5の今と未来 〜HTML5との正しいつきあい方〜 (羽田野太巳氏)

2012/02/16 デブサミ2012【16-C-1】HTML5の今と未来 〜HTML5との正しいつきあい方〜 #devsumiC - Togetter

HTML5 = Markup + API
ほとんどがAPIの塊

ウェブ標準は10年以上進化せずウェブの進化はプラグイン(Flash, SilverlightなどのRIA)によってもたらされた
iPhone, iPadなどの登場でリッチ・コンテンツをHTML5で作らざるを得ない状況に
現状AndroidではFlashをサポートしているがChrome for AndroidはFlash非サポート、MSはWindows8でFlash、Sliverlightをサポートしない。

APP基盤となるウェブ技術

  • マルチメディア再生
  • 2D/3Dグラフィックス
  • スレッド
  • ストレージ
  • ネットワーク
  • デバイス連携（カメラ・GPS）

->HTML5がOSの役割を担う

  • スレッド処理
    • WebWorkers
  • ファイル/ディレクトリ
    • File API/File Writer/File Directory System
  • グラフィックス
  • オフライン
    • Application Cache
  • 双方向リアルタイム通信
    • WebSocket API/WebSocket Protocol
  • カメラ/マイクロフォン
    • Media Capture/WebRTC
  • GPS
    • Geolocation API
  • ジャイロスコープ/加速度センサー
    • DeviceOrientation Event
  • バッテリー
    • Battery Status API
  • ネットワーク接続情報

Write once, Run Anywhere
ウェブ標準をネイティブAppsの基盤に

基盤をシフト

  • OSからブラウザへ
  • ネイティブ言語からJavaScript
  • デバイスを超えた開発環境の統一化


[16-D-2] 非ゲーム系ソフトウェア開発者のためのゲーム開発プロジェクト入門

2012/02/16 デブサミ2012【16-D-2】非ゲーム系ソフトウェア開発者のためのゲーム開発プロジェクト入門 #devsumiD

システム開発のエンジニアリングとコンテンツを作っていく系のエンジニアリング
開発プロセスの違い
一般
システム企画、要求分析、仕様分析 → 方式設計、詳細設計、実装 → リリース、フィードバック収集、さらなる計画

  • システム企画時にやりたいことがはっきりと落とし込める
  • 目的が「既存業務の改善」や「利便性の向上」であることがほとんどなので、定量的評価が可能
  • 画面設計などに落とし込めば、並行して作ることが可能
  • 早いうちにリリースできる、スモールスタートが可能

ゲームの場合
コンテンツ企画、コンセプト立証、全体計画 → プリプロダクション、制作、テスト、ポストプロダクション を複数回繰り返す → 何度も繰り返した後、製品リリース → ユーザ動向を見て、アイテム追加等、改善

プリプロダクション

ポストプロダクション

ゲーム開発の特徴

  • 「やりたいこと」が必ずしも定義的ない
  • 目的が「エンターテインメントの提供」なので定量的評価が困難
  • プレイ時の満足度が低いうちにリリースすると命取り

コンセプト共有の方法

  • イメージボード、コンセプトアートの制作
  • コンセプトムービーの制作
  • とりあえず動く企画書を作っちゃう <- Unityとか使うとここのコスト低い!

コンセプト、コンセプト、コンセプト

  • 「コンセプトをいかに共有するか」「コンセプトを開発中いかに死守するか」が最初の命運を決める。
    • お金出す人の圧力
    • チームの認識ずれ
    • なんかうまくいかない、どう作っていいか解らない
  • コンセプトを途中で妥協するとプロジェクトは死ぬ

プリプロダクションの割合

プロトタイプ

  • どういう遊びだったらこれが実現できるのか
  • 自分たちに作れるのか
  • どういうリソースがどのくらい必要になるのか

ゲームとツールの違い

  • DropBoxとEvernoteも使う、はあり
    • FarmVilleもDragonValeも遊ぶ...は？？？
  • PhotoShopがあれば、画像ツールはもういらない
    • FPSは何個遊んでもいい
  • 最初に遊んだ時に面白くないと、もう戻ってこないかも

チーム構成とエンジニアの役割

  • エンジニアはゲーム開発ではロジカルな役割に徹しきれない
    • ゲーム開発は料理に似ている
    • SE的に要件定義をしようとすると、やってられるかー！ということになる
    • ふわっとした話に対応する能力が必要
  • 「ゲームプログラムが作れる＝ゲームが作れる」ではない！

非エンジニアがチームにいる

  • アーティスト
  • ゲームデザイナー
  • サウンドデザイナー
  • エンジニアじゃないので「CI」とか「アジャイル」とか通じない！
  • 彼らが提供するウェットな価値を伸ばす役割を負っている

リソース生産設計

  • ゲーム開発の70%は実は「リソース作り」
  • 大量のリソースをいかに作っていくか？
    • パイプライン、工程設計
    • エンジニアじゃなくてもそれができるようにすること
    • お互いを邪魔せずに生産できる仕掛け
    • UnityだとPrefabなどをうまく使おう

外注

  • リソース作成時は要件定義書を作ろう

いつ発注？

  • プロトタイプで見積もりを作ろう
  • 少しずつ発注してイテレーションに組み込んでいくのが賢いやり方

リアルタイム系で求められること

  • 結局リアルタイムシステムなので
    • ハードウェアに関する知識
  • アセンブラとかもなんとなく解る人が1人は
    • グラフィックスに関する知識

プロファイラを使おう

  • Unityが違うのは後から調整できる点

参考図書

ファジーなところにうまく対応しよう
リソース生産設計と非エンジニアの力を引き出そう


[16-C-3] 趣味と実益の脆弱性発見 (はせがわ ようすけ 氏)

[デブサミ2012]趣味と実益の脆弱性発見

2012/02/16 デブサミ2012【16-C-3】趣味と実益の脆弱性発見 #devsumiC

  • Webブラウザ側の脆弱性
    • Webアプリケーション側のエスケープ漏れより影響範囲が大きい
    • 取り組んでいる人が少ない
  • Web Workers
    • JavaScript待望のマルチスレッド機構
    • バックグラウンドで思い処理を実行
  • 10年後も世界で通じるエンジニアであるために
  • Web = 標準化 + ブラウザ独自実装
    • 独自機能を追いかけ続ける技術は10年後も通用するはず！

未開の地を探し続ける！
セキュリティな話をもっと発信してほしい


[16-A-4] Effective Smartphone UX at GREE (米川 健一 氏)

2012/02/16 デブサミ2012【16-A-4】Effective Smartphone UX at GREE #devsumiA

2つの距離を縮めるような設計をする

  • 指からタッチパネルまでの距離
    • 間違えてもすぐやり直せる
  • タッチパネルからアプリケーションまでの距離
    • 即座にフィードバックを出す

スマートフォンらしいUI

  • HTMLベースで作っている。HTMLだけでできないことをアプリで補う

Speed x Quality

  • onClick delay
    • WebKitベースのブラウザの場合、300msの遅延（ダブルタップ待ちがあるため）
    • onTouchStart & onTouchEnd を onClick のかわりに使う
  • Timeline Context
    • HTMLベースで作っているのでブラウザバックしたときにページの先頭に戻る。
  • Offline
    • ユーザが何をしたいか考えて設計する必要がある

Cross Platform vs OS Culture

Effective UX

  • 即座にフィードバックを返す
  • 間違えてもやり直せる
  • ユーザの文脈を壊さない