1 pixel｜サイバーエージェント公式クリエイターズブログ -16ページ目

デザイナー視点のイベント開発

はじめまして！アメーバゲーム部門でデザイナーをしている筒井豊です。
スマートフォン向けゲーム「天下統一クロニクル」の開発・運用を担当しています。

現在3月25日から始まる新イベント「天下統一戦」の開発に関わっているのですが、
イベント開発の流れを追いながらデザイナーの作業の進め方や、意識していたこと等をご紹介したいと思います。

新イベント「天下統一戦」とは？

「天下統一クロニクル(http://tnk47.ameba.jp)」はご当地の偉人や名物を擬人化したカードを集め、県の仲間と力を合わせながら日本一を目指すゲームです。

ゲームの基本システムに毎週日本一の県が決まる「合戦」があるのですが、そこにフィーチャーしてしっかり盛り上げるイベントを作ろうという目的で2013年10月に構想がスタート。2014年2月公開に向けて動き始めました。

スケジュールの決定と共有方法

開発にあたり、下記の構成で開発チームが組まれました。
運用とは別にチームを作ることで開発に集中することが目的です。
・プランナー　1名
・デザイナー　1名（私）
・フロントエンドエンジニア　3名
・エンジニア　4名

目標の公開日が決まると、そこから逆算してリリース日や基本ループ完成予定日等のマイルストーンを引きます。その後プランナーが作った作成ページ一覧をベースに、作業を細分化していき、それぞれの優先順位を決めていきます。

デザイン側のスケジュールはフロントエンド側に「早く完成していると開発がスムーズになる項目を確認後、各項目毎にデザイン期限を決めていきました。
（基本的には「新しい技術の検証が必要」「ゲーム内の別ページを使いまわせない新規ページ」のように実装に時間がかかるページを優先することが多いです）

仕様や画面一覧、作業進捗、修正項目等はgoogle docsで管理しつつ、「各職種リーダー参加の毎朝の進捗共有」「週一回のプロジェクト全体共有」を行いチーム内で情報を共有していきました。

前半の主な作業（11月後半～12月中旬）

11月後半におおまかな仕様が決まり、いよいよデザイン作業がスタート。

■コンセプト画像の作成
まずイベントのテイストを決めるため、コンセプト画像とロゴを制作。
本来ならイベントの報酬になるキャラをメインで配置していくのですが、
今回は47都道府県が主役になるイベントなので都道府県を代表するキャラを主役に配置しました。

こういった画像が最初にあると、ページやアニメーションの構成を考える際のベースになり、プランナーとの意識合わせにも役立つため非常に便利です。
この画像はイベントを通して様々な場所で使われることになりました。

◇コンセプトイメージ

■ゲームの中心となる戦場ページ
次にイベントの肝になる戦場のページに着手。
現在のゲームの基本となる「合戦」とどのように差をつけるかを話合い、ラフ案をブラッシュアップしながら決定していきました。

この画面は上部のアバターをアニメーションで動かしたかったため、方向性が決まった段階で動作確認等を進めてもらいました。
このように技術検証が必要なページは検証期間や試行錯誤の時間を確保するため、優先してデザインすると開発がスムーズに進みます。

◇戦場デザインの推移

■決まっていない仕様をつめる
大きな箇所だと、戦場内でのバトル方法が決まっていなかったため、アイデアベースでラフを作りながらプランナーと仕様を考えていきました。
当初全く新しいバトルを想定していましたが、操作や仕様が複雑になるとの理由でユーザーが慣れている通常のバトルをベースにすることが決定しました。

運用が始まってからの開発ではプランナーが他のタスクとかけもちしていることも多く
細かい仕様を最初に詰め切るのはなかなか厳しいため、ざっとした仕様で画面を作り、
それを元に仕様を決めていく方がプロジェクトが早く進みやすいです。
（新規開発の方がもちろんこういったケースは多いのですが）

また、仕様が固まっていない前半は作業時間の見通しが立て辛いため、最初に計画した
デザインスケジュールから遅れが発生しやすくなります。
マイルストーンは死守しつつも、フロントエンド側と相談しながら作業の優先順位を
随時調整し、フロントエンドの作業が遅れない状況を維持する必要があります。
今回の開発だと、後で差し替えがきく細かい画像の作成をガンガン後回しにしていきました。

作業中盤（12月下旬～1月）

主要なページが一段落すると、次はメインループ以外のページ作成を進めていきます。
このあたりも実装に入れるレベルで作業をすすめ、時間がかかる細かい画像は後回しです。
このあたりで、後回しにしている画像の多さを実感し始め、愕然としてきます（笑）

この他に、前半で作った基本ループに修正が入ってくるので、実装に影響のありそうなものから
随時修正をしていきます。

作業後半（2月～3月）

UIを一通り作り終えたら後回しにしていた画像系の作成に着手。
画像の他に、イベント情報を少しずつ公開していくティザー関連のお知らせやバナー等も作っていきます。

◇作成した画像の一例

もう一つ後半で大事になるのが、実際にテストして判明することに対しての修正です。
静止画の状態では分からなかった演出の不足や導線の不備等が次々と出てくるため、公開までに対応するもの、4月の二次開発にまわすものに割り振りし対応していきます。
各種の修正、指摘事項を確認するためのMTGも定期的に行われていきました。

今回のケースだと、「隊士召喚」というフィーバーの演出をもっと盛り上げたいという要望がテスト後に発生したため、急遽カットインの前に新規のアニメーションを追加することになりました。

◇隊士召喚カットインと追加アニメーション

開発を通して意識していたこと

このような流れで作業を進め、現在は3/25の公開に向け、ティザー画像や
細かい画像修正等を行っている状況です。
最後にイベント開発をする上でいくつか意識していたことをまとめてみます。

【その１】やってみたい表現を提案する
「リソースがないので前と同じ構成じゃないと…」
「ブラウザなのであまり動きはつけられない…」
このように運用フェーズに入ったゲームではリソースの関係でなかなか思い切ったことができないのですが、せっかくの新規開発なのだから最初は夢を広げましょう。
技術は日々進化しているので、ブラウザの表現の可能性もどんどん広がっています。
また、新規開発では開発スパンが長いこともあり、面白そうなことにはどの職種もノってきてくれます。
そのためにも、普段から他のゲーム等にふれて面白い表現をストックしておくことが大事です。

【その2】デザイナーも考える
デザイン面はもちろん、ゲームの仕様も積極的に考えて自分の意見を言っていきましょう。
仕様が決まるのを待って言われた通りのものを作るのではなく、ベストな表現を目指して常に考えて提案することでプランナーも楽になりますし、スピードもあがります。そして何より楽しいです。

【その3】開発の手を止めないデザイン作成
新規ならではの修正や作り直し、予定していなかった新規要素の作成が発生したり、運用タスクのヘルプや差し込み等も多々あります。
自分の作業スピードを見極めた上で作業のバッファをしっかりとり、多少の差し込みがあっても
こなしていける状態を維持する必要があります。
どうしても間に合わない場合は早めにチーム内で共有し、優先順位の低いものは
後に回す等の判断を繰り返して開発の手が止まらないように注意しましょう。
（特に今回のように担当デザイナー1人の場合はデザインがボトルネックになりやすいです）

【番外編】個人の趣味に走らない
広島出身のため、あらゆるページやアニメーションに広島風お好み焼きちゃんを
配置したかったのですが、そこは大人ですからぐっと我慢我慢。

◇たこ焼きやわんこそばもいいけどやっぱり広島風お好み焼きでしょ！

最後に

コホン。
少し話しがそれましたが、最後までお付き合いいただきありがとうございます。
各地のご当地隊士が活躍する天下統一戦、ご期待いただければと思います。

運用2年目に入った天下統一クロニクルですが、2月後半に「戦神リーグ」、3月月初に「防衛戦」、そして3/25(火)に天下統一戦といった具合に開発も運用も全力で取り組み、日々進化しています。
地元に愛着があるそこのアナタ！ぜひ一度プレイしてみてください！

天下統一クロニクル
http://tnk47.ameba.jp

難しくないデザイン効率化のすすめ

はじめまして。アメーバゲーム部門でデザイナーをしております吉田直由と申します。
リリース直後からの1年2ヶ月の間、ガールフレンド（仮）でUIデザインの運用を担当しておりました。

運用のフェーズになると大きく問題になってくるのが「業務の効率化」ではないかと思います。便利ツールの導入や、難しい技術の取得などもありますが、、、使い慣れない技術は逆に効率を下げる結果になってしまうのでは？　と、なかなか一筋縄ではいかない問題です。
ガールフレンド（仮）デザインチームの場合、1年目～3年目の若いメンバーが多く、さらにメンバーの数も10人という大所帯でした。どうしたら全員にとって負荷が少なく最大限に効果を上げられるか、「難しくないデザイン効率化」を目指して導入した2つの施策についてお話させて頂けたと思います。

ガールフレンド（仮）とは

「ガールフレンド(仮)」とは、ユーザーが主人公となり、様々な女の子と出会っていく学園恋愛カードゲームです。

Adobe Photoshop スマートオブジェクトを使ったアイコン類の作成

ガールフレンド（仮）では、１枚のカード追加につき、UIで使用するアイコン・サムネイルなど7種を作成しています。1ヶ月で追加されるカードは150～200枚程度あるので、毎月1000以上の画像を作成・登録する必要があります。

以前は画像の数だけPSDファイルを作成し、一つ一つ手動で書き出していました。

このフローをファイルの数だけ繰り返します。気の遠くなるような作業です、、、、

そこで、１枚のカードで作成する画像を１つのPSDファイルにまとめて、スマートオブジェクトを使ってまとめて管理するテンプレートを導入しました。あらかじめ画像の種類によって縮尺、位置を調整したテンプレートです。スマートオブジェクトの差し替えだけでガールの画像が全て置き換わる仕組みになっています。

このテンプレートの導入で書き出しフローは下記の様に。

毎回ファイルごとに画像を差し替え、サイズや位置の調整をしていたフローが必要なくなり、作業効率が3～4倍アップしたことでタイトなスケジュールに対応できる様になりました。

さらに、
・まとめて書き出すことで作業の抜け漏れがなくなったこと
・書き出す画像の種類が増えても作業量はほとんど増えないこと
など、今後の運用にも大きなメリットがあります。

■難しくないポイント
新しいツールの導入ではないので勉強会いらずで敷居が低い！

モジュール化と簡易HTMLを使ったページデザインの管理

イベントページやガチャのランディングページの作成について、基本的にページの数だけPSDファイルを作成していました。
下記の画像のように情報パネルのモジュールだけ複数のパターンが存在する場合、パターンの数だけファイルを作成して管理していることもあります。

このようなページ単位のPSDデータが複数あると、例えばヘッダーのロゴに修正が入ったときに全部のファイルを修正しなければなりません。

また、上記の3つのファイルの中から、例えば「未エントリー」のモジュールデザインが欲しい場合、3つのファイルを開いて中を見てみないと探せません。

ファイルが3つなら問題ありませんが、これが10ファイル、100ファイルということもあり得るとしたら？？　特に新しくチームに入ったメンバーへの負担が膨らんでいました。

そこで、ページごとに作っていたPSDデータをモジュールごとに分割、さらにモジュールごとに書き出した画像データを簡単なHTMLで再現するフローを導入しました。

先ほどのページ単位で作成していたデータに適応してみると、、、

モジュールごとにファイルを分けたことで、ロゴに修正が入っても 01.jpg を上書きすれば全ページに修正が適応されます。モジュールの縦幅が変わっても修正した画像ファイルの上書きだけでページの体裁が保たれるのも効率的です。

また、下記の様に画像ファイルと元データのフォルダ構成をあわせておき、画像のパスからPSDファイルの場所が割り出せる様にしたことで、欲しいモジュールに素早くアクセスできるようになりました。

さらに、
・ブラウザ上で簡易的に遷移を確認できること
・メニューページを作成して一覧性をもたせられること
・モジュール単位でデータを渡せるのでマークアップ担当者にもやさしい
など、今後の運用にも大きなメリットがあります。

■難しくないポイント
HTMLはあえて単純に！
イメージ画像を積んだだけのHTMLにしておくことで、マークアップの経験がないメンバーがパニックにならないようにしておくことも大切なポイントです。

最後に

効率化だけを考えてしまうと逆に非効率になってしまうことがあります。
スマートオブジェクトのテンプレートを導入した際に、よかれと思いスマートオブジェクトを入れ子にするテンプレートも作成したのですが、わかりにくく不評だったので破棄したことがあります。特に運用のフェーズでは、難しくしないことが正義かなと、ガールフレンド（仮）の運用に携わったことで感じた次第です。

最後まで読んでいただきありがとうございました。
何かのヒントに少しでもなれば幸いです。

そしてぜひガールフレンド（仮）で遊んでみてください！

JavaScriptテンプレートエンジン「JsRender」のすすめ

こんにちは。フロントエンドエンジニアをしている清水です。
私は今、スマートフォン向けブラウザゲーム「天下統一クロニクル」を開発・運用しています。

本記事では、天下統一クロニクルで利用しているJsRenderというJavaScriptテンプレートエンジンの基本的な使い方とちょっとしたTIPSを紹介しようと思います。

JsRenderとは？

JsRenderとは、テンプレートエンジンの一種です。

jQuery Templatesの作者でもあるBorisMoore氏が、同ライブラリの後継として作成しているライブラリです。
jQuery Templatesの後継ライブラリではありますが、jQueryにもDOMにも依存していません(jQueryと一緒に使うこともできます)。
まだベータ版という位置づけではありますが、非常に安定しており、APIもわかりやすいです。

JsRenderのよいところ

JsRenderでは、簡単なtrue/falseの条件分岐だけでなく、論理演算子を利用したり、JavaScriptとほぼ同様の条件式が記述できます。

テンプレート内に複雑なロジックを書くべきではない、という議論もあります。
しかし、運用中にJavaScriptを書けないメンバーがテンプレートを触ることもあるので、ある程度許容する必要があると思います。
また、ロジックがテンプレートに書けることにより、ある程度の変更ならテンプレートの修正だけで完結できる、ということもポイントが高いです。

基本的な使い方

天下統一クロニクルはカードゲームなので、カード一覧を例にします。(実際のコードとは異なります)

下記のようなデータを元にカード一覧を作成します。

var data = {
  cards: [
      {
        id: '1',
        name: 'レアカード',
        level: 10,
        maxLevel: 20,
        hasSkill: true,
        skill: 'それなりのスキルだよ',
        rarity: 'rare'
      },
      {
        id: '2',
        name: 'のーまるかーど',
        level: 10,
        maxLevel: 10,
        hasSkill: false,
        skill: '',
        rarity: 'normal'
      }
  ],
  maxCardCount: 100,
  totalCardCount: 2,
  userId: '12345'
};

テンプレートはこんな感じです。
JavaScriptにインラインで書くこともできますが、HTML側にスクリプトタグで書いてしまったほうがメンテナンスはしやすいと思います(もちろんメンバーのスキルセットによります)。

<div id="result"></div>

<script id="templateCardList" type="text/x-jsrender">
  <p>{{:totalCardCount}}/{{:maxCardCount}}</p>
  <ul>
    {{for cards}}
    <li id="card_{{:id}}">
      <p>Name:<span>{{>name}}({{>rarity}}),</span>
      <span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span>
      </p>
      {{if hasSkill && skill !== ''}}
      <p>skill:<span>{{>skill}}</span></p>
      {{/if}}
    </li>
    {{/for}}
  </ul>
</script>

実際に使う場所はこんな感じです。

var data = { /* 上で書いた内容 */ };

// テンプレートの登録
jsviews.templates({
  cardList: document.getElementById('templateCardList').innerHTML
});

// 描画
document.getElementById('result').innerHTML = jsviews.render.cardList(data);

こんなHTMLが出力されるはずです。

<ul>
  <li id="card_1">
    <p>Name:<span>レアカード(rare),</span><span>10/20</span></p>
    <p>skill:<span>それなりのスキルだよ</span></p>
  </li>
  <li id="card_2">
    <p>Name:<span>のーまるかーど(normal),</span><span>10/10(max!)</span></p>
  </li>
</ul>

サンプル

JsRenderのタグの説明

では、上記サンプルで使用したJsRenderのタグについて簡単に説明します。

・`{{:foo}}`, `{{>foo}}`

これらは値を出力するためのタグです。>だと指定された値をエスケープして表示します。

・`{{for someArray}}/* ループしたい内容 */{{/for}}`

{{for someArray}} ~ {{/for}}で囲われた部分を、開始タグで指定された配列データを充てながらループします。
ループ内のコンテキストは配列内の各要素です。
ちなみにループのインデックスは#indexで取得できます。
また、{{for someArray}} ~ {{else}} ~ {{/for}のように記述すると、配列の長さが0の時に出力する内容を記述できます。

・`{{if someCondition}} ~ {{else}} ~ {{/if}}`

指定した条件で分岐できます。
単純なtrue/falseの値だけでなく、比較や論理演算子の利用もできます。
また、複数の条件分岐をしたい時は{{else}}句に条件を書き、いわゆるelseifとして使えます

{{if someCondition}}
  // some code
{{else anotherCondition}}
  // another code
{{/if}}

知っていると捗るTIPS

テンプレート内で別のテンプレートを呼び出す

上記の例だと、例えば新たに一つカードを追加したいときなどにすべての要素を描画しなおさないといけません。

それだと効率が悪いので、カード情報を別のテンプレートにし、個別に描画できるようにします。
コードは下記のとおりです。

<!-- HTML -->
<div id="result"></div>

<script id="templateCardList" type="text/x-jsrender">
  <p>所持数: <span>{{:totalCardCount}}/{{:maxCardCount}}</span></p>
  <ul id="myCardList">
    {{for cards tmpl="cardItem"/}}
  </ul>
</script>

<!-- テンプレートを分割 -->
<script id="templateCardItem" type="text/x-jsrender">
  <li>
    <p>Name:<span>{{>name}}({{>rarity}})</span></p>
    <p>Level:<span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span></p>
    {{if hasSkill && skill}}
    <p>skill:<span>{{>skill}}</span></p>
    {{/if}}
  </li>
</script>

/* JavaScript */
var data = { /* 上で使ったオブジェクト */ };

var anotherCardItem = {
  id: '4',
  name: 'ハイノーマルカード',
  level: 12,
  maxLevel: 15,
  hasSkill: true,
  skill: 'なんともいえないスキルだよ',
  rarity: 'highnormal'
};

// テンプレートの登録
jsviews.templates({
  cardList: document.getElementById('templateCardList').innerHTML,
  cardItem: document.getElementById('templateCardItem').innerHTML
});

jsviews.views.helpers({
  dump: function(value) { return JSON.stringify(value);}
});

// 描画
document.getElementById('result').innerHTML = jsviews.render.cardList(data);

// カードをリストにを追加
document.getElementById('myCardList').innerHTML += jsviews.render.cardItem(anotherCardItem);

サンプル

{{for}}以外に、{{props}}や{{include}}でも同様に外部のテンプレートを呼び出すことができます。
ただし、{{include}}では描画に使用するデータを指定することはできず、親のテンプレートと同じコンテキストが使用されます。

ループの中で、コンテキストの親データにアクセスする

forタグ内のコンテキストは配列内の各要素ですが、forループ内で配列の外側の値にアクセスしたい、ということもあります。
そんなときは下記の3つの方法が使えます。

1. `~root`を利用する

~rootは、そのテンプレートに渡されたオブジェクト／配列への参照です。
こから辿って行くことですべてのデータにアクセスできます。

<script id="templateCardList" type="text/x-jsrender">
<p>所持数: <span>{{:totalCardCount}}/{{:maxCardCount}}</span></p>
<ul>
  {{for cards}}
  <li data-user-id="{{>~root.userId}}">
    <p>Name:<span>{{>name}}({{>rarity}})</span></p>
    <p>Level:<span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span></p>
    {{if hasSkill && skill}}
    <p>skill:<span>{{>skill}}</span></p>
    {{/if}}
    <p>ユーザID: {{:~root.userId}}, カードID: {{:id}}</p>
  </li>
  {{/for}}
</ul>
</script>

サンプル

2. `#parent.data`を利用する

#parent.dataを利用すると、そのコンテキストの親データに移動することができます。
parentは任意の数だけつなげて上の階層へ移動できます。

<script id="templateCardList" type="text/x-jsrender">
<p>所持数: <span>{{:totalCardCount}}/{{:maxCardCount}}</span></p>
<ul>
  {{for cards}}
  <li data-user-id="{{>#parent.parent.data.userId}}">
    <p>Name:<span>{{>name}}({{>rarity}})</span></p>
    <p>Level:<span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span></p>
    {{if hasSkill && skill}}
    <p>skill:<span>{{>skill}}</span></p>
    {{/if}}
    <p>ユーザID: {{:#parent.parent.data.userId}}, カードID: {{:id}}</p>
  </li>
  {{/for}}
</ul>
</script>

サンプル

3. ループの中から参照できる値を設定する。

ループの中からは基本的に配列内の各要素にしかアクセスできませんが、ループの中から参照する値を個別に設定することができます。
for文の開始タグ内で~foo=someValueのように定義すると、for文内で~fooという形で参照できます。

<script id="templateCardList" type="text/x-jsrender">
<p>所持数: <span>{{:totalCardCount}}/{{:maxCardCount}}</span></p>
<ul>
  {{for cards ~userId=userId}}
  <li data-user-id="{{>~userId}}">
    <p>Name:<span>{{>name}}({{>rarity}})</span></p>
    <p>Level:<span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span></p>
    {{if hasSkill && skill}}
    <p>skill:<span>{{>skill}}</span></p>
    {{/if}}
    <p>ユーザID: {{:~userId}}, カードID: {{:id}}</p>
  </li>
  {{/for}}
</ul>
</script>

サンプル

テンプレートに、メインのデータ以外に別のデータを渡す

たとえばデータとテンプレートは使いまわす。でも画面によって少し出し分けしたい。という時などに利用できます。

下記はカード一覧と強化カード選択画面でボタンを出し分けたい、という時の一例です。ページの識別子を渡し、判定に使っています。
この別に渡された値のことを「ヘルパー」と呼びます。ヘルパーは変数名の前に~(チルダ)をつけることで呼び出せます。
ヘルパーは数値型や文字列型だけでなく、関数や配列、オブジェクト等を設定することもできます。

<!-- HTML -->
<script id="templateCardList" type="text/x-jsrender">
<p>所持数: <span>{{:totalCardCount}}/{{:maxCardCount}}</span></p>
<ul>
  {{for cards ~userId=userId}}
  <li data-user-id="{{>~userId}}">
    <p>Name:<span>{{>name}}({{>rarity}})</span></p>
    <p>Level:<span>{{:level}}/{{:maxLevel}}{{if level === maxLevel}}(max!){{/if}}</span></p>
    {{if hasSkill && skill}}
    <p>skill:<span>{{>skill}}</span></p>
    {{/if}}
    <p>ユーザID: {{:~userId}}, カードID: {{:id}}</p>
    <button class="jscCardAction">
      {{if ~pageId==='cardList'}}リーダーにする
      {{else ~pageId==='upgrade'}}強化素材にする{{/if}}
    </button>
  </li>
  {{/for}}
</ul>
</script>

/* JavaScript */
jsviews.render.cardList(data, {pageId: 'cardList'});

サンプル

出力する値をカスタマイズする

たとえば数値型の値をカンマで三桁区切りにしたいなど、サーバーから受け取った値を加工して表示したいことがあると思います。

そんな時はコンバーターが使えます。コンバーターはただの関数なので様々な処理が行えます。
コンバーターは{{converterName:value}}のようにして使います。

<!-- HTML -->
<script id="tmplConverter" type="text/x-jsrender">
<p>攻撃力:<span>{{thousands:attackPower}}</span></p>
</script>

/* JavaScript */
var data = {
    id: '1',
    name: 'レアカード',
    level: 10,
    maxLevel: 20,
    hasSkill: true,
    skill: 'それなりのスキルだよ',
    rarity: 'rare',
    attackPower: 25000
};

jsviews.templates({
    converter: document.getElementById('tmplConverter').innerHTML
});

// コンバーターの登録
jsviews.views.converters({
    thousands: function(num) {
        // 小数点消す
        num = '' + parseInt(num);

        // 3桁毎に区切る
        while(num != (num = num.replace(/^(-?\d+)(\d{3})/, "$1,$2")));

        return num;
    }
});

document.getElementById('result').innerHTML = jsviews.render.converter(data);

サンプル

オブジェクトをループする

{{props}}を使うと、特定のオブジェクトのプロパティをループすることができます。
{{props}}では、keyにプロパティ名、propに対応する値が入っています。
また、{{for}}と同じように、tmplを使って描画に使うテンプレートを指定することもできます。

サンプル

テンプレートをDOM形式で出力する

JsRenderは出力結果を文字列で返してくれますが、一手間加えることでDOM形式に変換することができます。

文字列をDOMに変換、というと

var temp = document.createElement('div');
temp.innerHTML = '<p>foo:<span>bar</span></p>';
document.body.appendChild(temp.firstChild);

みたいな書き方もできますが、divを余計に作る必要があったりしてスマートでないのでrangeを使います。

var range = document.createRange();
range.selectNodeContents(document.body);

// JsRenderで出力された文字列をdocumentFragment化
var tmplFragment = range.createContextualFragment(jsviews.render.someTmpl(data));

document.getElementById('result').appendChild(tmplFragment);

documentFragmentだとそのままappendChildできるのでいいですね。

サンプル

最後に

以上、簡単にJsRenderの使い方について説明させていただきました。

各サンプル毎にjsdo.itのサンプルを用意しておきましたので、実際に試してもらえるとありがたいです。
また、本家のドキュメントも英語ではありますが非常に充実しています。
その場でコードを試すこともできるので、何かあったら英語だと尻込みせず確認してみると幸せになれます。

それでは、最後まで読んでいただきありがとうございました！

色を色で見ないで

はじめまして。
2013年度新卒入社、AmebaのSimplogでWEBデザイナーをしているリュウタロウと申します。

以前新卒デザイナー同士の勉強会がありまして、そこでの私の発表内容がすごく好評でした。
以降より多くの人に向けて発信したいと考え、この場をお借りして記事を執筆させて頂く事になりました。

これから綴るのは、デザインの細かいテクニックやハウツーではありません。
様々なジャンルのクリエイティブに通じる、基本的なモノの見方、考え方の話です。
「ワタシ、デザインワカラナイワ」
というビジネスパーソンも、普段やっている仕事や趣味とリンクさせながら理解できる内容だと思います。
更にこれを読めば、様々なクリエイティブにチャレンジ出来る様になります。

少し長くなりますが、最後まできっと楽しんで頂けると思います:)

色を色で見ないで

"色を色で見ないで"という見出しが既に意味不明ですよね・・・
いきなりですが、まずは具体例をお見せします。
こちらをご覧下さい。

この色の並び、みなさんにはどう見えているでしょうか？
「いやいや、右から紺、赤、緑でしょ、誰でもわかるわ！」
そうですね、もう見たままです。
ですが、私にはこう見えています。（ドヤァ）

これは『明度』による見方です。
『明るい』『暗い』という見方。
私たち人間が見ている世界はフルカラーなので、こんな見方をする人はそうそう居ないと思います。

なんですが・・・
これはモノの『本質』を見極め、モノの『構造』を作り上げる上でとても重要なモノの見方になります。
『構造』は、建築で言えば骨組みや土台の部分です。
どんなに外見がお洒落でカッコ良くても、ちょっとの地震で壊れてしまう様じゃ建築物として成り立たないですよね？
つまり「ここがダメなら全部ダメ」という最も大事な部分になります。

デザインをする時『黄色』『青』という見方ではなく、
『明るい』『暗い』で見ながら画面作りをしましょう！
という話を、まずは綴っていきます。

シンプルかつ複雑であれ

こちらは"幾何構成"というやつです。
デザイン系の学生だった方なら馴染みがあると思うのですが、これは平面のデザインにおける最も基本的なワークになります。
やり方はとても簡単。
図形を重ねる様に配置して、沢山出来た面に色を置いていくだけです。

実はこの二つの幾何構成、左が悪い例、右が良い例になっています。
といってもピンと来ないと思いますので、冒頭で書いた『明度』による見方をしてみましょう。

左
明度が全体的に似ていて、主張したい事が何なのか分かりません。
ハッキリとした構造が見えないからです。
これではどこに視線を置いて良いのか分かりません。

右
大きな明るい面がまず目に入って来ます。
そこから小さな明るい面へと視線が流れていく。
最初に見せたい事が明快で、見る人の視線の動きを作っています。
構造が分かり易い。
ですが決して簡素ではなく、複雑で見応えがありますよね。

ここからが大事なポイント。
デザインをする時に、色を色で見て選ぶのではなく、まずは
『明るい』『暗い』の対比でザックリ大きく構成する。
次に、『明るい』という括りの中で、『明るい』『暗い』の幅を増やし、色味を加えていく。
『暗い』という括りの中で、『明るい』『暗い』の幅を増やし、色味を加えていく。

こうする事で、一見複雑で見応えがあるのに、シンプルで見やすい画面を作る事が出来るんです。

最初にザックリ決めた『明るい』『暗い』の括りを守れば、
多少要素がガチャついても画面が崩れにくくなります。
あと色を選ぶ時に、『明るい』『暗い』の基準があれば迷う事も少なくなります。
（もっといろんな幾何構成を見てみたい方は、東京造形大学デザイン学科の過去問をチェックしてみて下さい。）

物語の「起承転結」に例えると分かり易いと思います。
ぐちゃぐちゃに沢山の出来事が起きているけれども、離れて見れば「起」「承」「転」「結」というたった4つの括りでしかない。
それぞれの括りの中で出来事が複雑に絡み合っている。
これはプレゼンテーションにも応用できますね。

人に何かを伝えるにはシンプルである事が大切です。
そしてそれが複雑であれば人の感情を引き込む事が出来ます。

Twitter創業者ジャック・ドーシー氏の
「創造とはシンプルかつ複雑であること」
というよく分からない言葉もなんだか分かった気になれますね！

デザインだけじゃない

この画面の見方はグラフィックデザインはもちろん、絵画、写真、Webデザインにも応用出来ます。
様々なジャンルの作品を『明度』で見てみましょう。

海外のイケてるグラフィックデザイン。
（このサイトオススメです）
青い背景、写真、タイポグラフィ、ドローイング・・・と沢山の要素が重なっていて一見複雑に見えますが、
こうやって見てみると実にシンプルな『構造』になっている事が分かると思います。

モネの名画ですね。
これも女性、傘、空、草原・・・というぱっと目に見える要素ではなく、『本質』を見てみる。

写真も同じです。
（こちらの写真は海外のフォトコンペから）
ちなみに、
写真を撮る時に『明度』の構成を意識するとトリミングが上手くいきます。
今まで自分がいかに無駄なモノを撮っていたかが分かるので、試してみて下さい。
あと、写真加工アプリでコントラストを強くすると良い感じになりますよね？
あれは画面の『構造』が浮き立ってくるからなんです。
だから印象に残りやすくなるんです。

任天堂Wii UのWebサイト。
Webはグリッド状のデザインが多いのでもっと『構造』が分かり易いです。
写真や文字が盛り込まれた、商品をアピールするエリア（暗い）
ヘッダーとサイドのメニュー系（明るい）
ユーザーの視線と手の動きが自然とシンプルになります。

いかがでしょうか。
本当はもっと沢山サンプルをお見せしないと説得力が無いのですが・・・
良いものの多くはシンプルです。
一見複雑に見える絵画も、実はシンプルだったりするものです。
機会があれば、様々なジャンルの作品をモノクロに加工して『明度』で見てみると面白いと思います。

『意識』のはなし

「フツーの人はコウゾウがどうとかメイドがどうとか、
そんなん気にせぇへんやろ？
なんでそんな事考えなアカンねん。意味分からんわ。」

こんな事言われる前にいろいろつっこみたくなるところですが、
大変です、怒られてしまいました。

でもこれは本当にそうです。
人はそんなの気にしないですよね。
ここでちょっと人の『意識』の話をします。

人は画面を見る時、細かい形や色を意識しがちです。
冒頭でお見せした色の並びも、
「紺、赤、緑・・・」
という風に見えていましたよね？
ここで先ほどの幾何構成を思い出してみて下さい。
"視点をどこに置くか、どういう視線の流れで見るか"
というのは『明度』の『構造』によって自然と決まってくるんです。

つまり『構造』というのは人の『無意識』に作用しているもの。
見る側からしたらぱっと見で分からない。
なので素人が手を抜きがちな部分でもあります。

ラーメンに例えると、スープのダシみたいなものです。
食べる側からしたら何の材料で作ってるかなんて分からないですよね。
けど職人が１番時間とお金をかけるのは、味のベースを決める大事な部分だからです。

主役は特別

ここまで全体の『構造』の話をしましたが、『明度』によるモノの見方や考え方は『部分』でも効果を発揮します。

私達デザイナーは「もっと目立たせて」から始まって、
「大きくして」とか「太く！」とか「色を派手に！」
という様な要望を沢山頂きます。
あるあるです。
ここでちょっと面白いものをお見せします。

左と右の正方形を比べて見て下さい。
どちらが目立つでしょうか？
これを見れば
大きさの対比＜明度の対比
という事が分かると思います。

こちらは私が新卒研修で制作した、架空のホテルのWebサイトです。
(大きい画像 : page1 page2)
ホテルは予約を取ってもらう事を考えなきゃなので、ここで重要になるのは、"目を引く空き部屋検索ボタン"です。
単純にこうしちゃいましょう。↓

逆にこれじゃダメです。↓

白い（明るい）背景の上に大きな黄色い（明るい）ボタンを置いても目立たないんです。
逆に青い（暗い）ボタンなら小さくても人の目に入ってきます。
以前こんな記事が話題になりましたね。
会員登録ボタンと買い物カゴボタンのビフォーアフターに注目してみて下さい。

「じゃあ明るい背景に暗い色を置けば目立つのか！」
という単純な話ではなく・・・
理解しなければならないのは、モノ同士の関係性。
ある仕組みや関係性の中でどう見せるか。
つまり対象の『本質』を見極め、対象の『構造』を理解した上で、どういうアクションを起こすかを考えるという事です。
対象を大きくする前に、それ以外を小さくする事だって出来るんです。

「ホワイトのショーには全身ブラックでブラックのショーにはホワイトの靴を履く」
これは去年USAで大ヒットした曲、Justin Timberlake feat. Jay-Z "Suit & Tie"でのJay-Zバースの一節。
ショーの"主役"になっちゃう人の行動はいつでも特別なんですね！

ま・と・め

・『黄色』『青』という見方ではなく、『明るい』『暗い』で見る。
・『明るい』『暗い』の対比でザックリ大きく構成する。
・『明るい』という括りの中で、『明るい』『暗い』の幅を増やし、色味を加えていく。
・『暗い』という括りの中で、『明るい』『暗い』の幅を増やし、色味を加えていく。
・大きさの対比＜明度の対比

WEBページをPhotoshopで作っている途中、画面をモノクロに加工して見てみると良いです。
（調整レイヤーの白黒を使うのではなく、モードをグレースケールに）

さいごに

ここまで綴っておいて恐縮ですが・・・
これまでの話はあくまで"一つの見方"です。
なんでもかんでも
「コウゾウがさー、メイドがさー、」
なんて理屈を言っていたら正直ちょっとキモチワルいです。
女子から嫌われます。
心から楽しめる人とアンディ・ウォーホル展に行きたいものです。

「うわぁかっこいい！」
「かわいいー！」
「素敵！♥」
って言わせちゃうような、"言葉で説明できない感情"を動かす人の方がカッコいいと私は考えています。
むしろその為にこういったモノの見方や考え方がある、くらいに捉えて下さい。

『明度』がどうこうではなく・・・
理解しなきゃいけないのは、私たちの目に見えているモノは何かしらの『構造』上に成り立っている、
という事です。
美術の基本とされるデッサンは、目に見えたモノを描き写す"描写"と思われがちですが・・・
実はちょっと違います。
モチーフの『構造』を理解し、『本質』を見抜く。
どういうカタチなのか
後ろ側はどうなっているのか
何故ここに影が落ちているのか
どういう質感なのか
そしてそれを一枚の紙の上に表現し、他者に伝える行為を指すんです。

ミケランジェロお爺さんのおひげやお洋服を見ただけで頭が痛くなりそうですが・・・
こういう細かい形に惑わされずに大きな『構造』を捉える事が大切です。

大事なのは応用力です。
『構造』の定義も様々です。
WEBデザインにおいてはビジュアル的な『構造』もあれば、CSSの『構造』もあります。
その下にはサイトマップという『構造』があり、さらに掘り下げればサービスのコンセプトという『構造』の上に成り立っている。
デザインはアイディアを生み出す段階から始まっているのかもしれませんね。

冒頭で綴ったように、この考え方は様々なクリエイティブに通じるもの。
私は音楽を作ったり、こうやって文章を書くのも好きですし、大勢の人前でのプレゼンテーションを考えるのも楽しい、学生時代はラーメン作り（ダシから）に没頭していたり・・・
いろいろやりながら今も毎日楽しく過ごしています。

じゃあこの考え方を応用すれば何でもかんでも上手くいく、
という事ではなくて、あくまで何にでも"チャレンジできる"という事です。
"基本"を身につけた後は"経験"や"技術"が必要ですよね。
実際にチャレンジしてみて、経験ある先輩方から学ばなければいけません。
そして更に"基本"を磨き続けなければなりません。
私のWEBデザイン歴は2年にも満たないので、これから沢山の事を学んでいくでしょう:)

いかがでしたでしょうか。
何か一つでも参考になる事があったら嬉しいです:)
長くなりましたが、最後まで読んで頂きありがとうございました。

Follow me!!!
blog
twitter
facebook
pinterest
portfolio

nodeベースでGUIアプリを開発する「node-webkit」

こんにちは。Ameba事業本部の杉本と申します。

業務では「天下統一クロニクル」というチームでフロントエンドのディベロッパをしています。

今回は、「node-webkit」という一風変わったアプリケーションを紹介させていただきます。

私達は普段、gruntといったnode.js製のツールを使ってJavaScriptの結合や圧縮、画像の減色といった処理を自動化していますが、node-webkitはこれらnodeのモジュールを使ってGUIアプリケーションを作れるツールです。nodeの資産をそのまま利用できるので、私のようなディベロッパには嬉しいですね。

今日は、node-webkitの概要と仕組みからアプリケーションの作り方までを簡単に紹介させていただきます。
node-webkit

node-webkitとは

node-webkitは、Chromiumの機能を内包したGUIアプリケーションを実行します。インターフェースもHTML5/CSS3、クライアントロジックもJavaScriptで記述することができます。イメージとしては、Adobe AirのHTML5バージョンといったところでしょうか。まずは、以下のコードを見てください。node-webkitで実行するサンプルコードです。

<!doctype html>
<html lang="ja">
  <head>
    <title>Sample node-webkit app</title>
    <meta charset="UTF-8">
    <script>
      var fs = require('fs');

      document.addEventListener('DOMContentLoaded', function() {
        var contents = fs.readFileSync('./sample.txt');

        document.body.innerHTML = contents;
      });
    </script>
  </head>
  <body></body>
</html>

えっ、と思われた方もいるかもしれません。上のコードにはDOMのコードとnodeのコードが混在していますね。nodeのFileSystemモジュールをロードし、ローカルファイルの内容を読み込み、そのままinnerHTMLに代入しています（もちろん、本来はエスケープ処理が必要です）。

node-webkitでは、DOMとnodeの機能を併用することができるんです。もちろん、HTMLの装飾もタグでCSSへのリンクをつければスタイリングされますし、GUIのクリックイベントも従来どおりのJavaScriptでイベントハンドリングを行うことができます。

さらに、Chromiumのを内包したWebkitベースのアプリケーションとなるので、Windows/GNU Linux/Mac OSのどのプラットフォームで動作させることが可能で（それぞれのプラットフォーム用のビルドは必要です）、Webkitの機能をほぼ全て使うことができます。WebWorker、WebGL、localStorage、IndexedDB、SQLDataBase、WebSocketなど、互換性を気にする必要もありません。また、HTML側にもファイル操作関連の機能拡張がなされています。

少し興味が出てきたでしょうか？このコードをGUIアプリケーションとして動作させるのもとても簡単です。以下では、一番手軽で簡単なMac OS用のアプリケーションを例に上げます。また、node.jsが実行できる環境も用意しておきましょう。

node-webkit本体のインストール

npmからインストールできます。ターミナルから適当なディレクトリ内でnpmモジュールとしてインストールしましょう。

$ npm install nodewebkit

少し時間がかかりますが、これでインストール完了です。
（npmでインストールされるnode-webkitはやや古い場合があります。最新版を使用したい場合は、githubのページから最新のパッケージがダウンロードできます。）

アプリケーションの記述

node-webkitでは、メインで実行されるhtmlファイルと、package.jsonだけで動作可能です。サンプルのアプリケーションは以下のようになります。よくあるnodeのプロジェクトのようですね。

app - index.html
       |- package.json
       |- sample.txt
       |- node_modules

index.htmlは先に示したコードを記述し、"Hello, node-webkit!"という文字列を書いたテキストファイルをsample.txtとして配置します。続いて、pacakge.jsonを作成し、node-webkit用の設定を記述します。今回は以下のように記述しました。

// package.json
{
    "name": "Sample-node-webkit-app",
    "main": "index.html",
    "scripts": {
        "start" : "node_modules/nodewebkit/bin/nodewebkit"
    }
}

package.jsonのフォーマットも、npmで生成されるものと互換性があります。
ここまでできたら、ターミナルから以下のコマンドを実行します。

$ npm start

GUIアプリケーションが起動し、"Hello, node-webkit!"という文字が表示されたら成功です！

HTMLファイル一枚だけでGUIアプリケーションが作れてしまいました。また、Chromiumベースなので、DevToolもChromeと同じく優秀です。GUI上の歯車のマークをクリックすると、Chromeでお馴染みのDevToolが起動します。
さらにさらに、Consoleのペインでは、通常のJavaScriptのデバッグに加えて、nodeのコードも動かすことができます。ブレークポイントを使ってnodeのスクリプトのデバッグが行えるのも嬉しいですね！

続いて、GUIウインドウの設定を変更してみます。package.jsonに「window」というプロパティを追加し、設定を記述することで、ウインドウ制御を行うことができます。（アプリケーションの終了は、ターミナル上でCtrl+cを押してください）

// package.json
{
    "name": "Sample-node-webkit app",
    "main": "index.html",
    "scripts": {
        "start" : "node_modules/nodewebkit/bin/nodewebkit"
    },
    "window": {
    	"title" : "Sample-node-webkit-app",
    	"width": 800,
    	"height": 600,
    	"toolbar": false
    }
}

この設定で再度起動すると、今度はサイズが大きくなり、ツールバーのないGUIアプリケーションっぽい感じになりました。他にも、フルスクリーンの設定やキオスクモードの設定もあるので、詳細な設定項目は、Manifest formatのページを参照してください。

アプリケーションのデプロイ

さて、このままではnpm startのコマンドからしかアプリケーションが起動できません。せっかくなのでアプリケーション化し、アイコンのダブルクリックで起動できるようにしてみましょう。
まずは、npmでインストールしたnode-webkit本体を取り出します。
npmでインストールしたnode-webkitの場合、本体は、node_modules/nodewebkit/nodewebkit/node-webkit.appにあります（時計のようなアイコンです）ので、これを適当な場所にコピーします。

そして、アプリケーションの中身を表示して、Contents/Resourcesディレクトリの中に「app.nw」という名前のディレクトリを作成します。この名前は規定なので注意してください。

node-webkit.app
  |-Contents
    |-Resources
      |-app.nw  ←ここに作成

あとはapp.nwの中に、先に作成したindex.htmlとpackage.json、sample.txtを入れるだけで完了です（別途npmでモジュールを追加している場合は、node_modulesもコピーします）。試しにアプリケーションをダブルクリックしてみましょう。ちゃんと起動できれば、GUIアプリケーションの完成です。

また、毎回このような作業を行うのはとても手間なので、node-webkitのインストールからデプロイまでをgruntのタスクで自動化してしまいます。

ysugimoto / grunt-node-webkit-builder

上のリポジトリをnpmでインストールし、以下のように設定を書けばgruntコマンドでデプロイできます。(現在はMac OS用に作ってあります）

module.exports = function(grunt) {

    'use strict';

    grunt.initConfig({
        nodewebkit: {
            src: ['package.json', 'index.html', 'sample.txt'],
            name: 'Sample-node-webkit-app'
        }
    });

    grunt.loadNpmTasks('grunt-node-webkit-builder');
    grunt.registerTask('default', ['nodewebkit']);
};

nodeモジュールによる拡張性

node-webkitで作るGUIアプリケーションではnodeのモジュールが利用できると説明しました。これにより、シェルの実行などはchild_processを使えますし、httpモジュールを使えばビルトインサーバの起動やHTTP通信も可能です。また、Webkitだけでもできることは増えてきていますが、足りない機能をさらにnpmパッケージをインストールして使うことができます。

例えば、zipやtarの解凍などもnpmのモジュールを使えば簡単に実装できます。今までCLI上で実行されてきたnodeの機能がGUI上でも使えるとなれば、考えられるアプリケーションの幅も広がるのではないでしょうか。

シェルを実行するサンプルアプリケーション

例を考えてみましょう。Macをセットアップするとき、私はパッケージマネージャにHomeBrewを使いますが、ターミナルからインストールを行う作業はシェルに慣れていない方だと少々ハードルが高いかもしれません。そんなとき、インストールから実行までのシェルを実行するように書いたnode-webkitアプリを使ってもらえれば、ボタンひとつでインストールできるのではないでしょうか。

以下のようなHTMLファイルを用意して、GUIアプリにして配布すれば、どなたでもHomeBrewがインストールできます。

<!doctype html>
<html>
  <head>
    <title>BrewInstaller</title>
    <meta charset="UTF-8">
    <style>
      #install {
        display: inline-block;
        padding: 5px 10px;
        border-radius: 5px;
        background: #28cccc;
        border: none;
        text-align: center;
        width: 100px;
        font-size: 20px;
      }
      p {
        text-align: center;
      }
    </style>
  </head>
  <body>
    <p>HomeBrew Installer<br>
      <button id="install">Checking...</button>
    </p>
    <script>
      var exec       = require('child_process').exec,
          fs         = require('fs'),
          btn        = document.getElementById('install'),
          installing = false;

      // すでにインストール済みかどうかチェック
      exec('which brew', function(err, stdout, stderr) {
        if ( ! err ) {
          if ( stdout !== '' ) {
            // すでにインストールされている
            btn.classList.add('installed');
            btn.textContent = 'Installed';
            return;
          }

          btn.textContent = 'Install';
          btn.addEventListener('click', doInstall, false);
        }
      });

      function doInstall(evt) {
        if ( installing ) {
          return;
        }
        installing = true;

        var bashProfile= process.env.HOME + '/.bash_profile',
            proc;

        // .bash_profileが存在すればパス追記
        if ( fs.existsSync(bashProfile) ) {
          fs.appendFileSync(bashProfile, 'PATH=":/usr/local/bin"\n');
        } else {
          fs.writeFileSync(bashProfile, '#!/bin/sh\n\nPATH=":/usr/local/bin"');
        }

        // homebrewのインストール
        proc = exec('/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go/install)"', function(err, stdout, srderr) {
          if ( ! err ) {
            // .bash_profileを再読み込み
            exec('source ' + bashProfile, function() {
              btn.textContent = 'Installed';
              btn.removeEventListener('click', doInstall);
            );
          }
        });

        proc.stdout.on('data', function(msg) {
          // expectのように入力を促すstdoutに対してCRLFを送信
          if ( /PRESS\sENTER/.test(msg) ) {
            proc.write('\r\n');
          }
        });
      }
    </script>
  </body>
</html>

アプリケーションを起動すると以下のような小さなGUIが起動します。Installのボタンを押すと、シェルが実行され、HomeBrewがインストールされます（環境によって上手くいかないケースもあります）

HomeBrewのインストール後にさらに"brew insall git"といったコマンドを実行するように設定しておけば、開発環境のセットアップもGUIからボタン一つで行うことができるでしょう。
このようなシンプルなシェルの実行をラップしたGUIアプリケーションを手早く作るのにnode-webkitは最適だと思います。

SPAの練習に

また、SPA（Single Page Application）の練習にも丁度よいと思います。一枚のHTMLファイルに対して、JavaScriptからWebSocketやAPI通信、ファイルI/Oから動的にデータを書き換えるような処理をnode-webkitで作ってみるのも面白いと思います。

公式サイトにもデモアプリが幾つか掲載されているので、是非試してみてください。

zcbenz / nw-sample-apps

また、SPAの習作としてnode-webkitでAWS S3のクライアントアプリを作ってみました。

ysugimoto / aws-s3-dav

node-webkitの今後

まだ登場してあまり日が経ってないツールですが、最新が0.8.4と、メジャーバージョンがリリースされるのもそれほど遠くないかも知れません。活発にissuesも投げられています。海外では採用実績は色々あるようですが、日本ではまだそれほど情報も多くないようです。

（参考：Prepros: node-webkitで書かれたSassなどのGUI上のビルドツール）

もちろん本格的なGUIはC#のような言語には敵いませんが、スクリプトベースである利点を利用して、API監視ツールや、GUIでのアプリケーションインストーラなど、コンソールから実行していたものを視覚化するアプリの開発には有用ではないかと思っています。

最後に

簡単にnode-webkitの紹介とGUIアプリケーションの作り方を紹介させていただきました。

日常の開発の中で、自動化や効率化は重要な課題だと感じており、さらにこれらのツールをメンバーで共有することはさらに重要なことだと思います。
ミスを減らし、かつ効率を上げるため、冒頭に書いたようなgruntといったツールはもちろん、細かい作業も全てコマンド化したりすることで自動化しています。これらをnode-webkitのようなツールでGUI化し、開発環境のセットアップやメンテナンスを簡単にしていくのも効率を上げる手段の一つではないでしょうか。GUIなら「黒い画面」が苦手な方でも使える共通ツールになりえると思います。

node-webkitを使う上で、他のプラットフォームの対応や、DOMとnode実行環境での約束事、GUIの動的な制御など、本格的なGUIアプリケーションを作る際のもう少し深い話はまた機会があればご紹介させて頂きます。

それでは、最後まで読んでいただきありがとうございました！

半年で3億回押された「ありがとう」を伝えるボタン

みなさま、初めまして。
デザイナーのキムハヨンと申します。2013年に新卒入社しました。
現在、「きいてよ！ミルチョ」のデザインを担当しています。

今回はミルチョの流れの中でKEYボタンになる、
「ありがとうボタン」の制作方法についてお話させていただきたいと思います。

きいてよ！ミルチョ」とは…？

不思議な生き物ミルチョにど～でもいいひとりごとをきいてもらいながら
ゆる～くつながる新感覚コミュニティです。

ミルチョの流れ

ミルチョには以下の図のような流れがあります。

①Bさんのひとりごとに対して、
②Aさんが、ひとりごと「きいたよ」と言うと、
③Bさんは、きいてくれて「ありがとう」と返します。

ありがとうボタンは基本、図のようにハートの形ですが、季節ごとのイベントによって背景に合わせたモチーフでデザインを変えています。

ありがとうボタンの作り方

例えば、昨年の8月はかき氷をモチーフにしたありがとうボタンを作りました。
そのプロセスを具体的にご紹介致します。

まず、プロデューサーから夏を感じられるテーマのありがとうボタンを作りたいと依頼があり（①）、スイカやアイスバー、かき氷など思いついたものをスケッチしてみます（②）。
その中からボタンとしての素材になるかどうかの基準で絞り、モチーフを決めます（③）。
今回はかき氷の方が多くの人に共感できるモチーフであったため、「かき氷」を選びました。
モチーフを実物とまったく違うものならないようにするため、まずかき氷の参考になるイメージを検索します（④）。

そこからかき氷の形をちゃんと描き始めます（⑤）。
描いた紙をスキャンしてIllustratorでパスに起こします（⑥）。

起こしたパスのデータをPhotoshopにシェイプレイヤーとして持ってきます（⑦）。
色塗りとサイズ調整をして仮で入れてみます（⑧）。

→色が可愛くないし、表現も細かすぎて押して嬉しくなるボタンには見えないことに気付きます。

それでもう一度紙に描いて（⑤）、Illustrator→Photoshopのプロセスを踏みます（⑥→⑦）。

そうすることによって、以下のようなボタンになりました。

氷とシロップが混ざってるところの表現を簡略化して2段分けし、少し高めの彩度の色を使って夏に食べたくなるかき氷を表現しました。
コップの波の柄も最初のリアルな表現より可愛くなったと思います。
4色のバリエーションを出して、押した時にランダムに表示させるような設定をしたので、その変化によって楽しさも感じることができます。
スーパーありがとうボタンは普通のありがとうボタンの4色を使って、特別なボタン(コメントを書くとスーパーありがとうボタンを返すことができます)という認識をさせることができました。

まとめると、ありがとうボタンは8段階で出来上がります。
①テーマを与えられる
②テーマに合わせて思いつくものをスケッチする
③その中からモチーフを決める
④参考になるイメージを検索する
⑤下地を描く
⑥Illustratorでパスで起こす
⑦Photoshopでシェイプレイヤーとして持ってくる
⑧色塗り&サイズ調整をする

ボタンに押し心地をつける

しかし、ここで終わりではありません。
押した後のボタンのデザインが決まったらそれを元にして、今度は押す前のボタン(default)を作ります。
押す前のボタンはユーザーに期待感を持たせるためにシルエットだけ見せます。
イラストの細かい要素を捨てて形だけ残して、そこに押せる感を与えるため、90°下に内部シャドウを6px入れて立体感を表します。
次に押した瞬間のボタン(active)を作ります。
押す前のボタンとは逆に、90°上に内部シャドウを6px入れて、押されて凹んでいることを表現します。
そして、以下のような「default → active → after」ボタンになります。

最後に

いかがでしたか？
ミルチョチームに配属されてから今まで7ヶ月間作ってきたありがとうボタンは、
103万会員に合計3億回以上押されています。(2014年1月現在354,909,086回)
ユーザーがかわいい！押したい！という気持になって「ありがとう」を伝えられるよう、今までより良いモチーフとイラストを生み出していきたいと思います。

Frontrend in Fukuoka レポート

こんにちは、フロントエンドエンジニアの加藤（@ktknest）です。

1/25（土）、札幌に引き続き福岡にて、フロントディベロッパ/エンジニア向けの勉強会Frontrend in Fukuokaが開催されましたので、そちらのレポートをお届けします。

今回は、福岡で活動をされているWebコミュニティFukuoka Frontrend Frogsや、特定非営利活動法人 AIP、サイバーエージェント福岡オフィスの皆さんのご協力の元、関係者を含め200名近くと非常に多くの方々にご参加いただきました！

・Frontrend in Fukuoka 2014年1月25日（土）開催！
・当日のツイートまとめ

3トラック10セッション

今回はFrontrend初の試みとなる、以下の3トラック開催でお送りしました。

・エンジニアトラック
・デザイナートラック
・ハンズオン

基調講演、パネルディスカッションと合わせ、計10セッションと盛り沢山な回となりました。
それぞれ簡単にですが、セッションの様子を紹介していきます。

基調講演

レベルアップ：知っておきたいフロントエンド開発の今（斉藤祐也）

まずは基調講演として、斉藤より、今後のフロントエンドディベロッパにどういったスキルセットや考え方が求められるのかについて述べられました。Webの歴史はまだ20年と浅く、今は良いとされる方法でさえすぐに陳腐化してしまいます。そういった分野において、HTML/CSS/JSが抱える課題から、今後点を線につなげるための日々の取り組み方など、多岐に渡り紹介されました。

エンジニアトラック

Frontend Performance Tuning TIPS * n（佐藤歩）

佐藤のセッションでは、ユーザーにとって、よきフロントエンドであるためのチューニングTipsをふんだんに紹介。なぜそうすべきなのかという理由や具体例も挙げられ、すぐにでも活用できるものばかりで非常に参考になるセッションでした。

「HTML5でこんなことやりたいんですけど」というご相談を頂いたのでHTML5使わずにやってみた（株式会社アルキー下川北斗）

地元福岡で活躍されている株式会社アルキーの下川さんからは、クライアントワークにおいて、どうHTML5まわりの技術を、時にはそれを使わずにどう実現してするかなど、試行錯誤な実例を通してお話をいただきました。

Browser Computing Structure（泉水翔吾）

泉水からは、SPAのような複雑なアプリケーション実装が求められることが増えていく中、Computingに照準を当てて、高速化をどのようにしていくべきか、メモリ管理とどう向き合うかなどディープな領域について紹介していきました。

デザイナートラック

Efficient UI Development（石本光司）

石本のセッションは、変化の多いUIに対応するためのHTML/CSS設計方法や、システムとしての考え方、モジュール化の概念など、実際のプロジェクト経験にも触れた内容で、参加者の皆さんの関心を強く集めた内容でした。

UIとUXって何が違うんだろう（株式会社Fusic 山本光彦）＆ HTML5と最近のフロントエンド事情と勉強会と福岡の私（西村宗倫・卜部加奈子）

エンジニアトラックと同時間帯で、こちらも福岡勢によるセッションが繰り広げられました。山本さんのセッションではパッケージ考案の例を通して、UXが向上するためのUIの考え方について、西村さん卜部さんのセッションでは対談形式で、フロントエンドの様々な技術についてや地元のコミュニティについて多く取り上げた内容に。
このセッションでは入り口付近まで溢れるくらいの方が参加され、福岡のコミュニティの活発さが実感できた回でした。

フロントエンドの求めるデザイン（水野隼登）

水野からは、現状のWebデザイン事情を踏まえて、よりデザイナーとディベロッパーのギャップを埋めるべく、多数のツールやWebデザインの考え方、デザイナーも意識しておきたいパフォーマンスについても触れられました。

ハンズオン

怖くないGit for Frontend Engineers ~入門から導入ノウハウまで~（原一成）

今回複数トラックと同じく、初となるハンズオン形式のセッション。
原からは、慣れないと敬遠しがちなGitの概念・操作やGitHubの活用方法について、ブラウザベースのサービス（Code School - Try Git）を活用しつつ、実際のワークを通して学んでいきました。

Goal of Better CSS Architecture（谷拓樹）

CSSのプロパティでなく、セレクタを同設計すべきか、なぜ設計すべきかについて触れた谷のセッション。CSSが破綻”しづらい”設計にするためにはどうすればいいか、実際のWebサイトを題材にワークにより、その一歩を感じ取ってもらえたと思います。
Gitのハンズオンも同様に、15名の定員で距離感も近く、皆さん熱心に聞いてはワークを進めていっていました。

パネルディスカッション

各トラック終了後は、スピーカー陣によるパネルディスカッションを開催。
まずは自己紹介・キャリア、モチベーションの維持方法に続き、Webは今後どうなるか、となかなか答えの出づらい重要なテーマなど、それぞれの意見をぶつけ合い、共に考えたよい機会になったと思います。

最後に

懇親会（ビアバッシュ）とLTコンテンツにも多くの参加者が残られ、最後まで非常に活気のある勉強会となりました。

地元スタッフの皆さん曰く、福岡ではこの規模の勉強会はかつてなかったそうで、席が足りなくなるような嬉しい悲鳴も続き、このような場を共有できたことが非常に嬉しいです！

最後に、今回の福岡開催のきっかけとなった福岡オフィスの中島さんはじめ、地元スタッフの方々約20名、参加者の皆さんに厚く御礼を申し上げます。ありがとうございました！

※次回のFrontrendは4月頃に東京開催の予定です。詳細は未定ですので、是非FrontrendのサイトまたはTwitterをチェックしてもらえると幸いです。

アラサーアラフォーにとって居心地のよいデザインとは？

みなさま、こんにちは！
2013年に新卒入社したハヤサカと申します。
現在、大人のブカツbk2というSNSサービスのデザインを担当しています。

今回は担当しているサービスの中で、Amebaユーザーの30代～40代を意識しながら作っているUIデザインについて、スマホアプリを中心にご紹介させていただきたいと思います。

大人のブカツbk2とは

大人のブカツbk2は、"趣味でつながる"25歳以上限定のコミュニティサービスです。
「スマホ写真部」や「大人のラーメン部」、「なんか友達少ない部」など個性豊かな4000以上のブカツから自分にぴったりのブカツを見つけて、大人同士の落ち着いたコミュニケーションを楽しむことができます。
現在のメインユーザー層は30代から40代で、男女問わずご利用いただいております。
詳しくはこちら→http://bk-2.jp

大人のデザインルール

はじめに、サービスで規定しているデザインルールについてご紹介します。

1.落ち着いたトーンのカラー
30代～40代がサービスを長時間使うことを想定して、使用するカラーも目に優しい落ち着いたトーンでまとめました。男女問わず利用していただいているので、色も中性的なカラーを使用しています。

2.可愛くなりすぎないアイコン
カラー規定同様、男女問わず利用していただいているため、可愛いくなりすぎず、しかし堅苦しくならないデザインを採用しています。小さくても識別できるように、細かなパーツは使用しないようにしています。

大人のいいねボタン

次に、bk2で使用している「いいねボタン」についてご紹介します。

bk2に於いて、「いいねボタン」は会話と同じくらい重要な要素です。
・押してもらったユーザーのモチベーション向上
・アクティブなメンバーが顕著に分かるので盛り上がっている雰囲気がでる
などの理由があげられます。
さらに、コメントを記入するよりも気軽に気持ちを伝えることができるため、ユーザーには沢山ボタンを押して欲しいです。
そのためボタンを押す前の方が押した後よりも、押したくなるデザインである必要があります。

以上の理由で、現在bk2で使用されている「いいねボタン」は
①押す前は着色ありの立体ボタン→②触ると色が落ち、下に深くへこむ→③押した後は少し上に戻る、という３パターンの画像で出来ています。

さらに30代～40代のユーザーは10代～20代のユーザーと比べて分かりやすさが求められるため、親指のアイコンにテキストの表記を加えたところ、クリック率向上に効果がありました。

アクションボタンについては、弊社の画像系のサービスや掲示板系のサービスではまた違う扱い方をしているので、他のサービスの例も参考にしてみてください。

大人のUI設計

次に、このサービスのUI設計についてご紹介します。

まずはユーザーのアクションフローをご説明します。
①ブカツに入る
②ユーザー同士が出会う
③好きな趣味の話で盛り上がる
④毎日更新やお知らせをチェックする
⑤ ③～④を繰り返してモチベーションが高くなり、また新しいブカツを探しはじめる
→①へ戻る

この①～⑤のループに没頭してもらうために、30代～40代のユーザーでも迷わないシンプルなナビゲーションをつくりました。それが、ブカツを探すページとマイページです。

タブをふたつに絞り、自分に関わる情報とそれ以外をしっかりと分けることで、サービス内での動線がシンプルになります。
この構造にしたことで、社内でも定着率がトップレベルのサービスに成長することができました。

最後に

最後まで読んでいただきありがとうございます！

bk2は制作チームにもユーザーの皆さんにも恵まれ、日々進化しています。
わたしもbk2チームの一員として、ユーザーの皆さんにとってより良い時間を提供するために
日々精進して参ります。

今回ご紹介したのはbk2の世界観を構成する一部ですが、まだまだご紹介したいアイディアが沢山詰まっているサービスです。25歳以上の方、ぜひこの機会に覗いてみてくださいね。
そしてこれからもbk2をよろしくおねがいします！

ゲーム開発フレームワーク「Cocos2d-x」とMVC

こんにちは。
2012年度新卒入社、Ameba Native Game Studio の久保です。

今回はゲーム開発のフレームワーク Cocos2d-x を取り上げます。

まずは Cocos2d-x について簡単に紹介し、そして私たちのチームでどのように導入しているのか、特に自作ライブラリと設計モデルについて書きたいと思います。

1. Cocos2d-x

Cocos2d-x はゲームのクロスプラットフォーム開発を行うためのフレームワークで、 iPhone アプリや Android アプリを同一のソースからビルドすることができます。

スマホアプリのクロスプラットフォーム開発は他にも選択肢がありますが、 Cocos2d-x には次のような特徴があります。

オープンソース
MIT License
軽量なネイティブアプリの作成が可能
C++, JavaScript, Lua によるコーディング
高速なアニメーションを簡単に作成可能
パーティクルシステムを標準で使用可能
多くのライブラリやツールとの連携が可能

日本のネイティブアプリは Unity で開発するケースが多いようですが、 Cocos2d-x も徐々に普及してきています。
つい先日のネイティブアカデミーでは Cocos2d-x の講座も開かれ、今後は社内でも Cocos2d-x を使用するプロジェクトが増えていきそうです。

2. 社内ライブラリの開発

社内では Java を書く開発者が多く、私もゲーム部門に異動する前は Java で Web API の開発をしていました。

Java でコーディングをする場合、 GC や DI によって煩雑なインスタンスの管理はソースから極力排除されます。
また、Struts や Spring のようなフレームワークを用いれば、 MVC などの設計モデルに基づいた強い制約を受けるでしょう。

一方、 Cocos2d-x は設計について強い制約を与えるフレームワークではありません。
また C++ を使うのでメモリリークや不正なポインタアクセスに注意が必要です。
C++ でのゲーム開発が Native Studio にとって初めてで、かつ C++er が社内に少ないこともあるため、品質の高いコーディングを促す仕組みが必要です。

それと共に、今後 Cocos2d-x を使うプロジェクトが増えた際、有用な共通機能をライブラリ化して開発の効率化も図りたいと考えました。

そこで、社内で使用していくことを目的に Cocos2d-x のためのライブラリを作成しています。
以降では現在作成中のライブラリ「Coconut」について紹介します。

Coconut 本体は
https://github.com/sunfish-shogi/coconut
サンプルプログラムは
https://github.com/sunfish-shogi/coconut-sample
にあります。ぜひ実際に動かしてみてください。

3. MVC の導入

MVC は '70 年代から使われてきた設計モデルで、 Model, View, Controller の3種類のオブジェクトによって構成されます。

Model には UI に依存しないゲームの状態や処理を記述します。
View は Model の状態に基づいて描画を行います。
Controller はユーザからの入力やシーンをまたぐ処理を記述します。

Coconut では Cocos2d-x で MVC を用いるための機能を用意しています。
その使用方法を簡単に説明します。

Xcode で開発をする場合にはファイルテンプレートを用いて必要なクラスを簡単に作成することができます。
まず、次のように Xcode にファイルテンプレートを追加します。

# ディレクトリがない場合は作成
#mkdir -p "~/Library/Developer/Xcode/Templates/File Templates/"
cp -r "coconut/File Templates/coconut" "~/Library/Developer/Xcode/Templates/File Templates/"

そうすると、Xcode で [Project Navigator を右クリック] - [New File...] から coconut/coconut MVC というテンプレートが利用できるようになります。

このテンプレートを使うと

～Model.h/.cpp
～View.h/.cpp
～Controller.h/.cpp
～Module.h

の計7個のファイルが生成されます。

Model, View, Controller に加えて Module というのがありますが、ここにはクラスの依存関係が書かれています。
(本当は依存関係をソースから排除したいところですがC++では困難なので。)

サンプルプログラムでは更に GameManager というクラスを作り、ゲーム全体の設定やシーン遷移をここに集約しています。
そうするとクラスの構成はおよそ次の図のようになります。

Cocos2d-x では継承を多用しますが、 Coconut では継承という強い結びつきを使わないのが特徴です。
また、Cocos2d-x を直接使用する必要があるのは View だけで、Model は Cocos2d-x から切り離されます。

サンプルプログラムではこれを用いて15パズルを実装してみました。

簡単に15パズルの処理の流れを説明します。
(全ソースはリポジトリを参照してください。)

トップ画面で「15 Puzzle」ボタンが押されると GameManager の SelectSlidePuzzle イベントが発行されます。
そうすると、以下のコードが実行されてゲーム画面に遷移します。

// GameManager.cpp
onSelectSlidePuzzle([]() {
	MvcBuilder().setMainModule<SlidePuzzleModule>().prepare(SceneChangers::FlipU(0.5f));
});

シーンの遷移が完了すると Model の reset 関数が呼ばれ、タイルの初期化とシャッフルを開始します。
タイルが正しい順番に初期化されると Reset イベントが通知されます。

// SlidePuzzleModel.cpp
emitReset();

これを受け取った View が Sprite を作成してタイルを描画します。
その後、Model では 0.15 秒おきにランダムにタイルの移動が行われます。

// SlidePuzzleModel.cpp
_scheduleShuffle = _scheduleManager->scheduleForever(TIME_SLIDE, 1.0f, [this]() {
	shuffleProc();
});

タイルが移動するごとに Slide イベントが発行され、 View では Sprite に対して座標移動のアクションが実行されます。
シャッフルが終わるとユーザのタッチ操作に従い、 Controller から Model の slide 関数が呼ばれます。

// SlidePuzzleController.cpp
_view->onTouch([this](const Position& pos) {
	_model->slide(pos);
});

パズルが完成すると Model から Complete イベントが発行されて、 View で適当なアニメーションが実行されます。

// SlidePuzzleModel.cpp
void SlidePuzzleModel::check() {
	if (_status == SlidePuzzleStatus::PLAY && isCompleted()) {
		_status = SlidePuzzleStatus::COMPLETE;
		_scheduleManager->scheduleOnce(TIME_SLIDE, [this]() {
			emitComplete();
		});
	}
}

オブジェクト間のやりとりを図にすると次のようになります。

このように Model は UI に依存することなく、イベントの通知という弱い結びつきで描画の指示を出しています。

MVC のような UI との分離を行わないのであれば、次のように Sprite を継承して情報を付加させることでも実現できるでしょう。

class TileSprite : public cocos2d::Sprite {
private:
	Position correctPos; // 正しい位置
		～
};

class PuzzleLayer : public cocos2d::Layer {
private:
	Array2d<TileSprite*> tiles;
		～
};

今回のサンプル程度のゲームならそのほうが簡単かもしれません。
しかし、このようなコードは再利用性を低くしてしまい、そして簡単にソースコードの見通しを悪くし得るものです。

どういう設計が良いかはゲームにもよると思いますが、今回はひとつの試みとして MVC にできるだけ忠実な設計を取り入れました。

4. その他の機能

Cocos2d-x を使っていると、 autorelease や若干不思議なマクロなど Objective-C っぽい書き方がしばしば登場します。

これは、Cocos2d-x の元になった Cocos2d から来ているようです。
しかし、できれば C++ のラムダ式やスマートポインタを使いたいところです。
そこで Coconut ではスケジューラやいくつかのUIウィジェットなどをラッピングしたり作りなおしたりしています。
例えば先述の15パズルでも使用していた ScheduleManager を使えば指定時間経過をラムダ式でハンドリングできます。

_scheduleManager->scheduleOnce(0.5f, []() {
	/* 0.5秒後に実行する処理 */
});

その他、スワイプ、ピンチイン/アウトの検出やいくつかの Action など Cocos2d-x で用意されていない機能も作っています。
(自分が欲しくなったものを作っているだけなので、いろいろ足りないですが...)

サンプルプログラムには一部の機能を使った例が入っています。

5. おわりに

いっちょまえに自作ライブラリの紹介を書きましたが、ゲーム開発のプロジェクトは今回が初めてで、このライブラリがどこまで活用できるか正直なところよくわかりません。

これからもっと勉強をして、そして色々なアプローチを試して良い物を残していきたいと思っています。

以上、最後まで読んでいただきありがとうございました。

久保亮介
Twitter: @RyosukeKubo
GitHub: https://github.com/sunfish-shogi

非エンジニアが知ってると得するUnityの知識

みなさん、こんにちは。
アメーバ事業本部の中川(@neko_manma1)と申します。

ドラマチック弾丸アクションRPG「ウチの姫さまがいちばんカワイイ」
(以下、ウチ姫)にてUIの制作、キャラ/モンスターデザイン、モデリング／アニメーション、
背景ステージ制作等を担当しております。

ウチ姫は『Unity』というゲームエンジンを使って開発されました。
エンジニア向けのUnity記事はあちらこちらでよく目にするかと思いますので、
今回は非エンジニアの目線で「ここは押さえておきたいUnityの知識」を書かせて頂きます。

Unity開発の強み

Unityについて、まず簡単な説明をします。
Unityはスマートフォンネイティブゲームのみならず、WindowsPCやwebブラウザ
向けのゲーム開発ができるゲームエンジンです。
(その他のゲームエンジンとして、cocos2d-xやunreal等が挙げられます）

Unityの良さを軽く3点取り上げます。

・1つのプログラムソースで複数プラットフォーム（iOS,Android,PC等）書き出しが可能
・3D表現に強く、3Dデザインリソースの扱いが容易に行える
・アセットストアの存在が超強力（開発効率を高める優秀なアセットが入手できる）

この他にも魅力的な機能が、ここには書き尽くせないくらいたくさんあります。

Unityはデザイナー（プランナーも）が習得するのが容易なゲームエンジンです。
エンジニア抜きでモック開発を進めていく事もできます。

ゲームの面白さをとことん突き詰めていき、まとまった時点でそこからエンジニアと
合流して本開発に移行する。
Unityなら、そんな夢のような事がとても簡単に行えるのです。
ウチ姫も、開発初期段階の頃は数えきれない程多くの試行錯誤がありました。

非エンジニアが知るべきUnityの知識

ウチ姫を開発していく上で感じた、非エンジニアが知ってると得するUnityの知識は以下の通りになります

3Dゲームの基本
・FBX（3Dデータ）のInspector（プロパティ）設定を正しく理解しましょう
　　→ScaleFactorを使ってサイズ調整ができます
　　→Animationのloop/once設定でアニメーションの再生回数を制御できます
・3DCGツール
　　→ウチ姫では『Blender』を使って開発を行っています。オープンソースの
　　　フリーソフトですがその機能は商用ソフトに全くもって引けを取りません。
　　→Unityでの3Dモデル制作は一般的にMayaが代表的です。MayaLTという廉価版の
　　　ツールもありオススメ度はかなり高めです。
・最適化周り
　　→アニメーションクリップやモデルメッシュの共通化で容量節約。作業管理も容易に。
　　→SkinnedMeshRendererとSkinnedMeshRendererを使い分けてDynamicBatchingが
　　　使えそうな所は積極的に使い、drawcall数を低く抑えるよう心掛けましょう。
　　　（極端に言うとdrawcall数が少ないゲームはコマ落ちする事がなく快適に動きます）

2Dゲームの基本
ウチ姫内で2Dアニメーション系はノータッチなのですが、説明を入れておきます。

Unityの2D分野には『Uni2D』や『SmoothMoves』といった超優秀なアセット
ツールが存在します。
おすすめは『Uni2D』。多機能過ぎて鼻血が出てしまうくらいにすごいアセットです。
　最近になって2Dゲームに特化した標準機能がUnityに組み込まれたので、それで
頑張って制作するのもアリです。

cocos2d-xによる2Dのネイティブゲーム開発が盛んになってきていますが、Unityでも
何ら問題なくサクサク2Dゲーム開発は可能なのです。

UIの基本
・NGUIの基本操作を覚えましょう
　　→UnityでのUI制作はアセットを使うのが一般的です。
　　　昔はEzGUIというアセットが主流でしたが今ではNGUIというアセットが主流です。
　　　iGUIやDF-GUIというモノも出てます。とりあえずNGUIでなんら問題ありません。

　　→UI素材のアトラス化は基本です。四隅の解像度は保持したままスプライトを引き延ばす
　　　9sliceと呼ばれる手法を積極的に行いましょう。

　　→PSD2NGUIやFastGUIといったアセットがとても便利です。psdをそのままNGUIに
　　　置き換えますので工数節約になります。（FastGUIは更新が去年8月から止まって
　　　いるのでPSD2NGUIをおすすめします）

・iTween(HOTWeen)を扱えるようにして演出に凝りましょう
　　→iTween(HOTWeen)とは、動きをだんだんゆっくりにしたり早くしたり、揺らしたり
　　　跳ねさせたりするアセットの事です。これらは動きの演出面で大いに役立ちます。
　　　コード記述は1行程度のものが多いので非エンジニアでも簡単に書けます。

最後に

以上、最後に宣伝となりますが、『ウチの姫さまがいちばんカワイイ』は
より楽しくより魅力的なゲームとなるよう改修/機能開発が急ピッチで進んでおります。
これからも『ウチの姫さまがいちばんカワイイ』を、どうぞよろしくお願いします！
→公式ページ
→App Store

新イベント「天下統一戦」とは？

スケジュールの決定と共有方法

前半の主な作業（11月後半～12月中旬）

作業中盤（12月下旬～1月）

作業後半（2月～3月）

開発を通して意識していたこと

最後に

ガールフレンド（仮）とは

Adobe Photoshop スマートオブジェクトを使ったアイコン類の作成

モジュール化と簡易HTMLを使ったページデザインの管理

最後に

JsRenderとは？

JsRenderのよいところ

基本的な使い方

JsRenderのタグの説明

・{{:foo}}, {{>foo}}

・{{for someArray}}/* ループしたい内容 */{{/for}}

・{{if someCondition}} ~ {{else}} ~ {{/if}}

知っていると捗るTIPS

テンプレート内で別のテンプレートを呼び出す

ループの中で、コンテキストの親データにアクセスする

1. ~rootを利用する

2. #parent.dataを利用する

3. ループの中から参照できる値を設定する。

テンプレートに、メインのデータ以外に別のデータを渡す

出力する値をカスタマイズする

オブジェクトをループする

テンプレートをDOM形式で出力する

最後に

色を色で見ないで

シンプルかつ複雑であれ

デザインだけじゃない

『意識』のはなし

主役は特別

ま・と・め

さいごに

node-webkitとは

node-webkit本体のインストール

アプリケーションの記述

アプリケーションのデプロイ

nodeモジュールによる拡張性

シェルを実行するサンプルアプリケーション

SPAの練習に

node-webkitの今後

最後に

きいてよ！ミルチョ」とは…？

ミルチョの流れ

ありがとうボタンの作り方

ボタンに押し心地をつける

最後に

3トラック10セッション

基調講演

レベルアップ：知っておきたいフロントエンド開発の今（斉藤 祐也）

エンジニアトラック

Frontend Performance Tuning TIPS * n（佐藤 歩）

「HTML5でこんなことやりたいんですけど」というご相談を頂いたのでHTML5使わずにやってみた（株式会社アルキー 下川 北斗）

Browser Computing Structure（泉水 翔吾）

デザイナートラック

Efficient UI Development（石本 光司）

UIとUXって何が違うんだろう（株式会社Fusic 山本 光彦）＆ HTML5と最近のフロントエンド事情と勉強会と福岡の私（西村 宗倫・卜部 加奈子）

フロントエンドの求めるデザイン（水野 隼登）

ハンズオン

怖くないGit for Frontend Engineers ~入門から導入ノウハウまで~（原 一成）

Goal of Better CSS Architecture（谷 拓樹）

パネルディスカッション

最後に

大人のブカツbk2とは

大人のデザインルール

大人のいいねボタン

大人のUI設計

最後に

1. Cocos2d-x

2. 社内ライブラリの開発

3. MVC の導入

4. その他の機能

5. おわりに

Unity開発の強み

非エンジニアが知るべきUnityの知識

最後に

・`{{:foo}}`, `{{>foo}}`

・`{{for someArray}}/* ループしたい内容 */{{/for}}`

・`{{if someCondition}} ~ {{else}} ~ {{/if}}`

1. `~root`を利用する

2. `#parent.data`を利用する

レベルアップ：知っておきたいフロントエンド開発の今（斉藤祐也）

Frontend Performance Tuning TIPS * n（佐藤歩）

「HTML5でこんなことやりたいんですけど」というご相談を頂いたのでHTML5使わずにやってみた（株式会社アルキー下川北斗）

Browser Computing Structure（泉水翔吾）

Efficient UI Development（石本光司）

UIとUXって何が違うんだろう（株式会社Fusic 山本光彦）＆ HTML5と最近のフロントエンド事情と勉強会と福岡の私（西村宗倫・卜部加奈子）

フロントエンドの求めるデザイン（水野隼登）

怖くないGit for Frontend Engineers ~入門から導入ノウハウまで~（原一成）

Goal of Better CSS Architecture（谷拓樹）