実行行数がほぼ１６ｋｓというところ。（8/4の前回の生産状況から＋３ｋｓ増加）
まだ、エンディングとか、チュートリアルとか、調整とかでワサワサと増えそうな感じなので、完成時点で２０ｋｓぐらいになるかも。
以下、蛇足
ちなみに、仕事でプログラムを作る場合、ステップ数を見積もり値にしている所が意外と多くあるようですが、ステップ数の見積もり値なんて全然アテにならないのにやる意味あるんですかね？私が仮に、想定規模を計上する必要に迫られた場合、とりあえずFP法（私の場合、画面単位ではなく機能単位で算出する方が精度が高い）なりで何かしらの根拠のある数字を出しますが、だいたい以下のような要因でその数字はフェーズとともに上下します。
①「この機能とこの機能は共通化できる」（機能レベルの共通化見落とし）
②「この機能はｘ機能とｙ機能に分割しなきゃダメだ」（機能レベルの分割漏れ）
③「この機能が必要だった」（機能レベルの実装漏れ）
④「この機能は要らなかった」（機能レベルの冗長実装）
そして、より下流フェーズに進むと①～④の「機能」が「関数」とかの細かい単位に変わります。まぁ、下流フェーズでも機能レベルの設計ミス（＝すり抜け不良）がある程度残存するものですが。一般的に、見積もり値の上下幅は、上流フェーズの設計ミスほど広く、下流フェーズの設計ミスであれば狭くなります。自社開発なら、それでも大して問題は無いと思います。問題は、他社に請負契約で発注するケース。請負契約の場合、発注時点で発注に掛かる費用（予算）を決めますが、プログラムが完成していない時点（コーディング前）の場合、幾ら掛かるのか客観的に分かり難いため、適正価格が発注時点で分かりません。だから、かなりアヤフヤな値であることを承知で想定規模（想定される画面数やプログラムのステップ数）なんかを指標にしている企業がたくさん居る訳です。個人的には、請負契約が妥当なプロセスは、テスト工程（※定性的な項目が多い統合テストなどを除く）ぐらいだと思います。請負契約で上手くやる（見積もりと実績の乖離を減らす）のに有用な開発手法は、経験則ではスパイラルモデルの開発ぐらいです。要は、見積もりと実績の乖離を減らすには、すり抜け不良を少なくすれば良い訳で、それをやるのに一番良い手段は、開発サイクルを小さく分割することだけだと思っています。学問レベルでは色々な手法が考えられているようですが、スパイラル以外の実用レベルで使い物になる手法は未だ見たことがありません。ただし、スパイラルだとそれを第三者が管理するのは無理に等しいから、開発作業とマネジメント作業を両立できるエンジニア以外できないこと（＝要員確保が困難なこと）がネック。そして、そういうエンジニアは得てして単価が高いから、予算オーバーになり易いという落とし穴があります。そもそも、スパイラルで妥当な程度の規模にサイクルを分断すると、発注のオーバヘッド（恐らく裁断したサイクル単位で発注する→妥当な規模に裁断すると契約がポコポコ増える→大変になる）でパフォーマンスが落ちるような気もするので、結局のところ「コーディングまで委任契約がベスト」だと思っています。
要は、「コーディング＝定量的な作業」という風潮をなんとかする必要があるんじゃないかと。
