geniacllm/wiki40b huggingface dataset:
秋季大会は東京都（1955年まで参加）を除く7県の秋季大会優勝・準優勝校および開催県の3位校を加えた合計15校で争う。優勝校は明治神宮野球大会の出場権を得る。また、大会成績は翌年春の選抜高等学校野球大会の出場校選考にあたり重要な資料となる。現在の関東地区における同大会の出場枠は「4.5」となっていることから出場ラインとしてベスト4進出が一つの目安とされているが選考では試合内容や地域性も加味されるためこの限りではない。
作詞はイラストレーターの326で、作曲は19の2人が担当している。大まかには、Bメロとサビは岡平、Aメロは岩瀬が作ったものである。着うたダウンロードとネット投票を元に制作されたベストアルバム『19〜すべての人へ〜』では得票数1位となり、1曲目に収録されている。本来は「卒業の歌、友達の歌。」のシングルB面として発表されるはずだった。しかし、1999年春、TBSの「1999・春」キャンペーン・ソングに起用され、「この曲は誰の曲なのか？」という問い合わせが殺到した事から、急遽A面に変更された。この曲のデモバージョン「紙ひこうき」ではテンポがゆっくりとしたバラード調のものになっている。オリコンの初登場時のランキングはかろうじて50位圏内とあまり芳しいものではなかったものの、その後のテレビ出演により20週連続チャートインという息の長いヒットソングとなった。この曲の大ヒットがきっかけとなり、デビューからわずか1年で同曲で紅白歌合戦への出場を決める。朝日放送制作の「ワイドABCDE〜す」のエンディングテーマにも起用されていた。
1996年、静岡市立中央図書館に所蔵されていた『タイ買春読本』（データハウス）の廃棄を要求し、表現の自由・知る権利を擁護する観点からこれに反対した静岡市の図書館をよくする会と激しく対立した。その後は外務省や旧・郵政省から補助金の交付を受けフィリピンやタイで施設の建設事業を行っていた。
2003年、税制上の優遇措置を受けられる認定NPOの資格を得るが「書類の提出手続が煩雑で本来の業務に支障をきたす」「年度末に多額の寄付を受けても翌年度に繰り越せないのはおかしい」との理由で2005年に資格を返上した（内閣府によると、このような事例は現在のところカスパルが唯一だと言う）。また、2005年の総会における解散決議に基づいて、2006年春にNPO法人の資格そのものも返上して任意団体となって、以降は「特別救済活動」を団体名に冠するようになった。
2004年初頭からアダルトゲームの撲滅を主張し始め、ベクターが運営するアダルトゲーム情報サイト「Galge.com」に対して閉鎖を要求した。続いて特定非営利活動法人ジュベネイル・ガイドと共に自民党の野田聖子衆議院議員らに対してロビイングを展開している。2005年からはジュベネイル・ガイドと「美少女アダルトアニメ雑誌及び美少女アダルトアニメシミュレーションゲームの製造・販売を規制する法律の制定請求」と題した請願書の署名活動を開始。しかし共同歩調を取ってきたジュベネイル・ガイドの実態がアダルトゲーム製作会社であることを週刊新潮に報じられ、ジュベネイル・ガイドは活動を停止した。その後カスパルは独自に署名活動を継続し、アダルトゲームとその関連書籍の販売停止を要求する内容の「子どもたちのイノセントを守りましょう」と題した申入書を複数のゲームメーカーや出版社に送付している。児童買春、児童ポルノに係る行為等の処罰及び児童の保護等に関する法律の改正が問題となっていた2008年5月には、民主党の円より子参議院議員と下田敦子参議院議員を通じて、この請願書を第169回国会に提出 2008年5月14日、「街中に氾濫している美少女アダルトアニメ雑誌やゲームは、小学生の少女をイメージしているものが多く、このようなゲームに誘われた青少年の多くは知らず知らずのうちに心を破壊され、人間性を失っており、既に幼い少女が連れ去られ殺害される事件が起きている」として、「美少女ゲームの販売を規制すべき」とする内容の請願の紹介議員に、下田敦子参議院議員とともになった（これはカスパルによる請願）。。また、同年の第170回国会においても同党の村井宗明衆議院議員を通じて同請願書を提出している。
1998年バンコクアジア大会で代表初選出。2004年に北京タイガースに入団した後、2007年途中よりシアトル・マリナーズ傘下とマイナー契約。2009年からは再び古巣に復帰している。強肩強打が際立つ中国代表の正捕手。特にスローイングに関してはMLB関係者を驚かせるレベルの強肩と精度を誇る。打撃に関しても荒さは残るものの代表の中軸を任され、本塁打王経験もある一発長打を秘めたパンチ力をもっており、国際試合では攻守にわたって投手を助けてきた。彼の能力を当時の中国代表監督ジム・ラフィーバーは「スペシャル・キッド」と評している。2006年のワールド・ベースボール・クラシックでも西岡剛の盗塁を阻み強肩を見せつけ、さらには上原浩治から一時は同点となる大会第一号本塁打を放った。北京オリンピック代表にも選出されたものの、米国戦で本塁クロスプレーの際に米国選手の体当たりを受けて靱帯断裂の大怪我を負った。これによって2009年WBCは欠場を余儀なくされたが、国内リーグでの開幕から復帰している。2013年のWBCには出場している。
デリゲートは、オブジェクトインスタンスへの参照とメソッドへの参照をペアにしてカプセル化するものである。概念としてはC言語やC++の関数ポインタに近いが、デリゲートは完全なオブジェクト指向である。型安全であるという特徴がある。Object Pascal（Delphi）の「インスタンスのメソッドへのポインタを格納する、メソッドポインタ」と同様のものである。また、Microsoft Visual J++も、Javaと非互換のデリゲートを導入したが、.NET Frameworkのデリゲートはこれらを発展させたものである。なお、C++における「クラスの非静的メンバ関数を指す関数ポインタ」は、関数呼び出し時にそのクラスのインスタンスを必要とする。デリゲートのようにオブジェクトとして扱うためにはstd::functionなどの関数オブジェクトによるカプセル化が必要となる。デリゲートにより、メソッド単位のコンポジション (合成) が可能となる。デリゲートは主に、イベント処理での活用（コールバック処理のカスタマイズ）を想定している。Javaなどでのインターフェイスを利用したイベント処理と比べ、デリゲートによって参照されるメソッド（実体）の名前を自由に宣言できる、振る舞いをカスタマイズするためにインターフェイスの実装やスーパークラスの継承を行なう必要がない（新たにクラスをわざわざ定義しなくてよい）、などの利点がある。C#では複数のデリゲートを+, -, +=, -=演算子によって結合・分離させることもできる（マルチキャストデリゲート）。また、デリゲートの追加・削除と呼び出しに制約を加えて安全なコードを記述するための機構としてeventキーワードが用意されている 。eventキーワードで修飾されたデリゲート型メンバーに、外部からイベントのサブスクリプション（購読）を追加・削除する手段としては、+=演算子および-=演算子によるアクセスのみが許可される。また、eventキーワードで修飾されたデリゲート型メンバーを、クラス外部からメソッドとして呼び出すことはできない。なお、+=演算子および-=演算子の処理をカスタマイズするために、eventキーワードで修飾されたデリゲート型メンバーのaddアクセッサーとremoveアクセッサーを明示的に記述することも可能である。そのほか、スレッドプールを利用して非同期でデリゲートを実行する機能も存在する（非同期デリゲート）。
C#の例を示す。まず以下では、「string型の引数を1つと、int型の戻り値を持つデリゲート」を宣言している。delegate int SomeDelegate(string p);コンパイラによって、System.Delegateから派生するSomeDelegate型が生成される。次に、以下のようなメソッドを持つクラスがあったとする。class SomeClass{  private string someField = "TEST:";  public int SomeMethod(string p)  {    return this.someField.Length + p.Length;  }  public static int SomeStaticMethod(string p)  {    return p.Length;  }}そして、以下のように（デリゲートと同じ引数と戻り値を持つ）既存の名前付きメソッドを参照するデリゲート型オブジェクトを生成することができる。SomeDelegate del = new SomeDelegate(SomeClass.SomeStaticMethod);C/C++の関数ポインタと異なり、静的メソッドだけでなくインスタンスメソッドをデリゲートに代入することもできる（メソッドとインスタンスのペアがカプセル化される）。SomeClass obj = new SomeClass();SomeDelegate del = new SomeDelegate(obj.SomeMethod);C# 2.0以降では、匿名メソッド (anonymous method) としてインラインで記述したメソッドを参照するデリゲートを同時に定義することもできる。この書き方では、return文によって返される値がSomeDelegateデリゲートの戻り値に暗黙的に変換できない場合、エラーとなる。SomeDelegate del = new SomeDelegate(delegate(string p) {  return p.Length;});なおC# 3.0以降では、匿名メソッドの代わりにラムダ式を使って下記のように記述することもできる。SomeDelegate del = (p) => {  return p.Length;};匿名メソッドとラムダ式は併せて匿名関数 (anonymous function) と呼ばれる。匿名関数は外側の変数にアクセスすることができ、これをキャプチャと呼ぶ。匿名関数とデリゲートを用いてクロージャを実現することができる。こうして生成したデリゲート型オブジェクトは、通常のメソッドのように直接実行することができる。int ret = del("some string");なお、上記は以下のInvokeメソッド呼び出しに対する糖衣構文である。Invokeメソッドはコンパイラによって自動生成される。int ret = del.Invoke("some string");しかし、デリゲートの真価が発揮されるのはイベントと併用した時である。イベントは、次のように宣言する。class MyClass{  public event SomeDelegate SomeEvent;}こうして宣言したイベントには、+= 演算子と -= 演算子によって、デリゲート（イベントハンドラ）を追加したり削除したりすることができる。MyClass obj = new MyClass();obj.SomeEvent += new SomeDelegate(SomeEventHandler1);obj.SomeEvent -= new SomeDelegate(SomeEventHandler1);//obj.SomeEvent = new SomeDelegate(SomeEventHandler1); // 外部からの再代入はできないのでコンパイルエラー。//obj.SomeEvent(); // 外部からの呼び出しはできないのでコンパイルエラー。イベントハンドラの追加が += 演算子によって行われることから推測できるように、1つのイベントには複数のイベントハンドラを登録することができる。次のようにしてイベントの定義されたクラスの内部からイベントを起こすと、登録したイベントハンドラがまとめて実行される。class MyClass{  void ExecuteEventHandlers()  {    if (SomeEvent != null)      SomeEvent("some string");  }}実行される順番は登録順とは関係なく、未定義である。なお、eventで修飾されていない通常のデリゲート型メンバーと異なり、SomeEventにはクラス外部から=演算子で直接再代入をすることはできない。また、SomeEventが定義されたクラス内からしか呼び出せない。この制約により、誤ってイベントサブスクリプションをクリアしてしまうことを防止したり、イベントハンドラーを呼び出す責任の所在を明確にしたりすることができる。
プラットフォーム呼び出し（P/Invoke）の際は、デリゲートは既定でアンマネージ（ネイティブ）の関数ポインタにマーシャリングされる。例えば下記のようなC言語関数がMyLibrary.DLLに実装されているとする。typedef BOOL (__stdcall*TMyCallbackFuncPtr)(LPCWSTR fileName);/* カレントディレクトリのファイルを列挙する関数。ファイルが見つかるごとにコールバック関数が呼ばれる。 */extern __declspec(dllexport) BOOL EnumFiles(TMyCallbackFuncPtr callback);対応するP/Invokeラッパーインターフェイスおよび呼び出しの一例は下記のようになる。using System;using System.Runtime.InteropServices;static class MyPInvoker{    public delegate bool MyCallbackDelegate([In, MarshalAs(UnmanagedType.LPWStr)]string fileName);    [DllImport("MyLibrary.dll")]    public extern static bool EnumFiles(MyCallbackDelegate callback);    private static bool MyCallbackMethod(string fileName)    {        Console.WriteLine(fileName);        return true; // 列挙を続行。    }    private static void Test()    {        EnumFiles(MyCallbackMethod);    }}P/Invokeでデリゲートを渡す場合は、デリゲート型のインスタンスがガベージコレクションにより回収されてしまわないように注意する必要がある。また、コールバック関数の呼び出し規約が一致するようにしなければならない（.NET 1.1まではstdcall呼び出し規約のみが使用可能だったが、.NET 2.0以降ではUnmanagedFunctionPointerAttribute属性を明示的に指定することでcdecl呼び出し規約を使用することも可能である）。
D言語には関数オブジェクトがあり、型としてfunctionとdelegateがある。無名関数を作る式として関数リテラルがあり、functionとdelegateのそれぞれに対応した構文がある。関数リテラルの省略構文としてラムダ式がある。functionとdelegateの違いは、作られたスコープの環境にアクセスできるかどうかで、アクセスする場合はデリゲートである必要がある。ラムダ式では内容に応じて、デリゲートである必要がある場合はデリゲートになる。Javaはバージョン8にてラムダ式とともにメソッド参照の機能を導入した。ただしマルチキャストデリゲートに相当する機能はない。C++/CXは.NETマネージ言語ではなくネイティブ言語拡張だが、デリゲートをサポートする。イベントハンドラーの割り当てに利用される。ただし、C++/CXは参照カウントベースのガベージコレクションを採用していることから、強い参照による循環参照を防ぐため、イベントハンドラーの記述にはラムダ式よりも名前付き関数を利用することが推奨されている。Objective-Cは言語機能としてデリゲートを持たないが、Objective-Cを用いたイベント駆動型ソフトウェアを開発する際の基本的なデザインパターンとして「委譲」が採用されている。
尾崎 天風（おざき てんぷう、1886年 （明治19年）12月25日 - 1960年（昭和35年）3月24日）は、日本のジャーナリスト、実業家、政治家。衆議院議員。初名・百平。
佐賀県藤津郡古枝村（現鹿島市）で尾崎重吉の三男として生まれる。1898年頃、父の移住先北海道常呂郡常呂村に来住。すぐに働きはじめ、農業、出前持ち、馬橇の御者、馬喰などを経て、料理屋経営を行う。1916年頃、釧路新聞通信所記者となる。北見実業新聞記者を経て、1920年、札幌に出て休刊中の『北海道報』を継承し『北海道新聞』（現『北海道新聞』とは異なる）に改題して経営を行う。同年4月、裁判所の許可を得て「天風」と改名した。その後、常呂郡置戸村の公有林伐採事件で検挙されて『北海道新聞』が休刊となり、釈放後上京して、雑誌「建設ノ日本」社長となった。1922年頃、大木遠吉鉄道大臣邸で私設秘書のような役割をしていた時に、永井金次郎樺太庁長官と名刺交換を行い、その伝手を頼って名古屋の豪商と樺太に渡り、山林の年期特売の許可を得ることに成功し、樺太林業 (株) を設立するなど財を築いた。1932年2月の第18回衆議院議員総選挙において北海道第五区から立憲政友会所属で出馬して当選。第19回総選挙でも当選して、衆議院議員を通算二期務めた。この間、湧網線速成期成会長を務めた。1937年4月の第20回総選挙では次点で落選。その後、東京で陳情の窓口として活動。第21回総選挙（翼賛選挙）で非推薦候補者として出馬し、善戦したが次点で落選となった。
ウォルト・ディズニーとアブ・アイワークスは当初映画プロデューサーで配給業者でもあるチャールズ・ミンツ（Charles Mintz）の下で実写を織り交ぜたアニメーションシリーズ『アリス・コメディ（漫画の国のアリス）』を制作していたが、作中のキャラクター「ジュリアス・ザ・キャット（Julius the Cat）」が漫画家パット・サリバンの『フィリックス・ザ・キャット』の模倣であったため、サリバンからの抗議を受け、やがてシリーズの人気も下火になったことから、ミンツの指示で新しいアニメーションシリーズを企画しなければならなくなった。そこで2人は実写なしのフルアニメーションの制作に乗り出す。キャラクターを創造するにあたってウサギの案が浮上、また親しみの持てる丸みのある絵柄を追求していく中でオズワルドが誕生した。ウォルトの尽力によって第2作目『トロリー・トラブルズ “Trolley troubles” 』から大ヒットし、全26作品が制作されたが1928年2月、配給先のユニバーサル・ピクチャーズと製作費に関する交渉を行った際、所有権がユニバーサル側にあることを突きつけられ交渉は決裂、さらにチャールズ・ミンツによる従業員引き抜き工作によってウォルトとアブは作品を放棄。オズワルドに関する全ての権利に加えて、有能なアニメーターを手離すこととなったが、スタジオを手中に守った事で、その後、世界で最も有名なネズミのキャラクター「ミッキーマウス」を作り上げる。ウォルト撤退後はミンツの義理の関係であるジョージ・ウィンクラー（George Winkler）、さらに1929年からはウォルター・ランツ（Walter Lanz）によって製作が続けられたが、皮肉にも後にウォルトが制作したミッキーマウスシリーズに報復を受ける結果となり、ユニバーサル・ピクチャーズによるアニメ作品のヒットは、1940年にランツらによって製作されたウッディー・ウッドペッカーシリーズまで待たねばならなかった。2006年2月、ウォルト・ディズニー・カンパニーは傘下のABCのスポーツ実況アナウンサー・アル・マイケルズ（Al Michaels）のNBC移籍と引き替えに、NBCユニバーサルからウォルトが手がけた全26作品の返還に成功、晴れてディズニーキャラクターに加えられる事となった。
1927年から制作が開始され、全26作品がサイレントで作られた。第1作『かわいそうなパパ “poor papa”』は未公開に終わったが、第2作である『トロリー・トラブルズ “trolley troubles“”』が公開されるや人気作品となり、ディズニーは資金を注ぎ込んで作品制作に励む。しかし配給側から支払われる金額は一向に上がっていかないため、1928年2月、ウォルトは結婚3周年記念のニューヨーク旅行を兼ねて、配給先ユニバーサル・ピクチャーズに製作費値上げ等、契約交渉に出向いたが、先方から返されたのはオズワルド等の版権はすべてチャールズ・ミンツとユニバーサル・ピクチャーズに所有権があるため、勝手な作品作りは認めることができない、加えて「さらに製作費を下げなければアニメーターを引き抜く」との答だった。挙句にミンツによって秘密裏に行われたディズニー・カンパニーからの従業員引き抜き工作によって3月に帰ったウォルトが目にしたのは、空席だらけのスタジオと、引き抜きを断ったアブ・アイワークスとその助手の2人のスタッフだった。その後3人は昼間には契約上8月までに製作しなければならない4本のオズワルド作品を制作する一方で、夜になると会社の再建をかけて密かに新たなネズミのキャラクター“ミッキーマウス”の制作に取り掛かった。このオズワルドの苦い経験から、これ以降ウォルト・ディズニー・カンパニーでは「ミッキーマウス保護法」とも揶揄される非常に厳しい版権管理体制が敷かれることになる。このときのオズワルドのデザインは全身が黒く、初期のミッキー（1938年までの「黒目デザイン」）の鼻を縮めたような丸顔で、ミッキーの耳を伸ばし足を大きくしたような姿をしている（手袋や靴は無く、衣装はハーフパンツや片吊りサスペンダー付きのズボンのみ）。作品全体では、ストーリーや細かいギャグのアイデア等、後年のミッキー作品のモチーフを多く見出すことが出来る。また、作中、アニメーションの文字を操って道具にして使うサイレント作品ならではの演出や、自分の耳や足・首その他、身体の各パーツは適宜取り外すなど、独自のユーモラスな描写も取り入れられている。
1928年にウォルトの契約が切れると、ジョージ・ウィンクラーが製作の中心となり、ディズニー・カンパニーから引き抜いたアニメーターらで制作が継続された。1929年制作の『ヘン・フルーツ “Hen Fluit”』でオズワルド作品上はじめてのトーキーを実現させた。しかしユニバーサル・ピクチャーズ設立者であったカール・レムリはこのような制作体制は認めず、間もなくユニバーサル・ピクチャーズ直営の体制に変換させた。
1929年、カール・レムリからの指名を受けたウォルター・ランツはこれ以降のオズワルド作品の制作に携わった。しかし、オズワルドのキャラクターデザインは、当初のデザインをベースにしながらも変更が加えられた。表情を鮮明にする意図から頭を大きくして頭身が低くされ、「人間の子どもの立ち姿」のようなスタイルとなり、黒い楕円だった目には三角の「スリット」が入れられた。また衣装を身につけるようになり、普段の姿も「半ズボン、白手袋、靴」と、ミッキーマウスを意識したかのような姿となる。 さらに1935年以降は自然な形を重視するため、ステレオタイプな「ウサギのキャラクター」へと大幅に改変され、ディズニーやアイワークスらが創作したオズワルドのキャラクター造形とは完全に異なる姿に移行する。結局、こうした改変が観客の不評をかったことや、ランツが自身のオリジナル・キャラクターである「ウッディ・ウッドペッカー」や「アンディ・パンダ」で人気を確立したこともあり、1943年を最後にオズワルド作品はついえることとなった。2004年から2005年にかけて日本ではクレーンゲームの景品（タイトー）やキューブリックとして、1935年以前のウォルター・ランツ時代のデザイン（カラーはネイビーブルー）のオズワルドが商品化された。
2008年には「ウォルト・ディズニー・トレジャーズ」シリーズのひとつとしてDVD化され、初期短編のうち13作品が収録。その後は初期短編がディズニーチャンネルで放送されることがある。2010年から2012年にかけて開催された東京ディズニーランドの春季イベント「ディズニー・イースターワンダーランド」にオズワルドをデザインしたフロート車が登場した。2010年のゲームソフト『ディズニー エピックミッキー 〜ミッキーマウスと魔法の筆〜』ではミッキーマウスと初共演を果たし（声・フランク・ウェルカー）、続編の『ディズニー エピックミッキー2:二つの力』ではプレイヤーキャラクターのひとりとなっている。2013年（日本では2014年）公開の『アナと雪の女王』と同時上映された『ミッキーのミニー救出大作戦』に数秒間ながら出演、返還後初のアニメーション作品への登場となった。2014年4月2日から2015年3月31日まで、東京ディズニーシーのアメリカンウォーターフロント内にある、ケープコッドでキャラクターグリーティングを開催。全世界のディズニー・パークの中で初お目見えとなった。ディズニーチャンネルで放送中の短編アニメーション『ミッキーマウス!』にゲストキャラクターとして出演している[11]。2017年6月23日にアメリカで初放送、のちに日本でも放送された。
26作品のうち7作品が行方不明となっていたが、2018年に行方不明作品のひとつ「Neck 'n' Neck」のフィルムが日本のアニメ史研究家の所蔵品から発見された。フィルムは神戸映画資料館で保管されている。
1927年に制作された第2作で、大ヒットした。オズワルドはトロリー（路面電車）の運転士として登場する。線路の幅が変わるのに対しトロリーの車幅がそれに応じて変化し、また牛が線路をふさいでいるのに対し電車が下をくぐって前進するなど、初期のミッキー作品でも登場するユーモラスな動きが既に随所に表れている。
CardWirth（カードワース、略称「CW」）は、「groupAsk」（「開発者と公式サイト」の項にて後述）によって開発され、1998年8月にインターネット上で公開された。公式サイトに記述された紹介文によると「CardWirthはTRPG（テーブルトークRPG）の自由度と、カードゲームの遊び易さを融合した、新しい形態のRPG」とされている。自由に移動できるフィールドを持たない、画面内に配置されたカードをクリック（選択）することでゲームを進行させていく、キャラクターの能力値のほとんどが隠蔽されている、戦闘システムがカードバトルになっているなどの独特のゲームシステムが特徴である。そのプレイ感覚はコンピュータゲームに当てはめて例えた場合、どちらかといえばRPGよりもアドベンチャーゲーム (AVG) やサウンドノベルに近い。多くのRPGと異なり基本的に固定されたストーリーを持たず、「シナリオ」と呼ばれる外部データをユーザーが追加してプレイする形式が採られている。シナリオについては、CardWirthがTRPGを意識しているだけあって、特定のシナリオをプレイすることによって以降連鎖的にプレイ可能となるキャンペーンシナリオ形式にも対応している。CardWirth本体はシナリオを読み込み、動作させるためのエンジンとなっている。またこのエンジンとは別にシナリオ作成用エディタも公開されており、ユーザーの手によってシナリオを制作することが可能。現在ではユーザーが作成したシナリオやCardWirthでの利用に適した各種のリソース（画像、楽曲）が多数公開されている。一般に人気フリーソフトゲームのコミュニティ形成は「作者」：「ユーザー」の関係が一対多であることが多いが、CardWirthは先述の通りユーザーが創作側に回ることも珍しくなく、多対多のコミュニティが形成された。
groupAskは当初から同人ゲームの制作のみを目的としていたわけではなく、また制作したソフトウェアを同人誌即売会で頒布していない事からも、狭義における同人サークルとはスタンスの異なる同人集団である。かつてgroupAskの公式サイトに「groupAskはネットワークという仮想世界に存在するソフトウェア開発グループであり主にWindowsのソフトウェアの制作を行っている」という主旨の一文を掲載していたことからも、その事がうかがい知れる。もっとも、結果として同人ゲームであるCardWirth以外のソフトウェアを開発するまでには至らなかった。groupAskのメンバーは斉藤・倉貫・赤塚の3名。groupAskの「Ask」とは、groupAskのメンバーでありCardWirthを開発したメンバーでもあるこの3名の頭文字から名付けられた。この3名は当時大学の研究室で一緒に作業をしており、斉藤が年長で、倉貫と赤塚が一年後輩にあたる。開発時にはプログラムの大半を倉貫が、音楽を赤塚が担当し、グラフィックとシナリオの数多くを斉藤が手がけている。CardWirthがインターネット上で公開されるようになってからは主に倉貫が公式サイトの運営作業に当たる。その役割はサイト情報の更新に加え、ユーザー間の交流を目的に設置された各種コンテンツの管理、そしてユーザーが制作したシナリオを投稿できる「Adventurer's GUILD」（通称「ギルド」）と称されるサイトの運営であった。もっとも、現在は3名とも社会人として多忙な日々を送っているため、こうしたCardWirthの開発・公式サイトの運営作業からは退く。現在はgroupAskから正式に委託を受けた"CardWirthを愛する有志によって結成された団体"である「カードワース愛護協会」によって運営される公式ファンサイト、「groupAsk official fansite」がその機能を引き継いでいる。。
開発当初、CardWirthはProject_RPG3という開発名で呼ばれていた。斉藤が開発し始めたゲームプログラムの3つ目の意味で、Windowsプラットフォームで開発されたのはこれが最初のもの。本人の談によると、当初は10分くらいで終了するブリキの玩具のようなものが想定されており、インターネット上で公開するつもりもなかったという。後に倉貫・赤塚の両名が開発に加わり、このプログラムが本格的なゲームとしての具体性を帯びることになった事から、CardWirthは世に登場した。
CardWirthという名称、とりわけWirthという単語については、groupAskによる公式見解が存在しておらず名称の由来は不明である。"数日間悩んだ末、どこからか出た言葉"という赤塚の発言などもあるが、groupAsk名義で正式に定義されたことは無い。ユーザーの間でも過去に幾度かの考察がなされ、古くはWirthとは伝説や伝承を意味する言葉であり「札伝説」という意味であるというものが、後にはWirthは英語の古語で「自分で商売を営んでいる人」、転じて「宿屋の主人」を意味するというものが定説となった。
CardWirthのプログラムには先述の通り、本体となるシナリオ動作エンジン（CardWirth本体）とシナリオ作成用エディタ (CardWirthEditor等) が存在する。（配布はエンジン単体・あるいは両者をパッケージングした形態で行われているので必ずしもエディタがシステムに含まれるわけではない）これにデフォルトの各種リソース、データ、そしてユーザーが各自で追加したシナリオ群によって構成される。配布されているバージョンやパッケージング形態によっては後述する「エフェクトブースター」などが含まれていることもある。
CardWirthは設計された時期や開発コンセプトの関係上、DirectX等の複雑な描画・音響エフェクトは使用されておらず、基本的にそれほど高いスペックは要求されない（Windows 95以上が動くパソコンであれば問題はない）。そのこともあり、Windows XP以降の環境に十分に対応できていない状況が一時期続いていた。最新のバージョンではこの点は解消されているが、半面、描画・音響共に機能が向上していることもあって快適に動作させるためにはそれなりのスペックが必要となっている。（動作環境はCPUは1GHz以上、メモリは32ビットOSで1GB以上・64ビットOSでは2GB以上に改められている）
CardWirthEditorで制作したシナリオを動作させる、CardWirthの本体部分（エンジン）。このプログラム単体でゲームを起動することが可能。
CardWirthNextは、CardWirthエンジンVer.1.50を開発したLynaが手がける、派生エンジンの一つ。元はCardWirthエンジンVer.1.60として公開される予定であったが、完成直前にLynaが所属していたgroupAsk official fansiteから脱退したことで非公式エンジン扱いとなった。（そのため現在もこのエンジンのタイトルは「CardWirth Ver.1.60」となっている）このCardWirthNextという名称は、当初はソースコードを刷新したCardWirthエンジンのことを指しており、一時期はその嚆矢となるCardWirthエンジンVer.1.50もこれに含まれていたが、現在では公式エンジンとの区別を明確にする意味合いもあって、その定義で用いられることはほとんどない。CardWirthエンジンVer.1.50をベースにしているため基本となる部分はそれほど変わらないが、CardWirthエンジンにはない独自の機能が多数実装されている。またCardWirthエンジンに対し上位互換であるため、CardWirthエンジンのデータをそのまま利用できる。ただし、Nextエンジン及び後述するWirthBuilderから生成されるデータは独自形式となるため、一度変換してしまうとそれらは他のCardwirthエンジンとの互換性は一切なくなり、また各種のツール類を利用することも同様にできなくなる。
CWIは、クローンエンジン開発プロジェクトの一つ。CardWirthユーザーの一人であるThomasによって開発され、C#によって記述された独自の互換エンジンを持つ。現在は開発停止しているが、ソースコードが公開されているため、派生プロジェクトやこのエンジンを利用したツールなどが発表されている。同時にシナリオデータの仕様についても独自の解析結果を公表しており、後述のCardWirthPyでもその成果が利用されている。
CardWirthPyは、クローンエンジン開発プロジェクトの一つ。プログラム言語「Python」によって一から開発された独自の互換エンジンを用いており、「フリー・オープンソースの維持」「CardWirthとの99%の互換性を目指す」を標榜している。オープンソースであるため、プロジェクトへの参加やコードの変更は誰でも認められている。「CardWirthとの99%の互換性を目指す」のCardWirthとは、Ver.1.20からVer.1.50までのCardWirthエンジンおよび後述のバリアント仕様に改修されたエンジンを指しており、これらと双方向での互換性を持っている。一方で独自の拡張機能を多数備えており、シナリオのデータ形式をXMLによって記述されるCardWirthPy独自の形式のものにすることで、そうした機能を利用することもできる。前述の通りCardWirthNextのデータ形式を利用することはできないため、CardWirthNextとの互換性までは考慮されていないが、CardWirthPyの拡張機能にはCardWirthNextの独自機能と同等の機能を持ったものも一部存在する。
groupAskが配布している「CardWirthEditor」と、CardWirth Ver.1.28の仕様に合わせて軽微な改造を施してgroupAsk official fansiteがかつて配布していた「CardWirthEditor2」が存在するが、基本的に同一のものである。多くのエディタがスクリプトでの記述を必要とするのに対し、CardWirthEditorはインタフェースとして完全なGUIを備えており、全くの初心者であっても容易に扱えるのが特徴。その一方で、コンテントと呼ばれるアイコン化された一連の処理の並びが一般的なプログラミング言語のソースコードとそれほど変わらないため、昨今用いられるプログラミング言語（PerlやJavaなど）による開発に慣れているユーザーも直感的に扱えるという、非常に優れた開発ツールとしての一面も持つ。ただし、あくまでもCardWirth用に作られたシナリオエディタに過ぎないので、高度なプログラミングにまで対応しているわけではない。もっとも、多少複雑な処理を組み込むにしてもシナリオを制作する上で困ることはほとんどない。少なくともサウンドノベルのような形式のシナリオを作るのであれば、基本的なコンテントをいくつか覚えるだけですぐにでも思い通りの物を制作することが出来る。なおCardWirthEditorを長時間起動しているとメモリの使用量が増加していくという問題点（おそらくメモリリーク）が確認されている。
CardWirthEditorの後継として開発されたシナリオ制作エディタで、CardWirthエンジンVer.1.29以降に追加された機能をシナリオに盛り込むためにはこちらのツールを使う必要がある。ユーザインタフェースはCardWirthEditorを踏襲しており、旧来からのユーザーでも違和感なく操作できるようになっている。CardWirth Ver.1.50 フルパックではCardWirthEditorを完全に廃してこちらだけが同梱されるようになった。また、前述のCardWirthNextに同梱されているシナリオ制作エディタも、（CardWirthNext専用版となってはいるが）このWirthBuilderである。CardWirthエンジンVer.1.50用のものと見た目や使用感はほぼ同じであるが、前述の通りこのエディタを介して出力されたシナリオのデータは新規・既存を問わずこれまでと異なる専用の形式で保存されるため、他のエディタ（プロジェクト）では利用できなくなる。
元は前述のCardWirthPy専用のシナリオ制作エディタとして、CardWirthPy本体とは別のプロジェクトにより開発されたシナリオ制作エディタであったが、後にCardWirthエンジン用のシナリオも取り扱う機能が実装された。これにより、CWXEditorを使用することでどちらの形式のシナリオも作成することが可能となっている。CardWirthエンジン用の形式でシナリオを作成した場合、CardWirthEditorおよびCardWirthエンジンVer.1.50用のWirthBuilderで作られたシナリオデータと完全な互換性があり、相互で利用可能となっている。CardWirthPy専用のシナリオ形式でシナリオを作成した場合、CWXEditor以外で編集することはできない。また、前述の通りCardWirthNext用のWirthBuilderで作られたシナリオは独自形式で保存されるためCWXEditorで編集することは出来ず、CardWirthNextの機能を使ったシナリオをCWXEditorによって制作することも出来ない。非常に強力な各種シナリオ制作支援機能が搭載されているが、多機能すぎることやユーザインタフェースがCardWirthEditorと全く異なる事などから、旧来からのユーザーも含めて扱いにはそれなりの習熟が必要となる。
Ver.1.15にまで存在していた、CardWirthのプレイ時の各種データに対して修正や編集を行うためのユーティリティソフト。Ver.1.20からはエンジンにその機能の大半が譲られる形となり廃止されている。しかしこのプログラムには引退したプレイヤーキャラクターの具体的な数値データを見ることが出来るという、現在のエンジンにはない大きな特徴があった。
groupAsk official fansiteによって一から開発されたもの。これは単体のソフトウェアの名称ではなく、CardWirth Ver.1.20でJPEGファイルを読み込むために作られたDLLファイルを拡張し、画像エフェクト処理の再生機能を追加したものを利用した技術と、その関連ソフトウェアの総称である。この技術を利用することでCardWirthに様々な画像エフェクト機能を追加できるようになるが、CardWirth単体とは異なり使用時の再生パフォーマンスはハードウェアの性能に大きく依存する。関連ソフトウェア群の使い勝手がCardWirthEditorほど良くなく、またヘルプ群が不足していた（リファレンスですら説明が不十分である）点からあまり普及せず、一部のヘビーユーザーが使用するにとどまった。元々は開発者が試作ツールとして開発を進めていたものであり、一般に公開する予定がなかったという。CardWirthVer.1.50では上記のDLLが使われていないことから、現在エフェクトブースターは同バージョンのパッケージ内に同梱されていない。替わりにエンジンそのものに同様の機能が備えられており、既存のエフェクトの再生が可能。また一部機能に関してはWirthBuilder上からその設定が可能となっている。
エフェクトブースター関連のプログラムとしてかつて公開されていた開発ツール。エフェクトブースターの機能は独自仕様のスクリプト言語によってパラメータをいくつか記述するだけで使用できたが、完全にGUI化されたCardWirthEditorに慣れ親しんでいたユーザーからすれば扱い難いという問題があった。これを解消すべく後日このツールが公開されたが、エフェクトブースターの全機能が扱えない、また使い勝手の点でも洗練されているとは言えず、結局完成度が低いままに終わってしまった。
シナリオは、実際にはWindowsの1フォルダとしてパッケージングされたファイル群によって形成される。その主な内容はシナリオのソースファイル、シナリオのデータファイル、そしてリソースファイル（BMP・JPEG・PNG・MIDI・WAV・MP3・その他）となっている。オリジナルのCardWirth本体には「交易都市リューン」「ゴブリンの洞窟」の2本があらかじめ収録されている（ただし、収録されている付属シナリオは後述するバリアントの種類によって違いがある）。
当初は、多くのファンタジー作品に見られるような中世ヨーロッパをモチーフとした“剣と魔法の世界”がゲームの舞台として設定されていた。もっとも、CardWirthはユーザーがシナリオを自由に制作できる上、開発者のgroupAskもユーザーに対してシナリオの制作に関して特に制約を課すことがなかったので、ゲームの舞台となる世界観は必ずしも固定されたものではなかった。そのためシナリオによっては前述の世界観と大きくかけ離れた世界が舞台となる事もあり、銃器や活版印刷が当たり前のように普及している場合もあれば、それどころか科学技術によって宇宙に進出するようなことさえある。後に"CardWirthをまったく違う世界観で楽しもう"というコンセプトから「バリアント」と呼ばれる、CardWirthのシステムにパッチを当てた派生バージョンが誕生し、現代社会を舞台としたCardWirthなどが登場するようになった（なお、CardWirthにおけるバリアントとはこのように世界観そのものの変革を含めた意味となるため、CardWirthエンジン内のリソースファイルを変更しただけの改変プログラムはバリアントには該当しない）。ただし、バリアントは現状あまり普及しているとはいえない。これまでのところバリアント用エンジンはCardWirth Ver.1.28の実行ファイルを改変して作られているため、CardWirthNextでバリアント用に改造する手法は確立されていない。CardWirthPyではユーザーの手元にバリアント用エンジンがあれば、そちらのリソースを取り込むよう指定することで動作する。
groupAskがCardWirthの世界観として用意したもので、バリアントではなくオリジナルの世界観。中世ヨーロッパの都市に似た「リューン」という名の街を中心に、子守から人探し・護衛・モンスター討伐・果ては世界の命運を掛けるような大冒険まで、さまざまな仕事の依頼を引き受ける冒険者達の活劇を描く。プレイヤーは「冒険者の宿」に集まった、そんな冒険者達を駆ることで、それらの仕事を次々と引き受けていくことになる。本来の意味での公式設定というものは一切存在しないが、CardWirth（ファンタジーI型）においてはgroupAskが制作したシナリオに登場するわずかな設定を「公式設定」と定義することがある。そういった「公式設定」のほとんどがぼかされているのが特徴で、たとえば教会や神聖魔法が存在するのに神の定義が全く存在しなかったり、また舞台であるリューンにしても国家であるとは明言はされていない（ただし、王国騎士団の存在から王国であるらしきことなどは窺える）。リューンとその周辺のいくつかの文化・宗教・地理などの設定と、過去に超古代文明世界と古代王国期が存在していたという歴史などが、わずかに垣間見える程度である。この事から、各シナリオ作者は自作のシナリオにおいてそれらを自由に設定できると同時に、それらが公式設定たり得ることもない。なお、「公式設定」はおろかユーザーズシナリオを含め全体を見ても、エルフやドワーフといった有名どころの亜人があまり登場しないという王道的なファンタジー世界としては特異な傾向が見られる。
バリアントシステム第一弾として提唱元であるgroupAsk official fansiteがリリースした作品。現代から近未来にかけての日本（？）を舞台としており、プレイヤーキャラクターも冒険者から探偵事務所に所属する探偵という立場に変わっている。魔法の代わりとして超能力のようなものが一応存在している世界となっている。この設定を世界観として公式にサポートしていることから、世界観が中途半端で解りにくいという批判もわずかながらに存在した。
CardWirthユーザーの一人、「じぇんつ」が制作したバリアントシステム。現代日本（？）の巨大学園が舞台となっており、その近辺で巻き起こる日常・非日常な毎日をクラスメイトや先輩後輩、教師達と一緒になって送ることになる。世界観の変更に合わせて全体的なゲームシステムおよびゲームバランスの見直しが行われており、単純な世界観のすげ替えだけにとどまらず、既存のシステムと世界観を上手く融合させて新たな解釈を生み出した、バリアント企画の好例となった。
CardWirthの閉塞コミュニティ（「ユーザーとコミュニティ」の項にて後述）の一つで開発が進められてきたバリアントシステム。架空の東方国家「日の本」が舞台となっており、プレイヤーキャラクターは長屋を拠点とする「仕事人」（この世界における冒険者）という設定。江戸という響きから時代劇的な世界観を想定しがちだが、実際はファンタジーI型同様に細部はそれほど決められておらず、やはり各作者の裁量によって世界観をある程度変化させることが可能。実際、このバリアントシステムに同梱されているシナリオ「狸の住まう穴」の内容は正統派時代劇とは無縁の妖怪退治となっている。このことから江戸というよりは和風ファンタジー全般を扱っているとみた方が早い。同じ様に多様性を取り入れた現代バリアント・探偵に比べ、単純にこれまでファンタジーI型で行ってきたことを和風なものに置き換えさえすればよいという利点があり、創作は行いやすい。
上記以外にも人獣・悪鬼・蜥蜴・妖樹・悪魔など複数種族の妖魔が共棲する森での日々を描く妖魔バリアント、城で永い眠りから目覚めた黒曜・紅玉・黄金・白銀の４血族の吸血鬼達の冒険を描く吸血鬼バリアントなどバリアントシステムの作例がこれまでにいくつか存在するが、閉塞されたコミュニティ（「ユーザーとコミュニティ」の項にて後述）内で確認されている程度でこれまでのところ広く認識されているものはない。
ゲームを初めてプレイする際にはまず冒険者達の所属する、冒険者の宿を作成することから始まる。以後、プレイヤーはこの宿で冒険者の登録やパーティ編成などを行うことが出来る。手始めに、まずはこの宿に所属する冒険者の登録作業（プレイヤーキャラクターの作成）を行うこととなる。冒険者については名前や外見、性別や年代に加え能力の傾向と特徴を自由に設定可能。一度の冒険（シナリオ）に投入できる1パーティ（チーム）の人数は最大で6人までだが、宿自体に登録できる冒険者の数に上限はない。また、ある冒険者パーティでの冒険の最中でも「中断」することで他のメンバーを別の冒険に向かわせてプレイすることが可能。
シナリオの内容は必ずしも冒険（仕事）ばかりとは限らない。中には街や店で冒険者達が冒険の役に立つ武器や道具類である「アイテムカード」や、特技や魔法といった技術である「スキルカード」を購入するためのものも存在する。購入したカードを冒険者達に持たせることによって、それらの「カード」を冒険中に活用することが可能になる。一人が所持出来るカードの枚数はその冒険者の実力（いわゆるレベル）に応じて増加する。CardWirthには一般的なコンピュータRPGによく見られる職業（クラス）という概念はないので、ゲーム中の有利不利さえ気にしなければ冒険者の能力値の傾向と異なるカード、例えば豪傑タイプのキャラクターであっても魔法を所持することが可能。なお、CardWirthでは一般的な武器や防具といったものは各自あらかじめ装備しているものとみなされているため、それらを用意する必要はない。
全てのシナリオで共通しているわけではないが、基本的に冒険者は冒険者の宿で「仕事」の依頼を宿の主人あるいは依頼主から直接話を聞いた上で請け負い、出発するところからシナリオはスタートすることになる。依頼の内容は千差万別であり、駆け出しでもこなせる簡単な仕事から非常に危険で困難なものまで幅広く存在する。（大まかな難易度は「対象レベル」として予め表示される）
プレイヤー（プレイヤーキャラクター）が自由に行動を起こせるようになると、画面上にカードが表示される。プレイヤーがマウスポインタでカードをクリックすると基本的に何らかの反応があり、それによりゲームが進行する。多くの場合はメッセージが表示され最終的にいくつかの選択肢が出てくるのだが、時には冒険者の所持する「カード」を使って能動的に行動を取り、その後の展開を有利に進めたい場面も出てくるはずである。（たとえば敵の見張りを魔法の力で無力化したい、明らかに怪しい場所を調査技能を使って徹底的に調べてみたい、など）このような場合は画面上に表示されているカードに対して冒険者が手持ちの「カード」を使用することで狙い通りの動作を実行できる事がある。（シナリオ側がプレイヤーのそういった行動に対応していなければならない）。これは本作品の特徴のひとつで、「TRPGらしい」と言わしめる重要な要素となっている。
時には冒険者達と敵対する存在との間で戦闘が発生することもある。戦闘自体は一般的なターン制だが、よく見られるコマンドを入力する方式ではなくカードバトル方式となっている。それぞれの冒険者が手札として配布されたカードの中から適当と思われる一枚を選び、使用することで戦闘を進めていく。（なお冒険者達のカードは毎ターン自動的に選択されているが、プレイヤーが自由に選択することも出来る）手札には「攻撃」や「防御」といった基本的な行動が取れるカードの他に、プレイヤーが事前に用意しておいた「アイテムカード」や「スキルカード」も加わることになる。常に手札として用意されるアイテムカードを別にすると、手札として回ってこない行動を取ることは当然出来ない。また冒険者達のレベルが低いうちは手札の枚数も少なく、特殊なアイテムカードを所持していないとスキルカードもなかなか回ってこないなどカードバトルならではの特徴があり、それらを考慮した駆け引きが楽しめる。なお冒険者は基本的に「意識不明」になっても死亡する事はなく、比較的容易に戦列に復帰することが出来るが、全員が戦闘不能となった時点で敗北となり、ほとんどの場合はそれでゲームオーバーとなる。（イベントが発生し、そのままシナリオが継続されることもある）
無事に依頼を果たせたかどうかは別にして、宿に生還することが出来ればシナリオは終了する。多くの場合この時点で仕事に対する評定が行われ、成功報酬が支払われることになる。冒険者達の名声は経歴として残り、それが成長につながったり（一定以上の名声を得ることで、レベルが上がる）、またこの経歴が後の冒険につながることもある。（キャンペーンシナリオの前提条件となる）その他に、冒険の最中で一時的に仲間が加わることがあるが、そういった人物を新たな冒険者として宿に迎え入れることが出来るのもCardWirthの特徴の一つとなっている。（こちらについてもシナリオ側の対応次第）。
CardWirthはシリーズ化されていない単一の同人ゲームとしては非常に息が長いため、登場してから今日に至るまでの歴史を把握している者は今では非常に少なくなっている。以下はCardWirth全体を取り巻く大まかな流れをまとめたものであるが、個々の出来事をより詳細に記録した文献としてファンサイトの一つである「拾穂文庫」に「CardWirth史年表」というコンテンツが存在する。
CardWirthが公開されて間もないこの頃は当然ユーザー数も少なく、それに比例してシナリオやリソースもほとんど存在しなかった。裏を返せば、この当時からCardWirthの持つ魅力に気付き、盛り上げていくことに尽力してきたユーザーが多く存在した時期と言える。「ないものは作るしかない」、この発想からかこの頃のユーザーは一人のプレイヤーであると同時に自身が優秀なクリエイターでもあった。「Adventurer's GUILD」への投稿数がまだそれほど多くなかったこの頃は、groupAskによって投稿シナリオ一つ一つに対しコメントが付けられていた。また、極めて短期間ではあるがシナリオへの人気投票システムが稼動したこともあった。しかし人気投票についてはフリーソフトのゲームに評価で優劣をつけるということに対し疑念を抱くシナリオ作者も多く、騒動の元となった。その後、投票対象となるシナリオを登録制へと改められるなどの改良も行われたが、最終的には評価することの意義そのものが問われることになり、このシステムは廃止された。この議論以降、「Adventurer's GUILD」でのシナリオの取り扱いは「シナリオの登録」のみとなり、評価に関する一切は無くなる。
メディアでCardWirthが取り上げられる機会が多くなったこの頃、当時のインターネット事情とも相まってユーザーの総数が一気に増加し、それに伴いユーザーが作成したシナリオの登録数も急速に増加した。「Adventurer's GUILD」には大量のシナリオが登録されるようになり、実力派と呼ばれるようになるシナリオ作者達も多く現れた。その一方で、「Adventurer's GUILD」に投稿されるシナリオの完成度には大きな開きができ、まさに玉石混交といった様となり混迷を極めた。また、あまりの投稿数の増加にgroupAskによる手作業での登録作業では追いつかなくなり、一時は「Adventurer's GUILD」が機能しなくなるなどの弊害も見られた。（その後、公式サイトの移転と同時に「Adventurer's GUILD」をはじめとするユーザー情報の登録作業はすべて半自動化された）この頃はCardWirthを取り扱うユーザーズサイトも次々に開設され、オフ会などの動きも含めユーザー間による交流が最も多く見られた時期でもあった。
シナリオの投稿数が増えたことはユーザーにとっては歓迎すべき事態であると同時に、氾濫するシナリオを持て余し、自己にとってより良質のシナリオだけを求めるユーザー層（悪く言えばDOMユーザー）も増やす結果となっていった。その流れを象徴するかのように、それまで何度かに渡って物議を醸してきた「シナリオ作者としてのユーザーの視点」と「プレイヤーとしてのユーザーの視点」のずれ、すなわちシナリオの評価についての是非が再び持ち上がる。評価を是とするこの時の動きはそれまで以上に大きなものとなった為、シナリオ作者を中心とした多くのユーザー層からの不満や不信、反発といったものを招き、CardWirthコミュニティを二分するほどの勢いで意見の衝突を引き起こした。当時コミュニティの中核をなしていたユーザーの多くがこれらの騒動に大なり小なり関わってきたことから、議論が平行線のまま収束する頃にはそういったユーザーも様々な理由で次第にコミュニティから遠のいていった。急騰した人気が一段落したこともあり、ここからそれまでの賑わいが急速に収縮していくこととなる。