昨年末リリースした「Rimpaと若冲」がクライアント様のご好意でグッドデザイン賞に挑戦、昨日無事第一次審査を通過したとの知らせが入りました！次はノミネートデザイン２３００点が一堂に集められた東京ビッグサイトでの二次審査だそうです。
今となっては製作日数２週間の突貫に近い状態だったことだとか悔やまれたり、一次はわりと広き門なんだろうな、とか考えるものの、utweb中にやらしくGマークを飾るとかステキじゃねなんて思うと夢がどんどん膨らみます。
コミュニケーションプラス様ご依頼で
ひぐらしCMジェネレーターの制作を行いました！
企画・デザインをコミュニケーションプラス様から頂いた時点で、
という条件の中で、以下の点に工夫を凝らしました。
先ずは制作する対象となる作品が既に一定のファンを抱えていること。
作品そのものをとても大切に思っているファンを既に沢山抱えているという状況での広報作品を作り上げることは、いろんな意味で勉強になりました。
コンシューマー向けのゲーム作品であること。
ゲームというインタラクティブ性の高い商品の広告である以上、興味を持ったユーザーがまず最初に触れる部分だけに、いくら広告といえどここにバグや完成度の低さを見せるわけにはいかないので、極力実験的なことや難しい事を廃して面白く仕上げるかに腐心しました。
アクセスに対してサーバーの負荷を下げること。
いくら面白くても、サーバーに負荷がかかって落ちてしまっては意味がないので、与えられたサーバーのスペックの範囲内でジェネレートできる最短の方法をとりました。
ユーザー様から見て面白いと思うことと、
クライアント様から見て面白いと思うこと、
必ずしも一致しない場合も多いのですが、かといって正反対というわけでもなく、
ユーザーが全てをコントロールできたら面白くなるというわけでもなく、
クライアント側で締め付けたら面白いものができないわけでもなく、
僕らはそのギリギリのラインで、誰もが遊べるような楽しい何かを作り続けているわけですが、
今案件も先ずは触ってみて、楽しんで頂ければ何よりです。
前回の
●透過画像について
でpng24って書いちゃってました。正しくはpng32。
間違いついでに気になってた疑問。
png32よりも同じく透明書き出しのできるpng8の方がいいんじゃないの？ってことなんですが、はっきりさせるために実験。
▼元画像ファイルサイズ
・png8... 30.4kb
・png32...319kb
と歴然の差のpng兄弟。flash上でどちらとも写真画質（画質80）に圧縮してみましたところ・・・
▼パブリッシュ後のswfファイルサイズ
・png8... 20kb（20834ｂ）
・png32...20kb（20553ｂ）
わずかにpng32が軽い！
しかしこの後サイズの小さなpng両者で試すとpng8が200ｂほど軽かった。何なの？大きさなの？
この辺はケースバイなのかもしれないけれど、レギュレーションバナーでb単位のチマチマ詰めが必要じゃないなら、減色のないジャギーもないpng32の方が私は好きだ！
※ちなみにこの実験では両者に目立ったＣＰＵ負荷の差は見られず。
お絵かきができる！にじいろジーン番組ホームページが開設されました！
最初にktv様から企画を頂いて、ポイントは
でありましたので、いずれも当制作所得意中の得意分野としてこだわりのある制作をさせていただけました。
デザインに関しては、最初の段階から表情豊かな楽しいタレントさんが揃っていますので、ユーザーにとっつきやすい印象を与えることに苦労はなかったのですが、こだわりポイントとしては操作系に関するところになるでしょうか。
ユーザーが触れる部分はできるかぎり現実に即したものとするために、例えば「筆の太さを選ぶ」のではなく「太い筆を選ぶ」「細い筆を選ぶ」ようにひとつひとつ言葉に置き換えてわかりやすいほうをデザインとして反映していきました。
また、「このサイトは、画面上で直接お絵かきができるんですよ」って事は言葉で説明しないといけない部分で、実際にユーザーがこのサイトで何が出来るかを理解してもらうためには最低でも一回はキャンバス上でマウスをクリックしてヌリヌリしてもらう必要があります。
キャンバスをただ置いただけでは「なんだかえらい余白の多いサイトだな」とだけ思われて何もしてもらえずに別のページに移動される可能性が高いので、出来る限り見た目で「このサイトは絵が描ける」ということをわかってもらうために一番最初はぬり絵ふうの素材を置くことにしました。
このあたりは「こくばん.in」さんのようにただ黒板とチョークを置いただけでユーザーが一発で何が出来るサイトなのか理解するという素晴らしいアイデアをお手本にさせて頂きました。
プログラムに関しては特に目新しいことはしていません。Flashの描画機能を使えば結構高度なことは出来るのですが、では高機能なWEBドローツールを作れば案件は成功なのか、ということではないのでもの凄く真っ当にに「ユーザーが思った通りの動きをする」ことにのみ注力しました。
例えば描いた絵を番組に送るときの確認画面に、実際に描いた絵がサムネールで見えた方がいいのでそこに再描画させる処理など、見えないところでけっこう頑張っています。あとはページ下部でタレントさんがいかに遊んでる風に動かせるか、とか。
裏方の部分では、番組制作ってかなりな忙しさだと聞いていますので、ユーザーから投稿された絵を小難しい管理画面で処理してもらうよりは、ざっくりとjpeg画像としてダウンロードできて、ファイル操作で選びながらプリントアウトなども出来るように、Flashで描画された画像をファイルとして送信保存できるようにするなど、小難しい操作をさせないための小難しい技術、ってやつをふんだんに取り入れています。
制作全般において、こちらの自己満足で終わることがないよう、出来るだけ沢山の方に楽しんでもらいたいと願いを込めて作ったことが自己満足な、楽しいサイトに仕上がりました！
サイト制作者側としても、番組への素敵な投稿を願っています！
毎回フンフン言いながら作ったものがいざパブリッシュしてみるとCPUを圧迫しまくっていて、泣く泣く削る、なんてのが私の場合よくあるのでメモメモ。羽のように軽いflashをさらさらりと作るのが目標ですよ。
今回は間接アニメーション。ついつい楽しくて動きを足してしまう。
●全身写真1枚を間接ごとにマスク切り分け
元写真は一枚だからファイルサイズは小さいだろうと思って油断してたらすごい負荷。結果×。
●透過画像について
透過にする場合、gifよりもpng24png32の方がflashが軽く圧縮してくれる。しかもpngの方がキレイだし。
●ジャギーと圧縮との付き合い方
間接ごとに切り分けた画像それぞれにスムージングなしで圧縮すると、許せないくらいのジャギーが発生し見栄えが悪くなるが、全身アニメーションをpng連番書き出しをし、そのpngに圧縮をかけても、全体にほどよいノイズが乗るような感じでまだ許せる。
●連番書き出しのお得な点
一枚一枚透過の部分を切り捨てて再配置すると体の軸がズレるため、タイムラインでアニメーション制御する場合では絶対やりたくないくらいの奇妙なブレやせわしなさが演出できる。コマ落ちアニメーションには最適かも。
今回通してわかったのは、私でもややこしくて考えたくないことはflashも嫌なんだなと。両手・両足・胴・頭それぞれマスクかけて、これを反転させたやつをこのタイミングでアニメーション、とかそらCPUもウーン言いますわ。
追記2008/07/10-------------------------------
●透過画像について
png24って書いちゃってました。正しくは透過png32。
