ソーシャルゲーム運営地獄 - やねうらおブログ(移転しました)
実際に関係者から聞いた話なのだが、いま、底辺のソーシャルゲーム会社は大変なことになっているらしい。底辺じゃない会社もそれなりに大変なものかも知れないが、底辺の会社はそれどころの騒ぎではないようだ。 まず、プログラマーの力量に合っていない。 「ソーシャルゲーム(の開発を)舐めんな」みたいな話は大手の開発会社のプログラマーからよく聞くが、人数がある日突然何万ユーザーも増える。このへんの流入する人数の調整が利かない。 もともと何十万人規模の接続をさばくには、MMORPGなどのオンラインゲームよりもシビアであり(普通、MMORPGでもワールドがわかれていて、1つのサーバーの常時接続人数は数千人規模に収まるので)、大人数になったときにうまくスケールアウトするように設計するためには、ゲームシステム自体がそのへんを考慮してうまく練られていないといけない。 ところが、底辺ゲーム会社だと、社長がそのへんの理
古くて新しい自動迷路生成アルゴリズム - やねうらおブログ(移転しました)
最近、ゲーム界隈ではプロシージャルテクスチャー生成だとか、プロシージャルマップ生成だとか、手続き的にゲーム上で必要なデータを生成してしまおうというのが流行りであるが、その起源はどこにあるのだろうか。 メガデモでは初期のころから少ないデータでなるべくど派手な演出をするためにプロシージャルな生成は活用されてきたが、ゲームの世界でプロシージャル生成が初めて導入されたのは、もしかするとドルアーガの塔(1984年/ナムコ)の迷路の自動生成かも知れない。 なぜ私が迷路のことを突然思い出したのかと言うと、最近、Twitterで「30年前、父が7年と数ヶ月の歳月をかけて描いたA1サイズの迷路を、誰かゴールさせませんか。」というツイートが話題になっていたからである。 この迷路を見て「ああ、俺様も迷路のことを書かねば！俺様しか知らない(?)自動迷路生成のことを後世に書き残さねば！」と誰も求めちゃいない使命感が
ゲームの世界の経済学が現実世界に通用するという話 - やねうらおブログ(移転しました)
最近、私の会社では年商1,000億円ぐらいの規模の会社の販売管理系のシステムを開発しているのだが、どうもこのシステムの設計意図が私にとってはまさにデジャヴというか、「もうかれこれ10年ぐらい前にこれと同じこと考えてたよなー」と思ったので、そのあたりのことをだらだらと書いてみる。 いま、話を単純化するために店頭販売価格をいくらにすればいいかを決定するシステムを作りたいとしよう。 まず、経済学の教科書によく載っている需要曲線というのは次図のような反比例っぽいグラフである。 経済学の教科書では、これと供給曲線とを重ね合わせて、その交点が均衡価格(市場価格)だと説明がある。 販売する側の視点に立った場合、最適な価格(利益を最大化できる価格)というのは、均衡価格では決してない。そこで、いま供給曲線については考えないことにして、利益を最大化できる価格で売る、とだけ考えよう。 近年、インターネットの価格
ゲームROMの吸出しの歴史 - やねうらおブログ(移転しました)
日本のゲーム史はインベーダーゲームを嚆矢とする。インベーダーゲームがゲームセンターから消えて10年ぐらい経ったのちも、中学校の校則には「インベーダーゲーム店への入店を禁ずる」とか書かれていたケースも少なくはない。それほどインベーダーゲームの影響は絶大だった。 「インベーダーゲーム」とはタイトーが1978年に出した「スペースインベーダー」とこの類似ゲームおよびクローン(模倣品)に対する総称である。タイトーがスペースインベーダーを発表すると同時に一大ムーブメントが巻き起こり、各社一斉にシューティングゲームを作りはじめた。 例えばナムコ(現ナムコバンダイ)は翌年(1979年)にギャラクシアンを発表し、その2年後(1981年)にギャラガ、1984年にギャプラスを発表している。 このころの著名な作品のROMを吸出し競合他社がリバースアセンブルして研究するのは普通であった。 えー、要出典？ うーん。そ
クロージャーだと苦労するんじゃ？(ダジャレ) - やねうらおブログ(移転しました)
closureで継続(continuation)を実現する技法ってあるじゃないですか。 例えば次の記事は私が5年以上前に書いてますね。 C#2.0時代のゲームプログラミング(49) 〜 delegateを用いたcontinuation http://d.hatena.ne.jp/yaneurao/20070207 上の技法は私は10年ぐらい前にclosureを使い出したころに自力で発見しましたが、まあ、いまや常識ですよね。それで最近、それに似た話題があったので取り上げてみます。 ここで再度認識して欲しいのは、node.js の素晴らしさは「クライアント側で皆が使っているJavaScriptでプログラムが書ける」という部分などにあるのではない、という点だ。node.js がこれほど多くの支持者を得ているのは「本来記述が煩雑になりやすい非同期処理をJavaScriptの無名関数を利用して書きや
定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)
いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
