おにたま(オニオンソフト)のおぼえがき

引き続き、HSPプログラムコンテスト2009で実施したアンケート結果について報告したいと思います。(前回の記事はこちら)
それでは、HSPについての質問から1つ1つ見ていきたいと思います。

Q8.初めてHSPを知ったのはどこですか

これは「三択+その他」の形式で答えてもらっています。もともとオンラインソフトということもあってか、ネットで知ったという人が一番多かったです。その次に多いのが、「友達や先生から」という答えで、その他で書かれていた内容も大半は身近な人から知ったというものでした。意外に人から伝わっているケースが多いので、もう少し細かく経緯をアンケートしてみたくなりました。

Q9.プログラミングをどのように覚えましたか

これは「4つの中から選択+その他」の形式で答えてもらっていますが、なかなか興味深い結果です。HSP以外のプログラムも含んでいるかもしれませんが、おおむねHSPを学習する際のことだと考えるとネットの資料だけで事足りてしまうということでしょうか。書籍が出ていることを考えるとちょっと複雑な気分ですが、ネットが強いことは間違いないですね。

Q10.HSPの機能で一番入れて欲しいものは何ですか

「5つ(+その他)から一番欲しいものを1つ」という形式だったのですが、「動作の高速化(ネイティブコード生成含む)」が予想以上に強かったですね。応募者向けのアンケートなので、皆さん既にプログラムを組んでいるわけで、実際に利用している中から出てきた切実な意見と言えます。それだけギリギリまで使いこなしたいという願いもあるでしょう。このあたりは今後も追求していくべき問題の1つとして参考にさせてもらいます。

Q11.HSPを使い続けているのはなぜですか

これは「四択+その他」の形式で答えてもらっていますが、圧倒的に「手軽に使えるから」が占めています。ある意味、HSPの強みでもある部分なので嬉しいですね。
その他の回答としては、「低スペックPCでも動作するから」「コンテストがあるから」「短期間で作れるから」というものが目立ちました。このあたりが、恐らく他の言語とは違っている部分かもしれません。

Q12.初めて覚えたプログラミング言語は何ですか

HSPのコンテストで行なっているアンケートなので、HSPが多いのは当然としてなかなか面白い結果です。これは「6つの中から選択+その他」の形式で答えてもらっていますが、C#が意外に少なく、C/C++の方が多いですね。「その他」には、昔のBASIC(n88やMSX)や、「なでしこ」などが挙がっていました。
何にしても、HSP以外の言語を知っていてコンテストに応募してくれているのですから、何らかのメリットを感じてくれているということで、嬉しいことです。

Q13.プログラミングを覚えて最初に作ったプログラムは何ですか

これはテキストによる回答の項目です。「数当てゲーム」「イライラ棒ゲーム」「計算プログラム」など、昔からある題材がやはり多いですね。最初から大作を作っている人は見られませんでした。人によるかと思いますが、少しずつステップアップしながら作品を作るというスタイルが、プログラミングでは大切なのかもしれません。

Q14.HSPの機能やホームページについて、ご意見や要望などあればお書きください

Q10に近い質問でしたが、鋭い意見や励ましなど色々頂きました。ありがとうございます。全体として、機能は増やして欲しいが、複雑にはして欲しくないという「手軽さ」へのこだわりを感じました。中でも多かったのは、やはり速度面に対するものやエディタ(IDE)への要望など、細かいところまで使っている人の意見だけに大変参考になりました。
あとwebに関しては、掲示板の使い勝手や管理方法に関するご意見が多かったです。人手が足りなくて実現が難しいものから、なるほどと思わせるアイデアなどがあり、こちらも検討してみたいと思います。

というわけで、思っていた以上に色々とユーザーの話を聞くことができました。また何らかの形で、アンケートを実施してみたいと思いました。ご協力頂いた皆様に感謝致します。
尚、アンケートの結果についてはこちらで公開されている資料でも一部触れられています。興味のある方はどうぞ。
http://www.digrajapan.org/modules/mydownloads/viewcat.php?cid=11

遅くなりましたが、HSPプログラムコンテスト2009で実施したアンケート結果について報告したいと思います。
このアンケートは、2009年に開催されたHSPのプログラムコンテストの作品応募者を対象に行なったもので、全応募者の約半数にあたる80名の方から回答を頂いています。ご協力頂いた皆様、ありがとうございました。
大きく、コンテストについての質問と、HSPについての質問に分かれています。コンテスト応募者として、HSPユーザーとしてどのようなことを考えているのか、傾向などがわかる資料となるのではないでしょうか。
まずは、コンテストについての質問から1つ1つ見ていきたいと思います。

Q1.コンテストに作品を応募しようと思った一番の理由は何ですか

これは「五択+その他」の形式で答えてもらっています。一番多いのが「他の人に見てもらえるから」となっていて、他の人に発表する機会を求めている人が多いことがわかります。もちろん、ホームページやblogなどでも発表の機会はありますが、多くの人が集まる舞台で発表するということが、特別な意味を持っているのだと思います。
その他で寄せられた答えにも、「イベントだから」「みんなが参加しているから」といったものが多かったです。

Q2.コンテスト参加作品の製作で一番苦労した点は何ですか

これは「7つの中から選択+その他」の形式で答えてもらっていますが、見事にバラバラです。1つの作品を完成させる上で、様々な苦労があるということでしょうか。
「プログラムサイズの削減」が上位にありますが、これはおそらく「HSPTVプログラム部門」でスクリプトのサイズが限られているため、そこに収めるために苦労したということだと思います。その他で寄せられた答えの中には、「製作途中でソースが消えた」や「やる気が出ない」など切実な問題もあったりして、まさに苦労の積み重ねがあったのだと推測されます。

Q3.今回応募した作品を作ろうと思ったきっかけは何ですか

これは選択ではなく文章での回答になっていますが、結構な数の人が、コンテストがあるからそれに合わせて作品を作っていると答えていて、おそらくは普段から何か作りたいと思っている人の背中を押すいい機会になっているのではないかと思いました。
他には、「新しい技術に挑戦したかった」「いいアイデアを思いついた」「コンテストに出してみたかった」など。Q1に近い内容の質問だったせいか、回答もQ1に近いものとなりました。

Q4.これから作ってみたい、作っている作品があれば聞かせてください

Q3に関連してこれから作る予定の作品、ジャンルなどを聞いてみました。こちらも文章のみの回答ですが、やはりゲームで人気のジャンルが多かったです。特にRPGとシューティングは根強い人気がありますね。また、3Dに挑戦したいという人も多く見られました。

Q5.ネット審査員のシステムについてどのような形が望ましいですか

ここから先はコンテストの運営や参加についての質問になります。
「ネット審査員」は、コンテスト応募作品に対してコメントと評価をすることのできる仕組みです。応募者にとっては自分の作品に対しての反応を直接見ることのできる機会なだけに関心も大きい項目ではないかと思います。で、回答の結果から見ると割れています。応募者がユーザーからのコメントを望んでいることは間違いないのですが、焦点としては悪い(ネガティブな)意見や、コメント欄での争いなどを最初から排除するかどうか…ということなのかなと思います。コンテストの初期は、誰でも作品に対するコメントを書けるようにしていたのですが、不快な意見や荒らしまがいの行動が多かったため、現在は登録制になっています。このあたりの感覚は、人それぞれなので何が正しいというこはないでしょう。
まだ決定していませんが、次回のコンテストはこの結果を踏まえた上でシステムを作っていこうと考えています。

Q6.次回もコンテストがあれば参加してみたいですか

これは嬉しい結果です。まあ、アンケートにわざわざ参加しないことを表明する人も少ないでしょうが、まだそこそこ期待されていると思って頑張ります。

Q7.HSPプログラムコンテスト事務局へ、ご意見や要望などあればお聞かせください

こちらも色々なご意見を頂き、コンテストに対する関心の高さを感じました。特にコンテストページのシステム(CGIや応募ページなど)に対する不満が寄せられていて、これは何とかしたいところです。他には以下のような意見がありました。
「ゲームばかり優遇しないで」…応募作品がゲームに偏っているのは事実ですが、ツールや実用ソフトも良いものは等しく注目しています。ゲームでないものが最優秀にえらばれたことも過去にあるので、ぜひ前向きに頑張ってもらいたいと思っています。
「チーム参加と個人参加で完成度に差が出てしまう」…これが問題というよりは、完成度の高い(見栄えのよい)ソフトだけが注目されてしまう傾向はあるかと思います。少人数で作ってもアイデアの良いものはありますし、熱意のあるもの、作り込みを評価する雰囲気を作っていきたいですね。
「作品の更新が遅い」…すみません。更新は手作業で行なっているため、人手の関係で今はこれが精一杯になっています。自動登録になっていないのは、ウイルスチェックや規約違反などを人がチェックしているためです。ただ、更新のタイミング告知など改善できる点はあると思っています。
「コンテストＴＶで紹介するゲームの数を増やしてほしい」…わりと参加者の皆さんは楽しみにしているようで・・・できるだけ頑張ります。

Q8以降の質問は、HSPに関するアンケートになります。そちらはまた近日中に結果を報告したいと思います。

これは、うちにあるピンボールに入っているリレー回路です。

TTLのビデオゲームについて少し前に書きましたが、それ以前に作られていた電子回路を使わないゲーム、いわゆるエレメカでは、こうした機械式のリレーが論理回路として働いていました。TTLによるゲームも論理回路で構成されていますし、そもそもコンピューター(CPU)の中身も論理回路です。
つまり現在のゲームやPCが動作する原理の原始的な形がコレと言えなくもありません。
リレーは、電流が流れると電磁石の力でスイッチを引き寄せます。そして、電流が止まるとバネの力でスイッチが戻ってしまいます。簡単に言うと、別な回路のスイッチをON/OFFするのがリレーの役割なわけで、ゼルダの伝説で言うと床のスイッチを踏むと、遠くにある扉も一緒に開いたり閉じたりするのと似ています。
真空管やトランジスタ、ICチップであっても仕組みは同じことで、考え方の基本にあるのはデジタルの1と0を電流が流れているか、いないかで分けるということです。これだけの仕組みで計算ができてしまうのが驚きです。詳しくは触れませんが、興味のある人は以下のページなど参考にしてみてください。
http://www.infonet.co.jp/ueyama/ip/logic/adder_r.html

こういった論理回路によって、0か1かの情報、さらにそれを集めた2進数の情報を保持でき、複雑な動作が可能になりました。
たとえばピンボールゲームだと、ゲームのスタートボタンを押すとスコアなど各種設定がリセットされてボールが出てきます。そして、「A」「B」「C」のターゲット全部にボールが当たると1000点入るなどのギミックが動くようになります。
こういった最初にこれをやって、次にこうなって、その次はこれ…といったシーケンス動作は、コンピューターのプログラムが得意とする部分です。特に手続き型言語(BASICとかHSPとか)は、まさに動作の順番を書いていくだけです。
手続き型で考えるとだいたい、こんな感じになります。

1. スタートボタンが押されるまで待つ
↓
2. スコアや各種設定をリセット
↓
3.「A」のターゲットにボールが当たったら変数Aを1に
↓
4.「B」のターゲットにボールが当たったら変数Bを1に
↓
5.「C」のターゲットにボールが当たったら変数Cを1に
↓
6. 変数A～Cがすべて1ならば1000点加算
↓
7. 3.からの動作を繰り返し

これと同じことをリレーが行なうと、

1. スタートボタンが押されたら設定を保持している回路を切断(0)する
また、ゲーム中であることを示す回路を接続(1)する
2. 「A」のターゲットにボールが当たったらAの回路を接続(1)する
3. 「B」のターゲットにボールが当たったらBの回路を接続(1)する
4. 「C」のターゲットにボールが当たったらCの回路を接続(1)する
5. 回路A～Cがすべて接続されると1000点加算

のような感じになります。
それぞれのスイッチごとに、どのような動作を行なうか、他の回路とどのような関係を持つかなどを考慮して設計する必要があります。特に「ゲーム中であることを示す回路(リレー)」は、エレメカ時代のゲームには必ずついていて、お金を入れるまではプレイヤーの操作などゲームに関わる回路に電源が繋がらない仕組みになっていました。これがタイマーにより一定時間で切れたり、カウンターが進むと切れるようにすることでゲームオーバーを作っていたわけです。
こうした考え方は、今注目されているマルチスレッドプログラミングや関数型言語に近いものがあるように思います。何か一周してきたようで不思議なものです。
ところで、機械式のピンボールにはまだ一部アナログ的な動作も残っています。たとえば5000点加算するような場合、論理回路で5回カウントさせるのは規模もコストもかかります。そこで、オルゴールのように回転する円盤が物理的に5回スイッチを入れるようになっています。これはスコアモーターと呼ばれているもので、必要に応じて1回、3回、5回などのパルス(スイッチのON/OFF)を発生させます。ある意味で、これがエレメカゲームの心臓部と言えるかもしれません。

その後、ビデオゲームが登場しTTL制御の時代になっても、プログラムという手続き型の動作ではなく、エレメカの論理回路が行なっていた仕組みを継承し、より複雑なものになっていきました。
そう考えると、ブロック崩し(Breakout)などはどんな動作になっているのか興味深くなってきませんか?

※追記(2010/3/15)
さらに新しいバージョン(RC3)が公開されています。こちらの記事を参照してください。

前のバージョン(RC1)からいくつか内容を修正したHSP3.21RC2を作成しました。
RC1版との違いは、以下の点になります。

• sprocketさん製作のArtlet2D,SQLeleモジュール及びサンプルを同梱。
• hspinetプラグインに文字コード変換(nkf)、JSONサポートを追加。
• hspinetプラグインサンプルにTwitter API操作スクリプトを追加。
• mod_regexpモジュールを追加。
• Windows7用のマルチタッチサンプルスクリプトを追加。
• HGIMG3で直接描画のテクスチャ補間方法に関する設定を追加(hgimg3.txt参照)。

RC1から、HSP3及び標準的なランタイムに変更はありません。マイナーバージョンコードも変更していません。
プラグインや新規モジュールが主な更新ですが、よかったら試用してみてください。これで大きな問題がないようであれば、そのままリリース版として公開していく予定です。まだいくつか修正したい点はありますが、x64対応版への差し替えという側面もあるため、リリースを早めることを優先して進めています。

  hsp321rc2.zip (19.4 MiB)

フルセットの内容をzipファイルに圧縮してあります。
HSP3.2がインストールされている方は、別のフォルダに解凍するか、バックアップした上で上書きすることを推奨します。何らかの問題や不具合がありましたら、掲示板かこちらのコメント欄でお知らせ頂けると嬉しいです。
今回大きく更新された点として、sprocketさんが作られているHSP Document Library(HDL)及び、d3moduleモジュールに加えて、Artlet2D,SQLeleモジュールも正式に同梱されることになりました。特にArtlet2Dは、GDI+を利用した多彩な描画をサポートするもので、色々と応用ができそうです。(ただし、Windows XPより前のOSでは別途DLLのインストールが必要です)

他にも、HDLのドキュメントが見やすくまとまるようになったりと、細かい部分でバージョンアップされています。

現在、マイナーアップデートとなるHSP3.21の準備を進めていますが、その一環で文字コード変換機能をhspinetプラグインに付加しようとしています。
文字コードは、コンピューター内部で文字を扱う時の数値で、65ならば「A」、33ならば「!」のような感じに表示される文字と対応しています。ことに日本語の全角文字が環境やアプリケーションによって異なることがあり、文字コードが違うと正しく文字が表示されない「文字化け」が起こってしまいます。この文字コードは、歴史的経緯もあってなかなか統一できない点も含めて悩みのタネになっています。

2000年以降は、Unicodeと呼ばれる国際的な統一規格にまとまりそうな気配があるのですが、Unicodeが上位互換で新しい仕様を入れてくるため、対応が間に合わないとか、それ以前に作られたテキストが読めないなど難しい問題を抱えています。
特にWindows内部で使用しているUTF-16(Unicodeの一種)は、2バイト(16ビット)で1文字かと思いきや、サロゲートペアという不思議な仕様により4バイト(32ビット)になることがあったり、バイトオーダー(上位下位バイトの並び順)の違いがあったりと、かなり不親切な作りです。そこで、半角の文字や記号にわりと相性の良いUTF-8(これもUnicodeの一種)が、最近では主流になってきてるのかな…と感じています。
さて、その一方で日本のPC環境では、古くから日本語はSJIS(ShiftJIS)と呼ばれる文字コードが使用されてきました。HSPもずっと前から、SJISをベースに作ってきましたが、時代の流れとともに色々な問題が出てきました。

• SJISコードでは表現できない文字(漢字)がある
• Windowsの内部ではUnicode処理を行なっているため変換コストがかかる
• 各種コンポーネント(COM)がUnicodeをベースにしているため相性が良くない

HSPも色々な環境に対応するために、今後はUTF-8など新しい仕様に移行することが必要と感じています。と…こんな話の流れではありますが、Windows版については当面SJISベースを維持する予定です。その根拠というか、思うことはWindowsもしくは日本のマイクロソフトも完全なUnicodeベースにしようとはしていない気がするからです。
最新のWindows7でさえ、ユーザーが新規テキストを作成した後、メモ帳で保存される形式はSJIS(ansi)です。また、DOSプロンプトでファイルにリダイレクトした結果もSJISになります。

互換性の問題もあるかと思いますが、ファイルに記録される文字コードの形式としてSJISが残っている限りは、Unicodeに移行しても問題が起こります。それで問題を増やすよりは、単一のフォーマットにして混乱を避けるのも1つの道かなと考えています。
ただ、インターネットを始めとして新しい環境では、それに合った文字コードがあると思いますので、そちらに向けては積極的に対応を進めていきたいところです。

ところで、ここから先は昔話ですが、その昔ヒットした日本初のパソコンとして名高いPC-8001というマシンがあります。これが登場したのが1979年で、漢字を表示することすら難しい時代でした。
この頃は、256種類の文字データがROMに内蔵されていて、これを変更することは基本的にできませんでした。その256種類の文字がこちら。(左上が0、右下が255のコードになります)

ごくわずかな漢字、「年」とか「秒」とかが用意されているところが涙ぐましいですが、限られた種類の中で必要そうな文字を選ぼうとしていた跡が伺えます。
で、この文字コードはその後、PC-9801という16ビット機にも受け継がれ、そのマシン上でMS-DOS、Windows3.1とOSが進化しても半角文字に使われるこの256種類は維持されてきました。
特に、漢字が出なかった時代はカタカナが使われていて、事実上カタカナの文字コードはこれが標準と言っていいと思います。
で、現在使われているSJISのコードを見てみると、見事にこの256種類の中で基本的な文字とカタカナを避けて定義されていることがわかります。SJISの1バイト目は、$81～$9f、$e0～$fcというコードで、昔の文字コードで言うところの、わりと使われない記号とか、トランプのマーク、わずかな漢字などの領域を全角の識別用に使い、半角カナを含むテキストはそのまま読めるようにしています。
つまりそれだけ長い期間かけて互換性が維持されてきた文字コードがSJISなわけで、これがすべて置き換わるのも長い期間がかかるのではないかと思ってしまいます。

ちなみに、PC-8001と同時期にシャープが発売したMZ-80というパソコンが使用していた文字コードがこちら。

MZ-80シリーズ(後のMZ-700やMZ-1200の元になる)は、当時PC-8001など多くのメーカーがコンピューターの本場アメリカの技術をベースにしていたのに対して、国産技術をベースにしていた点がとても異色でした。
それもあってか、この文字コードではカタカナの並びが謎なだけでなく、アルファベットや記号のコードすら当時の国際標準(ascii)に沿っていません。しかしながら、256種類をフルに活用してユニークな記号や、明らかにゲーム向けな図柄も多く含まれていて好感が持てます。実際とてもユーザー本位な作りをしていて、今でも熱狂的なファンがいるのも何となく頷けます。もし、この機種が日本の標準になっていたら、現在のSJISコードも違った体系になっていたでしょう。
でも、このカタカナ配列はやだなぁ…。

※追記(2/17)
よくよく見たらMZ-80のカタカナの配列は、キーボードのABCD…に対応するカナ入力のコード順だったのか。その発想はなかったけど、コード配列としてはやっぱりやだなぁ…。

前に紹介したUSB制御システムHIDaspxですが、その後、HSPからも制御できるようになりました。

と言っても、HIDaspxで利用できるhidmon.dllというDLLを呼び出しているだけなので、とてもお手軽です。
何よりドライバのインストールなど煩わしさがないところがいいですね。私のWindows 7(x64)でも普通に動作しています。この基板では、ボタン入力2bitとLED出力8bitですが、いずれ別なものも接続してみたいところです。
せっかくなのでHSP3で使うためのヘッダファイルとサンプルを置いておきます。ちょっと試してみたいという方はどうぞ。(別途HSP3フルセットが必要です)

  hidmon_hsp3.zip (15.3 KiB)

※追記(2010/3/15)
さらに新しいバージョン(RC3)が公開されています。こちらの記事を参照してください。

HSP3.21RC1を作成しました。
まだテスト版としての扱いですが、よかったら試用してみてください。
主にHSP3.2で発見された不具合を解消するためのマイナーアップデートで、前から基本的に構成と仕様は大きく変わっていません。
下のリンクからダウンロードすることができます。

  hsp321rc1.zip (19.1 MiB)

フルセットの内容をzipファイルに圧縮してあります。
HSP3.2がインストールされている方は、別のフォルダに解凍するか、バックアップした上で上書きすることを推奨します。
HSP3.2からの主な変更点は以下の通りです。

Windows Vista及びWindows 7の64bit(x64)版でウィンドウが閉じなくなる不具合の修正

HGIMG3でメモリのリークがある不具合を修正

HGIMG3上でOBAQプラグインのオブジェクト描画に対応

HGIMG3でエミッターなどいくつかの機能追加

OBAQプラグイン用の簡易モデル作成ツールを追加

hspinetプラグインにRC4/BASE64サポートを追加

hspinetプラグインサンプルにメール送信スクリプトを追加

何らかの問題や不具合がありましたら、掲示板かこちらのコメント欄でお知らせ頂けると嬉しいです。

今年になって調べたいと思っているテーマの１つがTTL時代のアーケードゲームです。
TTL時代っていうのは、アーケード(ゲームセンター)にテレビを使ったゲームが登場した70年代初頭から、CPUによるゲームが普及してくる70年代後半までの短い期間を指します。というか、私がそう呼んでいるだけです(^^;

TTLとは何かと言うと、コンピューターの基本的な動作を行なう論理回路(またはICチップ)の総称で、コンピューター(CPU)が普及する前のデジタル回路では、欠かすことのできない仕組みです。
今では、ビデオゲームと言えば当たり前のようにCPUが入っていて、ゲームのソフト(プログラム)が動いていますが、70年代初頭のTTL時代ではCPUを使わずにデジタル回路だけでゲームを作っていました。プログラムを作らないでゲームが作れるの? って思っちゃいますが、実際に色々なゲームが作られています。
たとえば、アーケードのビデオゲーム初のヒット作として有名なPong(Atari 1972)。

あと、今でも知られているブロック崩し「Breakout(Atari 1976)」もプログラムは一切使われていません。

現在はハードウェアとソフトウェアの分担がはっきりしていて、パソコンで言えばビデオカードのハードウェアが絵を出す機能を持っていて、コントローラー等の入力をもとにどのような絵を出すかを決めるのがソフトウェア(プログラム)の役割です。
昔は、そのソフトウェア部分も含めてハードウェアで作ってしまっていました。ゲームごとに専用の回路を作っていたわけです。そのための一時的なデータ記憶や、条件判断を行なうためにTTL(Transistor-transistor logic)が使われていました。

今さらなぜTTL時代をテーマにしているかと言うと、その後のビデオゲームに比べて資料が少ないことと、TTLの持つシンプルさを今だから見直すといい…気がしたからです。

TTL時代のゲームを現在遊べる環境は極端に少ないです。また、80年代以降のゲームはエミュレーターにより今も遊べたりしますが、CPUを使用していない場合、厳密に同じ動作をパソコン上で再現するためには回路図をソフトウェアに起こす必要があり、とても難しくなります。
そのため、ビデオゲームの元祖的な存在でありながら取り上げられる機会も少なく、知らない人がほとんどではないかと思われます。ファミコンとか80年代のゲームについてはもう多くの人が語っていると思うので、今後ネタが続けばですが、TTL時代に作られたゲームと魅力について紹介をしていきたいなと思っています。
ちなみに、海外ではDiscrete Logicとも呼ばれていて、こちらのページはかなりオススメです。

Discrete Logistics
http://discrete.mameworld.info/

あと、パソコンでは再現が難しいと言いましたが、シミュレーターを作っている人もいるので雰囲気はわかるのではないかと思います。
http://adamulation.blogspot.com/
http://www.ascotti.org/programming/tickle/tickle.htm

昨年(2009年)11月くらいから、シマンテック社のノートン製品(Norton Antivirus 2010など)とHSP3の相性が大変悪くなっています。
だいたい経緯としては、以下のような感じです。

Norton Antivirus 2010の新機能SONAR2がHSP関連ファイルをセキュリティリスクと認識してユーザーの確認なしに削除
↓
サポートに連絡して改善の要求を行なう
↓
１ヶ月後、サポートから対応しましたという連絡が来る
↓
HSP3.1など一部のファイルは誤認識がなくなったものの、依然としてHSP3.2で同様の問題発生
↓
再度サポートに連絡
↓
その後、ファイルが勝手に削除されることはなくなった模様
↓
サポートからの返信はまだなし←いまここ

実行ファイルを解析して危険かどうかを判定する技術ということで、まだこなれていない面もあるかと思いますが、現在までの対応としてはサポートも含めて良くないなぁというのが正直な感想です。

あまりに状況が掴みづらいので、検証のためにソフトを購入してしまいました。
どんなアルゴリズムで検証しているかわかりませんが、hspランタイムが引っかかるのはわかるとしても、スクリプトエディタまでアウトなのはわかりません。exeファイルを生成するからでしょうか。

現在はとりあえず、以下のようなダイアログが出たら、続行を許可すればそのまま使用することができるようです。

ちなみに、ちょっとフォローしておくとシマンテックの対応は最悪…というほどではなく、他社製のアンチウイルスソフトではサポートの連絡ができなかったり、誤認識への対応を拒否される(!)ケースもあったので、それに比べればちゃんとしています。ただ、知名度と普及率から考えるともっと早い対応を望みたいところ。

HSP3とアンチウイルスソフトの誤認識については、以下のページにまとめています。
今後も情報があれば、報告していきたいと思います。
http://www.onionsoft.net/hsp/hsp3alert.html

窓の杜で、HSPプログラムコンテスト2009の作品が紹介されました。
http://www.forest.impress.co.jp/docs/serial/shumatsu/20100122_342276.html

こういった記事で、HSPTVブラウザが取り上げられるのは珍しいですが、とても良いことだと思います。
HSPTVブラウザは一度インストールさえしてしまえば、仕組みとか内容がわかってもらえるかと思うのですが、最初のステップがなかなか一般の人に認知されていないのがネックになっています。
もちろん、HSPTVブラウザを起動してからのおすすめ誘導とか、webとの連携とかまだできることは色々あるのですが、まずは多くの人に存在を知ってもらうことが大切だと考えています。
そのあたりの周知も含めて、仕組みを作っていきたいですね。
何かいいアイデアなどあれば、どんどんお知らせください。

コンテスト作品と言えば、海外で「ネズミマン」が取り上げられています。
なんと２００９年のインディー(自作)フリーゲームの部門で５位ですよ。
http://www.indiegames.com/blog/2010/01/feature_top_freeware_platforme.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+IndependentGaming+(Indie+Games)

indiegames.comでの個別紹介ページはこちら。外人のコメントもおおむね好意的です。
http://www.indiegames.com/blog/2009/11/freeware_game_pick_nezumiman_f.html

私が作ったわけではないですが、HSPで作られた作品が海外でも遊ばれているのを見るのは、何だか嬉しいですね。
このゲームに限らず、多くの優秀なソフトがコンテストに出品されているので、今後は海外へのアピールも積極的に行なって行きたいところです。