マイコンゲームの本４掲載。動き回るバクテリアを駆逐するゲーム。キャリーラボのバクテリアっぽいですが、ゲーム的には別ゲームです。
投稿者「Takky」のアーカイブ
ナオミちゃん１６
PiO 1984年4月号掲載。１６パズルゲーム。まあ、メジャーなパズルゲームなので説明不要でしょう。この手のパズルの場合、空いているところを中心に動かしますが、動かすキー操作が２系統に分かれると思います。これによって慣れの差が出そうな感じです。
キャラクタのグラフィックだけでここまで描けるのはすごいと思います。2000を使ってるときにK/C並みにキャラグラが扱えないのに悔しい思いをしたことがあります。まあ、その分、グラフィックを駆使すれば何とかなるのですけど、処理も重たくなるし煩雑さも増しますからねぇ。
タッコちゃん
I/O 1983年11月号掲載。タコを操作していくゲーム。キャラが結構多いので慣れる頃には楽しめるかも。
各国言語サポート
vosでは、古くからいろいろな言語サポートがあります。日本語はもちろん、韓国語やギリシャ語など世界各国で使えるようになってます。
業務で使ってるケースでは、デフォルトの英語で使用してました。日本語にするとファイル一覧などでタイムスタンプが出るときに日本語で出力しようとするので、端末によって表示できないケースもあるので設定してないのが現状でした。オンラインドキュメントに日本語サポートがなかったので、英語での利用でも問題なく行えました。細かいところまでローカライズできてないので、あえて日本語にする必要性もないという。
英語がメインでも、日本語表示などはできます。シフトモードという表示コードの切り替わりを示すコードを持ってます。JISコードを使うPCなどで、カナコードの開始を示すのにSI,SOというコードを使うものがありますがそれと同様です。コードが変わる最初に指定するロッキングシフトと文字コードそれぞれに指定するシングルシフトコードがありました。ですので、こういったコードを含むファイルなどを表示するデバイス（端末、プリンタ等）に送り込むと、コードに合わせていろいろな言語を表示できました。
日本語は漢字コードを示すものと、カナコードを示すものが2種類サポートされており、区別しないといけなかったのが面倒でした。ちなみに、漢字コードの場合に使われる文字コードはJISコードにMSBをONにしたものが使われてました。PCにバイナリデータを持ってきたときは、シングルシフトコードを取り除き、漢字２バイトに対して0x7F7FとORしてJISからSJISへ変換すると漢字コードを復元できました。カナコードはシングルシフトコードを取り除くだけだったのですけどね。
ちなみに、真のデフォルト文字コードはラテン語だったりする。OSインストール時に英語に設定してるので気づかない場合がほとんどだと思われます。なので、コードを扱うプログラムで、デフォルト値がラテン語というのがわかるかと思います。
ポート
VOSはプロセス・プログラムのI/Oにポートという概念を持ってます。プログラムのI/Oはポート番号でアクセスし、結びつけられたファイルや通信デバイスなどのI/O操作を行います。まあ、どんなOSでも似たような概念を持ってると思いますが、それらとほぼ同じです。
ログインしている端末で、list_port_attachment(lpa)というコマンドをたたくと、ログイン端末が今接続してるポート情報の一覧を出してくれます。情報には、ファイル名やデバイス名、オープン状態などが得られます。よく使うのは、mp_debugコマンドで実際に動いてるプロセスへ接続して、コマンドを打ち込んで実際に使用しているファイルやデバイスを調べたりします。
ファイルへアクセスするには、s$attach_portというAPIを呼び出し、物理的なファイル名とポートを結びつけます。戻されるポート番号を使て、ファイルのオープン、I/O、クローズなどの操作を行っていきます。使われたポートの開放はs$detach_portというAPIで行い、後始末を行います。
通信といってもレガシーなX.25、SNA、SDLCなどは通信ボードが古くからサポートしてるのでポートが使われてますが、TCP/IPはユーザーから見えにくくなっていて一般的なソケットでのI/Oとなります。
3D CAR RACE
マイコン 1983年3月号掲載。やや後ろからの視点のレースゲームで、道の起伏を３Dっぽくうまく表現してます。
オールマシン語ですが、チェックサムが無かったので打ち込みには苦労しました。
HEAD-ON
I/O 1979年10月号掲載。アーケードとは比較してませんが、結構よくできてると思います。相手と反対にコースを走ってぶつからないようにドットを消していくゲーム。ドットのある通路とコースを変えられるポイントで相手にぶつからないように操作していく。速度調節ができるので、通路に入ったらスピードを出したりして相手の動きを見つつ、コースを変えていくようにする。必要なら一度通ったところも通る必要もあります。
もうやめに・・・してないし
某スーパーが「もうやめにしよう」等と恵方巻を題材にして廃棄の問題を挙げてましたが、よく文面を読んでみると突っ込みどころ満載だった。廃棄を問題にするなら、完全予約制にして、店頭売りをゼロにすればいい。でも、実際は「前年実績で作る」って事。これって「どこでもやってる」事で珍しいことではない、逆にやってなかったことを恥じるべきじゃないか？
ロスについても言ってるが、ロスは廃棄ロスだけではない。機会ロス、不明ロスが存在する。廃棄ロスは名前の通り、生産した品物を廃棄することによる損失。機会ロスは、本来売れるまたは売れる可能性がああるのに品物がなくて売れなかった損失。不明ロスは帳簿と実際の数が合わないケース（万引きや、生産歩留りの相違もあるか？）
廃棄ロスは、どこでも減らず努力をしているロスです。お金を出して仕入れたものをお金を出して捨てるのですから当然です。では、廃棄ロスがゼロならそれでいいのか？と言われるとそうでもなく、本来販売していれば売れる・売れる可能性があった機会ロスが増えるといことになります。広告をうって閉店時に売り場に広告商品がゼロという状態や、営業中に商品がゼロという状態は機会ロスです。この廃棄ロスと機会ロスの制御が売り場の管理者の力量となるわけです。機会ロスを減らせば、廃棄ロスは増える。廃棄ロスを減らせば、機会ロスが増えるのが実情です。
どの企業でも廃棄ロスの許容範囲を設けてると思います。そのパーセンテージが大きいところは問題ですけど、いかにして廃棄ロスを減らして最大限に売り込めるかというのが企業の命題となるわけです。
現場で一番の問題となるのは、機会ロスとなったお客様からのクレームです。例えば、広告をみてガソリンなどの交通費を支払って来店し、品物がありませんでした・・・って結果になったらどうです？文句の一つもいいたくなるでしょう。店が売ると明言したものがなかったら、ある意味詐欺行為でもあります。これは許されますか？お客様が１００％許してくれるなら、廃棄ロスは減らせるでしょう。現状では、少なからずクレームとなりますので、それを抑える意味でも仕入れが過剰になり、廃棄ロスにつながるということです。（店で一番恐れるのは、お客様からのクレームです。お客様至上主義の店は特に。売上至上主義の店はお客様なんでどうでもいいのでしょうけど）
☆
では、今回の某スーパーのケースはどうでしょう？「当たり前のこと、やって当然のことを言ってる」だけでしょ？だから共感できない。どうせなら、「完全予約制にして店売りはしません」とか、「もう恵方巻は売りません」とか言わない限り、「廃棄ロスなんて減らないだろう？何いってるんだ？」としか思えないのです。実際、去年の実績で作って数店舗は廃棄が出てます。何なのでしょうね。この辺り突っ込まれないのが作為を感じる。
まあ、日本人はお祭り好きだから（該当しない方もいますが）、何らかのイベントがあれば参加したくなると思います。一度売り込めば、毎年行われるようになりますし、冷めた人が「前ら何をやってるんだ？」ってなっても収まらないのが現状です。クリスマスケーキ、恵方巻、バレンタインチョコ、等々。おかしいと思いつつも毎年売っていかねばならず、売らなければ売り上げにつながらない、やめたくてもやめられない、それが現実だと思います。そういう風土の中で、やめる宣言してやめるのならやめればいいだけです。ただ、やめられますか？って聞きたいですね。
地底最大の作戦
MZユーザーなら誰でも知ってる（と思う）ソフト、地底最大の作戦です。早期に発表され、80Bにも移植されていて、当時遊んだ人が多いと思います。上から落ちてくる蛇を捕獲していくゲームで、落ちた直後か餌を与えると丸くなり、その状態で捕獲していきます。穴は自由に掘れますが、埋めることはできません。蛇は穴の上にくると落ち、一定時間丸くなります。身動き取れなくなった蛇は一定時間経過すると下に穴を掘ります。最終的に基地を蛇が侵略するとゲームオーバーです。まあ、自機が全滅してもゲームオーバーですが。
耐障害性
Stratusの耐障害性は、ハード的に行われていて、アプリケーションプログラムは意識する必要性がありません。CPUボード、メモリーボードなどがすべて二重化されていて、片方が障害となっても動き続けます。当然双方障害だとだめですが。１つのボードも中身が二重化されていて、ボード内でも障害検知が行われます。それ故、故障したボードをオンライン中に抜き差ししても問題ないという。
ハード障害でアプリ的に問題（エラー検知）されるのは、通信障害くらいでしょうか。通信ボードは相手との接続の関係もあり、接続自体を二重化できませんから、バックアップに切り替わるときに回線が切断されたり、停止します。この時アプリには回線切断の事象が通知されます。この辺りは、アプリケーション的にエラーリカバリするのが一般的でした。（データを破棄して、相手側にタイムアウトを検知させるとか、エラーの通知を行う等）
TANDEMでは、CPUボードが停止すると、そのCPU上で動くプログラムはすべて停止します。プログラムをソフト的に二重化して対応しており、メインプログラムとバックアッププログラムを別CPUで動かし、同期をとりつつ動作し、障害時にプログラムが切り替わるという手法でした。こういった手法をプログラミングしなければならなかったので、プログラマーにかかる負担が大きかったです。
パッケージを移植するために初期調査している段階で、ＨＰの技術者にいろいろ聞きながら移植作業をおこなってましたが、この二重化の部分で聞いた情報が間違っていて、後に障害対策で苦労した記憶があります。ファーストユーザーに導入し、動かしてある程度の取引を処理したら、突然エラーが出始めたり、障害テストでCPUダウンさせて切り替わりのテストでバックアップがさらに停止したり散々だった。結局マニュアルを読み直して対応したのですが、社内の周りからの目は痛かったです。自分のスキルの低さもあったのだろうけど、自分的には騙された感の方が強かったと思う。
とまあ、ライバル２機種で比較すればStratusの圧勝って感じが今でも強いです。