【ナナのかぼちゃパン】は絵本タッチ

iBooks Authorが自分に適した制作ツールなのかどうか、実際に作品を作りながら試してみようというわけで、短編マルチタッチコミック【ナナのかぼちゃパン】の制作開始です。

【ナナのかぼちゃパン】はちょっとほのぼのとした内容なので、あまり3DCGっぽいリアルな画質は似合いません。というわけで上の画像のように絵本タッチにしました。

Poserでレンダリングした画像をベースに、Photoshop上でIntuosを使って手描き風味を加えつつポストワークして仕上げたものです。

ちょっと絵本タッチになりすぎたかも...もうちょっとマンガっぽくしたいところです。もっとIntuosで輪郭線をしっかり描けばいいんでしょうけど、でもそうしたくない気分もあって、そのあたりはもう少し試行錯誤をしてベストなバランスをみつけなくては。

マンガの画風やタッチって、作者によってぜんぜん変わらないタイプと、どんどん変わっていくタイプがありますよね。

読者としては、変わらないタイプの方がストーリーを追いやすいとか、安定感・安心感があるという利点がありますが、その反面毎回代わり映えしないのでちょっと厭きがくるという部分もあるかもしれません。

変わるタイプとしては、久しぶりに連載マンガを読んだら「同じキャラかー!?」っていうぐらい変わっちゃって驚かされるときもたまにあります。自分の好みの方向に変化してる場合は良いんですが、反対の場合はショックですよね。

巨匠・手塚治虫が「自分の絵は、ストーリーを表現するための記号のようなもの」というようなことを書いています。その「マンガ絵＝記号論」を読んだ時、それぞれのキャラを記号としてとらえているのであれば、その都度あまり悩まずに早く描くことができるのだろうな、と思ったことを憶えています。

たしかに手塚治虫の画風は、初期から後期にいたるまで子供向け・大人向け等の多少の描き方の差異があっても、全体的には画風があまり変化しなかったイメージです。

ご自身の絵を記号と捉えていたとしても、何と魅力的な記号であったことか。

先日、【バクマン。】の最新刊（18巻）を読みました。

小畑健は、【バクマン。】というマンガの内容上、何人ものマンガ家の作品を描き分けなければならないわけで、いろいろ工夫を凝らしていますね。特に最近は表情がすごい！「ちょっとやりすぎじゃないの!?」っていうくらい表情のデフォルメがすごい！

マンガだから誇張！という意識が強いように感じます。それから小さなコマの中でもパースをかなり効かせてますよね。

そういえば【ヒカルの碁】を連載してるときに、【月下の棋士】の能條純一の影響を受けている時期があったように思います。能條タッチの影響が素直に画に表れているところにむしろ好感がもてましたけど。

でも最近、サイコーやシュージン達キャラの顎を異様に尖らせているのはなぜでしょう？あまり尖ってないほうが良いと思うんですが...

今日は【ナナのかぼちゃパン】の内容に合わせて画のタッチをちょっと変えたということから、思いつくままに書いてしまいました。

自分はとてもマンガ絵を記号としては捉えられないので、その都度悩みながら描くしかありません。

そのあたりは、描くという行為の根幹に係わっているような気がします。

マルチタッチコミック

Appleでは、iBooks Authorで作成した電子ブックを「マルチタッチブック」というんですね。iBooks Authorの使い方をAppleのサイトで調べていたら、そう呼んでいました。

ということは、電子コミックはマルチタッチコミックということですよね。いいじゃないすか、マルチタッチコミック！

今までマルチメディアコミックという言い方をときどきしてたんですが、いまいちピンとこないし、ちょっと古臭い感じもします。これからは、電子書籍の中のマンガという意味では「電子コミック」、インタラクティブコミックという意味では「マルチタッチコミック」というように使い分けようと思います。

さて、前回のブログで、「ちょっとした短編を作りたくなってきた。でも懸念材料あり。」と書きました。

やっぱり実際にマルチタッチコミックを作ってみないことには、自分にとって必要なツールなのかどうかは分からないので、短編マンガを作りながら試してみることにしました。

それから「懸念材料あり」というのは、[ページが表示される] → [ウィジェットをタッチ] → [アニメや音声開始] → [ウィジェットを閉じる] → [フリックで次のページに進む] という一連の流れが面倒くさくないだろうか、ということです。

初めはこの操作が電子コミックらしくて良いと思ったんですが、はたして楽しい操作なのか面倒くさいのか良く分かりません。

そのあたりは作りながら動作チェックする過程で分かるでしょうけど。

あとウィジェットで確認したのは、パラパラアニメとサウンド再生だけですからね、実際に作り始めたら『こういう場合はどうすんだ？』とか『う〜む、困った』という場面が次々と出てきそうですが、とにかく作ってみることにしました。

ところで何を作るか？

Xcodeで開発中のiPad版電子コミック【Wings ウイングス】の一部を作ってみようか、それとも...

同じものじゃつまんないし...というわけで、【Wings ウイングス】のほうはXcodeにまかせて、iBooks Author用に【ナナのかぼちゃパン】という超短編マルチタッチコミックを作ることにしました。

上の画像は、鉛筆画をPhotoshopで加工したものです。

iBooks Author向きの絵本ぽい作品にするなら、こういうタッチでも良いかと思うんですけど、いつもの3DCGタッチにするかまだ決めてません。

上のようなタッチでいくなら、最近ぜんぜん使ってないintuosの出番かも。

ぜんぜん使ってないということは、使いこなせてないというわけだから...どうしようか。

もしiBooks Authorもうまくいかず、intuosも使いこなせないというダブルパンチになるとショックはでかいかも。

いや、『iBooks Authorでマルチタッチコミック完成！』しかも『intuosもばっちり！』というように、ポジティブにいきましょう！

続々・iBooks Authorを試す

iBooks Authorが良い感じなので、引き続きいじってます。

iBooks Authorを試し始めて最初のうちは、『超簡単と言われている割にはどうも...』という感じでしたが、ウィジェットがけっこうサクッとできたあたりから『いいねいいね、いい感じ！』に変わってきました。

静止画ベースのマンガを描く人も、私のようにアニメや音声やインタラクティブな仕掛けなどに凝りたい人も、それぞれのやり方で電子コミックを作成できるというところに可能性を感じます。

ここのところiBooks Authorをいじったり調べたりしているうちに、iPadを横向き・縦向きにした時のマンガの見せ方について自分なりにある程度納得できるようになりました。

iBooks Authorで作るコンテンツは、基本的に横向きで読むようにデザインされているんですね。そして横向き時の画面が見開きではなく、1ページになるようです。まぁ真ん中でくぎって見開きにすることもできるんでしょうけど。

縦向きの場合は、どちらかというと補足的な役割としてとらえた方が良さそうです。たとえば写真、文字、映像、音声などでデザインされた電子ブックは横画面でじっくり読み、縦画面にしたときは写真などをサムネイルで小さく表示しておき、文字だけでさーっと追えるようにしておくという見せ方です。

横向きが基本ということで、横向き固定にすることもできます。（書類インスペクタで[縦向きを無効にする]にチェックを入れる）

でも横向き固定は、せっかくのタブレットの魅力を損ねてしまうので、ぜったい横向きで見せたいという何らかの意図がないかぎり、どうかなと思います。

さてそこで私が考えたアイデアは、上の画像のように縦向き時は画コンテやネームを表示するというものです。

もともと自分は、完成作品だけじゃなく構想時のアイデアを書いたものや、画コンテや裏話など制作過程にも興味があるので、自分の作品ではそれらを一緒に観て貰いたいという気持ちがあります。

なので縦向き時はネームや画コンテというわけです。

iBooks Authorでは、表紙をめくると最初に表示される、イントロメディアというページがあります。ここにインパクトのある画像や動画を表示して、読者を作品に引き込もうという演出ページです。

ここを利用して、縦向き時はネーム等が見れるということを示しておいてもいいですね。iPadを縦方向にしたらいきなりラフな鉛筆画が表示されて「なんじゃ、こりゃ！」と面食らってもいけないので。

というわけで縦向き時の問題も自分なりに納得しつつあります。

あと音声やサウンドについても試してみました。

iBooks Authorでサウンドをどのように扱うのか、あまり情報が見つからなかったので実際に動作チェックしました。

.wavと.mp3と.m4aの3つのサウンドファイルを作って、それぞれボタンを押したらサウンドを再生するようにして、ウィジェットに固めたものです。

するとウィジェット・オブジェクトに上記ウィジェットをドラッグ＆ドロップしようとすると、その時点ではじかれてしまいました。

「HTML Dashcodeファイル"sound.wdgt"は追加されませんでした。このファイルには対応してないフォーマットのメディアファイルが含まれています。」と表示されて、ウィジェットを配置することもできませんでした。

なので、.wavを削除し、次に.mp3を削除という具合に一つずつ試していくと、最終的に.m4aだけになったときにやっとウィジェット・オブジェクトに配置することができました。

サウンドもちゃんと再生されたので、.m4aファイルで音は作れば良いんですね。

ちなみに.m4aファイルはiTunesで.wavや.mp3から変換することができます。

3回にわたってiBooks Authorについて試用感を書いてきましたが、だんだんちょっとした短編でも作ってみたくなってきました。

いま私の頭の中にちょっとした懸念材料があります。

そのあたりについてはまた次回。

続・iBooks Authorを試す

前回は、初めてiBooks Authorを使ってみて、その使用感を書きました。

自分が作りたい電子コミックは、iBooks Authorのテンプレートをそのまま利用して出来るものではないので、テンプレートをカスタマイズしなくてはなりません。

カスタマイズしようとすると、やはりその仕組みをある程度知らないとうまくいかないので、ちょっと面倒くさいなという感じでした。なにしろiBooks Authorは超簡単というのが頭にあって、すぐにでも電子コミック制作に取り掛かれるかもという期待があったので。

簡単なツールというのは得てしてそんなもんですよね。提案されたとおりに使う分には易しいけど、自分好みに改造しようとするや否やたちまち複雑になるもんです。

さて今回は、iBooks Authorでアニメーションを試してみました。

私が描きたい電子コミックにおいて、アニメーションは重要な表現要素だと考えています。

音声は当然使いたいわけですが、静止画で音声が聴こえるというのは、どうも臨場感がなくて自分的にはNGです。

ストーリーの流れの中でインタラクティブな仕掛けを施したい場合、そこから急に動きのあるシーンに変わっていくのも不自然な気がします。つまりこのマンガではキャラ達が動くのは当たり前、ということにマンガの始めからしておきたいわけです。

もちろん毎秒24コマというフルアニメである必要はないし、そんなことしたらヘビーになっちゃいますしね。

電子コミックに最適なアニメ表現は、いつも描きながら考えています。

話がそれましたが、iBooks Authorでアニメーションを表示するには、HTMLウィジェットを読み込むというやり方で可能です。

以下の手順で試してみました。


　1. HTML文書にJavaScriptでパラパラアニメのコードを書く → Safariで動作チェック

　2. Info.plistファイルを作成（アプリの情報をXML文書にまとめたもの）

　3. 上記HTMLファイルとInfo.plist、画像ファイルを同じフォルダにまとめ、フォルダ名に「.wdgt」という拡張子をつける → フォルダがDashboardウィジェットに変わる

　4. iBooks Authorで作成中のコンテンツを開き（前回練習用に作ったもの）、アニメーションを表示するページを選ぶ

　5. ツールバーのウィジェットボタンをクリックし、HTMLを選択 → ページ内にウィジェットオブジェクトが配置される

　6. 3のDashboardウィジェットを5のウィジェットオブジェクトにドラッグ＆ドロップする

　7. iPadをMacに接続し、動作チェックする


動きました。キビキビとした動きでアニメしてます。上の画像です。

上の画像は、ブログ用に４つの画を合成したものですが、この画と同じようにバク宙アニメがループで動いてます。

ページが表示されるといきなりアニメをするわけではなく、画面をタップするとウィジェット画面になり、アニメーションを開始します。

なので、まずページには静止画のマンガを表示しておいて、アニメを見たければタップすればいいわけです。静止画だけでどんどんページをめくっていっても良いわけだし。

電子コミックらしくて良いんじゃないでしょうか。

まだ課題はありそうですが、もっと進めてみたくなりました。

うん、良い感じ！

iBooks Authorを試す

前回の続きです。私の中で期待がどんどん膨らんでいるiBooks Authorを試してみました。

速攻でApp Storeに行き、無料でダウンロード。

いいですねぇ、無料。お試し版とかじゃなく正式版なのに無料。でもAppleは超儲かってるしね。

さっそくiBooks Authorを起動。

シンプルなユーザーインターフェースが、個人レベルでの電子出版時代を予感させてくれます。でもその代わり玉石混交のコンテンツの中から必要なものを選択する眼が求められる時代になるんでしょうね。

あっ、その前にテンプレートを選ぶんでした。起動すると、まずテンプレートを選ぶ画面が表示されました。

6種類のテンプレートの中から、自分の作りたいコンテンツに合ったデザインを選ぶわけですね。

どのテンプレートが電子コミックに適しているのか分からないので、とりあえず「基本」というのを選択しました。

以前iBooks Authorの紹介記事で、「驚くほど簡単に電子ブック作成可能！」というように書かれていたので、ひとまず自由にいじってみて自分のイメージするレイアウトや表示ができるかトライ。

電子コミックには不必要と思えるテキストなどのオブジェクトを削除したり、プレースホルダ（テンプレートにあらかじめ配置されている写真）の画像を、iPadアプリとして制作中の電子コミック【Wings ウイングス】の画像に差し替えてみたりしてみました。

一見簡単そうなんですが、けっこう適切な位置にベストサイズで表示しようとすると、なかなか思ったとおりにはいかなくて無理やり配置したのが上の画像です。

力技で配置してしまったけどこれで問題ないのだろうか？という疑問が残るので、やっぱりある程度仕組みを勉強しないとダメですね。

それでも何とかiPad横向き表示は大丈夫そう。フリックすると次ページに横スライドしてくれるし、前ページにも戻れるのでとりあえず良しとして、問題はiPad縦向き表示。

縦にすると画像がサムネイル表示になったり、消えてしまったりします。このあたりは、ちょっと調べて調節すれば問題ないと思いますが、縦方向にページがスクロールするのは固定の仕様？

縦方向にスクロールさせながら読み進めていくのは、マンガ向きではありませんよね。

『でもこの前ダウンロードしたビートルズのイエローサブマリンは、縦向きにしても横にページをめくれたよな...』というわけで、イエローサブマリンのようなスタイルのテンプレートがあるのか、それとも自分でカスタマイズするのか、という辺りを現在調べているところです。

さて、そんなわけで一見簡単そうなiBooks Authorをいじってみた感想ですが、『よしっ、これだ！期待どおり！』というわけには残念ながらいきませんでした。

たぶん、用意されたテンプレートに文字を流し込んで、画像を差し替えるだけでピッタリのコンテンツであれば、『素晴らしい！これだよ、これ！』ということになったと思います。

電子コミックの場合も、白紙に近いテンプレートにページをポンッポンッポンッと置いていけばたぶんOKと思っていましたが、なかなかそうはいきませんでした。特に縦方向のスクロールがちょっと...ね。

とはいえ、期待はまだ持続中。

それからJavaScriptで書いたウィジェット（小さなアプリケーション）の取り込みをまだ試してません。

引き続き、そのあたりをいじってみます。

電子コミックの現状と自分の方向性

Xcode4.3.2 for Lionを起動したら、ユーザーインターフェースがすっかり様変わりしていて戸惑ってしまいました。なにしろ今まで使っていた旧バージョンは、3.2.3なので(^_^;)。

これまでに書いたiPad版電子コミック【Wings ウイングス】のコードもけっこう読み替えないとだめだろうなぁ...かなり変わってるだろうから。

このままRetina対応版の制作に取り掛かるつもりでしたが、丁度良い機会なので、現在の電子コミック/電子書籍をめぐる状況と、自分の今後の方向性について少し整理してみることにしました。

まずはこれまでの歩みを少々。

デジタル時代・インターネット時代になって、マンガも新しいスタイルに変化していくだろうと決め付けていた私は、Webcomicと称して自分なりのマンガ表現を試行錯誤していました。そのときはWebブラウザで表示するという前提で、制作ツールはFlashを使用。

その後iPadに出合って、『こ、これはマンガに最適だ！』『新しいマンガのために創られたデバイスに違いない！』と一目ぼれした私は、iPad版電子コミックの制作を決意。

さっそく本などでiPad版電子コミックを作る方法を調べました。その結果が以下にまとめた3つのやり方です。（他にも方法はあるかもしれませんが）

　1. iPadアプリとしてオリジナル・コミックアプリを作り込む。

　2. ePub形式という電子出版のためのオープンフォーマットに従ってコミックコンテンツを作る。

　3. 各社が開発したiPad用専用リーダーアプリのためのコミックコンテンツを作る。

私は、迷うことなく1番目の「iPadアプリとしてオリジナル・コミックアプリを作り込む」という方法を選びました。

理由は、それまでWebcomicとしてFlashで作っていたマルチメディアコミック/インタラクティブコミックは、iPadアプリとしてしか実現不可だったからです。

その後の悪戦苦闘は、本ブログのカテゴリー【iPad版制作日記】に書いてきた通りです。

さて、電子コミック/電子書籍をめぐる状況はというと、昨年の10月（2011/10/11）にePub3.0が勧告され、今年のはじめ（2012/01/20）にAppleがiBooks Authorという電子書籍作成ツールを発表しました。

私は、ここのところずっとiPadアプリに集中していたので、ePubとかその周辺の動きに関しては横目でチラチラと見る程度でした。それでもじわじわと環境が整ってきているとは感じてました。

特にiBooks Authorは、『う〜む、いじってみたい...』とかなりそそられるツールです。

とはいえ、静止画ベースのマンガならすぐにでも試してみたいところですが、私のようなマルチメディアコミックの場合は、結局やりたことができないでしょう。

と思っていたところ、ePub3.0ではJavaScriptが使用可能になったとのこと。

『えっ!?...じゃあ、マルチメディアコミックもできるかも...』と私の中で期待が膨らんだところです。

このiBooks Authorが噂どおりの優れもので、ある程度簡単に電子コミックが作れるものであり、またJavaScriptで凝ったこともできるということであれば、なんか明るい道が開けそうな気がします。

まだ自分が試してないのにこんなこと書いているのは、『だったらいいな』という期待値を込めちゃってます。

ただ実際に試してみたら『まだまだだな。現状では使えないや。』ということはよくある話で。

でもその方向性でもう少し探ってみようかと思ってます。

新iPadのコンテンツ制作環境

新iPadのRetinaディスプレイに対応した電子コミックを制作するための、環境構築をしています。

iPadのRetinaディスプレイ対応版を作るには、Xcodeのver4.3.1/iOS SDK5.1以降が必要みたいなので、iOS Dev Centerでダウンロードしようと思ったところ、Snow Leopard版はver4.2までしか見つかりませんでした。

そうなんです。私のiMacはまだSnow Leopardなんですよね。

というわけでまずiMacのOSをLionにするところから始めなくては。

App StoreでOS X Lionを購入、インストール。

インストール時間はそれなりにかかりますが、本などを読んでいるうちにサックリと完了。

さて次は、Xcode4.3.2 for Lionを同じくApp Storeからインストール。

こちらも特に問題なくインストール完了。

最新のXcode4.3.2をインストールしても、旧バージョンのXcodeは残しておいてくれるとの情報は得ていましたが、確認するまでは安心できません。

まずは、アプリケーションフォルダのXcodeを起動 → 最新のver4.3.2が起動しました。よしっ！

次に、Developer/Applicationsフォルダの旧Xcodeを起動したところ、「Xcodeを開くには、Javaランタイムが必要です。今すぐJavaランタイムをインストールしますか？」というメッセージが表示された。

インストールボタンをクリックし、インストール完了を確認後、再び旧Xcodeを起動 → ちゃんと旧バージョンのXcodeが起ち上がりました。

これで、とりあえずいままでのソースコードをコピーしながら制作する環境ができたのでほっと一息。

それにしても、Retinaディスプレイと非Retinaの両方に対応したiPadコンテンツを作ると、画像の面積比で以前の5倍のファイルサイズか...なんだかなぁ。

続・新iPadを購入!

「新しいiPadを使ってしまうと、非RetinaのiPadには戻れない」というようなことを何かで読みました。

たしかに新iPadのRetina画面は、いくら目を凝らして見てもピクセル感は感じられず、新聞のようにはっきりくっきりしてて気持ち良いです。そしてその後にiPad2の画面を見ると、たしかにかすかなジャギーが感じられてしまいます。

いままでぜんぜん気にならなかったんですけどね。っていうより『iPadの画面てきれいで見やすいよね。』なんて言ってたのに。

写真などの画像は、ピンチアウトで拡大する回数が増えるんでしょうね。まず画面全体を見た後、細部までじっくりきれいな画像を楽しむという見方になっていくんだと思います。

Webコンテンツの世界では、JPEG圧縮で多少画像が荒れていても誰も文句は言いませんでした。でもこれからはそうも言ってられないかも。画質の悪さを許してもらえない時代が来つつあるような気がします。

回線速度はどんどん速くなるし、パソコンやスマホのスペックの向上もとどまるところを知らない。そしてディスプレイのRetina化ということになれば、コンテンツだけ低解像度でOKというわけにはいきません。

というような状況を確認したところで、自分のiPad版電子コミック制作について改めて考えてみました。

『マンガはそんなに高解像度でなくてもいいんじゃない!?』みたいなことを前回のブログで書きました。

でもだんだん考えが変化してきました。Retina時代の考え方に頭がシフトしてきたのかもしれません。

たとえば鳥瞰図のような場面で、登場人物達が地上に小さく見えるシーン。

当然、読者はピンチアウトで豆粒のように見える登場人物達を拡大して見ようとする。そのときキャラ達が適当に描かれていて、表情なども死んでいたらどうでしょう？がっかりしますよね。

反対に細部まできっちり描かれていたら、読者は二度楽しめるというか、電子コミックならではの新たな楽しみ方や可能性が広がります。

初代iPadに初めて触れたときには、新たな電子コミック制作の夢が膨らんだものでした。でもその後、実際に制作を開始して現実の厳しさをいろいろと味わってきたので、ここでもあまり夢を膨らませるのは控えますが。

Retinaディスプレイに対応するには、まず最新のXcode and iOS SDKで開発環境を再構築します。

そして2048×1536ピクセルのサイズで1ページずつ作っていくことになります。

それに非Retinaのファイルも用意しておかないといけないので、ファイルサイズが膨大になりますよね。

というわけで現時点では、ショートショート・ストーリーの積み重ねが現実的だと考えています。

数ページごとに落ちを入れるような。ギャグマンガならいいんですけどね...

iPadの本体（デバイス）やOS、開発ツールなどのアップグレードサイクルが早すぎて、ぜんぜん追いついていけません。

フットワークの軽いコンテンツに変えなければ。

新iPadを購入!

新しいiPadを購入。

出費は痛いですが、現在自分にとって最も興味があり、また力を入れてる電子コミックという分野で欠かせないデバイスなので頑張ってゲットしました。

外見はiPad2とほとんど変わらないし（0.6mm厚く、51g重くなった）、あっと驚くような新機能が付いたわけではないので、特に新鮮味は感じません。

とはいえiPad版電子コミックを制作中なので、コンテンツの見方・見せ方に影響するような新機能が盛り込まれていないほうが、正直ありがたいんですけどね。

問題は、超高解像度のRetinaディスプレイ。

初代のiPadとiPad2は1024×768ピクセルの画素数でしたが、今度の新しいiPadは2048×1536ピクセルです。つまり4倍の面積が同じ大きさのタブレットに圧縮して詰め込まれていることになります。

写真集とか細部まではっきりくっきり見たいコンテンツの場合は嬉しいんですけど、自分が制作中の電子コミックのようなコンテンツではそこまでの高解像度は必要だろうか!?...というか、各ページ2048×1536ピクセルで作ることになると...レンダリングが...う〜む、大変そうだ。

それにそれだけ高密度の画像をアニメさせるのに、新iPadにはA5XプロセッサーというパワフルなCPUが搭載されているとのことだが、パフォーマンスは本当に大丈夫なんだろうか!?

たとえばこの間作った、ポジ画像とネガ画像を全画面ですばやくアニメさせチカチカさせるのは!? 不安だなぁ...

だからといってこのまま1024×768ピクセルの解像度で制作を続けた場合、つまりRetina非対応ということになりますが、アップルの審査は問題ないのだろうか!?

さらにそんな高解像度で電子コミックみたいなコンテンツ作ったらファイルサイズがバカでかくなっちゃうけど、ユーザーがダウンロードする気なくなるのでは？

...などといろいろ考えてしまいました。

DTPの世界では、高精細な印刷物にするために写真などは高解像度でスキャンしたデータを用意します。一方、Webコンテンツの場合は、ネットの回線速度の問題から画質には目をつぶってもすばやい描画を優先させました。

そしてタブレットを電子書籍の閲覧用デバイスという側面から見た場合、印刷物のような高解像度のデータが要求されるという流れはもしかして必然かもしれません。

でも紙の印刷物は、文字と静止画像で表現されていますが、電子コミック/電子書籍は文字と静止画の他に、動画・サウンド・プログラミングによる双方向の仕掛けなどデジタルならではのマルチメディアでの表現が可能です。

なので単に高解像度のヘビーなファイルを『おっ、きれいだねぇ！』とほいほい受け入れれば良いというわけにはいきません。

とはいえRetinaディスプレイの方向性は決まったわけなので、クリエイターとしてはシャープで美しいこの画面を活かしたコンテンツをどのように作っていくか...

ところで、いままで作ったページをRetina対応に作り直す余力が自分に残っているのか？

そういえば作り直すにしても、ただ単に今の環境で高解像度版にすればいいわけではないようです。

先日Appleがリリースしたアプリ開発者用ツールでないと、Retina対応にはならないそうです。

開発環境も再構築か(´ﾟωﾟ｀)。

iPad版:慣れないなぁ、XcodeでObjective-C

和風展で和の雰囲気にひたった後は、またiPad版電子コミック【Wings ウイングス】の制作再開です。

和風展に投稿した作品は一枚絵で、マンガとはジャンルが違います。でも作品を完成させるということは、精神衛生的にいいですね。

Webcomic【時空マジシャン】はChapter.2で止まってるし、【Wings ウイングス】も牛歩の速度で完成はいつのことやらという状況。

なので和風展の投稿作品をきっかけに、これからさくさくとリズム良く制作が捗るといいんですが。

それから精神衛生上良くないといえば、いままで制作してきた各ページで中途半端なまま後回しにしてきた箇所が、積もり積もってじわじわと心の負担になってきているんですよね。

それを解消せねばということで、上の画像です。

主人公のレナが、「ここは...ケームショ!?Σw(ﾟдﾟw)」とショックを受けているシーン。

ここは当初は、ムンクの「叫び」のように画面を歪ませる効果を施すつもりでした。

で、そのまま保留になっていたんですけど、もっとダイレクトにガーン！とショックを受けた感じにしたほうが良いと思い、上の画像のように画面を反転させてチカチカとさせることにしました。ポジとネガを交互に数回すばやく表示するわけです。

iPadはレスポンスが良いので、自分が意図した感じにはなりました。

でも何か効果の実験室みたいな感じで、音声などを付加した後、全体を読みながら客観的に見てみないとまだ判りません。

それにしても、XcodeでObjective-C...なかなか慣れませんねぇ。

Flashのようなアニメーション制作ツールではもちろんありませんが、1ページ1ページ制作を重ねていくうちに、馴染んでくると思っていました。

ところが一向に馴染む気配がありません。

Flashも特にマンガ用というわけではないので、自分が作りたいWebcomicのために使い方をあれこれ工夫したわけです。でも使えば使うほど手に馴染む道具のように使い勝手が良くなっていったものでした。

一方、XcodeでObjective-Cの場合は、たとえばキャラに瞬きさせるにしてもコーディングしているので、マンガを作っている気がしないんですよね。

まぁ本来は、マンガ用ツールをObjective-Cで作ってから、そのツールでマンガを描くというのが正しい順序なんでしょうけど。

マンガが完成するのが先か、Objective-Cに慣れるのが先か。

それともその時は永遠に訪れないのか...!?