[戻る]
徹底改造SOLD
name：そとや 2006/02/28 19：18：22
え〜と、お久しぶりですｗ
ついに改造SOLD OUTに乗り出したんですね〜。
fukuさんの改造するSOってなんか凄いのになりそう＾＾；
僕も何回か改造SOを作ってみて（あの後も何度も作ろうかと
思ったんですけど、過去を反省してやめました(笑)）
改造SOってプログラミングの腕よりもどうするかの構想を練る
方がずっと大変なんですよね・・・＾＾；
長かったSOIE作成もいよいよ終わりに近づいて
大変でしょうに、また改造SO作成に取り組むなんて
すごいですね♪
もし完成したら絶対遊びにきますんで、
がんばってください〜〜(^□^)ｼ
name：fuku@管理人 2006/03/01 01：26：49
お久しぶりです〜
>ついに改造SOLD OUTに乗り出したんですね〜。
>fukuさんの改造するSOってなんか凄いのになりそう＾＾；
そうですねぇ、なかなかもの凄い構想になっております(笑)
構想だけ先行して実装、デバッグは年単位かかりそうな感じで、
しかも公開可能な負荷レベルになるのかすら分からない感じですが、
いつか、完成できるようコツコツと地味に進めたいと思います(笑)
name：Duke 2006/03/12 00：55：10
すれ違いでしょうがスレの節約のためここにｗ
以前から思っていたのですが、現商人物語の 由來
さんの作成したプログラムには、ほぼすべてに
「このプログラムは「カスタム使用」設定下では正常に動作しない可能\性があります。<br>
_config.cgiや_config-item-custom.cgi等にてカスタムページ使用を無効化してください。」と記述されているのですが、これはなぜなのでしょうか？
カスタムページを使いたい僕としては、ちょっとこの記述が気になるのですが
fukuさんなら知っているかな？と思ってここに書かせていただきました。
あと、2chを読んでてわかったのですが
SOLDOUT VIP街という街をご存知でしょうか？
現在かなりのペースで改造が加えられていて
参加者もかなりすごいところなのですが、
株式システムの要望が現在目立っています。
やはりプレイヤーとしても株はブームみたいなので、
新しいSOLDOUTに株というものをつけても面白いかもしれませんねｗ
僕は、ある人からの許可をいただいて
学習人工無能のSOLDOUT移植のproto版を作成いたしました。
でもまだプログラムとしての完成度は低めなので、がんばりたいと思います。
name：fuku@管理人 2006/03/12 07：07：47
どうも。
スレッドリソースが尽きそうになったら古い記事の過去ログ化でもして空き増やすのであまり気にしなくても(笑)
>現商人物語の 由來さんの作成したプログラムには、ほぼすべてに
>このプログラムは「カスタム使用」設定下では正常に動作しない可能性があります。
依頼スクリプトに書いてあったのは確認できたのでちょっと調べてみましたが(ソース見てただけですが)、
カスタムページを使用することで問題発生するという明確な証拠は見つかりませんでした。
現時点では修正されているが安全のため残っているとか、パッと見でわからない部分で問題を起こすとかなのかもしれません。
書いてあるからには過去に何かあったのでしょうが・・・
実際にやってみない限り、分からないかもしれませんね。
>SOLDOUT VIP街という街をご存知でしょうか？
一応知ってます。以前私のスクリプトを使用しているところを検索した時に出たところです、確か。
・・・今改めて探してみると、同名もいくつか。
2chっぽかったので合ってるとは思うのですが、2ch読んでるわけではないのでなんとも。
>株式システムの要望が現在目立っています。
去年あたりにニュースになりまくったのも拍車をかけてるのかもしれませんね〜。
ただ、株を実際にゲームに組み込むとなると、事実上厳しいんですよねぇ。
リアルにしようとするとそれなりに売買要求がないとただの商品と同じですし、
適当にランダムにしたらロトくじみたいな物になってしまうので、
うまく特徴が出ない可能性が高いのです・・・
>学習人工無能のSOLDOUT移植のproto版を作成いたしました。
人工無能は確か自動応答会話プログラムだったと記憶していますが、SO移植とはどのようなものなのでしょう？かなり興味があります(笑)
(人工無能については以前会話ログをネット上で見たことがあるだけなので、間違ってるかもですが・・・学習がついてるから別物だったりして^^;)
name：Y.Y 2006/03/12 22：33：49 http://tpy.in/
お久しぶりです。
私も徹底改造ネタを考えてはいるのですが実際に改造に着手する時間もなく、とりあえずShakeMaster2とTopFounder2を最新システムに移植する作業を行っております（がミスがあったようでorz）
>しかも公開可能な負荷レベルになるのかすら分からない感じですが
負荷の件ですが、次期自宅サーバでは最低でも現在の五倍くらいの性能を考えており、これは通常のレンタルサーバ（の中くらい？）に匹敵する性能です。
よって「重いSoldOut」でもある程度「快適」に動作できるようになると思います。
が、如何せんADSLですので・・・回線が細いのです。
光ファイバーの導入も前向きに検討して入るのですが・・・サービス提供開始時期すら未定の田舎でして。
とりあえず次期サーバーは初期費用（正確には購入費用ですが）が貯まり次第、「ファンレスで動作する」ことを条件にバリバリSoldOutが稼動できるような、そんなサーバーを目標にしております。
まだ明確な条件を定めていないのですが、「優秀なSoldOut」ならばどんどん設置していただき（FTP権限付で！）「優秀なSoldOutが負荷のために消えてゆく」という状況を打破しようと鋭意準備中ですので、ご安心を。
現状の自宅サーバーと同等もしくはそれ以上の安定性を確保予定ですので、安定性に関しては現状の自宅サーバーをご覧いただければと思います。
なんか自宅サーバーの宣伝みたいになっちゃいましたが（汗
忙しい日々を送っていますがなんとか私は「生きてます」w
name：fuku@管理人 2006/03/13 03：16：25
お久しぶりです。
徹底改造ってのもやってみると思ったより大変ですねぇ、
どんどん膨らむ構想とそれにつれて現実味がなくなっていく実装、
どの辺で折り合いをつけるかという本筋と違う壁が(笑)
(負荷うんぬん以前に実装自体が作れないような構想が・・・^^;)
そしてバランス調整も、ここまで基礎から変えちゃうと標準の流用では利かないし・・・ってな感じです。
>よって「重いSoldOut」でもある程度「快適」に動作できるようになると思います。
>が、如何せんADSLですので・・・回線が細いのです。
ADSLでも上り最大512Kbps=64KB/秒は出たと思いますが、SOが返すHTMLは問題とするほどの大きさなのでしょうか？
(2〜3の同時アクセスがくると帯域もツライ気がしますが・・・)
もしかすると圧縮転送に伴う圧縮処理の方がむしろ重いのではないかと思ってみたり。
>「優秀なSoldOutが負荷のために消えてゆく」という状況を打破しようと鋭意準備中ですので、ご安心を。
面白いものにするためにはある程度の負荷は覚悟しないといけませんしね。
(もともとCGI自体がゲームに向いていないのもあるのですけど・・・)
私もその準備に応えられるだけのものを完成できるよう、頑張ります^^。
name：Duke 2006/03/23 01：23：07
返信遅れてすいません。
学習人工無能は、人間の会話から学習もどきをする人工無能ですが、
この手のタイプのものは、荒らしにめちゃめちゃにされやすいものです。
そこで、SOLDOUTの一コンテンツとして暇つぶし程度に使ってもらえないかなと
思ってとある人工無能を、交渉の結果、GPLライセンスにしてもらい移植いたしました。そして、SOLDOUTの参加者以外をチャットから排除という形をとるために、SOLDOUTの関数群を読み込んで、SOLDOUT参加者だけのコンテンツにしました。というのも、SOLDOUTに参加する人自体、
荒らしが少ないので、学習機能が存分に働いてくれるから面白いものができるからです。
顔文字などの、()などのさまざまな記号を全て全角に変換し、SHIFT JISからUnicodeに変換して文字処理、そのあとSHIFT JISにへんかんして出力
という形をとっています。
僕のサイトでの運営で、意外と人気がでたので、
改良にとりくもうとおもいます。
SOLDOUTのデータとは独立しているので、取り外しも簡単ですね
といっても、まだレイアウトをSOLDOUT用にあわせただけなので
protoですねｗ
詳しくは、僕のサイトのSOLDOUTで参加して、学習無能で書き込んでみてください。まだ、学習量は足りないですが・・・
name：fuku@管理人 2006/03/24 00：01：50
>詳しくは、僕のサイトのSOLDOUTで参加して、学習無能で書き込んでみてください。
せっかくなので、書き込んでみました。
すっごく興味なさそうでした(笑)
前に人工無能会話ログを見たときも笑えましたが、やはりなかなか面白いですね〜。
いずれはこういうのも作ってみたいな〜とか思ってみたり。
・・・作りたいもの多すぎて、いつになるやら・・・ですが^^;
name：Y.Y 2006/04/03 02：08：22 http://tpy.jp/
ご無沙汰してます。
現在gcc4.1.0リリースに伴い、自宅サーバーをリフレッシュ中です。
（セルフコンパイルにどれだけ時間かけてるのやら・・・）
明日から再びネット環境がありませんので、今日中に構築せねば、と。
>(2〜3の同時アクセスがくると帯域もツライ気がしますが・・・)
>もしかすると圧縮転送に伴う圧縮処理の方がむしろ重いのではないかと思ってみたり。
SoldOutに限りませんが、ネット社会は
夜中の3時4時にはほとんどアクセスがありませんが、12時付近や4時、5時・・・8時は複数人が同時にアクセスが集中する
という感じですよね。
さらに、SoldOutは恐らく「口コミ」でもかなり広まると思いますので、小・中学生の間でヒットすれば、彼（彼女）らがほぼ同時刻に集中するのは必死だと考えているわけです。
次期サーバーですが、「デュアルコア」で「省電力」なYonah（Core Duo）がMerom発売後に安価になるのを狙って組んでみようかと考えております。
まぁ資金作りが大変ですが・・・
>面白いものにするためにはある程度の負荷は覚悟しないといけませんしね。
>(もともとCGI自体がゲームに向いていないのもあるのですけど・・・)
>私もその準備に応えられるだけのものを完成できるよう、頑張ります^^。
コンパイラの設定次第ではPerlも1〜2割程度高速化できるようです。
また、SoldOutのようなスクリプトの場合、Perlインタプリタの起動にかかる時間が命取りな訳でして。
後はデータファイルへのアクセス、ですか。
となると、mod_perl版SoldOutのような物を完成させ、データは保存せずにメモリ上に常駐（？）、定時的、もしくは規定回数のデータ変更があれば保存、のようにしてやれば「高速化」できるのでは、と目論んでいる次第であります。
name：fuku@管理人 2006/04/04 07：19：22
どうも。
>コンパイラの設定次第ではPerlも1〜2割程度高速化できるようです。
最適化による高速化は最速にするとコンパイラによっては「やりすぎて」しまうものがあるとか。
やりすぎた最適化によりタイミングがシビアになり、不安定になってしまうそうです。
実際、Ogg Vorbisサウンドの公式エンコーダがそんな感じでした。
Win32用のLIBファイルとソースが両方配布されているのですが、
LIBファイルを使って動かしているとエンコードしたファイルが壊れていたり、エンコーダ自体が強制終了、なんてことがたまにありました。
原因究明できないものかとソースファイルからVisual C++でビルドすると、
エンコード速度がほぼ半減、ファイル破損や強制終了はキレイになくなってしまいました。
同じバージョンなので多分同じソースコードだと思うのですが、
最適化で速度2倍はイロイロとやりすぎのようです。
異常の発生率自体も低いため、最適化オプションによる高速化と安定性の両立は大変そうです。
特に常駐させてしまうと落ちた時にデータ巻き戻りの危険が大きくなるため、程々にしておいたほうがいいかもしれませんね。
>また、SoldOutのようなスクリプトの場合、Perlインタプリタの起動にかかる時間が命取りな訳でして。
Perlインタプリタ自体の初期化って実際どれくらいの重量なんですかねぇ・・・
Perl5.8.8のソースを取ってきてみたものの、ファイルが多すぎて追跡する気力もでません(笑)
>後はデータファイルへのアクセス、ですか。
C系だとダンプしちゃうとか荒技(?)もありですけど、Perlだとやっぱり普通に解析する方向か、requireするか、というところですね。
随分以前のことなのでもう記憶があいまいですが、
requireを使う方法だと、読込速度を40%程度改善できたと思います。
その代償として書込にかかる処理時間が2倍くらいになっていたので、
セキュリティの観点も考慮すると微妙かもしれません。
>mod_perl版SoldOutのような物を完成させ、データは保存せずにメモリ上に常駐（？）
理想的にはそうするのがいいのでしょうが、SOが多数のファイルで構成されている点が気になります。
場合によっては「全て1ファイルから起動」なんて話になってしまうかも・・・
name：Y.Y 2007/01/08 01：09：27 http://shukukei.com/
お久しぶりです。
結構以前のレスなので、新規でレスを追加するのは少々気が引けたのですが。
あの後、いろいろと考えた結果、
・mod_Perl 化 （Fast CGI、Speedy CGI）
高速なレスポンス
データファイルを常にメモリ上に置いておいて・・・
利用できるサーバーが限定される
下手をすると全て1ファイルから起動に
・mod_PHP 化
mod_Perl化と同じ
場合によってはPerl以下の実行速度（得意、不得意がある）
大幅な変更が必要
利用できるサーバーはmod_Perlよりは多いものの・・・
※個人的にはPerlよりも遙かに書きやすいかと。
・MySQL 化
前述の方法と組み合わせることも可能
現行PerlのままでMySQL化を行っただけでも高速化可能かもしれない
利用できるサーバーが限定される
とはいえ、大幅な変更は避けられませんし、mod_PHP + MySQLで組んでみる、というのもアリかなぁ・・・と思ったりもします。
が、如何せん、時間的ゆとりが全く取れず・・・
もし、複数人のメンバーが集まれば、
SoldOutを構築しているファイルの全体の流れを完全に把握し、ファイル毎に担当を分けて書き換えていく、という手段があると思います。
一度mod_PHP + MySQLで動いてしまえばalpha版、beta版、rc、正式リリースと段階的に修正を加えていける筈ですので。
その間、私のサーバーの方で実行環境は整えられると思います。
その自宅サーバーの方ですが、2007年1月1日より正式に稼働を開始しました。
OS : VineLinux4.0
電源: Scythe KMRK-NF420A(鎌力準ファンレス)
CPU : AMD GeodeNX 1500@6W
M/B : ASRock K7VM3
Mem : 512MB * 2枚
HDD1: Seagate 40GB 7200rpm(SoftwareRAID1)
HDD2: Seagate 40GB 5400rpm(SoftwareRAID1)
name：fuku@管理人 2007/01/08 19：57：00
お久しぶりです。
PHP化だと完全書き直しになる(と思われる)ので結構な工数が予想されるわけですが、その時に
>場合によってはPerl以下の実行速度（得意、不得意がある）
の項目は結構なマイナスですね、やっぱり。
スクリプト互換性を破棄してまでやってむしろ遅くなった、だと悲しいものがありますし・・・
SQLの導入は・・・SOLDのデータサイズから考えた場合、
SQLを組み立ててSQLサーバと通信するコストと直接PerlやPHP上で検索するコストのどちらが重いかというのは少々微妙な気もします・・・
大規模な場合はSQLの方が有利かとは思いますが、SQL使用時の保守コストを考えると手間に見合うだけの効果が上がるかな、と。
とはいえ、Perlが書き難いのも確かですねぇ。
改造するにも言語変えるのも面倒な状況、これはPerlからのトランスレータ作るのも手段の一つでしょうか(笑)
まぁ、現実的に時間リソースが深刻に不足している状況ですし、比較的少ない工数で済むと思われるPerlベースの手法から検討した方が無難な気もしますが、どうでしょうか？
いずれにしても、軽量化というのはかなり地味でありながら手間のかかる作業なので参加してくれる人集めが最大の壁になりそうですねぇ・・・
（特にPHP移植は両方の言語がそれなりに使える人でなければいけないため、より大変になりそう）
・・・今しがたperlのドキュメントを見ていたらdumpなるものを発見。
生成速度が良ければデータファイルrequire化の弱点だったコード生成とかエスケープとかを改善できるかも？
name：たそがれ 2007/04/20 07：23：16
はじめまして。
SOIE使わせていただきました。
最近アイテムデータを手書きで修正していくのに限界を感じており、
SQLかエクセルで楽に扱えるようにしようと思っていた矢先にこちらを知りました。
大変助かっております。感謝です。
いまアイテムデータの製造レシピをMySQLでデータベース化しようとしているんですが、
アイテム数多いので作業も地道でなかなか思うように進まないです・・
アイテムデータの文字列置き換えて読みやすくしておいて、
検索フォーム１つ付け加えるだけで、後はnamazu等でリスト化してしまったほうが楽でいいのかなとか思ったりもしています。
不躾なのですが、このあたり何かアドバイス頂けるとうれしいです。
蛇足ながら、SOLDOUTの高速化についてですが
私のところでは以前はそれなりのマシンにmod_perlを組み込んで圧縮転送していたのですが
現在はサーバー機をグレードダウン（cpu:セレ800MHz mem:256M）させまして、無圧縮で転送するようにしています。
高スペックのサーバーで圧縮転送するよりも、
考え方としてはPHPのように各ユーザーにおまかせするような感じでやっております。
ユーザー数は100名ほどになりますが、レスポンスに特に不満もなく快適です。
自前で全てやろうとせず、こういうやり方も１つかなぁとか思います。
name：たそがれ 2007/04/20 07：47：30
追記で、SOIEに少しだけ要望なのですが
#コメント行をスルーするようにはならないでしょうか
ちょっとしたメモなど残したいのですが、読み込まれず消えてしまうので。
読込時にコメント行だけ別に抽出しておいて、保存時に元の行番号に付記という感じでしょうか
よろしければよろしくお願いします。
name：fuku@管理人 2007/04/20 18：49：48
はじめまして。
SOIEのご利用ありがとうございます。
>いまアイテムデータの製造レシピをMySQLでデータベース化しようとしているんですが、
>アイテム数多いので作業も地道でなかなか思うように進まないです・・
>アイテムデータの文字列置き換えて読みやすくしておいて、
>検索フォーム１つ付け加えるだけで、後はnamazu等でリスト化してしまったほうが楽でいいのかなとか思ったりもしています。
データベースやnamazuはそこまで詳しくないのであまり細かいことはいえないのですが^^;
感覚的にはレシピを先に独自の処理しやすい形で記述しておいて、
inc-item-data形式をそれを元に出力させた方が楽ではないかと思います。
#SOIEは内部形式に変換しているので変換関数だけ作ればどうとでも置換できるといえばできます。
#もっとも、外部から制御できるようにするには相当手間が掛かるのでちょっと現実的ではないですが、
#CSV形式への変換ぐらいなら何かに使えそうなので実装するかもしれません。
#(inc-item-data形式よりはCSVの方が解析対応しやすいですしね)
>高スペックのサーバーで圧縮転送するよりも、
>考え方としてはPHPのように各ユーザーにおまかせするような感じでやっております。
PHPも詳しくないので記憶違いかもしれませんが、PHPってサーバサイドで処理してたような気がします。
それはともかくネットワーク帯域に余裕がある状態なら圧縮転送はしない方が有利と私も考えています。
可能な限りJavaScriptでクライアントに放り出すという検討もしてみたことがあるのですが、
現行の仕様だとJavaScriptで処理するのに送出する必要のあるデータが多く、
その選定とコード生成をする分のサーバ処理以上の効果を上げられるかが未知数なため、
時間的にもやってみれないのが実情です。
>#コメント行をスルーするようにはならないでしょうか
>ちょっとしたメモなど残したいのですが、読み込まれず消えてしまうので。
>読込時にコメント行だけ別に抽出しておいて、保存時に元の行番号に付記という感じでしょうか
編集していると行番号は変わってしまうことが多いので、
復元する時に行番号だけで復元というわけにはいかない事情があり、
各記述中の行コメントの温存はそう単純にはいかないのです。
とはいえメモぐらい残せてもいいと思うので、
現在忙しいので時間が掛かるかもしれませんが、検討させていただきます。
ご要望、ありがとうございました。
name：Y.Y 2007/10/20 12：53：06 http://shukukei.com/
お久しぶりです。
先日、ようやく自宅サーバーの切り替え作業が終了しました。
今回は、ファンレスサーバーへと進化(?)を遂げることが出来ました。
現在、個人的にはデータベースサーバー化を検討しています。
高負荷になった場合に、ファイルロックに失敗し、データファイルが破損する、という事態を回避可能だと思います。
MySQLにデータの管理を任せてしまえば高速化も図れるのではないか、と考えています。
また、Apache + mod_perlではなく、Lighttpd + FastCGIを利用することにより、高速化が図れるとの噂を耳にしており、現在調査中であります。
私も、SoldOutは、データファイルへのアクセスがボトルネックのように感じておりますので、データベースサーバーに任せてしまうのが一番良いのかなー、と考えています。
やはり、data.cgiとmakeitem.cgiで生成されるitemのデータ全てをデータベース化、これで高速化の可能性がないかを検討してみたいと思います。
時間がとれないのが問題ではありますが--;
name：fuku@管理人 2007/10/21 01：13：41
お久しぶりです。
ふむふむ、完全データベース化ですか。
データベースとの通信速度如何では十分高速化の余地はありそうですが、
問題はセキュリティと書き換え範囲ですかね。
アイテムデータを移管するとなるとかなり広範囲の修正が必要そうですが・・・
>時間がとれないのが問題ではありますが--;
結局、最終的にはそうなるんですよね・・・^^;