Tokyo Railways ユーザー報告用ページ

　Tokyo Railways のユーザーが投稿できるページを作成しました。
　ご感想・ご要望・障害報告等、なんでもご投稿ください。
　投稿方法については、向こうのページをご覧ください。

開発：Tokyo Railways 2

　今月に入ってから、「Tokyo Railways コンピュータ版」の次期メジャーバージョンアップ版、「Tokyo Railways 2」の開発を進めています。とはいえ、まだなかなかテンションが上がらず、まだお見せできるような機能できてないので、オープニングの画像だけお見せします。
　「2」のリリースはまだまだ数ヶ月先の予定ですので、今月にリリースする次期バージョンは、現行のv1.xx系となります。次期バージョンはバグフィックスと新マップの追加が中心となります。
　「2」の方の新機能は以下の３つがメインとなる予定。
　　１）ネットワーク対戦機能
　　　　　この機能の目的は、複数のパソコンをつなぐことで、同時に多人数で遊んでもらえる環境を作ることです。
　　　　　インターネット越しではなくって、LAN内での対戦を前提とした機能です。ルーターなどの設定をいじれば、インターネット越しに対戦することも不可能ではないですが、基本的にはLAN内での接続を前提とします。手軽にインターネット越しに対戦できる機能は将来の課題とします。

　　２）地形グラフィックの大幅変更
　　　　　この機能の目的は、グラフックのインパクトを強めて、多くの方にこのゲームをアピールすることです。
　　　　　地形をもうちょっと立体感のあるグラフィックに差し替えます。今のグラフィックも設定変更すれば選べるようにします。追加のグラフィックセットを用意すれば、別の地形グラフィックに切り替えられるようにします。

　　３）キャンペーンシナリオ機能の追加
　　　　　この機能の目的は、より多くのマップを遊んでもらって、多様なマップの面白さを知ってもらうことです。
　　　　　８つ程度のマップから構成されるキャンペーンシナリオを用意します。
　　　　　標準のキャンペーンは日本をテーマとしたものと世界をテーマにしたものの２つ。
　　　　　世界を舞台にしたマップはまだ４つしかないので、今後のリリースで更に４つ追加する予定です。
　　　　　追加マップの方もあと５つ追加して、２本のキャンペーンを用意する予定です。
　　　　　キャンペーンでは１つずつマップをプレイしていき、１位となったらそのマップをクリアして次のマップに挑戦するという形式で、すべてのマップのクリアまでに何回プレイしたかを競うものとなります。
　　　　　
　今は１）の開発を始めているのですが、まだ通信そのもののプログラミングまで進んでなくって、接続前のいろんな画面の作成をやってます。画面の作成は単純作業が多くって、ちょっとテンションが上がらないのですが、もうちょっと気合を入れて開発を進めていこうと思いますので、応援をよろしくお願いします。

　今後、開発が進んだら、随時情報をアップしていきます。

　でも、そろそろ「２」の開発を一時中断して、今月のリリースの準備を始めないといけないかな・・・

アグリコラ その２ １人用ゲームの戦略

　ボードゲーム「アグリコラ」の話の２回目です。今日の話は、「アグリコラ」の１人用ゲームの戦略についてです。
　実は、この「アグリコラ」の１人用ゲームはよくできていて、私はすっかりハマリこんでしまっています。
　先日アップしたときには、まだ開封したばかりでルールをざっと読んで１人用プレイを２回くらいやってみただけだったんですが、あの後何回か１人用ゲームをやってみて、勝ったり負けたりしているうちに、ようやくコツをつかみました。５０点とれば勝利のところで１回目に６１点、続けて１枚の職業カードを残してプレイする２回目で７０点を稼げるところまで上達しました。といってもまだエントリーカードしか使ったことがないんですけどね。

　何回か負けてるうちに気がついたのですが、アグリコラは基本的に職業カード・小さな進歩カードはデッキが３種類ある上に、毎回登場するカードは変わるし、ラウンドカードの出てくる順番によっても戦略は変わってくるのですが、１人用ゲームにはハッキリとした定石が存在します。今回はその定石を紹介します。

　まずは第１～４ラウンドの第１ステージですが、このステージ中に木と葦を確保しておく必要があります。なぜなら第２ステージにはやることがいっぱいあって、第１ステージ中にできることはさっさとやっておかないと、間に合わないからです。
　また、第１ステージに麦を植えておくと、第４ステージで野菜を植えることで、最後の第６ステージに３回目の種まきをするチャンスがあるので、ここでできるか限り麦の種をまいておければ、だいぶ楽になります。
　セオリーとしては、第１ラウンドのアクションは「職業」と「日雇い労働者」、第２は「小麦１を取る」と「畑１を耕す」、第３は「葦」と「種を播く」（ここで「種を播く」が出ていなければ「木」）、第４は「漁」と「木」（すでに木を取っていれば「種を播く」）。小さな進歩カードや職業カードの内容によっては、小麦を植えることをあきらめて、種付けまでの３アクションを別のアクションにまわすことも考えられます。

　第５～７ラウンドの第２ステージは、家族が２人のままだと６アクションしかないのですが、このステージ中に以下のことをやらなきゃなりません。「増築」、「家族を増やす」、「レンガ」、「大きな進歩」（かまどか調理場を確保）、「羊」（家の中に一匹だけ残してあとは全部食料にする）、ここまでで５アクション。できる限り早く家族を増やせれば、こなせるアクション数が多くなってだいぶ楽になりますが、もし「家族を増やす」の登場が第７ラウンドになった場合、第３ラウンド中の残りのアクション数は１つしかないので、注意が必要です。また、もし手順やカードの事情でレンガが十分にあまっていて、レンガの家に改築とかまどや調理場の確保が同時にできる状況なら一気にレンガの家に改築しまえば、「改築」ついでに「大きな進歩」も実行できるので、両方を一度に手に入れられます。

　第８ラウンド以降の第３～６ステージは、職業カードや小さな進歩カードの内容によって、かなり展開が変わってくるので、ステージごとの手順は書きませんが、以下のことに留意した方がいいです。
　１）家族を早く増やせるとそれだけ展開が楽になる。早めに増築して早く家族を増やすこと。
　２）作物は次に種まきするタイミングが重なるように種を播く。第３ステージは小麦を植え、第４ステージは野菜を植える。そうすると両方とも第５ステージの収穫ですべての収穫が終わり、第６ステージに一気に両方の畑に種を播ける。
　３）第５ステージに増築せずにできる「家族を増やす」アクションが登場するが、なるべくこれは使わないように早めに５部屋まで増築したほうがいい。
　　　なぜなら、最終的に増築したほうが点が高いし、第２ステージに登場する「家族を増やす」アクションなら、同時に「小さい進歩」も出せるので、手順がお得である。
　４）空き地を残すぐらいなら牧場にすべき。柵は一回で何本でもつくれるので、最後に大量に「木」をとってから「柵」をつくれば、空き地を一気に埋められる。さらに「猪」と「牛」をとれれば、一気に高得点が狙える。最後ラウンドにはこれ以外に種まきもやりたいはずなので、これを考えて、最終ラウンドには十分なアクションが残っているように注意する。可能なら前のラウンドで木を取っておくとよい。
　５）後でもう一回とるつもりの資源なら、１回目は必要以上にたまるまで待つ必要はない。早く取れば、次のときにより多く取れるだけのことである。
　６）効果が薄い職業や小さい進歩カードを無理して使う必要はない。たとえば木が余計に１本とれる「きこり」などは、どうせ木を取る回数なんて、１ゲーム中に２～３回くらいなんだから、１アクションと食料１個を木２・３本と取り替えることが本当に必要なのか考えたほうがいい。効果の高い小さい進歩カードの中には職業の枚数が条件になっているものがあるので、そういうカードがある時には多少効果が薄い職業カードも積極的に使うべき。

　長々と書いてしまいましたが、実際にプレイするときに参考にしてください。
　ちなみにこの戦略はあくまで１人用ゲーム用です。２人以上は相手がいるので、ぜんぜん通用しません。
　さて、まだ私はこのゲームを買って数日なので、１人用しかしたことがないのだが、２人以上で遊べるのはいつになることやら。今月中には１・２回くらい遊ぶ予定なので、その時には感想をアップします。

↓の評価ボタンを押してランキングをチェック！

アグリコラ

　ボードゲーム「アグリコラ」の日本語版を買いました。このゲーム１人から５人まででプレイ可能で、中世ヨーロッパの農家を題材にしたゲームで、ファン投票で選ばれるドイツゲーム賞の2008年１位を獲得した作品です。
ゲームの内容としては、いろんな仕事をこなしながらいろんな資源や職業などを獲得し、だんだんと畑・家畜を増やし、家を増築して家族を増やし、いろんな職業や技術を憶え、家の設備や家そのものを豪華にして豊かな生活を築こうというゲームのようです。
　十数種類・300個以上の木の駒と、100枚くらいの厚紙の駒、９枚のゲームボード、360枚のカードと、とんでもない量のコンポーネントが出てきて、ルールも沢山あるヘビーなゲームです。
　ゲームはルールが簡単で「仕事カード」と「小さい進歩カード」を使わないファミリーゲームと、「仕事カード」と「小さい進歩カード」を使うメインゲームの２種類に分かれています。さらにメインゲームでは複雑さの異なる３種類のカードのどれかを選んでゲームします。また人数によって使うカードが異なるため、かなりのバリエーションがあります。
　これだけヘビーなゲームなのでプレイ時間がかかりそうですが、一応、ゲームブックには１人につき３０分と書いてあります。つまり５人なら２時間半ということらしいです。でも最初はそんなに早くは行かないと思います。さっき１人プレイルールで１ゲームだけ遊んでみたら１時間以上かかりました。ちなみに１人プレイルールではだんだんとハードルが高くなる条件で８ゲームをクリアしてやっと勝利だそうです。そうすると１人プレイは慣れても４時間かかることになりますねえ（苦笑）。
　ちょっとルールが多くって憶えるのが大変そうなゲームですが、その対策として１人プレイのルールとか、初心者用ルールのファミリーゲームとか、難易度別のカードセットとかいろんな工夫がしてあって、無理なく憶えられるように工夫してあるようです。

　今度、仲間と遊んでみたら、その感想を加えてまた紹介します。

↓の評価ボタンを押してランキングをチェック！

またまたハードディスククラッシュ

　先月後半にMac miniのHDDクラッシュで交換作業を強いられたばかりだというのに、昨日にもまた別のHDDクラッシュが発生。今度壊れたのはBuffaloのLink Stationというネットワークハードディスク。この機械はただのディスクではなくって、チューナーとつなぐとテレビの録画をできるという機能があって、私は普段はこれでテレビ番組を録画して、LAN越しにPCから見ているのですが、おとといから妙な音がするようになり、昨日になってコピー作業中にディスクが認識しなくなっちゃいました。
　仕方がないから代わりを探しにいきましたが、いまどきアナログチューナーと連携できるモデルはすでに家電量販店の店頭からは姿を消しているようです。かといって、我が家は東京タワーを背後にした斜面にあるので、地デジ未対応の中継局から電波を受けていて、代わりの中継局ができる来年３月くらいまではTVK以外は地デジが映らない。しかたがないので、後で自分の手でなんとかハードディスクを交換してファームウェアをインストールして、Link Stationを復活させることにして、当面はUbuntuが動いているMac miniでVMware Playerを使ってWin XPを動かして、これで録画するという急場しのぎの策で乗り切ることにしました。
　で、毎日Link Stationのデータをバックアップしていた外付けHDDをオリジナルに変えて、あまってた別のディスクのデータを消してこっちをバックアップに回すということになり、データ消去作業だの、コピー作業だの面倒で時間のかかる作業が目白押し。

　・・・なんか最近こんなことばっかりやっているけど、なにかの呪いでしょうか。

FC町田ゼルビア 対 ソニー仙台戦

　今年のゼルビアの試合も残すところ、あと４試合、ホーム試合は２試合だけです。
　今日のゼルビアのホームゲームは、現在６位のゼルビアから勝ち点３差の５位に位置するソニー仙台との直接対決です。もちろん観戦してきました。今日、５位に浮上するためには３点差以上で勝つ必要があります。
　試合の方は立ち上がり１分くらいで、ゼルビアがソニーゴールに殺到、怒涛の攻撃の末に御給選手のゴールで先制！しかし、ソニー仙台は徐々に調子をつかんできて、やがて一方的にゼルビアゴールに攻めかかってきますが、ゼルビアの守護神・修業選手の好セーブを連発してなんとかリードを守り続けます。
　しかし、前半終了間際、ソニーは波状攻撃でとうとう修業選手をかわしてゴール。１－１の同点で前半終了。

　後半は両チームとも相手ゴールを激しく攻める展開となりますが、互いに決定的なチャンスを逃し続け、結局１－１のまま試合終了で引き分け。

　今日のゼルビアは、いつものようなサイドから突破する機会が少なくって、センターに打ち込んで一気にゴールを狙う展開が多かった気がします。むしろ、ソニー仙台の方が両サイドを突破してくる攻撃が目立ちました。また、今日のゼルビアはいつものようなパス回しでの攻撃があまり見られず、これもソニー仙台の方が多かった気がします。
　両チームとも似たような攻撃パターンのチームということもあるのかもしれませんが、今日は津田選手のサイド突破があまり見られず、後半早々に森川選手と交代してしまったのをみて、津田選手のコンディションが悪かったのではないかとちょっと心配しました。

　次のホームゲームはホーム最終戦です。最後はスカッと勝ってほしいものです。

↓の評価ボタンを押してランキングをチェック！

アップデート：相模原追加マップ

　Tokyo Railwaysコンピュータ版の追加マップ・相模原をアップデートしました。
　修正点はこのコメントでpumpCurryさんからご指摘を受けた盤外接続・青山の矢印の方向が逆になっている点です。
　見た目以外はゲーム上関係ないですが、気になる方はダウンロードして入れ替えてください。

JLayerとUbuntu 9.10のOpenJDK+PulseAudioの相性問題

　相変わらず「Tokyo Railwaysコンピュータ版」の障害対応をやってます。
　今日片付けた問題は、先日リリースされたばかりのUbuntu 9.10上で「Tokyo Railwaysコンピュータ版」の音がならなくなるという問題。先日アップした「Ubuntu 9.10にアップグレード」という記事の中でちょっとだけ触れた話です。
　この問題は実は調査した結果、私の環境では起きるけど、「Tokyo Railways コンピュータ版」をダウンロードしてそのままUbuntu 9.10で使っている分にはおそらく起きないだろうという結論になってます。私の環境とダウンロードしてそのままの環境で何が違うのかというと、私のUbuntu環境ではBGMにMP3ファイルを使っているが、ダウンロードしてそのままの環境ならBGMはMIDIファイルを使っているはずという点です。この障害はBGMにMP3を使って、Ubuntu 9.10の環境で「Tokyo Railways コンピュータ版」を実行しない限り発生しないと思います。なぜなら、この現象はMP3ファイルの再生に使っているオープンソースの「JLayer」というライブラリーの内部でBGMの切り替え時に発生してるからです。また、Ubuntu 9.04まではこの現象は発生していなかったので、Ubuntu 9.10とJLayerの相性に起因しているようです。
　調査した結果、問題の現象は以下の２つに分かれます。

　(1)MP3のBGMの切り替えが数秒間遅れることがある。
　(2)MP3のBGMの切り替え時に以後ずっと音がならなくなることがある。

　まず(1)を調べてみると、JLayerフレームワークに含まれているjavazoom.jl.player.Playerというクラスの、isComplete()というメソッドが通常の環境では即時復帰してくれるのに、Ubntu 9.10環境では10秒程度復帰しない場合があるというものでした。実は「Tokyo Railways コンピュータ版」のBGM再生処理では、isComplete()と500ミリ秒のスリープを繰り返しながらループしていて、BGMが完了したかどうかをisComplete()でチェックし、もし完了していたら再度再生することで、エンドレス再生を行ってます。また、isComplete()の直後のタイミングでBGMの停止や切り替えもチェックしています。だからisComplete()で待たされると、BGMの停止や切り替えも遅れるわけです。
　これの対策は比較的容易で、isComplete()を使用せずに自前でフラグを用意して曲の終了をチェックすれば解決です。なぜこれが容易かというと、実はPlayerクラスのplay()というメソッドでMP3を再生しているのですが、このメソッドが演奏が完了するまで復帰してくれないので、その対策として自前でスレッドを作って管理しているので、このスレッドの処理内でplay()の前後でフラグを制御すれば、演奏中かどうかは容易にチェックできるわけです。

　さて、残るは(2)だけなんですが、これの回避策を見つけるのはかなり面倒でした。(2)の問題はエラー出力に出てくるログを見て判断すると、BGMの演奏が終了するタイミングでPlayerクラスのclose()メソッドを使ってBGMを停止しようとすると、Ubuntu 9.10環境ではJLayerがOpenJDK経由でPulseAudioというLinux環境で使われてるサウンドサーバーにサウンドを停止させにいくようなんですが、Ubuntu 9.10環境のPulseAudioではこのタイミングで例外が発生するケースがあるようです。しかもその例外に対するJLayerの処理になにか問題がある様で、なんとまあclose()メソッドが永遠に復帰せずに、以降JLayer内部でなにか排他が開放されなくなる状態となり、結局ハングアップしてしまうようです。
　これは明らかにJLayerのPlayerクラスのclose()メソッドのバグなわけで、問題を回避するにはPlayerクラスのclose()を使わずにBGMを停止する必要があります。で、いろいろと試したのですが、結局うまく言った方法は、Playerクラスのインスタンスを生成する時に、コンストラクターに渡しているMP3ファイルのInputStreamを別途保存しておいて、BGMを止めたいときにはこのInputStreamのclose()を呼んで、MP3ファイルの読み込みを停止してしまえばよいみたいです。この方法で試してみたら、PulseAudioの例外は発生しなくなって、JLayerはハングアップしなくなりました。

　さて、この方法、確かにUbuntu 9.10では有効のようですが、他の環境では何か副作用は出ないのかと言う点がちょっと心配です。たぶん大丈夫だと思うのですが、原因が環境の相性問題だったんで、いろんな環境で一通りテストしてみる必要がありますねえ。
　ただ、いろんなの環境って言っても、いくつあるのだろうか。OSの種類とJavaの種類の組み合わせで考えると、簡単に10種類を越えちゃいますねえ。私が用意できる環境で数えると、11種類もある。うーん、まだまだ完全解決までにはちょっとかかりそうですねえ・・・

Tokyo Railways コンピュータ版のバグ修正

　昨日と今日は「Tokyo Railways コンピュータ版」の障害修正を集中的にやってます。特に今日は、先日にpumpCurryさんがたくさん報告してくれた件をまとめて直していて、コメントにあった２、３、４、８、９をつぶしました。
　この中で一番苦労したのが３番。コメントにあった「保存後読み込み直した時「プレイヤーさんの番です」と出たあと、なにかのはずみでフェイズが１つ進む時があります」というやつです。これは最初は「プレイヤーさんの番です」というダイアログの閉じるボタンのクリックイベントが２回以上入っておきているのだと思ったが、実は違っていた。ダイアログボタンの閉じるボタンのクリックイベントでは、ダイアログを閉じる以上のことは何一つやってなかった。連打はこの問題を引き起こす状態を作り出しやすいが、かならずしもボタンの連打とは関係ない現象だった。
　データをロードしたときの処理は、実は通常のセーブデータと自動セーブデータではちょっとだけ違っている。
　通常のセーブは移動フェイズか建設フェイズで行われるが、自動セーブデータはターン終了フェイズというタイミングでやっている。通常セーブしたデータをロードすると、セーブしたときのフェイズの初期処理をやってから、途中の状態の操作を再実行している。だが自動セーブデータの場合、通常セーブの処理の前にターン終了フェイズを完了させてターンを進行させている。問題の核心は、フェイズの初期処理とフェイズの終了処理はいずれもロード処理とは別のスレッドを作成して実行している点にあった。
　つまり、自動セーブデータのロード処理では以下の２つのスレッドを順番に実行している。
　　(1)ターン終了フェイズの終了処理スレッドの生成・実行
　　(2)現在のフェイズの初期処理スレッドの生成・実行
　この中で(1)のスレッドは非常に処理が短く終わり、(1)と(2)の間の処理は少しだけ重たい処理なので、通常ならば(2)が始まる前に(1)が終わる。つまり(1)のターン終了処理で次のターンに進んで、次のターンプレイヤーの移動処理の初期処理が走る。
　ところが、何らかの理由で(1)で生成されたスレッドが実行される前に(2)が始まってしまう場合がある。その場合には、(2)の現在のフェイズがまだターン終了フェイズのままだったりする。このとき、ターン終了フェイズの初期処理はもう一度データの自動セーブを行った後、そのまま現在のフェイズの終了処理を行ってしまう。そうすると、フェイズ終了処理が２回行われ、２度目の処理の時にはすでに移動フェイズに進んでいて、移動フェイズの終了処理が走ってしまっていた。
　この現象を起こす何らかの理由としては、沢山のスレッドを生成・実行している時というのが一番考えられるが、実はマウスクリック処理は、仕組上、クリックのたびにスレッドを生成・実行している。だからマウスクリックを連打すると沢山のスレッドが生成されてその順番待ちが発生し、(1)で生成されたスレッドの実行が遅れて、(2)に先に到達してしまうのだと思う。
　この現象はCPUコア数が少なければ発生しやすく、シングルコアのPCが一番発生しやすいと思うのだが、実は開発やテスト環境のPCはすべて２つ以上のコアをつんでたりする。だから私が発見できなかったのだと思う。
　で、対策なのだが、実は自動セーブデータのロードの際には(1)の処理は必要なのだが、(2)はいらなかったのだ。だから(2)をスキップすればそれで解決。要するに自動セーブデータと通常セーブデータで条件をきりか分けて処理を分けていたのだが、ちゃんと切り分けきれてなかったというだけの問題だった。それが、こんなスレッドがらみの面倒な不具合につながっていたとはちょっと最初はわからなかった。

　なにはともあれ、解決できてよかった。この問題を報告してくれたpumpCurry様に改めて感謝します。

　

Windows XP Mode

Windows 7に乗り換えてから３日目ですが、なかなか快調です。今日はWindows 7の目玉の一つ、Windows XP Modeを入れてみたので、これについて書いてみます。
まずは、Windows XP Mode(以下はXP Modeと略します)っていうのは何かというと、仮想PCソフトであるVirtual PC用のXP環境です。通常は、Virtual PCやVMwareのような仮想PC上でWindows XPを動作させる場合、その仮想PC用のライセンスを別途用意してインストールする必要があります。ところがWindows 7のProfessional/Ultimate/Enterprise版では、追加のライセンスなしでVirtual PC上でXPを動作させることができる専用のXP環境が用意されてまして、これがXP Modeというわけです。
なぜ、XP Modeが用意されているかというと、Vistaよりはマシになったとはいえ、Windows 7にも互換性の問題があり、Windows XPでしか動かないソフトが存在していて、こうしたソフトをWindows 7のPCで共存できるようにするためです。
このXP Modeは、インストールCDとは別にダウンロードしてからインストールする必要があります。また、XP ModeはVirtual PC上で動くので、Virtual PCもダウンロードしてインストールする必要があります。ダウンロードや機能の説明はここから行ってください。ちなみにWindows XP Modeは約600MB、Virtual PCの64bit版は約10MBほどのサイズがありました。

さて、前置きはこの辺までにして、それでダウンロードとインストールを終わらせて、XP Modeを動かした後の話に移ります。インストール時にユーザーのパスワードを入力しましたが、ユーザー名はXPMUserで固定されているようでした。
XPのバージョンは以下の画像のとおり。Professional版のSP3です。

仮想PCのメモリは512MBに設定されています。この辺は、Virtual PCの設定画面で変更可能です。
起動したらまず最初に出てきたので、セキュリティ警告。ウィルス対策ソフトがインストールされていないとうの警告です。XP Modeのためにウィルス対策ソフトのライセンスを別途用意するのはもったいないので、無料提供されているMicrosoft Security Essentialsをインストールしました。
それからWindows Updateを実施すると、Microsoft Updateのインストールをはじめとしてたくさんのアップデートが引っかかってきました(下記画像)。この辺は最新になってないみたいです。面倒なので全部適用済みのを用意してほしいのですけどねえ。

Internet Explorerのバージョンは6が入ってました。Microsoft Updateを実施するとIE8のインストールが表示されてきましたが、互換性のためにこの環境を用意しているのなら、IE6のままがいいかなと思い、そのままにしておきました。
タスクマネージャーを開いてみると、CPUのグラフが１つだけ(下の画像)。このPCは8スレッド同時実行可能で、親環境ではCPUグラフが8つ出てきるのですが、XP Modeでは１コア分しか使えないみたいです。ちょっと残念。

さて、これでXP Mode環境ができたものの、とりあえず特に動かしたいソフトもなかったので、私の開発している「Tokyo Railways コンピュータ版」をダウンロードして動かしてみました。もちろん問題なく動きました。

もう特にすることものないので、シャットダウンしよう思ったのですが・・・

なぜか「ログオフ」しかない。
しかしVirtual PCのメニューを見てみると、操作のところに「再起動」とか「閉じる」とかある(下の画像)。で、閉じるを選んでみたのですが、シャットダウンされずに休止状態になってしまいました。

シャットダウンする方法はないのかと調べてみると、ちゃんとありました。まずはメニューのCtrl+Alt+Delを選択すると、おなじみの下の画像のメニューが出てくる。ここからシャットダウンを選択すれば、ちゃんとシャットダウンできる。なんかわかりにくいですねえ。

というわけで、とりあえずXP Modeをインストールして環境を整備しただけでしたが、きょうの話はここまでです。

↓の評価ボタンを押してランキングをチェック！

Tokyo Railways コンピュータ版で画面が乱れる障害

「Tokyo Railways コンピュータ版」のv1.75をリリースする直前にユーザーから寄せられた障害で、この図のように画面が乱れるというものがあります。
発生する環境はかなり限られていて、WindowsやLinuxでは発生しないようで、Macの場合でもMac OS Xの最新バージョン10.6(Snow Leopard)では発生しないようです。つまりMac OS X 10.5に限られてきます。また、図のようにひどい状態になる環境やマップはかなり限られていて、発生しやすいマップは北陸のような横長のマップのようで、さらに画面の解像度が縦800以下では発生しにくいようです。
これだけの条件を並べてわかるように、どうもこれはMac OS X 10.5に付属するJava側の障害という気がするのですが、そうは言ってもなんとか回避しないとユーザーに不便をかける訳で、回避策を調べてみました。
どうもこの問題はイメージの上に別のイメージを上書きする際に、その範囲が重ならない部分があるときにMac OS X 10.5のJava環境が正しく処理できない問題に起因するようです。
仕方がないので次期バージョンでは、上書きするイメージから、上書きされるイメージと重なる範囲を抜き出し、その範囲内だけ上書きするように対処します。
それで申し訳ないのですが、次のバージョンをリリーするまでの間、上記現象を避けるために、Mac OS X 10.5 環境をお使いの人はメニューを出す場所をなるべく真ん中あたりにして、回避していただくようお願いしたいと思います。

これとあわせて、Windows Vistaや7で、ウィンドウサイズが少し小さめになってしまって、よけいなスクロールバーが出てしまう件も抜本的な対応策を見つけたので、次のバージョンで対処される予定です。

次のバージョンは11月下旬リリースを予定しています。