概要
「マンガを描いてみたい!サーバーサイドエンジニアにもできるかな」
というわけで
マンガの各手順を特に情報収集しないでやってみる。遊びなので雑にやってみよう。
マンガの構成要素の分析
ざつにソフトウェア開発のフェーズに当てはめる - 要件定義: マンガの方向性・趣旨・読者層を定義する - 技術調査: 開発者の強みなど活かせるかも含めて - 環境整備: 爆速かつ低コストでマンガを描くための - インフラ整備: 作ったマンガをデプロイする導線確保 - テスト: ネーム - 実装: 実際に描く - 保守運用: 改変していくか、続編かくか、派生するか、消すか - 分析: 他のマンガの研究
何駆動か
- リビドー駆動
- マネー駆動
- 名声駆動
- 個人的楽しみ駆動
- 能力拡張駆動
組み合わせもいろいろある。
今回はIDD-イキオイ駆動-で開発する。
結局たいへんなのでまずはプロトタイプを作る
- 要件定義: マンガの形をなせばなんでもよく、何ページでも良い
- 技術調査: kritaが入っていたのでそれを使う。トラックボールで描く
- 環境整備: スクショでとればいい
- インフラ整備: ここにUPすればいい
- テスト: なし
- 実装: 実際に描く
- 保守運用: ぶんなげ
- 分析: 他の漫画などない
- 制限時間: 5分程度が目安
完成です
気が向いたら整備していくかもしれないし、していかないかもしれない。
おまけ: 漫画をシステムしたときの雑なユースケースメモ
ドメインモデルを探す
紙、描く人、読む人、コマ、イラスト、タイトル
要件定義(ユースケースモデリング)
システム==紙+私 - システムは、コマ、イラスト、タイトルを順不同で描画する - ユーザーは、１つ目のコマにアクセスする - ユーザーは、コマの中に 絵を認識し、読む - ユーザーは、次のコマを見る - ユーザーは、すべてのコマを読み終わり、フーンと思う
モデル
- Paper has_one title
- Paper has_many comas
- Coma has_one イラスト
