mkworks

シムトラ関係のエントリーまとめ群

最近のアドオン制作環境について2019改訂版

adventar.org
このエントリーはSimutrans Advent Calendar 2019 7日目の記事になります

学会補足資料:アドオンを効率的に作る - less /home/honoka/simutrans/simplay.logs
以前、このようなエントリーを補足記事として書いた事がある。今回はその記事に対して進歩やら技術的な紹介に対する自分の返答であり、まとめであるかもしれない。
そして、内容については初心者お断りに近くなるのでLinuxの簡単な操作や軽いプログラミングの知識があると読みやすいと思う。わからないところは随時調べながら読むか、以下のリンクからTwitterにて質問を受け付けるので気軽に聞いて欲しい。なるべく平易な表現を用いるようにはしたいが、時々難解な表現を用いる事があるのでそのあたりは留意してもらえると幸いである。

twitter.com

基本的な制作フロー

まずはアドオン制作のフローについて考えてみよう、以下のプロセスを経て1つのアドオンが誕生する。
これはこの記事を書いている筆者自身のパターンなので他にもあるかもしれない、ここでは架空の新産業セットを立ち上げる前提で話を進めることにする。

  1. 基本要件定義
    1. 産業の定義(種類・流れ)
    2. 貨物の定義(名前・カテゴリー・積載可能車両等)
  2. 要件定義を受けて各種ファイルを作成
    1. 貨物のdat作成・更新*1
    2. 産業のdat作成・更新
    3. 産業のpng作成・更新
      1. 複数タイルにまたがる場合は切り出し実施
  3. 各種ファイルがまとまったらpak化
  4. テスト環境に導入して各種確認作業

以上6(7)個の作業があるのだが、datやpngの作成はまだしも更新は何度もありその度にpak化を行っていた場合には古いデータのままテストして更新結果が反映されていなくてうんうんと唸ったりすることが~~実際にあった~~あるので自動化出来る要素は自動化しこの様な事故を減らしたいと思う。
次から具体的な実装例について上げていく。

pak化

先のパターンにおいて

各種ファイルがまとまったらpak化

と書いているが半分間違いとも言える、実態としては各pak毎にdatとpngが揃った時点で既にpak化を始めてしまうからだ。そして必要なファイルは揃った事や更新を検知したい、その為にLinux環境下という限定的な条件があるがinotifyというライブラリを用いる必要が出てくる。これは単独でも動作させられるがツールとして使おうとしたら各種機能が必要となってくる、そこで自分の環境下においてはRubyにてpak化のツールを作った。最近のカジュアルな開発のトレンドとして継続的インテグレーションというのがあるが、これに近いものをシンプルに実装して運用している事となる。

少し話を脱線して先程登場した""継続的インテグレーション""についての話をさせてもらいたい、これについてはCI – 継続的インテグレーションとは? | tracpath:Worksより次の文章を引用させていただくこととする

継続的インテグレーションとは、ソフトウェア開発のプロセスを自動化することで開発者がソースコードをコミットし、共有しているリポジトリにマージされることでビルドとテストが自動的に実行される手法である。
継続的インテグレーションにより、ソフトウェアのバグを早期に発見し対処することができ、チーム開発のスピードを上げ、コードの品質を保証することが可能である。

何を言っているかわからない人もいる気がするのでアドオン制作に置き換えながらざっくりとした解説を挟ませてもらう。最初にプロセスの自動化とあるがmakeobjを通したpakを生成する作業である、先に自動化出来る要素と挙げているがこのpak化という作業について言及している。次にソースコードのコミットとあるがソースコードについてはdatもしくはpngを想定していただき、コミットについてはそのdatもしくはpngを保存すると考えてほぼ差し支えないだろう。*2
このざっくりとした説明から何を言いたいかわかってくれたら幸いである、Twitter等で問い合わせは受け付けます。

自動化というがディレクトリの構成やファイル名に一定の規則が適応されることになっている、基本的にはdatとpng名のファイル名は同一としたり出来たpakファイル特定のディレクトリに入れさせたりするなどである。
特定の名前を付けた空ファイルをディレクトリに入れておくと、そのディレクトリの中でpngもしくはdatが更新されたらとしてもpak化を行わないなどである。

画像を切り出したい

さて、ここまででpak化が自動化出来てはい終わりとしたいがまだ実装したものがある画像切り出しである。2枚画像が並んでいるが1枚めがソースになる画像であり、2枚目が1タイル(64px x 64px)の範囲内に収まるように切り出した画像だ。

f:id:mashita_07_15:20191207155916p:plain
ソース
f:id:mashita_07_15:20191207155936p:plain
切り出し済みデータ
どこぞのホームセンターっぽいとか言われたら御名答と答えよう。それはさておき、書き出した画像も自動的に切り出したいという要求が生まれてくる。アドオン制作のツールの一つにTileCutterという画像を切り出すGUIツールが有るのだが、画像を書き出した後に別ツールを操作して更にpak化用の画像を書き出すというのはどうにも~~面倒~~スムーズにアドオンを制作したいと思う。しかし、画像を切り出すとは言ってもサイズや切り出すサイズ等の問題が出て来てしまう。それをどうにかして力技に近い感じで解決した。

pak化について少し戻るが、そのツールにはpak化以外にも切り出しツールとの連携も機能として搭載している。切り出すpngとサイズを設定したファイルを読み込み、該当するpngが更新された時に切り出し処理が走る簡単な仕組みだ。

少し便利となっているがやはり手動でやるべき事は残ってはいる、設定ファイルを作ることだ。これがないといくら画像を書いた所で切り出してはくれない。

これからの展望

実は既に新しいツールの開発に着手している。鉄道車両ヲ制作する上で苦労するのが連結設定である、1文字間違えるだけでも車庫内で連結できないなど相当シビアで有る*3
dat更新時にこれを通して問題が出たら通知を出そうとかそういう展開を考えている、他にもまだアイデア程度だが実装したいものは用意している。

最後に

今年もカレンダーに参加して技術的な話をさせていただきました、小難しいを通り越してますがまぁそういうことです。
この記事の投稿日基準で明後日にはまた自分のエントリーとして軽く景観についてと語る予定です。

Simutransはいいぞ
アドオン自作はいいぞ
ツール自作はいいぞ

*1:貨物の性能定義のみで終わるのでpngが不要なため

*2:ファイルに対する変更の記録なので間違いはないが巻き戻せるかどうかで違う気がする

*3:OTRPにおける増解結ならびに121から入ったanyは除く