[ 開発室・鉄道側面画研究(走行手段篇) ]

[ 色々あるけれど… ]

おぱく堂は「ウェブ上に鉄道シーンを作る」という目的を実現するための手段として ダイナミックHTML(CSS+JavaScript)を選択した。
だが、他にも列車をウェブページ上で走らせる手段はいくつかある。ここではそれらの方法を試してみて実感したことを書く。試してない方法についても、ちょいと触れる。
* ウェブ以外の側面画走行(スクリーンセーバ等)はこのページの研究対象外なので触れない。
* 古い低速CPUパソコンでは、左上フレーム走行見本と、このページの Flash、HTML+Time、Marquee と動画GIF の5つを同時に動かすのが辛い場合がある。動作がギクシャクする場合は「左上見本停止」されたし。但し、最初の列車が走り始める以前は停止できない上に、一度停止すると再スタートできないという問題もある。見本番号によっては停止できないものもあるかも。
* なお、このページには前記の他に Canvas と inline SVG を使った走行見本もある。但し、Canvas や inline SVG が表示できる新しい時代のブラウザは、逆に HTML+Time に対応していないから、すべてを同時に動かすことはできない。

●Flash×過去の走行手段)(PNG画像で代替表示)

代替PNG画像

まずは、ウェブ表現ハイクオリティ化の代表だった時代もある「Flash」である。
かつては、企業サイトでは当り前のように使われていたが、モバイル端末が Flash に対応しなかったことと、高度な表現力を持つ HTML5 が普及するにともない、ウェブ上から消えた。高度な鉄道シーンを作るには最高のツールだったはずだが、そういう鉄道シーン表現を見ぬまま時代は通り過ぎてしまった。
* Flash プラグインが、2021年1月を以て廃止されて表示できなくなったため、PNG画像で代替表示した。但し、代替画像は静止画。
* 縦曲線からの勾配など、高度な表現が可能だった。但し、専用ソフトが必要でハードルが高かった。


●HTML+Time×過去の走行手段)

時間軸に沿って HTMLを動的に変化させ、ページ上にあるものを動かせる機能。
但し、Windows版 Internet Explorer(IE5〜IE8)専用機能であり、他のブラウザでは全く使えない。そういう事情はあるものの試してみた。
* 正式名称= Timed Interactive Multimedia Extensions for HTML.
* CSS+JavaScriptのみならず、HTML+TimeもダイナミックHTMLの一ジャンルという扱いらしい。CSSによる座標指定を動的に変化させる、という構造はどちらも同じだ。

Powered by HTML+Time
↑ CSS指定による風景と車輌の位置重ね+「HTML+Time」による動作 (Windows IE5 から IE8 まで)

* IE9 で HTML+TIME は廃止された
* HTML+Time は「JavaScriptより簡単に、Marquee 以上のことが可能」というのを売りにしていた。JavaScriptより簡単だとは思えなかったが、それでも Marquee 以上の表現をしたい人々にとっては魅力的だったのは事実。それに乗って、色々な表現を試みていた人々を、平気で見捨てるようなブラウザの進化とはいったい何なんだ。過去互換を軽視するにも程がある。


●Marquee

ウェブページ上にあるものを、簡単にスクロールさせることができる機能。動く鉄道シーンを作る方法としては最も手軽。
* かつては Internet Explorer専用だった機能。Netscape4 など、過去のブラウザには非対応のものもあるが、今は、対応していないブラウザはない。
* 指定が簡単なのが最大のメリットだが、凝ったことができないデメリットもある。

Powered by Marquee
↑ CSS指定による風景と車輌の位置重ね+「Marquee」による動作
* Marqueeで鉄道シーンを作っているサイトでは、車輌の位置決めに Margin指定をしている例が多く見られる。CSSのMarginに関してはブラウザ毎に解釈の違い等もあり、MacIEで見ると「宙に浮いて走る電車」になっている場合が多い。Marginではなく、座標を指定した方が確実だ。
[ 追記 ]
* ブラウザによっては、CSS指定してしまうと Marquee の動作範囲が車輌画像の幅に限定されてしまい、シーンとしておかしなことになる。解決方法(オブジェクトにいちいち width 指定を入れる)はあるが、そういうことを考えなければいけない時点で、あまり使えない方法と言える。結局、次々項の Table 指定 が一番使いやすいことになる。
* もっとも、オブジェクト(配置物)が勝手に画像幅に clip されてしまう仕様は、Marquee では不便だが、それ以外の用途では寧ろ歓迎されるべき仕様である。電車走行キット的にも、この仕様ゆえに無駄な横スクロールバーが出ないですむ場合があり、ありがたい話ではあるのだ。

Powered by Marquee +傾斜

↑ CSS指定(傾斜付)+「Marquee」による動作
* 上記「Marquee の動作範囲が車輌画像の幅に限定」という問題を解決(width 指定を追加)した上に、CSS3 の transform : rotate() 指定による勾配表現を追加したもの。古いブラウザでは傾斜しない。なお、この指定を電車走行キットに組み込んだ例が No.1442 にあるが、傾斜表現は Marquee と組み合わせる方が簡単。
左行 - 停止 - 右行
* IE では動作するが、他のブラウザでは方向切替が出来ない場合がある。

JavaScriptで簡単な制御もできるが、凝ったことは出来ない。
唯一、風景と組み合わせるのに CSS や HTMLの知識が必要なのが、ウェブページ作りの初心者にとっての壁となる。それでもウェブ上で鉄道シーンを作るための最も簡単な方法であることには変わりない。

↑ Tableを使った風景と車輌の位置重ね+「Marquee」による動作
* Tableだけで配置する場合は前景は置けない。また、枠付のTableを使うと、ブラウザによって背景画像の原点に枠を含めるものと含めないものがあるので、見る人によっては「宙に浮いて走る電車」になってしまう。枠なし必須。
* このページでは、CSSだけを使った位置重ねと、Tableだけを使った位置重ねの見本を載せたが、Marqueeで鉄道を走らせているシーンのあるサイトの多くでは、CSSと Tableを組み合わせている。CSSを使うのであれば Tableを使う必要はないのだが、Table兼用の方が指定は簡単であるし、ブラウザ毎に異なる CSS解釈の揺らぎを回避する手段として有効だったりもする。でも、CSS的には邪道なんだろうなぁ。


↑ 風景なし
* CSSもTableも使わないと風景との組み合わせができないため、必然的にこのような表現が限度となる。

風景との組み合わせにより、それなりの鉄道シーンも作れるし「定速走行+常に同じ編成」だけでよい、というのであれば Marqueeという選択も悪くない。
* 但し、おぱく堂作の車輌は、Marqueeでの使用を許可してはいない(TB画像を除く)。Marqueeを否定しているわけではないが、自分の描いた画像は自分が開発したプログラム上で動かしてもらいたいからだ。

[ 追記 ]
* HTML5 では marquee 廃止。そのかわり、高度な表現が可能な CSS3 で同様の動作を再現可能とか。とはいえ、CSS3 を使う方法は簡単とは言いがたい。簡単であることが marquee の特徴だっただけに、ややこしい記述が必要になったのは残念なことだ。HTML5 は確かに凄いのだけど、色々とハードルが高い。HTML4.01 までには存在した、ある種の「緩さ」も人間には必要だろう。コンピュータ優先で人間の感覚が後回しになるような風潮は面白くないところだ。このサイトも、一部 HTML5を使った個所もあったりするが、HTML4.01を捨てる気にはなれない。


●JavaScript

言うまでもなく、電車走行キットはこれである。
とりあえず、HTML+Time や Marquee と同じ画像で走行シーンを作ってみた。


↑ CSS指定による風景と車輌の位置重ね+「JavaScript」による動作
* 一から JavaScriptで鉄道シーンを作るのはそれなりに大変だが、既にある TKプログラムのパラメータ設定をするだけなら、簡単さは Marquee とさほど変わらないのではないか?
* ちなみに、このページの走行車輌は「立山砂防」のトロッコ。TBサイズ(32px高)の TK縮尺(1px=10cm)という両規格兼用画像。Flashシーンのみ倍サイズ。

Powered by JavaScript
↑ 過去互換を切り捨てた、超簡素な「JavaScript」による動作
* 電車走行キットを使わず、getElementById が使えない過去のブラウザを見捨て、Marquee レベルの動作だけに限定した、簡単すぎるスクリプト。コードは、わずか 6 行である。当然、汎用性はなく、左行のみ、1編成のみ、定速(Km/h 換算ではなく、ピクセル単位の移動)のみ。clip 指定(表示範囲指定)は入っているが、電車走行キットのような JavaScript による clip をしていない結果、ブラウザによっては、画面外を走行する車輌が見えてしまう問題もある。
* 少しでも機能を追加しようとすると途端に行数が増えてしまうから、ある程度以上の表現をする場合は TKプログラムを使った方が楽だと思う。だが、スクリプトが書ける人にとっては、自分でコーディングした方が、最低限の行数で思いどおりのシーンが作れるわけだから、走行手段の選択肢のひとつとなろう。

 
●CSS3 Animation

HTML5 + CSS3 で可能になった、CSS要素を時系列に沿って変化させられる機能。
position を変化させることで鉄道走行が可能になるが、透明度、色、形状など、あらゆる設定を変化させられるので、表現の幅は広い。


↑ CSS3 Animation を使った動作 (IE10 以降)
* アニメーション開始点(0%)から終了点(100%)までの、どの時点でどう表現するかを指定し、その中間は自動的に補完され、動作は滑らかだ。Flash の指定方法と発想は同じ。補完は、直線的にも曲線的にも選択できる。見本は直線的だが、曲線的な補完を使って指定を工夫すれば、ギクシャクしないスムーズな駅停車も表現できそうだ。
* IE は ver.10 以降に限定される。とはいえ、未対応ブラウザでは静止画になるだけで、ページデザインが乱れるわけではない。Progressive Enhancement(最新ブラウザでは高度な表現、古いブラウザでは最低限の表現をするウェブデザインの手法)には有用。
* JavaScript 不要だが、Script と組み合わせることで、更に高度な表現が可能になるようだ。

 
●Canvas/inline SVG

終焉した Flash に変わって、多様な表現の主流に躍り出たのが、HTML5 + CSS3 で追加された Canvas や inline SVG。どちらもテキストとして記述され、動かすのは JavaScript
* Canvas(2D)は、ウェブページ上に専用の描画スペースを設定する機能。そこに JavaScript で絵を描く。
* SVG は、Scalable Vector Graphics の略。画像ファイル(拡張子 .svg)もあるが、ウェブページ上に直接記述できるのが inline SVG だ。Canvas と違い、静止画なら JavaScript は不要。
* GIF や PNG などのバイナリの画像ファイルではなく、テキストで記述されたものがブラウザ上で画像に変換される。テキストだからこそ、画像そのものを JavaScript で制御できてしまうのが特徴で、画像の変形や色置換といったことも可能になる

名称 Canvas inline SVG
記述 テキスト形式でコードを書く
画像形式 ピクセル(ラスター)形式 ベクトル形式
静止画 JavaScript で描画 タグ指定だけで描画
動画 JavaScript で再描画くりかえし JavaScript で変形(移動を含む)
非対応 ×IE8以前* ×IE8以前/Android 2.x以前

* IE8以前でも、専用のライブラリを読込ませることで Canvas 表現は可能になるとか。


↑ Canvas を使った描画と走行 (IE9 以降)
* Canvas ならではの高度な表現をほとんど使っていないが、テキストから画像を生成する Canvas の特性を活かした、車体色をボタンで変更する機能は付けてみた。
* 手書きのコーディング(テキスト・エディタで直接、座標等を記述)なので手抜き。Canvas はベジェ曲線も指定可能だから、山も丸くしたかったが、このシーンを作った時点ではノウハウ不足でカクカクした直線のみ。半透明化もできるので、車輌に窓も付けるべきだが、それもなし。
* GIF や PNG を読込むことも可能だが、Canvas ならではの高度な表現と組み合わせるのでなければ、通常画像を使う意味がない。
* Canvas の動画は、動かしたいものだけを動かすのではなく、全てを描画しなおす。動かしたい個所だけを動かす電車走行キット的なコードに慣れた感覚だと、けっこう違和感がある。
* Firefox と Chrome では、Canvas で生成した画像を png(静止画)として保存できる。
[ Canvasを使ったシーン ]
* No.1580 は、動く Canvasを背景に使用。直上のサンプルと異なり、ベジェ曲線も使用してみた。ちなみに、このシーンは IE と 旧Edge では表示不可。動作はするが、半透明の色指定が再現されないため、表示させない設定にした。


↑ inline SVG を使った描画と走行 (IE9 以降)
* これまた inline SVG ならではの高度な表現はまるでなし。車体色変更ボタンはあり。
* 上の Canvas シーンと同一の座標数値を指定しているため、ほとんど同じ風景。ただ、見た目は同じでも中身はまるで違う。
* inline SVG の動画は、Canvas と異なり、動かしたいものだけを動かす。電車走行キット的な感覚では、最初はこちらの方がやりやすく感じたが、あれこれ試してみたところ、Canvas より手強い面もある。ゲームを作っている人のブログ等を読んでも、SVG より Canvas の方が動くものには使いやすいそうだ。
* IE11 と 旧Edge では、inline SVG で生成した画像を svgファイル(静止画)として保存できる。
[ SVGを使ったシーン ]
* No.1576 は、背景画が SVG。但し、インラインではなく、LibreOffice Draw で描いた SVGファイル。高精細モニタで見ると違いが分かる。だが、車輌が GIFのままなので、高精細モニタではギザギザのない風景とギザギザ感のある車輛とのギャップが目立つ。
* No.1577 は、背景画と時計がインラインSVG。時計のように動かすものは、インラインでないと都合が悪い。これも、車輌が GIFなので精度のギャップがある。

ネット上にある数々の使用例を見ると、かなり高度なことが可能。しかし、高度なことをやろうとするほどコードを書くのが難しくなる。もっとも、作成ソフトも一応あるようなので、それを使えば多少楽にはなるだろう。
* 上のおぱく堂見本のように、テキスト・エディタで手書きすれば、専用ソフトを買わずに済み、安上がりである。しかし、単純な図形でお茶を濁すのではなく、ちゃんとした鉄道車輌を描こうとすると、かなり大変だ。手書きでは座標の数値を記述しなければいけないのだが、その座標を調べるために、一旦、描画ソフトで絵を描いてみないといけない。その画像をそのまま使って鉄道シーンを作った方がよほど楽で、かなり、バカバカしい話だ。だから、専用ソフトを使わないのであれば、この方法で鉄道シーンを作る意味はないと思う。

[ 余談・VRML ]
* コードを記述してパソコンに描画させるものとして、今は完全に衰退した VRML(Virtual Reality Modeling Language = ウェブページ上に 3D世界を作ることのできる言語)を思い出す。1990年代は、VRMLプラグインはブラウザ標準装備だったが、それも遠い過去になった。 おぱく堂もかつて VRML にハマり、その時に描いた「能楽堂」の 3D画像を No.236 の背景に使っている。前面の能面と、能楽堂の鏡板に貼り付けた松のテクスチャの2つだけは通常の画像だが、能楽堂本体は、座標を手書きで入力したものだ。その作品のスクリーンショット数枚とコードを表示したものが No.1591 になる。……さらに言えば、上右フレームにある「おぱく堂顔」も基本は VRML で描いた 3D画像である。あの頃は、ちゃんとした専用ツールもなく、手間のわりに大した結果にならなかったから普及はしなかったが、Canvas や inline SVG はそこそこ普及するだろう。とはいえ、個人の鉄道趣味のツールとしてはハードルがやや高いと思う。
* 今は、2D の Canvas 上に、3D-CG をレンダリングして表現してしまう WebGL という技術(後述)がある。プラグインがなくても、ブラウザだけで表現できてしまうのが、さすが HTML5 時代の産物だが、一定以上のハードウェア性能が要求されるのと、ブラウザ間の互換性が完全ではないという問題がある。とはいえ、WebGL の 3D 表現能力は凄いとしか言いようがない。VRML が完全に過去のものになったと実感すると同時に、Canvas を使えばとんでもない高度な表現が可能だということを知ることができる。

 
●WebGL

ウェブブラウザ上で、高度な3D表現を可能にする技術。大は小を兼ねるので、2Dシーンも作れる。
* Canvas上に JavaScriptで描画する。前述の通常の Canvas描画(=Context2D)と似て非なるもの。


↑ WebGL を使った2D描画と走行 (IE9 以降)
* WebGLは、高度な 3D表現のためにある。それなのに、こんな低レベルな 2D表現に使うのは無駄。300km/h以上で走行可能なランボルギーニにわざわざ乗って、徒歩や自転車で十分な 100m先のコンビニに買い物に行くようなもの。
* 素の WebGLは難しすぎるので、簡単な記述で3D表現を可能にする代表的なライブラリ「Three.js」を使用。それでも、自分には 3Dは難しすぎる。
* CSSにしろ、Canvasにしろ、SVGにしろ、左上が座標 X:0 Y:0 の基点。一方で、WebGLはシーン中央が XYZ3軸のゼロ座標なので、感覚的にも分かりづらい。
* テキスト表現が難しいので、「Drawn with WebGL」の文字は入れられなかった。その代わり、小さな立方体を回転させて、本当は 3D用の技術であることを表現した。
* この見本は、風景だけではなく車両も WebGLで描いているが、右下の立方体以外はすべて 2Dオブジェクトで構成。
[ WebGLを使ったシーン ]
* No.1578 は、簡単すぎるが一応 3D風景。UFOの移動にあわせて光源を移動させている。
* No.1579 は、WebGLによる安直な2D風景。但し、このページ直上の見本と異なり、このシーンは 3D立体オブジェクトを 2Dに見えるように並べた上で、環境光源のみを使って立体感を消したもの。
* 同じ WebGLなのに、IE11では後者は問題なく表示され、前者はエラーになる。前者のどこが IE非対応なのか、ちょっと調べたが全く分からなかった。


●Java (Applet)×過去の走行手段)

かつて、ダイナミックHTMLも Marqueeもなかった時代があった。
その頃にウェブページ上で動画を扱う手段は「Java」しかなかった。書店のインターネット関連書籍のコーナーには、時代の最先端としての Java に関する書物が溢れていた…。昔話である。
* 蛇足ながら、Java と JavaScript は別物である。
* その後、書店から Java に関する書物が激減したが、再び増えてきた。理由は追記として後述。

鉄道側面画の黎明期(TSV規格やTB規格が生まれた頃)は、そんな時代であった。
Javaは本格的プログラム言語なので可能性は高いのだが、当時、一般に流通していたものは簡単なスクローラ(Marquee と同じ程度のことしかできないもの)だけで、それでも鉄道車輌を走行させられるのは画期的だった。それゆえ、TSV画像配布サイトでは、ウェブ上での見本走行用に Java を使っている例が多々見られたものだ。
* Marqueeが登場した頃は、まだ Marquee非対応の NetscapeがシェアNo.1だったし、ダイナミックHTMLもどうやって使うのかという情報が不足していて当初は(今でも?)普及は進まなかった。それゆえに、Javaによる鉄道シーンは MarqueeやダイナミックHTMLが登場したからといって急に過去のものになったわけではなかった。

その後、簡単なスクローラ程度の表現は Marqueeにとってかわられ、そこそこの事は JavaScriptで可能になり、凝った表現のツールとして Flashが普及した。そんなこんなで Java(をブラウザ上で動作させる Applet)を見る機会は大いに減ってしまい、鉄道側面画用ツールとしては消えてしまった
* Javaは本格的プログラムであり、Flashでも出来なかったような高度なことが可能である。ということで鉄道関連の Java をインターネット上で探してみると「3Dの鉄道シーンをウェブ上に再現する Applet」なんていうものがあった。やはり、非常に高度な世界では Javaは生きていた。だが、Java プラグインがブラウザに標準装備でなくなってしまったので、ウェブ用としては、もはや有用な表現ツールではない。

その後、主要ブラウザである Chrome (ver.42〜)や Firefox (ver.52〜) が、Java Applet への対応を止めてしまい、ウェブ表現用としての Java は完全に終わった。
* Edge や Safari に関しては分からないが、おそらくは既に対応終了になっていると思われる。
* 一方で 、Android アプリが Java で記述されることから、Java 自体は廃れたわけではなさそうだ。


●動画GIF

車輌も風景もまとめて、一枚の動画のGIF画像にしてしまう手法もある。
HTMLや CSSの知識も不要で、ある意味では最も手軽な方法かもしれないし、走行以外の要素をシーン中に持ち込むのも簡易なので、表現の幅も広い。

だが、走行シーン用としては問題もある。
リンクバナーぐらいの極小サイズならともかく、それなりの面積の鉄道シーンで列車をスムーズに動かそうとすると、フレーム数(コマ数)が、ものすごい数になる。結果として、画像容量が重くなり、サーバー容量も食う。さらに言えば、膨大なフレーム数の動画作成は、うんざりするほど大変な作業だ。
* 作業を軽減してくれる機能のある描画ソフトも、あるいは存在するかもしれないが…。

Powered by Animated GIF
↑ 動画GIF による風景と車輌の一体画像
* 25フレームの動画だが、走りはギクシャク。上の Marquee 見本と同じスムーズ動作を実現するためには 10倍の 250フレームも必要になり、作業的にも容量的にも非現実的。
* ちなみに、他の手段では車輌と風景を合わせた画像容量の総計が 7KBなのだが、これは 32色まで減色して容量を減らしているにもかかわらず、22KB。このページ最初にある Flashシーンでも、これより軽い 19KBなのだ。この見本ではこれしか差はつかないが、絵柄によってはかなりの容量になってしまう可能性がある。

もうひとつの問題は、車輌と風景をあわせて 256色以内という色数の制約だ。
見本のような階調変化の小さい風景なら問題はないが、階調変化の大きい風景を使うには色数が足りない。シーンのクオリティ追求に限界があるのだ。
* とはいえ、画像寸法が小さければ、このような問題は重要ではなく、TB規格などでは有効な表現手段ではある。動画GIF表現の実例は「TBシーン画像」ページ参照。


●動画PNG

上の動画GIFと同じ手法だが、こちらはPNG。
GIFと違って色数の制約がなく、24bit フルカラーと半透明アルファチャンネルが使えるのがメリット。
以前は対応しているブラウザが限定されていたので使いづらかったが、現行ブラウザはすべて対応している。
* 非対応ブラウザで見ると、ただの静止画(最初のフレームのみ表示)となる。
* 対応しているブラウザは、Firefox と Safari、Chrome 59以降、及び Chromium化した後の Edge。
* Firefox 以外のブラウザが対応せずに忘れられた存在だったが、Mac や iPhone 標準ブラウザの Safari が対応したことで流れが変わり、遂に Chrome も対応。Windows 標準の Edge も Chromium化して対応。動画PNGを問題なく使える環境が整った。

Powered by Animated PNG
↑ 動画PNG による風景と車輌の一体画像 (Firefox / Safari / Chrome)
* 上の GIF と同じ絵、同じ 25フレーム。ゆえに、動画PNG ならではの、フルカラーや半透明などを一切使っていない見本。GIF の 22KBに対して、PNG は 14KB。
* この画像形式の存在を知ったのは、深谷さんのサイトで使われていたのを見て。なんか色々と、他の方のサイトを見て初めて知ることが多い。おぱく堂は、ウェブに関して勉強不足なわけね。いいのか、それで?
* 2016年初夏時点では、動画PNGを作れるソフトは非常に少ない。おぱく堂が使ったのは「APNG Assembler 2.9」という英語版のフリーソフト。


●結局のところ…

簡単な鉄道シーンなら、Marquee。
凝った鉄道シーンなら、JavaScript(=電車走行キット
……という現実を、あらためて確認しただけであった。
一方で、高度な鉄道シーンは、過去には Flash だったが、今は Canvas (HTML5 + CSS3) か。
* 鉄道側面画走行という目的に限れば、現実的な選択肢はこれぐらいのものだろう。
* HTML5 の表現力の凄さには驚くが、使いこなす難しさと、ブラウザ間の互換性の問題があるようなので、鉄道シーン表現ツールとしては未知数ではある。とはいえ、高度な表現を試みようとすれば、今後はそれしか選択肢がないのではないかとも思われる。


……電車走行キットという走行手段の本家が、他の方法について研究する意味は何か。
日本をよく知るためには、外国を知ることである。内側からだけでは見えないことが、外からなら見えることがあるし、比較して初めて分かることも多いからだ。同じく、他の走行手段を知ることで、電車走行キットで出来ること出来ないことが明確になる。今回は「電車走行キットに出来ないことを、Flashでどこまで出来るのか」という好奇心からスタートしたわけだが、Marquee や HTML+Time も試すことで「Web Railroad(ウェブ上での鉄道/模型鉄道=Model Railroad をもじった表現)」の全体像も見えた。

自分は電車走行キット開発元であるから、他の手段を使って鉄道シーンを作ることもないし、自分の描いた画像を他の手段で使うことも許可はしていない(TB規格を除く)。しかし、鉄道側面画を趣味とする人々一般にとって、走行させる手段はあくまで手段でしかないのであって「どんな鉄道シーンをどう見せるのか」によって、それぞれ最適な手段はあろうということである。その選択結果が電車走行キットでないとか TK規格車輌じゃないからといって文句を言いたいわけではなく、簡単な Marquee でいいから車輌と風景を組み合わせてウェブ上に鉄道シーンを作ってみよう、という話である。そうやって、鉄道側面画による Web Railroad の世界が広がれば、自ずと電車走行キットの世界も広がるだろうし(結局それかい!)……まぁ、なんというか、そういうことである。


<< 前頁へ戻る