「技術的な話」カテゴリーアーカイブ

Ci-enのクリエイター状況ちょっと眺めてみた

ここのところ『援交少女』の原稿を描き上げてはCi-enに投稿するのが同人活動の中心になってます。

それで、プラットホームとしてのCi-enはどんな状況かいな、と先日ちょっとだけ調べてみたのでブログに書き留めておきます。

調べたのは8月29日の夜10時頃。その時点でクリエイターページの開設数は1141でした。
そのうち、1000人以上のフォロワー数を集めているクリエイターは84人(7%)
フォロワー100人超が467人(41%)

Ci-enがスタートしたのが4月16日、4か月半で1141のクリエイターページってのは多いのか少ないのか……。
このくらいの数なら全クリエイターの一覧をザッと眺めるくらいはそんなに苦になりません。そのくらいの登録数で収まってるというのは、もう少し頑張りましょうって感じなのかもですね。
旅の道第三停留所さんが書かれている「パトロンサイトを徹底比較してみる話」という4月29日付けの記事でも、4パトロンサイトのランク付けの中では最下位、「初動で完全にコケてる」ってバッサリ斬られちゃってますし(==;


さて、Ci-enはEnty, Fantia, pixivFANBOXと同類のパトロンサイトと呼ばれるクリエイター支援サービス。となるとその収支はどんなもんでっしゃろってところも気になりますね。
そこで上記の、フォロワー千人斬り……じゃなかった千人越えの大手クリエイターを対象に、把握できる範囲でその収支を追っ掛けるというヤラシイことをしてみましたw

84人中、有償のプランを開設し、かつそのフォロワー数も公開してくださってる方は36名。
これらの方々のフォロワー数と、有償プラン&そのフォロワー数、そこから導かれる月間売上などを一覧表にしてみました。

No. フォロワー
総数
プラン1金額
(支援者数)
プラン2金額
(支援者数)
プラン3金額
(支援者数)
売上 有償加入% 期待値
1 7772 100(13) 1300 0.2 0.17
2 4096 100(91) 9100 2.2 2.22
3 3706 500(125) 62500 3.4 16.86
4 3200 300(1) 500(2) 1300 0.1 0.41
5 3195 200(11) 2200 0.3 0.69
6 3107 300(52) 15600 1.7 5.02
7 3072 100(165) 16500 5.4 5.37
8 2763 500(254) 127000 9.2 45.96
9 2741 500(297) 148500 10.8 54.18
10 2180 200(100) 20000 4.6 9.17
11 2159 300(34) 10200 1.6 4.72
12 2050 500(127) 63500 6.2 30.98
13 2040 500(172) 86000 8.4 42.16
14 1938 100(84) 500(6) 11400 4.6 5.88
15 1926 100(82) 500(31) 23700 5.9 12.31
16 1838 500(11) 5500 0.6 2.80
17 1829 500(171) 1000(10) 2000(7) 109500 10.3 59.87
18 1786 500(10) 5000 0.6 2.80
19 1661 300(43) 12900 2.6 7.77
20 1545 500(36) 18000 2.3 11.65
21 1517 300(25) 600(11) 14100 2.4 9.29
22 1264 500(96) 48000 7.6 37.97
23 1260 500(8) 4000 0.6 3.17
24 1257 100(5) 500(60) 1000(13) 43500 6.2 34.61
25 1222 300(5) 1500 0.4 1.23
26 1216 300(7) 500(137) 70600 11.8 58.06
27 1172 100(15) 1500 1.3 1.28
28 1155 100(3) 300 0.3 0.26
29 1154 500(17) 8500 1.5 7.37
30 1152 500(8) 4000 0.7 3.47
31 1151 200(17) 3400 1.5 2.95
32 1130 300(3) 900 0.3 0.80
33 1117 500(17) 8500 1.5 7.37
34 1069 200(65) 500(15) 20500 7.5 19.18
35 1032 500(67) 33500 6.5 32.46
36 1012 100(41) 4100 4.1 4.05
平均値 3.7 15.14
中央値 2.4 6.62

「有償加入%」は、フォロワー全員の内で有償プランに出資してくれている方の率。
「期待値」というのは、売上をフォロワー総数で割ったもの、つまりフォロワー一人当たりに見込める売上額の期待値です。

どちらも結構ばらつきがあって、また総フォロワー数との相関はざっと見た感じあまりなさそうです。
高い有償加入率や期待値を持っているクリエイターをいくつかピックアップして眺めてみましたが、RPG系のゲームサークルが強い印象ですね。
そして有償プランに加入することで遊べる、何らかのインセンティブを付けて有償プランを「販売」しているところが多いです。
反対にたとえフォロワーが多くても、見返りが薄く純粋に支援を期待するような有償プランは(まぁ当然の結果ではありますが)プラン月額の高低にはあまり関係なく集客力には優れません。
(端からこうした売上にはこだわらず、フォロワーさんとの繋がりを膨らませるためのミニツールっぽい使い方をされてる方も大勢おられますが)

突出してる幾つかのクリエイターがいますので平均値より中央値の方が当てになりそうでしょうか。
フォロワー数100人あたり有償プラン加入者は2~3人、月間売上は600~700円くらいのラインになりそうです。

そして売上が1万円を超えてるクリエイターさんは全部で20名。
これは1141名のクリエイターの1.8%の狭き門です。
閾値5万だと僅か7名0.6%!

現状だとビジネスツールとして捉えるには厳しいですね(^^;


2018/09/05追記

最後のところで考察ミスがありましたm(_ _;)m

テーブルで表示されてるのは、フォロワー1000人越えクリエイター84名中、有償プランの参加人数を公開しておられる36名(43%)に限られてます。
この割合からの単純な逆算が成り立つとすれば、売上1万越えの人数予想は45~50人程度(約4%)/5万越えは15~20人程度(約1.4%)くらいかと予想されます。


作画工程ご紹介

Ci-en Ci-enで公開済みの記事でスミマセンが、自前ブログの方にも掲載しておきますね~。

今回は『援交少女』p16の2コマ目をサンプルにメイキング紹介などやってみたいと思います。

ネタバレしちゃうけど、まいっか~皆様きっとご想像のとおりでしょし。そうですコイツがワルモノです。

使用してるのはCLIP STUDIO PAINT。
ずっとPro版だったのですが、このマンガを描くためにEXにアップグレードしました。月額500円のリース版なのでキャプチャ画像のタイトルバーに「次のライセンス照合は2日後」なんて出ちゃってますw
タブレットはCintiqの13inch液タブ。作業はフルデジタルでアナログ画材使う工程は一切ありません。


ラフ描き

デジタルツールの機能を存分に活かして(おんぶにだっことも言う)各人物・各パーツをそれぞれ別レイヤーに振り分け、線のカラーも変更して描いてます。
デッサン力無いので、こうしないと前後に重なり合ったパーツがグッチャになって描いてて分からんくなるのです。
各レイヤーはラフ描きしながら、移動・拡大縮小・回転なんかも使ってバランスを整えながら描きます。この最初の時点で形が歪んでると後から追っ付けで直そうとしてもだいたい上手くいかないです。

ラフ描く時のイメージとしては、ぼわ~んとした雲のようなフォルムの中から徐々に輪郭線にピントをフォーカスしてくような感覚で描いてます。たぶん上手い人はこのピントフォーカスが早く、更に画力ある人は脳内で済ましてしまえるので、いきなりビャ~ッと一発描きが出来るんじゃないでしょうか。僕には無理ポ。スケブなんて絶対よ~描かんです。

今回完成画ではオッサンは服着てるんですが、ラフの段階ではヌードで描いて、後からこれまた別レイヤーで衣服を描きます。
枠線の外側の体まで描いてるのは、デッサン力無いのでそうしないとコマ内のプロポーションまで狂ってきちゃうから。


下描き

ラフを入れてるフォルダとは別のフォルダに下描きを描いていきます。
ここでもパーツごとにレイヤー分けまくりです。とにかくレイヤー使いまくるのがデジタルに完全におんぶにだっこされる陰陽流。


ペン入れ

ズボンの下でオッサンのチンコがバキッてるのが何げなポイントw

昔はこのペン入れ工程、単に自分が描いた下描きをトレスしてるだけじゃん創造性無いな~…って嫌いでしたが最近はそうでもなくなってきました。
トレスしてるんじゃなくて、下描きを参考にもっと良いラインが無いかな~と探りながらもう一度描いてる感覚になってきたからかなと思います。
タッチの付け方とかも画面デザインの一部、ペン入れは創造性の無いトレス作業じゃないぞよ昔のワシよ。

主線に使うのは殆どGペン。あと丸ペンやカブラも少し使います。
以前はペンツールが苦手で、この工程も鉛筆ツールで描いてたんですけど、このマンガ描き始めてからだんだんペンツールにも馴染んできました。

ただ馴れるにつれて線がだんだん細くなってってる印象。
今回のマンガは後々ゲームやCG集で描くカラー画像の練習の狙いもあるのでトーンを多く使う塗り方していて、輪郭線より陰影を重視する描き方に頭の中が徐々にシフトしてってるのかもしれません。

とは言いながら陰影を主体にした描き方するには技術的に未熟だなぁって感じるところも多くて、服の皺なんかまだまだだなぁ…と。
今回の脱がされてる服の皺なんて似たポーズやシチュエーションの画像を参考資料に使ってはいますが、そのものズバリな角度や状況があるでなく、殆どを想像で描いちゃってるのでリアリティが乏しいですね。

主線はほとんどベクターレイヤーで描いています。
後からポイントを調整して修正できるのが、僕の描き方には性に合ってるので。
顔のパーツみたいに微ッ妙なニュアンスが要求される箇所だけはラスターレイヤーです。


下塗り

描き上げた主線の各レイヤーをそれぞれフォルダに放り込んで、各々のフォルダの底にラスターレイヤーを敷いて自動選択やバケツで塗り潰していきます。
この過程で主線の上下配置を変更調整して、各パーツの前後関係も固まります。

主線段階から細かくレイヤーに分けてあると、この下塗りは割合頭使わなくても機械的に出来ちゃう工程なのですが、その分退屈な単純労働感もあってあんまり好きではありません。
その割に結構手間暇食うし。AIとかでアプリが全部やってくれるようになんないかな~。

スーツやズボンとかスカートとか、それぞれの固有色(今回はモノクロ作品なので濃度)は決めてはいますが、結構コマごとに変更しちゃいます。あとマンガの場合は隣のコマと比較してデザイン的な狙いでコマ全体の明暗をイジったりもします。
実写や3DCGでもライティングや露出次第で固有色の見え方なんて全然変わっちゃう訳だし、その場面内でのパーツ間の相対的な明暗対比が合ってりゃイイのよ。たぶん┐(´ー`)┌


陰影付け

各パーツごとに分かれてるフォルダの中で、下塗りのラスターレイヤーと主線ベクターレイヤーの間に別レイヤー挟んでクリッピングして陰影を塗ります。

だいたい1レイヤー1色の単色で塗って、必要に応じて輪郭をブラシでコスってぼかします。このコスりぼかしでグラデーションが生まれるので、単色レイヤーでも柔らかい立体感が出せます。俗に言う「ギャルゲー塗り」ですね。

でも敢えてこのボカシを付けない「アニメ塗り」も独特のテイストがあるので、いつか他の作品でチャレンジしてみたいかな。
ボカシをかける前のパキッとした輪郭の影の段階でも、ちゃんと濡れば立体感は出せます。ていうか最初のラフ描きの時のデッサンと同じで、アニメ塗り段階できちんと立体感意識して影を塗っとかないと、後からボカした時も陰影が嘘っぽくなりがち。

このマンガはモノクロなので陰影のレイヤーはそんなに枚数重ねてません。
1影だけで済ませちゃう場合も多く、一番使っても1影+2影+ハイライトの3レイヤーくらいです。

背景はこのコマではCLIP STUDIOのストアで購入した3Dオブジェクトを配置しました。クリスタのLT変換ごいす
あと全体描き上げてから、せっかく描いた左手の拳が見切れてるのがもったいないな~と思ったので全体を少し縮小。

マンガではこの上にセリフのレイヤーが乗っかって完成です。
そちらはCi-enの有料プランにて。

……1コマ描くのにほぼ丸一日かけてる。カロリー高杉(´-`;)


『つつじいろ』ブラウザベースCG表示エンジン「紙芝居(仮)」が出来ました

先日、次回作『躑躅色の記憶 ~つつじいろのきおく~』の構想発表した時に、

html5ベースでブラウザ表示前提の本編を作れないかなぁ、と。(連番静止画の方はPDF等で同梱する形で)
画像切り替え時のちょっとしたフェードイン・アウトとか、ノベルゲーに似たクリック対応の段階的テキスト表示、右クリック等でテキスト表示/非表示切替くらいのことが出来ればイイかな~、と。

というようなことを書きましたが、その後本編のシナリオがほぼ完成し、じゃあちょっとそのCG集表示エンジン作ってみっか、と先週ガチャガチャやっとりまして。
昨日あたりで、まぁ基本的にはコレでOK、というレベルまで出来上がりましたので、シナリオの冒頭部分を使用してデモを作ってみました。
(ただ、まだ本作用の画像は一枚もないので、背景はグレーのベタです…)

『躑躅色の記憶 ~つつじいろのきおく~』テストデモ

縦書き・横書き混在可能で、ページ遷移の時にフェードイン・フェードアウトも出来るようにしました。
また目次ページを表示して、鑑賞中に別の章にジャンプできるようにもしました。

中身は完全なWebコーディングですから、html5/css3/JavaScriptを使ってやれることは何でも出来ます。
試しに『オレかの』で採用したJOKS(邪魔な男は消してしまえ)機能を組み込んでみました。これもデモの最後のページに入れてありますので、遊んでみてください。

ある程度フレームワーク的な作りにしてますので、本格的なWebコーディングは難しいという方でも、簡単なhtmlさえ書ければ、テンプレートに従って組んでいくだけで使用できるエンジンにしてあるつもりです。
もしご興味おありの方おられましたら、無償でお分けしますのでお声掛けください。


ひとつ残念なのは、このWeb構成のシステム、iOSやAndroidではデバイス内に保存して直接開くのが難しいみたいなんですよね~。

それさえ出来ればクロスプラットフォーム自在な制作環境が構築出来るんですが。。。
何でWebサーバからのhtmlは開けるのに、ローカル保存したhtml開けねーんだよ全く…

フリーで公開するだけならデータ本体をWebサーバ上に置けば済むんですが、
有償配布するとなると、会員登録システム作って、SSL(https)認証を取得して、決済代行会社の審査通して、、、と大仕事になっちゃいます。

DMMさんやDLsiteさんがプラットフォーム提供してくれないかなぁ…


さて、こういうのはあくまで余技で、肝心なのは本編の制作です。

たとえばBGMや音声機能だとか、ページ遷移のトランジションだとか、エンジン強化のアイデアはいくらでも出てきますが、今回必要なのはあくまでCG集の表示用途です。今の状態でそれに必要な機能は揃ったと考えて、エンジン開発はひとまずここまでにして、シナリオのページへの落とし込みをこれからやっていきます。
出来れば今週=今月中にはそれを終わらせて、来月頭からはひたすらグラフィックに集中したいですね。

で、その肝心の本編のお話の内容ですが、、、

色々宣伝方法も考えてはみたのですが、今回はストーリーについてはあまり情報を出さない方がいい内容かな…という気持ちがありまして。

グラフィックについては、ネタバレにならない範囲で18禁のも含めてどんどん公開していく予定ですが、
お話についてはあらすじ紹介や体験版等も出さないで、いきなり本編をドン!とリリースする方向でいこうかなと。

なので漠然としたことしか申し上げられないのですが、前回のブログにも書いたとおり、現実的な生々しいお話です。
シナリオ書き上げてからもう10日ほど経って、多少醒めた客観的な目で読み返してみても割と出来映えは気に入っていて、作者としては手応え感じておりますのでどうかご期待ください。
読み終わった後、ご自身の彼女や奥さんをチラ見しながら「ひょっとしたらコイツも俺に隠れてアンナコトやコンナコトを…」みたいな猜疑心&イヤ~な読後感を抱いて頂けるように、頑張って作ります(^m^)


背景加工

今日Twitterの方に投稿したんですが、ネタ的にブログ向きな内容だったのでまとめときます。

シーン背景は出来れば自前で描きたいと思ってたんですが、制作のための時間とか体力的な面とか、色々考えると全部を自分で描くというのはちょっと難しいな…ということで、市販の背景画像集を見繕って、使える所はそれでひとまず手を打とう、ということにしました。
オンライン販売のゲームの場合、どうしても…となったら後からパッチで差し替えも出来ますしね。

…とはいえ、既にシナリオは出来上がってて音声も殆ど発注&納品済みになっている現在、
既製品の背景画像だとどうしてもストーリーとの間に矛盾が出てくる箇所や、8割方OKなんだけどあとちょっとココ何とかなんない?みたいな画像もあります。

なので既製品をそのまんま使うだけじゃなくて、必要な箇所に手直しを入れたり、トリミングしたり、複数の画像を組み合わせたり、カラー補正を施したり…といった二次加工をやっております。
今回はその幾つかのご紹介。


まずはメイン舞台となる自宅。
間取りの設定は僕の脳内には1,2階ともしっかり出来上がってるんですが、市販品の画像でピッタリと合うものは当たり前ですがありません。
そのへんは適当にお茶を濁すしかないんですが、でも玄関など建物の外観と内観で辻褄が合わなかったり、脚本との整合性でココはコレじゃないんだよな~、て最低限の場面は修正しときたいな、と。

自宅before玄関before自宅の外観、そして玄関の画像は上の2枚を使うことにしたんですが、
コレじゃお互いにドアの向きが合わない。
それに脚本の都合上玄関ドアはソレじゃないんだよなァ…ってんで、それぞれ以下のように修正しました。自宅after玄関after


お次は食事シーン背景用の食卓画像。
テーブルの上に昔使ってた3DCGアプリとその素材集使って適当にお料理並べました。ダイニングbeforeダイニングafter3Dアプリの使い方相当忘れてた~(汗)
でも自前で全部作らなきゃならない背景画像も今後少しずつ出てくると思うので、良いリハビリです。


最後は質素なアパートの女の子の部屋。
アパートの部屋beforeアパートの部屋after同じ構図の別画像からベッドを持ってきて、カーテンには女の子らしくちょっとした柄を追加。
全体の色調も暖色寄りに補正しました。

そんでもって、コレにブルーのベタ塗りの画像レイヤーを2枚ほど、焼き込みモードと乗算モードで乗せると、、、
アパートの部屋-夜夜間シーンの出来上がり。
画像集にも朝、昼、夜(灯り付き)のバリエーションは付いてましたが、照明の消えた後の暗がりシーンは無かったので自分で作りました。

昼の明度・彩度の高い画像があれば、夜のシーンへの転換はこんな感じでものの10分もあれば出来ちゃいます。
市販の画像集のバリエーションも、よく見ると塗り直してるんじゃなくて単にレイヤー加えて色調変えただけ、なんてのもありそうですねぃ。


こんな感じで作成した背景画像を組み込んでテストプレイしてみると、、、2017-02-05_19h06_13

背景画が入ると一気にゲームらしくなってきますね~って、
ひとりニヤけながら引き続き作業中__φ(´∀`)

 

 


【吉里吉里】[move]でレイヤー移動したら、[trans]前に[wm]で受けといた方が良さげ

「どうせ時間経ちゃ行き着くじゃん」
って放りっぱなしにしてたら、スキップでページを高速捲りしてたら[move]が完了する前に[trans]が起動して、
けったいな位置で対象レイヤーが停止したままになってしまいました(′д`)


吉里吉里のlayerのindexについて

マニュアルには、

標準では、前景レイヤ 0 が 1000、前景レイヤ 1 が 2000 ( 以降 1000 ずつ増える )、 メッセージレイヤ 0 が 1000000、メッセージレイヤ 1 が 1001000 ( 以降 1000 ずつ増える )、  メッセージ履歴を表示するためのレイヤが 2000000 となっています。

となってるのですが、例えばこんな構成になってた時、

レイヤー index
メッセージレイヤー0 1001000
前景レイヤー1 2000
前景レイヤー0 1000
背景レイヤー 0

前景レイヤー0を前景レイヤー1の上に持ってきたくて、
[layopt layer=0 index=3000]
とすると、、、

レイヤー index
メッセージレイヤー0 1001000
前景レイヤー0 3000
前景レイヤー1 2000
背景レイヤー 0

↑こうなるかと思いきや、

レイヤー index
前景レイヤー0 3000
メッセージレイヤー0 1001000
前景レイヤー1 2000
背景レイヤー 0

、、、と、前景レイヤー0がメッセージレイヤーの上まで飛び出してしまいます。

で、吉里吉里のコンソールで、各レイヤーの順番を調べようとすると、、、
kag.fore.messages[0].order = (int)2
kag.fore.layers[1].order = (int)1
kag.fore.layers[0].order = (int)3
kag.fore.base.order = (int)0

、、、となってて、ちなみにだけど、これらのレイヤーにindexっていうメンバー変数は存在しません。

そこで、最初に戻って、
[layopt layer=0 index=2]
[layopt layer=1 index=1]

と指定してやると、

レイヤー order
メッセージレイヤー0 3
前景レイヤー0 2
前景レイヤー1 1
背景レイヤー 0

と、想定していた順序になりました。


htmlのz-indexなんかとは挙動が異なり、マニュアルにあるあのレイヤー番号の記述は、一番最初にレイヤー構成を敷く時にあのデカい数値順に並べられる、というだけで、
一旦レイヤーが並べられた後はそれらの数値は廃棄され、後は各レイヤーはそれぞれのorder属性に基いて重ねられてるだけのように見えますね。
([laycount]タグでレイヤーの数を変更するとレイヤーの重ね順がリセットされる、という理屈もそう考えると腑に落ちます)

従って後からその重ね順を変更する[layopt]のindex数値は、そのorderを上書きするってコトみたいです。

続きを読む 吉里吉里のlayerのindexについて


吉里吉里のクリッカブルマップに使うPhotoshopのスウォッチに「Windows」の使用は避けた方が良いかも

この手の技術的なお話はブログのテーマと若干ズレるので、別ブログかWiki作ってそっちに移管するつもりですが、とりいそぎでココに備忘録的に書いておきます。


表題のとおりで、吉里吉里のクリッカブルマップに使用する「ファイル名_p.png」画像を作っていた時なんですが、

png_8形式で出力する際にカラーテーブルを参照して、その順番にインデックスは割り振られます。
全部で256個のエリア指定が可能ですが、その時に使用するカラーテーブルとして、僕は当初スウォッチの中のWindowsってタイプを、あまり深く考えずに使ってました。
ちょうど256個で構成されてるのでコレに合わせて塗っとけば、インデックス番号の管理がやりやすいや、ということで。

ところが、あまり多い色数を使ってなかった時には別段問題なかったんですが、256全色近い大量のクリックポイントがあるマップを作ったら誤動作が発生して、調べてみたらWindowsスウォッチには0x808080で重複してるボタンがあるじゃないですか。

swatch_windows「Windows」スウォッチ。なぜか1ペアだけ重複(´・ω・`)

で、Mac OSスウォッチに差し替えたらそうした問題はなく、きれいに大量のボタンが並んだクリッカブルマップが作れました。

swatch_MacOS「Mac OS」スウォッチ。こちらには重複はありません

なまじ沢山の色だから、一からチクチク塗り直すのめんどかったです。

CONFIG


なおPhotoshopで吉里吉里のクリッカブルマップを作成する方法については、こちらのブログが非常に分かり易くて参考になりましたm(_ _)m

吉里吉里のクリカブルマップをphotoshopで作ろうか -intro-:腐ったかつおぶしの日記:So-netブログ