ペルリ的な何かなブログ

Simutransとかいろいろ自由気ままに書き散らす

【Simutrans】続スケールスピードを考える

ぼんやりしてたら今月も月末になったので記事のネタを忘れていました。

ということで雑な記事で誤魔化すことにします。

ローカルマップは亀の歩みのごとく進めていますが、まだ表に堂々と出せる程度のモノには仕上がってないので少しだけスクショを出して誤魔化しておきます。

地方都市の駅に集う列車

都会の私鉄のターミナル駅

マップ最大となる国鉄ターミナル駅

スイッチバック駅もあります

 

ということで今月の本題です。

過去にこんな記事を書きました。

pm1965.hatenadiary.jp

この記事は1ヶ月あたりの走行タイル数を検証した結果ですが、こんな検証せずとも1ヶ月あたりの走行タイル数がわかるというのは少し前に発覚してました。

貨物一覧のこの謎の数値ですが、その速度で走ったときの1ヶ月の走行距離だったんですね。

これがBPM=19のときなので過去の検証で100km/hの時には638タイルくらいとなります。という結果に当てはめると加速分を考慮した場合に数値がほぼ一致しています。

ということで、この数値が1ヶ月あたりの走行タイル数となることが証明されたわけです。(知ってるよって人はそうだねくらいで眺めていただけると幸いです)

ちなみにこの100km/hの速度で進むタイル数は以下の計算式で算出できます。

2^(BPM値-13)*10

この計算に基づいて鉄道車両のサイズを基準としたときの各BPMによる1ヶ月を〇としたときの速度も計算できます。

となり、128jpの場合はBPM23のときに100km/h出している乗り物は106.6km/h相当の速度を出していることになります。(1タイル=25mとした場合)

同様に、64や128でBPM23のときに100km/h出している乗り物は170km/h程度出してることになります。(1タイル=40mとした場合)

これで逆のアプローチで64や128のスピードが100km/h、1タイルあたり40mとした場合に近くなるのはBPM=21、1ヶ月を1日とした場合となります。

こういう考え方でリアルに近いスケールスピードが算出できるのではないでしょうか。

(たぶん自分は使わないけど…デフォルメ系の64や128はそれほど厳密に考える必要もないと思うので)

 

ここからまたさらに拡張して、これらの車両が現実世界でのどのくらいのスピードになるかという話まで拡張しようと思います。

またまた過去にこんな記事を投稿しています。

pm1965.hatenadiary.jp

1ヶ月を1日としたときにBPM=22、これがちょうど13時間58分となり現実の約14時間でシムトラの1ヶ月を1日に見立てた時に現実世界で経過する時間となります。割と使いやすいスケール感なんじゃないでしょうか。

 

なお、この話を拡張すると列車の加速性能の調整にtickを導入することによって特定の速度(100km/h)に到達するまでにかかる時間で調整して車両の加速シミュレーションを行い、列車出力調整の指標にできるのではないでしょうかというところで今回の文章は締めたいと思います。

【Simutrans OTRP】OTRPで追加されたルートコストに関わる設定事項

前回の記事↓の続きというか補足というかです。

pm1965.hatenadiary.jp

今回の記事はこれを説明します。

 

このあたりの挙動どうなのよってところを解説していきます。

このへんの挙動関係なしに基本的な旅客挙動は以下の記事をだらだらと続きもので4記事くらい読み流すと理解しやすいと思います。

基本的なSimutransの旅客流動の発生と列車乗車順序に関して理解していれば読む必要はありません。だいたい重複解説しています。

具体的には

・主にルートコストで乗換駅が決まる

・先に到着した乗り物から順番に乗る(※OTRPではこのルールが適用されない設定がある)
・降りる駅が近い順に乗る(※同上)

あたりのキーワードを覚えていれば問題ありません。

 

pm1965.hatenadiary.jp

そして8年ぶりにこの路線図に登場してもらいました。新駅が開業したりしてるのでリメイクしました。

路線図も見やすくパワーアップ

解説で使いやすいJR京都・神戸線の京都~西明石の路線図です。

この路線図の通りに運行されていると仮定して乗換えどうのこうのを論じていましたが、今回はちゃんと用意しました。こういうところもパワーアップしてます。

手抜きせずに用意しました

 

これで実際に駅に沸いた客の乗換え先を追いかけることによってそれぞれの設定における乗換駅がわかるということです。

例えば先に上げた記事での実例ですが、芦屋から京都まで行く場合はそのまま新快速に乗るのがルートコストが最少となることから乗換えなしで芦屋から京都まで向かうことになります。

今回も

芦屋駅から京都駅

高槻駅から兵庫駅
朝霧駅から摂津富田駅

西大路駅から摂津本山駅

それぞれ発生した旅客の行先を観察していきます。

芦屋駅から京都駅の場合

探しにくいので印がついてます。理論の通りですね。

高槻駅から兵庫駅

これも快速に乗り続けるのが最少のルートコストとなりますので乗換えなしでの移動となります。

朝霧駅から摂津富田駅

高槻~明石で新快速に乗るのがルートコスト最少となるためこの通りになります。

西大路駅から摂津本山駅

芦屋まで快速なルートになりそうですが摂津本山を見ると住吉から快速に乗ってますね。なぜでしょうか?快速芦屋に止まるはずなのに…

何はともあれこれをベースにOTRPで追加された「全員降車」と「乗車区間を区切る」の違いについて観察していきたいと思います。

 

【全員降車の場合】

全員降車を使った場合、系統分断と同じ状態となります。

路線が1つしかない場合には全員降車にチェックを入れた駅で全員乗換えとなります。

 

前提として快速は芦屋、普通は高槻、大阪、芦屋、神戸にチェックを入れます。

芦屋駅から京都駅の場合

変わらないので省略します。

高槻駅から兵庫駅

快速電車が芦屋駅で強制乗換えになる影響で神戸駅での乗換えに変わりました。

そのほか普通電車で行ける駅が減ったので全体的に乗り換えるルートをとるようになっています。

また行先別に乗換える駅に着目するとある程度決まった駅で乗り換えるようになっているように思えます。

高槻駅に着目すると折り返し乗車も増えました。快速電車も芦屋駅で強制乗換えのためでしょうか。

 

朝霧駅から摂津富田駅

ここは変わりません。新快速を使うことになるので。

 

 

西大路駅から摂津本山駅

芦屋駅乗換えに変わりましたね。

摂津本山に目を向けると芦屋まで乗って神戸方面に折り返し乗車の行き先が増えました。

 

【乗車区間を区切るの場合】

乗車区間を区切るを使った場合、区切った駅を2つ跨いだ場合に全員降車と同じ挙動になります。

なので乗車区間を区切る場合は2つ以上使わないと意味がありません。

先ほどと同様に快速は芦屋、普通は高槻、大阪、芦屋、神戸にチェックを入れますが、快速は意味がありません。

芦屋駅から京都駅

相変わらず変化がないので省略します。

高槻駅から兵庫駅

あまり変化がないことがわかると思います。一応普通電車乗り通しが少しだけ減っていますが。


朝霧駅から摂津富田駅

さらに変化がありません。少しだけ何も設定しないのと乗車区間を区切るのハイブリッド感がありますが。

 

西大路駅から摂津本山駅

こちらも変化は少なめです。

乗車区間を区切るのほうは緩行種別を細かく区切ったほうがいいと思います。もう少し細かく区切れば目に見える形になるとは思いますが。

当然ながら短い路線で乗車区間を区切るを使ってもさほど意味は薄くなります。

 

●ここからおまけ

いままでずっとSimutransの旅客輸送に関しての

①主にルートコストで乗換駅が決まる

②先に到着した乗り物から順番に乗る
③降りる駅が近い順に乗る

という3つの基本法則ですが、OTRPでは②、③に関しても設定次第で変更が可能となっています。

②ですが、スケジュールで発車時刻を設定した場合に

出発直前に積載(B)という項目がチェックできるようになります。これにチェックを入れるとその名前の通り到着した乗り物順ではなくなり、優先順位が下がります。

緩急接続などで速達種別と接続するときに使えば上位種別に乗換えさせることができます。

また、③ですが、高度な設定から

first_come_first_serveにチェックを入れると先に駅に到着した乗客から優先して乗り物に乗るようになります。

 

そんな感じでいろいろ旅客流動に関しての挙動を変更する仕様があります。

【Simutrans OTRP】スケジュールの設定項目って色々あるけど実際どうやって使うの?って話

まぁタイトルの通りです。

いつの間にかいろいろ機能追加されていますが、実際問題「これってどう使うの」みたいなところがあり、自分もいまいち理解できてない部分もあったのでこれを機会に積極的に触ってみて紹介していきたいと思います。

OTRPの路線メニュー

今回は連結回りや発車時刻関連の解説は省略して、旅客等の乗降に関する事項を解説していきます。

OTRP公式の解説と重複するところはありますが、自分なりの使い方を交えての解説とします。

 

①臨時系統

このスケジュールはルートコストの計算に寄与しません。と出てきます。

臨時列車に使ったり運行本数が少なくルートコストに影響を与えたくない場合に使っています。

具体的には寝台列車のような定員の少ない列車を運行し、その輸送力を新幹線で補う場合などでしょうか。

起終点や途中停車駅が重なるような路線に使っています。

また一時的な混雑(デッドロックによる運行停止)解消用の代行輸送路線などに適用して既存のルートコストに影響を与えなくないときにも使います。

 

②応荷重制御

③乗降時間制御

主に発車時刻を設定するとき、時間計測をするとき、それによって制定されたダイヤに沿って運行するときに使っています。

 

④乗車不可

⑤降車不可

それぞれの通りです。
使用方法としては長距離列車などで近距離客を乗せたくない場合などに使います。

例としては東海道新幹線で東京~品川の乗車をやめるなどでしょうか。

 

⑥全員降車

⑦乗車区間を区切る

この二つは別記事にて紹介します。ちょっとわかりにくいところがあるので。

 

⑧最高速度

路線での最高速度の上限を設定します。個人的には使い方をあまり見いだせてないです。

最高速度は車両の速度や線路、架線の速度よりも低い場合に適用されます。

 

⑨連結相手を待つ
⑩連結を試みる

この二つは列車などを連結するときに使います。OTRPの公式記事を参照してください。

 

⑪発車時刻まで待機

ダイヤに沿って運行させる場合に使います。過去記事でも参照してください。

pm1965.hatenadiary.jp

 

⑫すべて同じ発車時刻設定を適用

文章の通りですね。使いどころが見いだせてない機能その2です。

 

同一記事にするつもりでしたが、後で別記事に起こします。

【Simutrans】年の初めは鉄道車両の選定から

この記事を読んでいる皆様。謹んで新年のご挨拶をお申し上げます。

今年もまだ6日しかたってないというのに大きな地震があったり、羽田空港で大きな事故があって滑走路が使えなくなって帰省客に多大なる影響を未だ残していてこの濃厚な正月は何だったんだろうか見たいな感じになっています。

 

動画公開を前提とした新マッププロジェクトは順調に遅れております。

10月頃のつもりでは1月には動画にできるだろうなんて高を括っていましたが、そうもいかずほかのゲームに浮気したりしながらのんびりとやっています。

 

今回はSimutransで使う車両の用途とその役割について軽く触れていきたいと思います。

アドオンを大量に追加した日本の環境だといろんな車両が車庫の中にたくさん並んで何をどう使えばいいのか見たいなことになったりとかすると思います。

電車のオタクならなんとなくその用途がわかるかと思いますが、それでも詳しくない人はよくわからんになります。

なんとなくそれらの使い道をずらずらと解説していきますが、これが絶対というわけではなく、そういう使われ方をしていたとかそういう風に使うのがシムトラ的に使いやすいとかそういう話です。

さて、ガンガン車両アドオンを入れた車庫というのはだいたいこんな感じになっちゃってると思います。

pak64の車庫

デフラグ画面ですね(たぶん最近の若者には通じない)

まぁ、とにかくたくさんの鉄道車両があることがわかります。

それらが概ねどんな役割を持っているのかというのを解説していきます。

主に国鉄~JR型で説明します。私鉄は話がややこしくなるので。

また電車のみとします。これもややこしくなるので

 

①特急型電車(485系651系、683系など)

長距離列車の基幹列車と位置付けたい列車ですが、総じて定員は乏しいです。

ざっくりいうと速度は出るけど1列車あたりの輸送力は弱いです。

ルートコスト調整用の列車として運行し、たくさんの客を引き込むのが役割なのではないでしょうか。

長距離輸送が追い付かなくなったらいよいよ新幹線の出番を考えたほうがいいと思います。

 

②急行型電車(165系451系一族など)

特急列車よりは多少定員が多くても最高速度もやや控えめになっています。

急行列車も特急列車同様にルートコスト調整メインで下位種別にもある程度の輸送を丸投げするくらいのつもりで運行したほうがいいと思います。

現代は廃れてしまったカテゴリーの列車でもありますが、晩年は地方で短編成化されて普通列車として運用されたケースもありますし、もとからそのつもりで設計されてるだけあって需要の少ないローカル線区での普通列車をのんびり走らせるにはちょうどいいかもしれません。

 

③近郊型電車(113系、211系、313系など)

中長距離を快適に移動するため立席を認めて定員を多くしつつ高速性能もある車両群です。

特急列車の定員の少なさをこの定員の多さでフォローするくらいのつもりでいたほうがいいと思います。そういう列車設定を考えましょう。

 

④通勤型・一般形電車(103系205系E231系など)

近距離の通勤列車を担う大量輸送型です。あまり長距離輸送には向きませんが車両によってはたまにそういう使い方をする車両も紛れ込んでいます。

新しい電車になれば最高速度も近郊型や特急形に匹敵する性能のモノも混ざってきたりします。

近距離から長距離の詰め込みまで幅広く活躍する形式ですが、長距離列車に使うとあまり評判はよくないかもしれません。(ゲーム内的にはまったく問題ないですが)

 

寝台列車(14系客車、583系など)

はっきり言って趣味でしか使い道がありません。定員が少なすぎるからです。

運行するなら新幹線に完全並行させて定員の少なさを新幹線にフォローしてもらうくらいのつもりじゃないと厳しいと思います。

ただ、ロマンはありますよね。

速度的にもやや劣るものもありますし、使うのは非常に難しいし工夫が必要だと思います。

 

 

自分の場合はよく国鉄時代だと特急列車と急行列車を走らせ急行列車の一部停車駅を選択停車制にして同じ区間で快速列車として近郊型車両を運行。系統分断された普通列車が都市周辺を走るみたいな構図で列車を設定します。

定員の少ない特急や急行からあふれた客を近郊型の収容力でフォローしつつって感じですね。

それでも輸送力に難があれば新幹線を作っちゃう。そんな感じです。

寝台列車はたまに趣味で対向列車のバリエーションを増やすみたいな使い方をしています。

今月はもう1本記事に出せるかなぁ見たな内容があるのでそれも出せたらいいなぁって感じで今月の記事を締めたいと思います。

【Simutrans】マルチプレイ(NetSimutrans)の環境の変化とその及ぼす影響について+α( #SimutransAdventCalendar2023 の記事)

今年もアドベントカレンダーが始まっていますね。相変わらずいろんな人がつぎからつぎへといろんな記事を出してきておりますが、自分はいつものペースでやっていきたいと思います。

 

あらかじめ言っときますが、今回の記事は画像なしとなっています。

少々退屈かもしれませんが、文字だけの読み物として楽しみいただければと思います。

 

今年のSimutransAdventCalendar2023は↓のリンクからどうぞ。(いつもの定型文)

adventar.org

Simutransにオンラインプレイモードが実装されたのも随分と昔の話で今年でもう12年も前の話になるようです。

自分がネットに顔を出してマルチプレイするようになってからすでに10年くらいが経過しているようで時の流れというのは早いもんですね。

すでにシムトラを始めた時にはすでにネットワークモードが実装されてた世代が当たり前のようにいますし、それ以前から遊んでる人も随分と減ってきたように思えます。

逆に新しい人も随分と増えて10年前と比べると露出してる人も随分と顔ぶれが変わったようで、10年前に建てた鯖のデータを見ると随分と懐かしい名前を見てはあの人どうしてるんだろうなんて思いに更けたりもしてました。

 

自分がSimutransでマルチプレイができるようになったと知ったのはニコニコ動画でした。

この動画です。

www.nicovideo.jp

就職して上京しPCも当時のゲームがそこそこ遊べるようになってちょうどSimutransから一番離れてた時期かもしれません。

あのSimutransでオンラインプレイができると知って色々な人をTwitterでフォローしてようやくサーバーに参加できたのはこの動画を見て半年くらい経った頃でしょうか。

今も昔も一時期を除けばマルチプレイのサーバーに参加したいと思ってもなかなかすぐには参加できないのは同じのようで、当時はサーバーの数が少なく開催期間も今に比べて短かったのですが、兎にも角にも募集に対して参加希望者が多く参加希望を募ったらすぐに埋まるような状態でした。

初めて参加したサーバーでは隣の見よう見まねで周りに迷惑をかけないようにしつつ自分のやりたいこととできることをやった感じです。その時の記事はすでに書いてるので良ければ読んでください。

pm1965.hatenadiary.jp

その後ほどなくして自分でもサーバーが立てられないかと考えるようになり、サーバーPCを用意してサーバーを建てて定期的な開催をして参加したい人をどんどんと受け入れるようになり今に至ります。

最近はサーバーの数も増えたり自分もそれほど精力的にSimutransができなくなってきているのでその頻度も減りましたが、2014年頃はほぼ常時開設のサーバーとして稼働して多くの人を受け入れるようになりました。

当時は概ね2~3ヶ月ごとにゲームを行っており、基本的に7割くらいのメンバーが固定だったと思います。

 

長々と昔話を続けていますがまだ本題ではありません。

 

当時のマルチプレイ環境はTwitterでの連絡とマーカーを併用してのコミュニケーションくらいしかなく、今のようにDiscordなんて便利なモノもなかったので結構大変だったのかもしれませんね。今となってはよく覚えてないロストテクノロジーかもしれませんが。

Twitterにスクショを頻繁に上げて楽しいことをやってる感は外に出してた感はありますね。先ほど出した動画のように動画を投稿してこういうのがあるっていうのをアピールしたりもしてましたね。

この頃はアドオン作者もTwitterに露出するのが活発で制作中のアドオンの画像を頻繁にアップしてた記憶がありますね。

ゆえに当時の事情としてはTwitterやニコ動で広報活動をしてサーバーの参加者を募っていました。

当時のマルチプレイ事情はそんな感じでしょうか。

 

ここからが本題なのですが、当然10年も時が経てば事情もすっかりと変わっちゃうわけで、当時のTwitterもいまではすっかりと変わってしまい、マルチプレイでのコミュニティもDiscordなどに移行して半ばクローズドな環境となりました。

以前ほどTwitterでのSimutransの活動も沈静化し動画投稿も少なくなりSimutransというものの広報能力も弱くなってしまったように思えます。

また人が入れ替わっていると言えども新規流入が少なくなり、逆にマルチプレイのサーバーはかつてよりも多くなっているのが現状ではないでしょうか。

そのサーバーも多種多様になり、昔はみんなで集まってただSimutransのマルチプレイを楽しんでいただけに過ぎなかったのが今では風景を作りこんだりOTRPの機能を駆使してダイヤ通りに運行したり特定のマップで実在の路線を再現してその時代にあわせた列車を運行するなんて企画があったりと多種多様になりました。

また、アドオン作者の事情も変化し、かつては作ったアドオンを他人に使ってもらうには各wikiなどにアップしないと使ってもらえなかったのが今では同じサーバーにいれば使ってもらえるという事情もあり、そのサーバー内でしか流通してないようなアドオンも随分と増えました。たまに上がってくるスクショを見るとどこにも公開されてないようなアドオンも散見されます。

当然ながらアドオンを公開するか否かはその作者の自由なのでとやかく言われてもとはなります。理由も多種多様な事情が考えられるので一概に言えるわけではないですが、少なくとも10年前に比べても作られたアドオンが投稿されるという昔ながらの状態は衰退しているようにも思えます。

そしてSimutransの仕様やその挙動、バグなどの情報交換も減っているように思えます。

一方のサーバーでは当たり前のように知られたバグも他のサーバーでは知られてないなど情報の格差も拡大してるように思えます。

 

あとやっぱりマルチプレイをやりたくてもどこに行けばいいのかわからないという一種の難民みたいな人たちも少なからずいるようですね。

自分がいまのコミュニティに入ったときにはこの人に繋がっていればコミュニティにたどり着けるという人がそこそこ居ましたが、今ではすっかりと減ってしまったようにも思えます。

 

また、参加者と主催者でサーバーの趣旨のすれ違いというものもたまに見かける気がします。

例えばルールに書かれてないからやっていいよねみたいな感じでルールの隙をついて自分のやりたいことを押し通して主催者やほかの参加者から顰蹙を買うみたいなことがたまにあったりします。

主催者から見ればルールの隙をつくような行為は嫌うことがありますし、参加者からしたらルールに書かれてないことはやっていいよねと言う言い分がありますが、やはりそういう考えでは決してどちらも得しないのではないでしょうか。

やはり主催・参加者ともにサーバーの趣旨を理解しよくコミュニケーションをとってより良いサーバー運営に繋がればいいんじゃないでしょうか。

ただ、他人とSimutransをするということは決して自分のやりたいことを押し通すというわけではないということは頭に入れておいたほうがいいと思います。

 

Simutransが今後どのように変化し発展していくのかというのは未知ですが、今までどうやって発展してきたのかというのを考えるとこの現状は決して明るくない話なのではないでしょうか。

特に情報交換が停滞しつつあるのは少々気になるところではあります。

とは言え趣味の世界なのでそれも致し方ないのかとも思いますが。

偉そうに語っていますが、自分もいろいろやって挫折して立ち直っての繰り返しなのでなかなか難しいものがあると思いますし、一人の力では決してどうしようもないことでもありますので。

そんな将来のことを考えた師走のある一日でした。

【Simutrans】突如湧いて出てくる記事( #SimutransAdventCalendar2023 の記事)

今年は枠が余ってそうなので予定してた記事とは別立てで記事を書きました。

ネタどうしようかななんて思っているんですが、なんとなくこれでいいかって感じの毎月のブログネタみたいなのでお茶を濁して枠埋めの足しにしようかと思っています。

今年は真ん中の枠をとっているのでそこそこ気合い入れた記事書こうかななんて思ってますが、夏ごろに大規模な検証をしたので半ば力尽きています。

思えばアドカレも毎年毎年こうやって記事を寄稿してるわけで過去にどんな記事書いたっけなんて思いながら過去の記事を漁ってはやってないことを書いていこうなんてことをやってるのでそろそろネタ切れ感出てきています。

このブログは過去記事を見ればわかる通り、Simutransの様々な解説や検証の結果などの記事もありますので興味がありましたらカテゴリーから過去の記事を漁ってもらえればなんて思います。

 

というわけで、適当にお茶を濁すのはわかってるようでわかってないSimutransのショートカットキーでもまとめてみたいと思います。

 

簡単ながら表にまとめました。なおデフォルトでインストールした状態でのショートカットキーとなります。

Simutransのショートカットキー

pak64系統のショートカットキー設定と128系列があるようですね。

64系統の設定は64をもとにしているnipponや128japanなんかがそうですね。

128Germanは128をもとにしているようですね。

それにしてもこんなショートカットもあったんだなみたいな感じになりました。

意外と割り当てられてないキーもそこそこありそうですね。

 

そもそもここ5年くらいで追加された機能に対するショートカットキーが割り当てられてなかったりもするのでそろそろ見直しをしてもいいのかもしれませんね。誰がどうやってやるのかみたいなところもありますが。

あと、日本語配列と英字配列のキーボードでそれぞれ使うのが面倒くさいキーがあったりするのでその辺の配慮も必要な気がします。

 

あまり使わない高度な設定とかそういうのはCtrl+なにかに割り当ててよく使う機能を簡単に使えるようにしたり、誤操作の可能性のある機能を…とかいろいろ考えることはできますが、そういうゲームデザインも研究可能な分野に思えてきました。

もちろん使い慣れたショートカットキーが使いやすいのかもしれませんが。

 

いつか誰かがこれを参考に新しいショートカットキーの割り当てを作り出してくれるといいですね。(そのうち自分でやっちゃうかもしれませんが)

 

今回は簡単ながらそんな記事でした。

 

 

今年のSimutransAdventCalendar2023は↓のリンクからどうぞ。(いつもの定型文)

adventar.org

【Simutrans】隣町としてたまに使われる役場だけの都市についてあれこれ

はやいもので今年もあと少しとなりまして、アドベントカレンダーの受付も始まりましたね。

例年11月も末になるとそこそこ埋まってきてた印象がありますが、今年は埋まりが遅いような気がするのでここでも宣伝しておきます。

adventar.org

まぁ、例年の流れからもう1枠とってしょうもない記事でも書き散らして空いた穴を埋めるのもいいのですが、いろんな人がいろんな記事を投稿してこそのアドベントカレンダーだと思うので。

 

だいたい例年12月はアドカレの記事と気が向いたら書く記事と2つ書いてるのでそれをアドカレに転用すればいいだけのことなのですが、今年は少し何を書こうかななんて状態なもので急に枠が空いたから…なんてことになるとネタに困りそうですね。

 

さて、今月の記事はタイトルでわかるかと思いますが、マップ外接続として疑似的に役場を設置したときに関する記事です。

たまに見かけるマップ外接続を目的とした都市

昔はたまにこういう役場だけの都市を疑似的な旅客発生源としてマップ端に配置してマップ外との旅客流動を表現するなんてことをやってた人がいました。

今回はこれに関して少し検証してみました。

 

まず、「効果はあるのか」という点ですが、今年長々と続けてきた検証で、役場から発生する旅客は市内建築から発生する旅客と同じ性質である(=産業や特殊建築にも旅客が発生する)ことが判明しています。

pm1965.hatenadiary.jpということでマップ外からの旅客流動を表現する手法としてそれなりに適した手法ではないかと思います。

マップ外から来た客がマップ内に存在する観光地なんかに向けても旅客が発生するという点でもその効果が得られるので。

また、比較的旅客発生の高い役場を使うことで高い旅客度が期待できます。

なお、同一市内の市内建築が存在しないことから役場から発生した旅客はすべて別の都市へと向かうことになるのもメリットの一つだと思います。

しかしながら、欠点もいくつかあります。

・マップの両端にマップ外都市を設置してもlocality_factorの影響を受けるのでマップ外~[マップ内の幹線]~マップ外みたいな輸送を考えた時にもlocality_factorの影響を受けるのでマップ外都市からマップ内を通過してさらに外に出るような輸送需要が期待できない場合がります。特にlocality_factorの値がマップサイズに対して小さい場合などです。

・旅客度が役場の旅客度のみに依存するため役場が大きくならないとマップ外からの需要も変化しない。

 そのまんまですが、マップ内が発展してもマップ外都市も発展させないと役場が大きくならない。場合によっては旅客度が大きな役場のpakファイルがないpaksetなどではその効果が失われることになります。

 

だいたいこんな感じでしょうか。

 

ちなみに役場の旅客度はその役場のpakファイルで定義されている値とpassenger_factorの値のみで決まり、浮浪者や無職者の数とは無縁であることがわかっています。

pm1965.hatenadiary.jp

この二つの画像を見比べれば都市の人口や浮浪者、無職者が役場の旅客度に影響がないことが一目瞭然です。

 

この理論でいくならば、あまり使われない気候(砂漠あたり?)でしか建設されない役場を作って疑似隣町の役場としてどんどん人口増加に伴って役場を拡張していく…なんてこともできると思います。役場移転には十分な注意が必要ですが。

 

今月はそんな記事でした。

アドカレの記事も書かないとなぁ