SyntaxHighlighter

2012年8月11日土曜日

ブログを分割した

・blog1
AVA,BF3等をはじめとするFPS関係。
攻略や分析、e-Sportsの普及に努めるブログ。

・blog2
このブログ。
Hellgate,Diablo 3をはじめとするハクスラ,MMO,MO関連。
プレイヤーとして思ったことを書く。

・blog3
上記以外。
blog2から誰得な技術的な話題の記事を移行した。


動機。
適当に書き始めるのはいいんだけど、ごちゃごちゃしてくると次第に何書けばいいのか分からなくなる。
そんなことを思ってたときに、この記事(ブログの整理:Radium Software)を読んで影響されて、ブログを分けることにした。

2012年7月29日日曜日

Diablo 3日記 part.7

【WizardでVaultラン動画】



動画の簡単な解説。
・Vault of the Assasin
ここでNV5をstackする。
ピンチになったときにいかに素早くArchonのbuffアイコンをクリックし変身を解除できるかが生死を分ける。
主な回復リソースはLife each kill 2000。
後半に弾速低下+反射持ちに苦戦してるのが面白いかもしれない。

・Sewer of Cladeum
エリートが2匹いると思ってたが、金ゴブ込みの数だったみたいで無駄に歩き回る。
NV5の状態なら効率の良い場所。

・Black Canyon Mines
油断して雑魚に殴り殺され、FireChainに焼き殺される姿が拝める。
修理アイコンが真っ赤になったので退散する。

・Alcamus周辺
普通のエリート狩り。
同じアイテムを4回も拾おうとしたりして挙動不審である。

・Timed Dungeon
最後のエリートが手下無敵だったのが結果的には良かったのかもしれない。

・Mysterious Cave
このゲームで困難な状況を打破する要素は火力しかない、という真理が見れる。
がっかりオレンジアイテムを拾う。

・鑑定
レア多数拾っているが、なかなか装備更新は難しい。

Act.3だとコテンパンにされるのでfarmingはAct.2安定。
Act.3をArchonで回るにはDPS100kぐらいいるんじゃないだろうか。



【WDはじめました】
Nightmareのact.3まで進行した。
Soul HarvestやGruesome FeastでIntを上げてからのMana大解放がものすごい火力。
Normalの時点でDPS1000越えとかいうわけの分からないレベル。
瞬間火力はWizのArchonを上回るんじゃないかと思ってワクワクしている。
問題はいつまでこのやり方が通用するかだ。

2012年7月21日土曜日

HDDが逝った


OSが入っていたCドライブが死んだ。
享年18ヶ月。
1つのPCで色々やりすぎたのが原因かもしれない。

そもそも面倒臭がりで、ゲームもTV録画もネットサーフィンもプログラミングも全部1台で!っていうのがあらゆる点でリスキーだった。反省してる。
特に最近はAVAのレーティング用糞アプリが無駄に細かいファイルを何百万個と乱造しまくるのが良くなかった。
Diablo 3も挙動が怪しく、しょっちゅうデータ読み込みが間に合わなくなってた。
TVの録画はものすごくHDDの容量食ってた。

というわけでHDDを換装してOS再インスコ。
せっかくだからSSDも投入した。

OSとかゲームとか → 母艦・SSD
それ以外 → 母艦・HDD
TV → 母艦・別の専用ドライブ
糞アプリ → サブマシン・母艦と共有の外付けHDD

出費が数万と結構な時間かかったけどすっきりした。
SSDはめちゃくちゃ早かった。電源入れてから起動まで20秒かからないレベル。


いくつかのファイルのサルベージに失敗したけど、どうせくだらないファイルだろうから問題ない、ということにしておく。
あと、ファイルたくさん作るのやめて、読み込みに無駄が多くても100MByteくらいで1ファイルにまとめて置くのがいいかもしれない。

2012年7月18日水曜日

Diablo 3日記 part.6

ついにGhom撃破。
そのまま進めてたらあっさりSiege Breaker,Azmodanを倒してact.3クリアしてしまったという話。


【act.2周回で高額品入手】




Each Hit Adds +900 Lifeと+150 VitにそこそこのDPSがあるmonk用1-Hand。
1M開始N/A出品したら壮絶bid合戦の後、16Mで売れて一気にホクホクに。
bidあればwatchリストに入るので高額が予想される品は低額スタートN/A出品がいいかも。


その他も100k~500kクラスがちょいちょい売れて、そのお金で装備面を強化。
Sparkflint(+12%)とGlass Cannon(+15%)込みでDPS 42kに。

【Ghomに挑む】
よし、これで勝つる!とソロでGhom行ったらあっさり死亡。
本当に何も出来ずに死んだ。


【PubでGhomに挑む】
変身特化ビルドにしつつ、適当なPT入ってNV貯めつつGhomに挑むことにした。
act3でPubるのは初めて。
自分(Wiz),Wiz(orb鰤ヒドラ),Monk(マントラ),DH(変態)の4人PT。

Wizの人は典型的なビルド。

Monkの人は割りと辛そうだったけど、逃げつつもちゃんと前線維持しようとしてて好感持てた。
マントラ要員だぜヒャッハーとか言ってた。女キャラで。

DHの人はMonkの友達。変態。
どんな相手でも足止めして密着でずっと爆発してた。矢は1発も撃ってない。
多分Shadow Powerで回復してるんだと思う。
シールド持ちはキツい感じだったけど、圧倒的なtank感だった。
凍結Wizに火力追加したような強さ。無敵すぎる。

GhomはDHが完全に固定してくれたから滅茶苦茶楽だった。
もう一人のWizも同じこと思ったみたいで、すげーって感謝してた。

PTは解散。


【PubでSiege Breakerに挑む】
Pubでの寄生に味を占め、再び適当なPTにjoinする。
凍結Wiz,結構強い馬場,残念なWDが居た。

馬場が集めて凍結Wizが固定してくれたので、自分はArchonで焼き払うだけという。
とっても美味しいです^q^
meleeはFire Chainで事故ると死ぬけど、rangedは低リスクで火力出して気持ちEEEという感じ。

WDはどうやってここまで来たんだっていうくらいHellクリア直後、act1レベルの装備だった。
Wizが「おい、WD何し来たんだ」って言って、馬場が「そりゃFarmだろ?装備なんて今から拾えばいい」って言っててマジイケメンだった。
自分はさっきGhom倒したばかりなことは言わなかった。
WDが出してた踊ってる奴はかわいかった。Fetish。

minion無敵だろうと全部なぎ倒してNV5でSiege Breakerへ。

入り口で馬場がSiege捕まって、そのままwizがひたすら凍らせてた。
Siegeはそのまま一歩も動かずに死んでた。
馬場がやることねーってずっと言ってて笑った。

WDと自分以外はfarm目的だったので、そのまま解散した。


【フレとAzmodanに挑む】
いい感じにAzmodanランしてる2人組(Wiz&Monk)が居たので突撃した。
凍結wizとmonkが息ぴったりに前線を維持してた。
Pubとはまた違った安定感があった。
どっちも日本人。

ArchonしてるだけでAzmodanまで連れて行ってもらえた。

Azmodan。
自分は体力3割くらいになったら沼に囲まれてあっさり死亡。
その後もう一人のWizも沼の上で棒立ちしてるカッケーと思ったら残り1割くらい死んでた。
Monkさんが仕方ねぇなって感じでそのままトドメ刺して終了。

なかなか楽しかった。

【act4へ?】
挑むんだろうか。
まだ装備的には挑める感じでは無いし、Diablo倒したところでどうということもないしなぁ。
しばらくは自由に歩けるようになったact3で狩り場所探す感じになりそう。

2012年7月14日土曜日

Diablo 3日記 part.5

未だにAct.3 Ghomさんが倒せずにVault of the Asassinでくすぶっているという話。


【ステータス編】
DPSは33kの据え置きで防御面が若干強化。
Life 14k → 19k
Critical Hit Chance 26% → 46.5%


悪党無しでもCMass安定するようになったのでテンプラさんに連れを変更。

竜巻置いてればDiamond Skinを1~2秒に1回張り替えられる。
Life per Second 15k相当の回復力とかいう壊れ性能。
HydraのAEKバグを彷彿とする。
果たしていつnerfされるのだろうか。




【近接CMass盾持ちビルド編】

盾を持つと硬くなって安定するかなと思ったらそうでもなかった。
DPS 20kぐらいで竜巻kiteしてるとエリートが発狂することもしばしば。
変身状態で雑魚蛇に2回以上殴られたりするのも辛い。
火力上げて短い時間で倒しきったほうが効率いいかもしれない。

ソース持ちよりもポーション飲む回数が増えるのがなんとも。

【Design : Flawless Star Topaz】
拾った。



もう市場価値はなさそうでGem製作販売は赤字になる。
でも、記念にFlawless Star 2つ作った。


【ハメ殺し】
入り口。

入り口から180度進行したところ。


敵が引っかかって一方的に攻撃することが可能。
敵の方がよっぽど理不尽にハメ殺して来るので、罪悪感や後ろめたさは全くない。


【VaultランとHellgateのウィンチェスター寺院】
高密度のエリート集団を繰り返し討伐して装備を探していくという点で似ている。
まだInf Diabloは倒してないが、Vaultランはかなりのエンドコンテンツ感はある。
低ストレスで無駄が少ない。

ただ、どちらも没入感が大事なのにシステム面がそれを阻害しているのが残念だ。
Resume/Leaveを繰り返したり、アイテムがいっぱいになって街に戻るのは良くない。
どうせ装備の更新なんて滅多にないのだから街に戻る必要なんてなく、いらないアイテムは取得後即換金、エリート狩り終わったらLeaveではなくただダンジョンの階層を降りるほうが良い。

まぁ、Rogueやってろよって話だけれども。
HellgateとかDiablo 3のシステムでRogueとか絶対楽しいはず。オフラインでも。


【RMT】
この手のゲームは過程こそが全てであり、強くなった先には何もない。
今まで苦戦してた敵が簡単に倒せるようになるだけであり、アイテムくじ引き1回30分だったのが10分になるだけだ。
この時間を限りなく縮めると、ボタンを押すだけでアイテムガチャができる仕組みになる。

そこまでくるとそれはもう最高のハッピージェネレーターだ。
なにも苦労しなくても幸せ。
自分にとって必要なものはだんだん出にくくなるのだが、いらないアイテムでも周囲が引き取ってくれるからお金になる。
ボタンを押すだけでお金が出てくる。

問題はそこからで、なんのためにそのボタンを押すのかと思うようになる。
人が己に意義を問うときは幸せじゃないときだ。
お金のためにボタンを押すようになったらかなり危険だ。
幸せをお金で買うならともかく、お金のために幸せを売るのは本末転倒である。

「お金を得るのが幸せ」というのならゲームは引退したほうが良い。

2012年6月29日金曜日

Diablo 3日記 part.4

1.03でASがnerfされ、水路ランが閉鎖。
そんな中、Drop rate変更と聞き、なんとか無理矢理Inf act.3まで進めたものの……という話。


【ANDARIEL'S VISAGE】
フレの人とact.1回ってたら初レジェンダリをArmor rackから取得。




+Dexなのがポイント?でも、使う予定はなさそう。





7Mで売れましたと。所持金が一気に10倍以上に。
これのおかげで、act.2水路ランを卒業するための資金が調った。


【Berial】
act.2最後のボス。
かなり苦戦して、死にまくって、修理代200Kぐらい失った。
最初の蛇とベリアルタイマンはなんとかなるのだが、第三ステージの腕が避けられない。
当たると即死。
…が、したらばの情報を参考にしたらあっさりクリアできた。

・DPS30K程度にし毒ヒドラ置いて全力で逃げるだけ
・腕落下点(事前に光る)が自分の位置ならそのまま避ける
・腕落下点が自分の左なら、左の攻撃終了後、左に避ける(右に避けると逃げ切れない


【act.3】
ダメージソースがEnergy Twister:Wicked WindのみのドMビルドで進行。



やってることは走り馬場と近い。

update後にメテオや竜巻にもCritical MassやArcane Power on Critの効果が出るようになった。
そこでクリ率を30%、AP on Critを30近く(wand,sorce,hat)積んでエターナル竜巻ビルドに。
Diamond Skinで耐えつつ、Frost Novaで凍らせ、竜巻連打するだけ。
AP切れはほとんどなく、エリートとの勝率も3割くらいでなんとか進めるようになった。

でも、Ghomさんに叩きのめされた。
毒が痛すぎて何も出来ずに死ぬ。
逃げながら竜巻撒いても2割削る前に発狂する。
ダイナモ変身ビームでも3割しか減らないので絶望した。
多分今の装備では無理なんだろう。


【念願のVaultラン】
act.3でのFarmは無理っぽいのでact.2に戻って強化。
クリ率と過剰なAPを生かしたビルドに変更して、Vaultランすることに。
色々死にながら試行錯誤した結果、こんな感じになった。




Pubでやったら大迷惑なMeteor Showerビルド。
ソロですら視界不良になる。



buff無。Life 13KでもDSあればなんとかなるかも。

竜巻は火力不足なのでメテオに変更。
Vault of the Asassinは雑魚がわらわらいるのでMeteor ShowerとArchonで一掃する感じに。
エリート相手にはDynamo貯めつつ、Meteor Shower。
APが枯渇しにくく、そこそこ火力があり、まとめて倒せるのが利点。
でも、1,2秒DSが剥げる事が多いので引き撃ち気味になる。
もう少しクリ率が欲しいところ。
場合によってはArchonでそのまま倒す。
ダンジョンの構造的に地形ハメもしやすかったりする。


1周で色付き6~7packと1ゴブ。
終わったらWPからAlcarnus前とAncient坂の金ゴブ狩って終了。
黒字になるまでビルド組むのが大変だったけど、Butcherランよりもかなり効率が良くて良い感じ。
何より敵密度が高くて歩き回らなくていいのが楽。


【その他】
craft素材の値段が急降下中。
貴重な資金源だったのだが、装備を砕くべきか微妙な感じに。
レア砕くとたまにレジェ素材でるのが美味しいんだけど、ここまで下がるとそのまま店売りの方が利益でそうな気がしないでもない。

2012年6月12日火曜日

Diablo 3日記 part.3

inf act.2の水路まで行った辺りでだれてる。

MF無しBuff有りの装備だとDPS 44k, Armor 7k, Resi 150, Health 8kくらい。
蛇からのツンツンは1回しか耐えられない。
やられるまえにやるしかない。

水路はMortarかReflect持ちだったら即leave。
硬い系能力持ちだと運ゲーだけど、それ以外はだいたいArchon中に倒しきれる。
水路は美味いかもしれないけど、作業すぎて精神に異常をきたすと思う。

pubでact.1無双するのが楽。
10kでも売れないレアとかでも、引き取ってくれる新人さんがいたりすると和む。
でも、必要なものマジで何も出ないので飽きはじめてる。

AHで稼ぐ側になるにはさらなる廃人化が必要で、そんなに時間もないってのがだるい。


とりあえずButcherでact.2以降の装備が落ちるv.1.03を待つしかないかも。
Butcherさんと戦ってるとマジ癒される。

2012年6月1日金曜日

Diablo 3日記 part.2

Wizardのみ育ててる。
MonkとBarbarianは開幕のzombieでだるくなった。
DeamonHunterもだるかったけどSkeleton King倒すまでは進めた。
Witch Doctorはやってない。

WizardはNightmareでLv.44でBerial倒したところ。

NormalからNightmareで試したビルド。
Frost NovaとDiamond Skin、PassiveもEvocationは外せない感じだった。
それ以外は何でもいいと思う。
防具はIntとAttack speed重視(DPS重視)で選んだ。
硬くするんじゃなくて、やられる前に倒すゲームですよね、これ?

Storm ArmorとDiamond SkinのArcaneコスト下げるやつで、常時ビームしたりするのもなかなか楽しかった。でもそんなに強くないと思う。

Ice Armorが攻守バランス取れてて、Storm Armorが攻撃寄りで、Energy Armorが守備寄りっぽい感じで使い分けてたけど、Galvanizing Ward取得してからはEnergy Armorばっかり使ってた。

Berial倒したスキル。

Primary :
・Shock Pulse の Fire Bolts
至近距離で単体相手なら一番DPS出ると思う。

Secondary : なし

Defensive :
・Frost Nova の Cold Snap
効果も範囲も申し分ない、瞬間冷凍機。
Berial第二形態には効かないけど、それ以外には超強い。
これだけでtankとして成立するレベル。

・Diamond Skin の Crystal Shell
敵の群れに突っ込む前にDS展開して、FNで冷凍後に駆逐するのは基本。
Berialで4人PTだったけど、3人が毒沼で死んだ中、これのおかげで逃げ切れた。
Berialは割と蘇生の余裕あるので、毒沼さえ耐えれば勝てる。

Force :
・Wave of Force の Forceful Wave
他の範囲スキルは発動までが長いけど、これは即発動で範囲も広い。
ノックバックも小さいので敵も散らない。
雑魚敵の一掃に便利。

Conjuration :
・Energy Armor の Pinpoint Barrier
ガチムチになる上に、クリ率も上昇する。
Berialの時点でArmor1100のHealth2000くらいだったけど、死ぬ要素がなかった、

Mastery :
・Explosive Blast の Short Fuse
最初はゴミスキルだと思ってたけど意外に強かった。
詠唱前と詠唱後に隙がないからMeteorより使いやすい。
cooldownも短いし、Arcaneコストも低いから連発できる。
欠点は自分の周辺しか攻撃できないことだけ。

Passive :
Evocation, Cold Blooded, Galvanizing Ward

基本的にはFNで冷凍後にExplosive BlastとPrimary連打。
あとは状況見ながらWave of Forceで距離をとったり殲滅したり。
なんだかんだで殴りWizardになってる気がする。

多分HellとかInfとかだと耐久足りなくて成立しなくなるんだろうな。
それまではこれで遊ぼう。


2012年5月24日木曜日

Wizard始めてます

Diablo 3の話。
Lv25くらいまでプレイした。
スキルいっぱいで、組み合わせいっぱい。
試行錯誤が楽しいです。


防御スキル。
Frost Novaが強いと思う。敵が3秒凍る。
RuneのCold SnapでCooldownが9秒に、PassiveのEvocationでさらに15%縮むのが強い。
Diamond Skinもなかなか便利。数秒間ほぼ無敵状態。
Frost NovaとCooldown調整すればガンガン前出れる。

Slow Timeは空気、というかPTだと邪魔じゃないか?
Teleportは囲まれても安心なのであるといい。移動にも便利。

フォーススキル。
Wave of Forceはスロット余ったら入れとくといい。
攻撃にも回避にも使える。
でも、Cooldown長くてメインには使いにくい。
Energy Twisterはとりあえず出せば強いけど、軌道が読めなくて微妙。
Hydraは可愛いけど、あんまり火力無いので、スロット数的に使わなかった。
どこにでも召喚できるので便利っちゃ便利だし、ボス戦にはいいと思う。

Meteorは神。
威力はガッカリするかもしれないけど、連打できるのがいい。
Arcaneは全部Meteorに捧げる勢いでプレイしてる。
全てはMeteorを当てるために。

コンジュレーションスキル。
いまひとつ使い勝手がよくないと思う。
Magic Weaponは強いけど、スロット足りないしなぁ。
マスタリースキルもそんな感じ。

攻撃スキル。
Spectral BladeとArcane Orbが主体だった。
Defensive Skilが強いので、突っ込んで敵集めての範囲攻撃が強い。
でも、Tankが残念だとだんだん辛くなってくる。

Meteor覚えてからはArcaneは全部Meteorに使いたいので、ElectrocuteとMeteorがメイン火力になった。

Ray of Frostは便利だけど、Arcane使うほどのスキルじゃない。
Arcane TorrentもArcane Orbが使える状況なら火力不足。
Disintegrateは貫通が強いけど、火力は低いし、他のスキルが使えなくなるので微妙。

Wizardは万能職。
いろんな状況に対応できるように、手数を増やすのがいいと思う。

馬場とDHとWDと組んだけど、馬場とやるのが一番楽だった。
DHは自分が前でないといけないので若干しんどい。
WDは何考えてるか分からないので、こっちも適当にやるしかなかった。
Monkはどこにおるん?

2012年5月17日木曜日

Diablo 3が始まった

Diablo 3やってるけどどこに書けばいいだろうか。
なんか、このブログネトゲから遠ざかってるし、もう1個の方はAVA関係だし、混ぜるのもよくないからもうひとつブログ作ろうかな。

今のところ、自分でハクスラ作る気が起きないほどには面白い。

2012年4月30日月曜日

SSDが欲しくなってきた

100万項目くらいならソートしても数秒もかからない。
けど、HDDからの読み込みは分単位でかかる。
最大のネックはHDD←→メモリ。

オンライン上で利用料金気にしながら作業するのも精神衛生上良くない。
ローカルで処理して、オンライン上は閲覧機能だけの方が楽。

SSD買おうかな。
CPUとメモリ資源は余ってるので、ディスクさえ空けば裏で別のことできるし。

2012年4月28日土曜日

ハクスラ製作休止とこのブログの運用

当面はAVA用のユーティリティツール作るほうに力入れることにした。
それ終わったらDiablo 3も発売されるだろう。
そこで不満があればまた考えよう。

Hellgateへの不満がモチベだったけど、今はAVAでのクラン戦が楽しいし、Diablo 3もなんだかんだで期待が大きい。
そんななので、作る理由が消えかけている。


あっちのブログの方をネトゲのプレイ日記。
ここをサンデープログラマとしての日記にしようかな、と予定している。

2012年4月23日月曜日

データの権威とオンライン実行

RPG要素のあるゲームは全部オンライン実行でいいと思う。
バランスを無視したMODやチート、直接パラメータを弄れるコンソールがデータの権威を落とす。
権威が必要なものはオンライン認証すべき。

無敵になって無差別な殺戮を楽しむという欲求も分からなくないけど、それをやってしまったら終わりだ。すぐに飽きる。普通にプレイするのが馬鹿らしくなってしまう。簡単に時速140kmで走れる靴を履いて徒競走に出るようなものだ。過程を楽しませる配慮がないと、人間は退屈で死んでしまう。

勿論、無双感が足りない人はそれを補えばいいと思う。ただし別の形で。
そういったものは昨今大変に充実している。
お腹がすいた人はまず食べ物を探すべきだ。
おっぱいを揉みたい人はまず女性を口説くべきだ。
図書館に食糧が無いことを怒る人はちょっとおかしい。
そこは本が置いてある場所であって、食べる施設ではない。

育成を楽しむゲームで育成の価値の否定してはいけない。
パラメータを直接弄るユーザーの介入は、育成の価値を否定しかねない。
オンライン実行は改造を容易にする。

オフライン実行させないというのは、ユーザーに間違った選択をさせないという点で優れていると思う。

暫定的なゲームバランス

カラオケ採点の接待モードとは言い得て妙だな、我ながら。

暫定的なゲームバランスは以下のようにして進めている。
・基本はアクションゲームとして考える
・アクション苦手な人は性能の高い装備を揃えることで差を補ってもらう
・スキルはアクションを拡張する


RPG寄りのバランス調整が嫌い
・避けたのにあたった!
・敵の必中攻撃!
・敵の長い無敵時間!
・ランダムエンカウント!


強い敵を前にプレイヤーが取れる選択肢
・性能の高い武器をそろえる
・アクションの腕を磨く
・ビルドや作戦を練り直す
・戦わない


やったことないけど、これ多分モンハンと大差ないと思う。
スキルの種類でしか差別化計れない。

参加性と権威性

「食べログ」と「ミシュラン」の違いからメディアにおける参加性と権威性を考える
上記事のメソッドはゲームにも適用できそう。
普通のCGMの話なんだけど、ミシュランと対比させての分析が分かりやすかった。

食べログ型
・プレイヤーの内容変更に関する参加が容易
・多様な好みやビルドがあることを前提としたゲーム設計
・糞ビルドも存在しうるし、それはプレイヤー側の責任になる
・製作側が制御しにくい

ミシュラン型
・プレイヤーの自由度が低い、映画的
・製作者が提供する形こそが文句なしに面白いという前提に立つ
・内容に関する責任は全て製作者が負うが、品質も保証する
・製作者が内容に関する絶対的な決定権を持つ

ゲームの自由度って曖昧で微妙な表現だけど、ここではストーリーの選択や分岐の話ではなくて、(ハクスラなので)戦闘における戦術・作戦の幅の話。

自由度が高いけどゲームバランスがいいって矛盾している。多様な入力を許すけど出力の結果にばらつきが無いってバランスは、結局自由度が低いってことになる。それは食べログに見せかけたミシュランであり、何かがステルスされている。言い換えると、自由度が高い気分にさせてくれるだけで、実際のところ製作者の手のひらの上ということだ。カラオケの採点システムの接待モードの原理だ。それはそれですごい技術だけど。

ユーザーはどちらを期待しているのか。

自分はミシュランには成れない。

Diablo3 beta

色んなところで言われているけど、びっくりするほどシンプルになっていると思う。
1職しかやって無いしbetaの範囲なので評価はまだ早いかもしれないけど。

ゲームとして新しいことは少なそうだなぁ。
本当に気になるのは公式RMTがどうなるかぐらい。

でも、多分買います。
今年のゲームの中では間違いなく面白い方。

2012年4月19日木曜日

やりたいことの名前

あんまり書くこと無い。
このブログ、ノイズが多すぎて役に立たないらしいけど、元々役に立つ情報なんて書いてない。

AVAのクランランキング
不正確な5項目100万行のデータを破棄した。
正確なデータを取得し直して、使いやすい形で保存した。
見る人が欲しいと思う情報を動的に生成したいんだけど、結構難しい。
Google App Engine、3日ぐらい弄ってるけど全然分からない。
長期戦になりそう。

・ゲーム
デザインパターンを復習した。
全然分かってなかった。
SceneとかStreamとかほざいてたのはMementoだった。
柔軟なスキルの実装方法で悩んでたのは、Chain of ResponsibilityにするかDecoratorにするかということだった。
やりたいことの名前が分かったのは大きな進歩だと思う。

コードはあんまり書いてない。

2012年4月15日日曜日

エントロピーとゲーム

読み返したけど、全然安定してない。

和ゲーと米ゲーで最近話題になるタイトルだと、単純に資源量の差を感じる。
開発資源の量は強みだ。お金、市場規模、万歳。

量が多いというのは複雑さを生みやすい。
でも情報量を増やすだけなら別に大量の開発資源はいらない。
アイテムを増やすことよりも、アイテムを組み合わせることを考えれば良い。
エントロピーが増える。

でも、例えば、10個のアイテムを組み合わせて追加で45個のアイテムが出来たとして、それで実際に使えるのは8個ぐらいだったら残りの50個余りは無駄だよね。
だったら初めから8個のアイテムでよかったんじゃないか?

情報量の多さと、人間にとって意味のある情報の量はあんまり関係が無い。

ただ、55個から8個を選ぶ過程は楽しい。
違いを楽しむ人には最高だ。

現代人の楽しみは差異を消費することしかない。
差異は情報、エントロピー。
よく訓練された人間は小さな違いでも喜んで愛でる。
これは低エントロピーでも退屈しないための知恵だ。
逆に言うと小さな差異しか生み出せないコンテンツはどんどんオタク向けになる。

人間にとって意味のある差異と、ただの情報としての差異はちがう。

例えば、今作っているゲームで移動スキルを3種実装した。
敵に向かって移動するのと、壁に向かって移動するのと、一定距離移動するものだ。
移動スキルは他の攻撃スキルと組み合わせやすい。
例えば殴るスキルと組み合わせるとこんなものができる。

・敵に突進して殴る
・殴ってから別の敵に接近する
・殴ってから壁に素早く退避する
少し工夫すれば
・一定距離移動して移動範囲内の敵を全部殴る
・スーパーボール並に壁や敵の間を跳ねるように移動して殴る

…とか。
最初は全ての移動スキルと全ての攻撃スキルを自由な順番でプレイヤーが組み合わせることが出来たら楽しいかと思った。移動後に攻撃してもいいし、攻撃後に移動してもいいし、それらを組み合わせても良い。それでスキルの種類が事実上大幅に増加する、なんという神ゲー、私の才能が恐ろしい、とか思った。でも、実際のところスキルの大半の組み合わせが無意味だ。エントロピーの増加は質の低下だ。

例えばDiablo 3のキャラクターは初めから攻撃に色々な要素が組み合わさったものがスキルだ。Demon hunterなんて自動で引き撃ちしてくれる。Diabloは何故移動と射撃を分けて実装しなかったのだろうか。彼らは全てカスタマイズできることが必ずしも楽しみに繋がるとは限らないことを知っているからだ。

テトリスが愛されるのは4マスのテトリミノの組み合わせが絶妙だからだ。あれが1マスや2マスずつのブロックで構成されていたら興ざめだ。5マスだと難易度が少し高すぎる。
いくら良い素材があるからといって、それを使った料理が美味しいとは限らない。大事なのは調和だ。

では、開発資源も良い組み合わせを創る感性も乏しい人がどうやってゲームを作ればいいのか。

自分で組み合わせを作らないことだ。
結局最初の方針で進めるしかない。
自由な組み合わせを出来る場を提供して、あとはプレイヤーに任せる。
アンチャーデッドを高級料理店、林檎アプリをお惣菜屋さんに例えるなら、自分はスーパーの食品売り場と駐車場に置かれた七輪みたいな。
人間は情報量を減らし、質を高めるのが仕事。

食材の種類と調理器具を増やすことだけを考えて、あとは知らないで通す。
食材はビルドの要素であり、調理器具は敵の種類だ。

でも、それすらユーザーがModで作ってるゲーム文化圏もあるような…。
じゃあ新しくゲーム作る意味ってあるのか?
エンジンだけ作ってあとは放置?

まぁSource EngineとかUDKとかUnityとかで自給自足してる集団とか大量にいそうだ。
料理や食材は買うものって概念がおかしい、自分で遊ぶものは自分で作るのが一番、みたいな。
最強すぎる。何も反論できない。反消費社会マンセー。

そうなると、ゲーム作る理由は2つしかない。
1つは自分で遊ぶため。
もう1つは他人のため。お金や名誉のため。自然発生的分業。ゲーム作るの得意だから作るね、っていう。
まぁ、自分なんか今、疎外ってるから、よく分かんないけどゲーム作ったら解決するかもって感じで作る人もいるかもしれない。永遠のワナビー。作ることが目的化。It's me.

閑話休題。

同じゲームを何時間もやるなんてジャンクフードで腹を満たすようなものだ。
vs
調味料の進化で我々は腐った素材でも吐き出さずに済むようになった

だからさ、ゲームに何求めてるの?
新しい体験?だったらゲーム以外の事した方がいいよ。
繰り返し同じ作業続けておいて、つまんねーとか言ってるの頭湧いてるんじゃないの?

ゲームは気慰み。
人生はどうせ満たされない。
満たされたと思ってもまた足りなくなる。
苦しみの果てにしか幸せはない。
射精の衝動は苦しみからの解放だ。
苦しめば苦しむほど、開放されたときの快楽が大きい。
感情の落差を求める。興奮と安静を求める。
動物は能力を最大限に発揮しないとストレスがたまる。

どんな新鮮な体験も繰り返すうちに簡単にできるようになってしまう。
飽きる。
人は絶えずやる事を探さなければならないのだろうか?
どこで?

ゲームは無限に課題を生成できる。
解くべき問題を与えてくれる。退屈を殺してくれる。
本当はブロックを積み上げて崩すだけの繰り返しでも、それと気付かないように演出してくれる。
誰かが負けなくてもエンドルフィンが生成される。
気の利いた良い奴だ。
ゲームは間違いなく人間の生活を向上させる。

ブロックを積み上げて崩すだけの繰り返しがちょっと複雑になったのが生物のエネルギーの変換。
最初からなにもかも意味なんて無い。
永遠の幸せは死ぬか、ドラッグ決めて死ぬことでしか得られない。

もっとゆるやかに退屈せず死ねる方法を考えたほうがいい。
最早地球には人間に必要なエントロピーが足りないのだ。
使う量を減らすか、使えるものを増やすしかない。もしくは人が減る。
効率的な食料生産は有用なエントロピーを増やす。
効率的な社会システムは使うエントロピーを減らす。
効率的なエンターテイメントは感情を増やすのか、減らすのか。

減らすぐらいならやらないほうが良い。
増やすためには贅沢でなければならない。
贅沢とは情報量が多いことであり、情報量とは質やユニークさだ。

全員が贅沢であるためにはまだ世の中にゲームは足りない。

もう書いてて自分でもよく分からなくなったので、この辺で書くのやめる。

FE終わった

Fundamental Information Technology Engineer Examination。
華麗に63%ぐらい得点した。
それで御飯食べてるわけじゃないから別にどっちでもいいんだけど。

2012年4月13日金曜日

週末やること、考えてること

核となる部分が固まらない。動き出せない。
微妙な忙しさが面倒。

週末やること、やってること

AVAのクランランキングの改善
面倒だからってCSV形式で全部管理しようとしたら破綻した。
原因はそれだけじゃなくて、Permalinkだと思ってたものがそうでなくて、それを識別子に使ったもんだから死んだってのもある。それに気付かなかったのは管理がまずかったからなのだが。
まじめにSQLとかデータベースを勉強しよう。
あとGoogle Data APIとかちゃんと使えるようにしたい。でも、資料が英語ばっかりでメンドクサイ。でも、日本語だから分かりやすいわけでもないんだよな。

覚えれば、多分ゲームの素材管理とかにも使える。
共有する相手とかいないけど。


・デッキ構築型ゲームの知見
ビルドという点では、それ専門のゲームの知恵を拝借するもの有りかもしれない。
組み合わせを考える楽しさをゲームに取り入れる方法が分からない。
ただスキルを並べてどうぞ遊んでくださいで、楽しくなるほど甘くないと思う。

対人だと相手から得られる情報が多い。
次もまた戦いたいってなる。
運ゲーの楽しさもあるけど、学びの興奮もあると思う。

敵から何か学べるようにすればいいのだろうか。
敵のスキルを奪って強くなるとか古典的だけど熱い。

つづく。


・理不尽な運ゲーとは何かを考える
これは勝手に思ったことだけど、理不尽な運ゲーとそうでないものがあると思う。
選択が出来るかどうかと、結果の出力までの時間の長さが理不尽さに影響すると思う。

具体的には
理不尽でないもの。じゃんけん。コイントス。
理不尽でないけど理不尽に感じるもの。人生の進路。保険。恋人の10年後。
理不尽だけど理不尽に感じないもの。カジノ。飲食店の質。
理不尽なもの。カースト制度。

具体例が悪すぎる。
でも、野蛮な人間は長期的な投資が下手、という事の理由が説明できる。

ゲーム的には、ユーザーが選んだら即結果を出力するか、ユーザーが選んだ結果が間違っていて結構時間が経っていたら簡単に選択をやりなおせるとかすると理不尽じゃないかも。
ゲーマー向けに言うと、スキルの性能がわからないのにスキリセ1800円もするとか運営マジ鬼畜、という話。もちろんスキリセが高コストであることのメリットが無いわけじゃなくて、例えばユーザーが1回のビルド構築を大事にする、みたいなこともあるんだけど、人生を大事に慎重に生きることが人間にとって幸せかどうかはまた別の話、ということ。

2012年4月11日水曜日

ハクスラは育成ゲームなのか

なんか実際に作らないでこういう記事ばっか書いてると信用をなくす気がする。
でも書く。


【育成ゲームの育成とは何か】
・Lvが上がる、Lvの概念がある
・熟練度システム的なものがある

一般化するとこう
・キャラクターが強くなる

育成ゲームではキャラクターが強くなるので、強くするのを楽しむことができる。
キャラクターを強くするための資源は「経験値」や「使用回数」「熟練度」などだ。
RPGだと資源の獲得量はプレイ時間に比例するタイプであるものが多い。何故そうなのかを考えると何気に深いテーマだから、ここでは触れない。
ステージクリア型だと育成資源そのものが制限されていて、プレイヤーが資源を分配するのを楽しむというタイプのものもある。ファイアーエムブレムとかがそう。


【ハクスラする人の育成】
でも、ハクスラ界隈だとレベルがカンストしてからが本当のゲーム、みたいな風潮がある。
やる事は終わりのない育成ゲーム的な「キャラ強化」なのだが、ハクスラだと少し意味合いが違う。
ハクスラではキャラの強さは「装備」と「ビルド」で決まる。レベルの高さで競うことを嫌う。

これはどういう意味なのか。

装備やビルドは、レベルに比べて運や選択の要素が強い。
これらが好まれるというは、ただ時間をかけてプレイしてれば強くなる、というゲームの否定である。


【レベルと装備の共通点と違い】
目的の装備を集めるための「トレハン」という行為は、同じ敵を何度も狩ることを前提としている。
レア装備という概念は、経験値資源を乱数かけてプレイヤーに配布しているのと同じと言える。
レア装備作成の素材を集める、というのはもうほとんどレベル上げと同じだ。

違うのは、どの装備を集めるためにどの敵を狩るかをプレイヤーが選択できることだ。
まぁ、レベリングでもメタルスライム狩りに没頭する人とかいるのだけど。


【ハクスラerが望むもの】
勿論レア装備を集めるのが好きな人が多い。クリックに付随する快感も無視できない。
でも、レア装備ってなんなの?という事をしっかりと考えないと悲劇が起こる。
ただのレア装備という結果は経験値と本質的に違いがない。

大事なのは過程だ。
プレイヤー固有の目的を持って行動を選択できることだ。
強制が無く、自らに没頭することができる環境だ。

暗い世界観が好まれるのもそういう気質の人が多いからだと思う。


【具体的に】
ゲーム作って表現します。


【Hellgateの悲劇】
・終盤になるにつれ装備ビルドの選択の幅が少なくなる
・武器の[+数]を競う不毛な無限レベリング
・でも、お金[上級強化保護]でショートカットできるよ(はぁと

デザインとしては、内発的動機付けを奪う最低なレベルである。

難易度ノーマルでLv35くらいまでで終わるゲームとしてなら綺麗だった。
長くデータを蓄積するMMOデザインとは相性が悪いということが証明された。
過程を楽しむものだから、リセット前提の方がみんな幸せだ。
不毛だと思った瞬簡にすぐ引退できるから社会にも優しい。

無限に過程をランダム生成できるならいいんだけど。
それを楽しませたまま、不毛だと感じさせずにできるのかっていう。
ディスガイアは、まぁ、一つの解だと思う。


【ソーシャルな何かとハクスラ】
基本的に相性が悪い。
マズローのそれを引用するなら、「承認」止まりで「自己実現」に至れない。
いつまでも承認の檻に閉じ込めて集金するビジネスは社会を不幸にする。

装備自慢はささやかなものであるべきだ。
承認が目的になると、人は短期的には力を発揮するが、やがて自己を見失う。
考えたビルドの実現こそ至高である、というゲームがいい。

でも、ゲーム側が自由度を訴えすぎると逆に鬱陶しいというのもある。
場を提供するだけにとどめるのがクールだと思う。
間違ったインセンティブを与えるルールを作らないようにしよう。


【具体的に】
ハードルあげすぎたかも。

贅沢なプログラミング

課題。
・要素の重複の無い
・ソート済みの
・2つの配列を
・重複が無いようにマージしたものを出力する
・片方の配列のサイズは100万位

自分は先月までC++erだったので、
・重複の範囲(先頭)を探す
・そこから先を連結する
というのが最も自然で高速だと思っていた。

でも、こういうのって、些細なミスで1つの要素が欠けたり、重複したりする可能性もあると思う。

でも、C#で楽なやり方だと
・要素が含まれてなければ適当に追加する
・ソートする
…見たいな感じで、しかもミスする要素が無い。
100万個くらいなら一瞬で終わるし、テストするまでもない。

もっと言うと、C#風だと前提条件の
・要素の重複の無い
・sort済みの
という条件は無くてもいい。

C#風とか勝手に言ってるけど、勝手に思ってるだけかもしれない。


入力の条件は緩くて、出力の条件は厳しいというのが楽。
なんでもかんでも放り込んで、でも何故かちゃんと結果が返ってくる、みたいな概念。

2012年4月8日日曜日

パラメータ化できるものはランダムに出来る

ランダムで作る意味とはなんだろうか。

ダンジョンを、アイテムを、キャラクタを、ランダムで生成する。

【メリット】
・プレイするたびに変化するため、繰り返しプレイに向く
・(製作側の)変更が容易

【デメリット】
・製作側がプレイヤーの状態を予想しにくい
・ゲーム性が損なわれる可能性がある
・バランスの調整が難しい


娯楽の最も贅沢な形は「実際に体験すること」。
もっとも固有な情報が得られるが、費用が高い。
次点で贅沢なのは、現状では映画。
でも、映画は参加できない。
視聴者それぞれが異なる、映画のような質の体験をさせるには費用がかかりすぎる。

ゲームが出力しているのは映像だ。
しかし、ゲームの体験の質は一般的には映画よりも低い。
もちろん薄まっているようで、完成度・中毒性の高いものは存在するが、情報量が多くないのは否定できない。

一本道のゲーム(FF13とか?)というのは映画とゲームの中間だ。
ゲームの中に映画のメリットを組み込める。
製作者が意図した展開、興奮、演出を作りやすい。

一本道のゲームの感動をランダムに生成できないだろうか?
一本道のゲームを軽んじているわけではない。
でも、本質を理解できれば原理的には可能だ。
結局のところ素材を自動生成して再生するだけだ。
実現したら毎日違ったリッチなゲームを楽しめる。
でも、現状ランダムで面白い物語が作る方法を発見した人を知らない。
物語論はまだそこまで進んでないと思う。
一から取り組むなら、もう少し簡単な課題にすべきだ。

ランダムで生成してもゲームバランスが崩壊しないようにすることはできないだろうか。
繰り返しプレイしてもらって、フィードバックを得て改良するのも良いかもしれない。
でも、もっと手作業を減らして、本質を理解して、簡単に出来ないだろうか。

難易度を考えてみる
(正しい選択肢の割合)=(正解の選択肢の数)/(全ての選択肢の数)
(正解に気付く確立)=(正しい選択肢の割合)*(正解の気付きやすさ)
(難易度)=(正解に気付く確立)*(正しく入力できる確率)

だめだ、曖昧だ。

でも、ゲームバランスジェネレーターは作りたい。
多分作ったらゲームそのものより価値がある気がする。
ゲーム無料で公開して、プレイデータ収集して遊ぶのも楽しそうだ。

大事なのはデータだよな。
データを集める手段を考えよう。

時を操る程度の能力

最適化の思わぬ副産物。

戦闘の情報をScene(場面)とStream(流れ)に分割した。
通常プレイヤーが見るのはSceneを1秒間に60個描画した画面。
だいたい、1FにScene1個が対応するんでいいと思う。

Scene同士を適当に関連付けたのがStream。
普通は作成された順に並んだSceneがStreamを形成する。
Sceneは使い捨てるのが普通なので、Streamはゲームには必須ではない。
でもこれが意外と便利。

例えばAIが「ある時点のSceneを元に思考する」ということが簡単に可能になる。元々組んでいたAIシステムだと、その時点の情報を元に判断するか、ある時点の情報をAI自身が保存しておくしかなかった。
でも、Streamによって全AIが記憶を共有できるようになる。
理不尽な挙動のAIへの罠でもある。
また、これによってAIの遅延評価も可能になる。認識できないキャラクタは別にリアルタイムで計算する必要もなく、必要になったら今まで計算してた風に表現すればいい。
メモリが大量にあって、CPU資源が足りない状況なら有効だと思う。

あと、過去の世界に簡単にアクセスできるようになったので、プレイヤーは時を操ることが出来るようになった。この概念は非常にエキサイティングなんだけど、どうやってゲームにするんだよっていう。ある時点でタイムポータルみたいなの設置して、それ以降は過去に簡単にアクセスできるとかでもいいけど、それって面白いのだろうか。自分がいない過去が勝手にStreamされていくのは面白いかもしれない。遅延評価ならメインのゲームに影響与えずに実装できそうだから試してみようかな。

【追記】
・刺し穿つ死棘の槍なんかも実装できますね
・キャラクタを逆再生もできるか
・意外と面白いかもしれない

2012年4月4日水曜日

だが、A君の前にはさらなる絶望が待ちかまえている

連載:[完全版]究極のC#プログラミング
この川俣晶さんの連載がとてもためになってありがたいのだけど、時々、というかわりと頻繁に胸にナイフ刺してくるのが辛い。

少し休む

ブログタイトルそっちのけで、前日に書いたことをまだ続けている。
思ったより学ぶことが多い。
学んだ先に見える果実がとても美味しそうなので非常にモチベーションが高い。

学んでもどうせその場しのぎでしか役に立たなそうなものでも、今は積極的に使って行きたい。まずは目の前の問題を解決したい。学んだことは決して無駄にならないと思いたい。
C++を学んで、DxLibとBox2Dの使い方覚えて、C#の色々なライブラリ・ツール群を使い始めている。多分これからは言語を学ぶのではなくて、ライブラリを学ぶ時代になると思う。新しいライブラリは長いサポートを受けられる保障は無いし、使い込まれたものに比べて資料も乏しい。それでも積極的に使っていった方が、物事が早く解決すると思う。未知の領域のツールってちゃんと使い始めないと「それで何が出来るか」がつかめない。多分経験が足りない。あと、大した根拠は無いけど、C++の標準ストリームは「これはダメだな」と思わせる何かがあった。

低レベルなものを大事にしないとかそういう問題ではないと思う。

というわけで、LINQ to SQL使います。
これが何に使えるか分からないけど。

2012年4月3日火曜日

C#でカバーできる範囲はC#のほうが優秀だと思う

既に使いやすい形で欲しいものが揃ってるし、ControlとSpace押してれば勝手にコードが生成される。Emacs使わなくてもHHK使っててよかった、ってなる。あとUnicode。

でも、多分ゲームはC++で書く。
でも、早い段階で気付けてよかった。

マルチスレッド関係の進捗とか

思ったより効果無さそうなのでやる気なくしてる。
普通に計算量減らすこと考えたほうが何倍も効率よさそう。

休日に一気読みした『グーグル ネット覇者の真実 追われる立場から追う立場へ』にものすごく影響を受けた。もっと機械にやらせよう。その場しのぎのパッチじゃなくて、もっと良い方法を考えよう。

テキスト処理が面倒

慣れてないせいもあるけどC++でのテキスト処理は面倒だと思う。

C#で調べながら書くのめんどくさい

C++で欲しいもの一気に書く

細かいところで手続きが抽象化されてなくてだれる

はじめから.Net使ってたほうが早かったかも

習得コストを過大評価して無闇に逃げてはいけないな。
というか、言語で選ぶのナンセンスとか言えるようにならないと。
機能で選ぼう。


あと、時代の先端を行ってそうな人がWindows(Microsoft)はダメみたいな発言するの良く見るけど、ライブラリの資料とかめちゃくちゃ充実しててアクセスし易いし、プログラミング始めてからWindowsが有り余る金(?)で作り上げた王国の巨大さに感動してて、Microsoftはすごいと実感している。
GoogleとかMSとか明らかに独占企業だけど、邪悪にならなければ、そのまま独占してもっと便利なもの下々に垂れ流してくれればいいと思う。

2012年3月29日木曜日

用語の整理

やりたいことの名前が分かってきた。超適当にタスクとか呼んでたけど、どっちかっていうとスレッドとかプロセスとかいう名前だった。処理の分割の単位のこと。
スレッド ⊆ プロセス ⊆ タスク

多分やりたいのはマルチプロセスじゃなくて、マルチスレッド処理だと思う。

もう少し先を見据えておく

処理速度にこだわるならマルチコア対応だろう。
でもこれは雰囲気で言ってみただけで、実際のところこの言葉の意味は分からない。
人生で全く勉強してこなかったツケがかなりまわってきている。
専門・大学でこれらをちゃんと勉強した人がちょっと羨ましい。

なんとなくのイメージだと、1つのCPUだけじゃなくて複数のCPUを使って処理をして、高速化してくれるような印象だ。これって、C++で書いたソースのレベルで記述するものなのだろうか。それともコンパイル時にうまいこと勝手にやってくれたり、実行時に環境側がなんとかしてくれるのだろうか。

並列計算ってことだよな多分。Wikipedia読む限りだと、巷で話題のHaskellとか使わない限りは、自分で何とかしろって感じに見える。Haskellで調べてたらそれっぽい定義があった。リンク先で並行/並列/分散プログラミングの定義がされている。なるほど。

分散計算は明らかに普通のゲームには向いてないと思う。ハクスラとか適用できる要素が分からない。Googleがギガントでも開発したらそれに使うかもしれないけど。
並行計算はどうなんだろう。できる部分とできない部分が有ると思う。多分、キャラクタ同士の関係の計算を分離する必要があると思う。

boost::MPIとかboost::Treadとかそれっぽいけど違いが分からない。調べてみよう。

別に今すぐ導入するとかじゃなくて、今後導入するとなったときに根本的にプログラム書き直さないとダメとかなると非常にだるいので、そうならないように予め調べておこうと思う。

2012年3月27日火曜日

たくさんの敵の処理 現状編

どうやって処理の大きさを測るかという問題に対してはタスクシステムの導入がいいかもしれない。

現状だと、毎フレーム処理したり監視したり更新したりする必要のあるオブジェクトにはすべてvoid Step(int current_time)みたいなインターフェイスのメンバ関数があって、毎フレームそれを実行している。

簡潔ではあるが、外からは何をしているのかは分からないし、処理の大きさはそのオブジェクトしか分からないので、最適化しにくい。まぁ、結局処理の大きさはキャラクタ数と密集度でだいたい決まるので分かるといえばわかるのだけど、これはキャラクタがどれもだいたい同じ大きさの処理という前提があるからだ。しかし、今後そうである保証は無い。

それを逆に、保証してしまえば良い。
だいたい同じくらいの処理の大きさにStepを分割して、タスクシステムに処理を登録。
タスクシシテムは数を数えるだけで1Stepあたりの資源を簡単に把握できる。
タスクに優先度を設定すれば資源の分配がより効率的になる。

…でも、タスクシステムに処理を登録するかどうかっていつ誰が判断するんだ?

1.キャラクタが生成されたとき
2.衝突したとき
3.毎フレーム存在するもの全部登録

現状のStep関数を回して、そこから必要なタスクを生成登録するのがベターかな。

たくさんの敵の処理

Hey, Scripting Guy!のコラムが楽しくてそっちばかりずっと読んでた。
でも、先週CUI童貞を卒業したばかりなので、PowerShellを有効に使ってるとはいえない。
繰り返し動作は積極的にCUIに任せて行きたい。

閑話休題。

リアルタイム処理なアクションゲームにおいてパフォーマンスは非常に重要だ。
速度こそ命である。
現在MyGameは以下のような問題を抱えている。

・だいたい自機・敵機・弾合わせて500個くらいが限界
・敵機が自機を捕捉した状態だと50~100個くらいが限界
・捕捉すると敵が自機周辺に密集するので50個ぐらいで60fpsを割る

このパフォーマンスはIntel® Core™ i7-960でデバッグモードで実行したときのもの。
その環境で動かないゲームなんて現状産廃にしかならない。

まだ、実際に処理時間を計ったわけではないので計る必要がある。
しかし、だいたいの改善方針を立てた(実のところ実際に計るのが面倒だったため、方針ばかり考えていた。

前提として、敵が適切に分散・停止していれば1万個でも問題ないというのはBox2Dを使い始めた初期に実験して確かめた。
大事なのは不要な処理をしないことと、大きな処理でも1/60秒以内に必ず結論を出すことだ。
この2つはまったく別のアプローチなので分けて考える。

不要な処理をしないというのはヒューリスティクスな問題だ。
いくつか不要と思われる処理がある。

明らかに遠くにいる敵が毎フレーム自機を探索するのは(プレイヤーの体験として)無駄である。幸い自動生成された迷路は部屋ごとの関係性を出力しやすいので、同じ部屋にいる者同士のみが探索を行ったり、少し拡張して探索範囲は隣の部屋まで、といったこともできそう。
現状、近くにいる敵の探索方法も効率的ではない。しかし、機能も充分とはいえないので改善するにはまだ早い。
Box2DのBullet処理も悩みの種だ。Bulletは弾同士がすり抜けないように弾道を再帰的に計算してくれるのだが、当然これが重い(自作するよりも遥かに効率的で素晴らしいのだけどね)。どれくらい重いかというと、経験的には同じ処理時間なら8倍くらい物体の密度に差が出せる。特に密集するとヤバイ。敵に密集させないように行動させるか、Bulletを外すか、敵の数を減らすか、という問題になる。これは一番目の答を選びたい。Box2Dは物体が物体にめり込んだ場合、物体の中心点同士の関係に応じて斥力が働いて上手く距離をとってくれるが、中心点が重なると(充分に近いと)くっついてしまう。深刻なバグというほどでもないが、発生頻度は決して低くないし、Bulletを外すとこの現象はさらに発生しやすくなる。しかも一度発生すると「宇宙の 法則が 乱れる!」ので、そのb2Worldを長期間稼動させるならこれは避けたい。

あと、毎フレーム処理(出力)しないというのも大事な方法だと思う。
これはもう一つのアプローチにも関連する。

大きな処理でも短い時間に分割して処理したり、とりあえずの暫定的な結論をだす機能があればフレームレートに影響を与えないかもしれない。将棋囲碁ソフトなんかは自然にやってのけてると思う。
例えば、税金の使い方みたいにあらかじめ予算を組んで、その予算内で仕事してください、と各部署に頼むみたいに。末端の人間のやることが決まっているのでこの方法は上手く働くと思う。でも、「予算足りないのでこっちにまわしてください><」みたいな自体には対応できない。だから予算の配分が何よりも重要になる。これは実際に計ってみるしか無いし、お役所が前例主義なのはシステム的に仕方ない。でも、ある程度大まかに分けたら、あとは分割しすぎないほうが資源は自然に効率的に分配される。
あと、どうやって大きな処理を分割するかという問題になる。分け方には縦割りと横割りがある。縦割りは省庁ごとの分割、描画とか衝突とかAIとか。横割りは、AIが「考えること」を時間数で分割して、前のフレームと今のフレームと次のフレームが連携して1つの問題に取り組む。

そもそも横割りが必要なほどの巨大な処理をするべきかという問題もある。処理が充分に小さければこんなことは考える必要が無いのだ。でも、100体でも1000体でも問題なく動くゲームにはこの仕組みが必要になるかもしれない。まぁ、実際には1000体になったらどうするか、という問題を末端に丸投げしているだけなのだが。仕事増えたけど、予算変わらないけど、優秀なキミタチならなんとかしてくれるよね、と頼む。そして、頼まれた側は可能な限り手抜きする。精度を落としたり、AIを単純にしたり、描画をシャギらせたり。でも、待って欲しい。はじめから手抜きが許されるなら、いままで100体でやっていたリッチな処理は無駄だったんじゃないだろうか。そう考えると初めから1000体で最適化しておけば効率的だったのではないだろうか。

これは部分最適と全体最適の問題である。1000体で最適化しておけば良かったというのは、部分最適の経験が蓄積したから全体最適の結論として言えるわけで、処理の前にはそんなことは分からなかったのである。全体最適されたシステムは効率的だが、汎用性が低い。だから問題の本質は、「そのシステムはあらゆる事態に対処すべきか否か」である。

あらゆる事態とはどんな事態だろうか。ゲームにおける事態の幅は、動くオブジェクトの数が多いか少ないかしかない。これは事前に分かることだ。PCゲームにおいては処理環境の性能不足という不測の事態もあるが、これも事前に分かることだ。

しかし、事前に分かるといってもその調整は誰かがやらなくてはいけない。手作業でやると、機能の追加のたびに調整員が死ぬ。なんという労働集約型ビジネス。こんな環境は人類のためにさっさと駆逐しなくてはいけない。

汎用性の高い横割りシステムを作って、それを少し動かした後、勝手に全体最適化してくれるシステムが文句なしに最強だ。多分既に誰かが作ってて名前があるはずだけど、知らないので調べてみよう。

あぁ、結局まだ何もしていない。

2012年3月26日月曜日

週末にやったこと

やったことを細かく記述しよう。
意味のある記述をしようとするからよくない。
実際何もやってないのに書いてやった気分になるのはよくない。

週末やったこと
・仮想OS(VMWare Player)に興味を持った
・Emacsに再び興味を持った(drill-instructorに叱られたいと思った)
・自分の使う環境を、車輪の再発明でも自分で構築することに興味を持った(DIY?)
・やりたいことと自分のスキルのバランスが取れてないから、小さいことからやっていこうと思った
・RSSフィードを編集して効率的にネット巡回しようと思ったけど面倒臭くて投げた
・Google Readerからやりたいけど方法が分からなかった
・AVAとBF3はたくさんやった。どっちもM14ずっと使ってた。M14は美しい。

結論
・何もやってない。

どっかの2chまとめで読んだけど、ネットを巡回するだけの存在だけど、ネットの波に乗れてないからサーファーでもなくて、浜辺でうろうろしている不審者、みたいな記述がまさに自分のことだと思った。

2012年3月24日土曜日

本当に足りないゲーム

来週から本気出す

月曜日(3/19)から今(土曜日)に至るまでほとんど何も進んでない。
完全に寄り道してた。
.Net Frameworkで遊んでた。

.Net Frameworkは必要なものはたいてい揃っている気がするから、何かしようと思ったらその手段のありかを探すのだけど、探す時間が伸びるとだれる。かといって自分で作るのも悔しい。あと、自分で作るならC++で書きたい。

あと、C++/CLIは.Net FrameworkをC++で利用するためのもので、C#でC++で書いたものを利用するものではないらしい。後者をしたいのだけど、方法がよくわからない。


ハクスラの方は一週間寝かせたので、作業は進まなかったけど、脳内仕様はわりと固まった。

基本的には、妄想だけ膨らんでいた機能やコンテンツをバッサリ切り落として、個人製作可能な範囲にまとめる方向にした。例えば武器やスキルの種類だけ作業量が増えるのだけど、操作は単調にしたくないのでスキルは減らしたくないし、武器のカスタマイズ性も損ないたくないので、武器の種類を大幅に減らした。
個人的に近接攻撃があまり好きではないので、それを減らす方向で。殴るのは嫌いだけど、ショットガンは好き。敵より短いリーチで戦うのが嫌い。その理由については多くあるのだけど、今は話がそれるので簡単にしか書かない。いつか書くかもしれない。

殴りが楽しいハクスラは既に競争相手が多すぎるというのもある。
Diablo 3は既にスタンバってるし。
Titan QuestのチームがGrim Dawn開発してるし。
Dark Questやその他多くのコンソールARPGも殴りが基本だ。
MythosやLineage Eternalなんかも多分気持ちの良い殴りゲーだろう。

自分はHackもSlashもそんなに好きではない。
Diablo 2もそれほどプレイしなかった。
ハマったのはHellgateであってその中でも銃器使いのMarksmanや万能職のEvokerが好きだった。

こいつらの戦いの唯一の美しいあり方は「接近される前に倒す」である。
つまり接近して殴られたら死ぬ。
近付けば効率よくダメージを与えられるが、被弾リスクが高い。
これは非常にシンプルだ。


そういう意味ではFPSのSerious Samみたいなコンセプトが好きだ。
大量の敵が押し寄せてきて、効率的に捌かないとあっという間に囲まれて死ぬようなゲーム。


それに対して、敵にちんたら歩いて近寄って目の前で盆踊りするようなゲームはだめだ。
気泡緩衝材をつぶしているような気分になる。
ひねり潰したい衝動に駆られる。欲求不満になる。
ヒットアンドアウェイなんてのも、結局のところハイリスクな飛び道具でしかない。
敵の胸元に飛び込むのは手下のゾンビがやればいいことで、プレイヤーの仕事じゃない。

Serious Samのようなゲーム性は近接職でもできないことはないだろうけど、非常に調整が難しいだろう。例えば、完璧に立ち回ってもチマチマと削られるのは悪いストレスだ。しかし、完璧に立ち回ればノーダメージとなると、無双シリーズのような単調な戦闘(好みでない)か、DMCシリーズのようなプレイヤーにシビアなレスポンスを求めるゲームになる。DMCはとても好きだけど、ハクスラはある程度だらだらやるゲーム(…ですよね?)なので戦闘中に0.2秒単位の回避を求める緊張を与えるのは悪いストレスになる可能性が高い。いや、操作に熟練してフローに入っちゃえば、緊張が転化して普遍的な気持ち良さを提供するんだろうけど、その習熟コストは万人が払えるものじゃない。これは多くのハードコアなゲームが抱える問題だ。

その点Serious Samは操作自体は単純なのだけど、素早く行動の優先順位を考えるという緊張がある。これはさっきも書いたように構造自体がシンプルだから、慣れるのは簡単だ。慣れてしまえば考えてること自体を忘れて、ひたすら俺Tueeeを味わえる。まぁ、そうなると、やってることはドラクエやWizardryのコマンド戦闘と大差ないかもしれないけど。気持ちよければいいのです。

ただ、ドラクエの戦闘は素晴らしいのだけど、ドラクエにはできない戦闘を実装したい。Diablo 3やLineage Eternalみたいな規模のゲームで実装できない、全くスケールしない実験的なキワモノにしたい。ハクスラの本質的な快感のあり方を調味料にして、それでようやく食えるようなものにしたい。具体的に書いてもいいけど、公開するとモチベーションが下がりそうだから書かないことにしよう。


来週から本気出せればいいね。

2012年3月23日金曜日

寄り道その2

C#でできることがなんとなくわかったので満足した。
そういえばC++はダメだけど、C#だとUnityを無料版で弄れたような。
今度弄ろう。


C#とか弄って、.NetFrameworkすげーってなってPowerShellやべーってなってる。
なんか日々やってることはもっと便利に自動化できることに気付いて感動してる。
ゲーム作ってる場合じゃない気がしてきた。
というか、PCとかプログラムとかの本来の用途がわかってなかったのかもしれない。
文系という免罪符の下にくっそ狭い世界しか見ようとせず生きてきたようだ。


味を占めてさらに別言語も弄ってみたいと思った。
Webアプリとか通信とかさっぱりなのでPHPとApacheをインスコした。
導入がめんどくさくてそこで力尽きた。

2012年3月21日水曜日

寄り道

自分はC++以外の言語に触れたことが無い。
ゲーム作ろうと思って3ヶ月前に学び始めた次第。

ただ、ゲーム作るついでに学んだことで色々できるようになってくると、製作中にこんなアプリ欲しいなぁと欲が出てきたりする。そんなわけでC#でWindows Presentation Foundation(WPF)を弄って簡単なWindowsアプリ(ToDoリスト的なもの)作ってみている。実のところ、そんな簡単なアプリケーションすら作ったこと無い。

WPFはびっくりするほど簡単にそれっぽいものが作れる。

簡単な自分用アプリを作るとき、特に実行速度が要求されないような場合はC#を使うようになるかもしれない。



Design and Evolution of C++を読んだ後にC#の仕様を見るとなかなか面白い。
Cとの互換性のために嫌々搭載されてるような機能がバッサリ切り落とされている。
あとC++みたいなスピードに拘らなければならないみたいな脅迫観念が無くて、ユーザーが落とし穴に落ちにくく、より簡単に安全に使えるように考えられてると思う。
まだ1日しか使ってないけど、比較するとなかなかに美しい言語だと思う。

ただ、多重継承が無いのは不便じゃないのかな?
わからない。



ゲームのUIなんかはC#でプロトタイプ作るのもアリだと思う。
そもそも言語が出力するものが違うので、そのまま流用は出来ない(と思う)けど、プロトタイプは色々試せるものの方がいい。

2012年3月19日月曜日

ひとつずつ、着実に

今回は課題こそ決して難しいものではないが、過程において得るものが多かった。
テストの存在はスタックトレースを考えた頃から自分の中で重要度を増していった。

原因が分かりにくいデバッグはだるい。
この世から抹殺したい。

テスト。
テストコードとテスト対象(実装したい機能)を平行して書く。
CreateMaze()を書くためにCreateMazeTest()を書いて、場合によってはCreateMazeTest::DrawMaze()まで書く。
視覚的に一瞬で結果が分かればモチベーションも高まる。
CreateMaze()の仕様は実はMazeクラスとMazeTest()を書いたときに大体決まる。

ただあんまりテストコードが肥大化するとテストコードのテストコードが必要になる気がする。
このあたりはまだ分からない。

作る前に完全な仕様を思い浮かべるのは困難だ。
まず手を動かしながら考える方がいい。
何を出力したいか、どんな機能が必要かという事をテストコードから考え、仕様を逆算することも出来る。

機能と機能を組み合わせたときに足りない機能が見えてくることもある。
そのとき追加した機能をすぐにテストしたい。
単体テストのコードがあれば、もう片方の機能が出来上がってなくてもすぐテストできる。

テストが前提になると1つの課題が小さくなる。
なぜなら複雑なテストは組み合わせの数だけテストが膨大になり、面倒だからだ。
小さな課題は解決しやすい。
大きな課題を小さな課題に分割する指標としてテストの存在は大きい。

コード読解は面倒だ。
意味は分かっても、完全に正しいかどうかは分からない。
人間の目で判断する作業は非常に神経をすり減らすものだ。
時間が経ってブラックボックス化してしまった機能も、テストコードさえあれば「とりあえず動いている」ことはすぐに確認できる。

テストコードを書くことはいい事ずくめだ。

自動生成ダンジョンのプロトタイプ

アルゴリズムは洗練されてないし、生成がデシ秒単位でとても遅いけどとりあえず出来た。


一応、迷路の大きさは可変。
boostのdynamic_bitsetとか導入した。

マスの大きさを変えられたり、もうちょっと通路が環になればいいと思う。

2012年3月16日金曜日

Unity神輿

Unityが猛烈に気になる。
余りに進化の速度が早い。
Asset Storeで売られてるツールが安くてコンパクトで強烈に見える。
導入したら楽しくなるだろうな、というのが簡単に想像できる。
「乗るしかない、このビッグウェーブに」なのか。

Unity神輿なんだよな。
何もしてなくても競争に晒される。
勝つためには一人では力不足で何かを担ぐしかない。
神輿から恩恵を受ける変わりにUnityに貢献する。
勿論ユーザーが受け取ってるモノの方が圧倒的に多いのだけど。
それを信仰すればするほど、信じる他なくなるのが怖い。

とりあえず、いつか書いたけど、今の環境で作り上げてから考えよう。
Unityへ移植してリッチにするのはそれからでも良いし。
Diablo3への後出しジャンケンも出来るし(笑…っていいのかこれ……

Unity。 RivalTheoryチームが怖い
別に業界人じゃないけど、この人の気持ちが今はすごく分かる。

2012年3月15日木曜日

部屋の自動生成

前回迷路作ったので今回は部屋を作った。
連絡通路の方向を決めれば適当にランダムな部屋を作る。

部屋の形状の情報をブロック単位(普通のRogue部屋)で出力するか、ローカル空間(迷路の1マス分、セル)に対する相対座標にするか迷ったけど、汎用性を考慮して後者にした。でも、いまのところブロックでも出力可能な部屋しか生成してない。


セル間の通路の道幅をランダムにしたけど、見栄え的に1つの通路は同じ幅の方がいい気がする。
一つの通路は[部屋Aからの通路,セル間連絡通路、部屋Bからの通路]で構成される。

次は連絡通路作ろう。


ゲームに反映するまでの残り工程
・連絡通路作成
・迷路、部屋、連絡通路の合成
・Box2Dへの変換



ふと思ったのだけど、ゲーム作っているよりこの部品製作の方が楽しい。
多分、仕様を考える→書く→テストする→正しく出力される、の過程がスムーズだし、出力結果がすぐ目に見える(Dxライブラリだとすぐ書ける)だと思う。
ゲーム部の記述はオブジェクト同士の関係性の記述や、それらの処理フローの記述ばかりで、ヴィジュアル的には非常に地味だ。しかも複雑でバグが見えにくく、テストしにくくて頭が痛い。
小さいものを書くのがいいね。

2012年3月13日火曜日

胡散臭い迷路

迷路自動生成アルゴリズムを参考にさせて頂きました。
ただ、細かいところが怪しくて微妙に道幅が広い。

壁倒し法なので一応全部の通路が繋がっていることが保障されるはず。

48x48

64x64

120x120

実際に使うには一番上の迷路ですら広すぎるのでもっと小さくするかも。
迷路の1ブロックを1部屋(もしくは通路)に見立てて以下のように(Rogue形式)で連結。


それをBox2Dのstatic_bodyとして出力しつつ、自前のゲーム部の壁キャラクタとして登録する。Box2Dは凸型シェイプしかサポートしないので、地味にめんどくさそう。

2012年3月12日月曜日

ランダムに生成されるダンジョン

ローグっぽくてもいいけど、迷路にするのはなんか微妙。
さまざまなアクションが生かされる舞台である必要がある。
いいアルゴリズムはないだろうか。

マンデルブロ集合とかいうフラクタル?とかなんとかが面白そうと思って調べた。

そしてリンクを参考に簡単にDxLibで出力した。
右上の数字は計算回数。つまり、大きいほどより複雑に出力される。













これがダンジョン生成に使えるかというと、非常に難しいと思う。
適当に複雑な図形を出力することは出来るけど、それなら別にフラクタルじゃなくてもいいし。

部屋と通路の組み合わせ以外の方法は何かないだろうか。
模索中。


(同日追記)
Maze generation algorithmというらしい。
とりあえず迷路が手に入れば、あとはRogue形式で部屋を作ればいいのか。
当たり前の話なんだけど気付くのに時間がかかった。
迷路は部屋と部屋の連結の表現であって、部屋は出入り口さえ作れば中身はどうでもいい。
抽象化のレベルが1つ上がった。

このジャンル、先人の創意工夫の歴史が多くてサーフィンしてると面白い。

汎用ゲーム実行フロー

・できる?

できない → しない
できる → いつかやっといて

・俺のターン

・タスク消化

三者面談
A→できる?→B
B→できる?→C
C→回答→B
B→回答→A
A→じゃ、やります→B
B→やっといて→C

このフローから分かることは、仕事をこなすことも重要だが、先んじて何をするかを決めることも同じく重要ということ。末端のオブジェクトは何が出来るかを常に公開していなくてはいけないし、上流のオブジェクトは最小限の命令で必要なオブジェクトを働かせることが望ましい。

社会の縮図を感じる。

2012年3月11日日曜日

細かい変更

skillやweaponに対してuseやinvokeやreloadみたいなインターフェイスで使ってたけど、命令が増えると思い通りに動かない。
命令間の整合性を保つために、コマンドを呼んだ時に可能なら即実行じゃなくて、命令を少なくともそのフレームの間はスタックしておいて、優先順位をつけつつ不要不可能な命令は無視してそのフレームの終わりにまとめて実行する方がよさそうだ。

reloadをshootでキャンセル可能にしたのはいいけど、それらを同時に実行できるとかいうわけの分からないことになったのでそういう問題が発生した。あと、shootの後、次のshootが可能になるまでの間隔はreload出来ないほうがいいかもしれない。shotgunのshootがreload連発でRoFが向上するとか言うわけの分からない状態を直そう。

2012年3月9日金曜日

単体テスト?

テスト駆動開発ってかっこいいな。
printfもどきじゃなくて、assertマクロ使えよ。
って言うか、それよりもちゃんとテストしろよってことか。


ゲームの方は、銃の弾倉オプションとしてチューブマガジン実装した。
普通の弾倉はQueueだけどチューブはStack。
最後に入れた弾が最初に出るので、弾の種類を臨機応変にすれば楽しく立ち回れる…かも。

リファクタリング成果

リファクタリング成果という名の日記。

・だいたい30%ぐらい効率が向上した。
敵100体から130体ぐらい動かしてもOKの変化。内部でどうなってるか分からないので、30%というのは実に適当な数字だ。効率ってなんだよ。

・標準STLのアルゴリズム
だいたい使えるようになったのでループが見やすくなった。以前は関数オブジェクトのことを関数のポインタかなにかだと思ってました。ただのクラスですね。

・生ポインタ撲滅運動ができた。
設計がだいぶまともになったのでshared_ptr,weak_ptr,unique_ptrの使い分けが出来るようになった。nullptrとの比較じゃなくてexpired()使うようになったので非常にお行儀がよくなったと思う。でも、他ライブラリと連携する場面だと、ナマポ使わざるを得ない。
静的記憶でもよさそうな場面でも、継承することを考えるとポインタで持ってた方がメモリ的には(継承元の使わない機能とかあると)無駄がなかったりするような気がする、けど、実際の効率は知らない。
所有権が明確になるので、積極的にポインタが使えるようになる。そのおかげでコピーや情報の更新の手間が大分減る。

・バグの特定スキルが向上した
デバッグが長引くと異常なまでに萎えてくる。これは重要。

・ゲームの開発意欲が若干低下した
あれ?
なんか、人としての視野が若干狭くなった感が否めない。

2012年3月4日日曜日

無題

機能が明らかなクラスは演算子をオーバーロードすると見た目がすっきり。
クラス名は名詞、関数名は動詞にしてるけど、両者の語源が同じなら関数オブジェクトにしてしまったほうが良いのかもしれない。
見た目が変わってないので、相変わらず進捗SSは無いです。


Ameroadの話題、熱いなぁ。早いしスマートだし。

2012年3月3日土曜日

時代が早くしろと言うのです

開発にスピード感がない。
最適化のためにリリースが遅れるのは悪みたいな風潮が辛い。最適化のスピードがハードウェアの進歩よりも遅いなら無駄と言われても仕方ないような気もする。でも、ハードウェアの性能が10倍になるのに5年かかって、ソフトウェアの効率を10倍にするのに5年かかるとしたら、どっちもちゃんと仕事すれば5年後には開発開始当時の100倍の体験が出来るよね。18ヶ月で等倍の効率のソフトウェアをリリースしてもその時点では18ヶ月前の2倍(cf.ムーアの法則)の体験しかできない。

まぁ、机上の空論と一蹴されるような話ですね。
企画クラッシャーにならないように頑張ろう。



以下、まったり開発の試行錯誤。


const修飾子つければダウンキャストしていいんですね、知らなかった。
推奨される事はないだろうけど、こういう書き方も出来るんだなーと。
つい多用したくなりそうだ。

こんなのが必要な場合、関数fの引数の型のBaseクラスの設計が悪いとは言えそう。
もう一段階抽象度を上げれば解決しそうだけど、まぁ、優先度は低いので後でやろう。



もう一つ設計の問題(解決済み)
何かのクラスに何かの値をセットしたいとき。

クラスTが充分に小さかったらこれでいい(かもしれない)のだけど、コピーコストが無視できないときがある。
どっかでT作って捨てる処理が1回余分に発生するので。
その時右辺値参照が便利そうなのだけど、そのためにはSet関数の引数のconst外さないといけない、と思う。

めんどくせー。

ゲームのプログラムで値をセットするためのオブジェクト(ただのラッパー)なんてどうせ一時的なものなので、constなんていらなかったということですね。




あと、ハマったことのメモ。
MSVC++ 2010でのコンパイルエラー

error C2248: 'std::unique_ptr<_ty>::operator =' : private メンバー (クラス 'std::unique_ptr<_ty>' で宣言されている) にアクセスできません。

unique_ptrをprivateなメンバー変数に持つクラスをコピーしようとすると発生した。同様に代入もダメ。自動生成されるコピーコンストラクタじゃ対処できないので、自分で書かないといけないってことらしい。
上手いこと自動でやってくれないのね、って思ったけど良く考えるとそれも困るのか。unique_ptrで管理されるインスタンスの所有権が曖昧にならないよう、コピーメンバ関数みたいなので実装したほうがいいかもしれない。

コピーメンバ関数?

メンバが増えると書き直さないとダメだけどとりあえずこれでいいのかもしれない。
・引数にとったクラスのprivateメンバってアクセスしていいのね…(自身からのアクセスってことになるからなのか?当然引数にconst付いてるとこんなこと(swap)は出来ない)
・copy実行すると引数にとったクラスのメンバー変数のポインタ(pimpl)はnullptrになる


【同日追記】
そもそも最初からunique_ptrで管理してればコピー関数なんていらないかもしれない。
新しくインスタンスが作られないので。

これならポインタを付け替えるだけなので、コピーコンストラクタが呼ばれない。
関数に渡すときはunique_ptrごと参照で渡す。
つまるところ、unique_ptrは感染するということになるのだろうか。

2012年3月1日木曜日

ダメな開発例を学んだ

リファクタリング作業もほとんど終わり。
でも、こんな作業2度とやりたくないとか思ってます。

今までの開発は”とりあえず動くもの”を作って、そこに機能を追加していく形でした。個人開発なので適切な表現か分かりませんが、アジャイルと言えると思います。機能を追加してすぐ試せるので、モチベーションが下がりにくいですし、バグも早い段階で取り除けます。

しかし、コードの複雑化により、機能の追加が困難になってきました。そこでリファクタリングすることにしました。

今後の機能追加に耐えられるよう、柔軟で使いやすい設計を考えました。今までの資産も流用できるようにしました。その後、コーディング作業に取り掛かりました。しかし、リファクタリング開始前に考えた設計では必要な機能が足りず、リファクタリングしながら順次機能追加をしていきました。

そして頭がこんがらがりました。
進捗状況や作業中のコードと完成したコードの区別がわからなくなりました。
そのうち脅迫されたようにコンパイルを通すだけの作業になりました。

コンパイルは通ったが即エラーが!単純なものでしたが。

今回の経験で色々な教訓が生まれました。
まとめると以下の2点です。

・自分はメモとか苦手
未完成のコードとそうでないコードを分けるためにコメントとかしません。
それでも大丈夫な作業形態にすべきです。

・作業は小さく
そもそも、今回だって一度に一気にリファクタリングする必要なんてなかったのです。
それに終わりの見えない作業は誰だって苦痛です。



とりあえず、明日には2/22時点と同等の機能をもったもののところまで終わりそうです。

2012年2月22日水曜日

スパゲティ爆発

コードが複雑になりすぎて頭が爆発した。
設計を見直そう。

仕様を決めずに拡張性の高いコードを書こう、と思ったのだけど、無謀だった。とりあえず動くものはできたが、いざ機能を追加しようとしても、コードがあちこちに散在しすぎてて修正箇所の把握が困難。作業効率が悪すぎて一向に前に進まない。

…というわけで、早めに正しい設計に戻そう。コードの重複に死を。適当にconstされてないポインタ戻すのは最早誰が中身を弄っているのか分からないし最悪だ。かといってGetSetにまみれた糞クラスも作ってはいけない。

今回の件から我々が得るべき教訓は、仕様が確定しないうちに製造を始めても決して完成しないということだ。



My Hack and Slash Gameにおける仕様と設計

【おおざっぱな仕様】
--あらゆる手段で敵を倒すのが目的である
--武器、スキル、キャラクタは外部から数値が変更されることがある
【少し細かい仕様】
--CharacterにはPlayer,Friend,Enemy,Bullet,AoE,Wall等がある
--SkillにはActiveSklillとPassiveSkillがある
----前者は実際にSkillをInvokeするTrigger
----WeaponはSkill発動の条件にはなるが、それ自体にInvokeの概念は無い
----後者は内部的にはほとんどWeaponと同じだが、Itemではない
--WeaponはSkillの性能を変更させる
----普通のARPGにおけるItemはWeaponとして処理する
--Skill,WeaponはCharacterが所有する
----それらは変更のされない参照を無制限にされる
--CharacterがSkillを使い、CharacterとSkillとWeaponに基づいてCharacterを生成する
--Characterの数値が変更されるEventは以下の条件で発生する
----Character同士の衝突
------衝突開始、接触中、接触終了により処理が分岐する
----時間経過
------SkillやWeaponの時間経過によるCharacterへの影響
------Character自身のTimeEventによる変化
----Userによる操作
------専らPlayerのみである。SkillのInvokeと移動を行う
----AIによる操作
------Player以外はCharacter自身で保有するAIがSkillのInvokeと移動を行う
----Skillによる衝突に拠らないCharacterへの干渉
------Friendの操作など
------SkillのPowerCost等はInvoke時ではなくここに処理がStackされ実行される
----CharacterがDeathってるならそのFrameの終わりにInstanceが消滅する
----その他
------未定┗(^o^ )┓三
--衝突、Characterの挙動はBox2Dが全部面倒見てくれます


【恒例の進行具合SS】


敵の体力ゲージ作ったらAoE放つともりもり減ってんぎもぢぃいいいい。

【確認されている不具合】
敵が200体ぐらいいると超重い。
プレイヤー発見した状態で毎F敵同士密着しながら接近してくると50体でも重い。

あと、Box2D側の不具合(?)かどうかは分からないけど、b2_staticBody上になんらかのb2_dynamicBodyをめり込んだ状態で生成してしまうと、以降全てのb2_dynamicBodyがisBullet=true状態でもめりこみまくりーの状態になる。ただし、普通はこの不正な場所への生成自体がなされないんだけど、一度に沢山生成するとたまに失敗するっぽい。

2012年2月20日月曜日

簡単なUIができた


今回はBox2DではなくほとんどDxLibを触っていた。

左右の赤(Health)と青(Power)の円アイコンの増減は、残量に応じてマスクを移動させた後、中身を埋めた円を描画することで実装。

それより小さな円アイコンは
a. 割り当てたスキルの画像
b. スキルの再使用時間
c. 利用回数制限があるスキルはその残り利用回数
…を表示

ウィンドウの大きさを可変にしたいので、画像の大きさも可変にする必要がある。ただ、b.(円グラフ)を表現するためにDxLib::DrawCircleGaugeっていう便利な関数を使いたかったが、これの引数のグラフィックハンドルは既に適切な大きさになっている必要がある。画像を拡大縮小して描画する関数にDxLib::DrawExtendGraphがあるが、DxLib::ExtendGraphCircleGauge関数なるものは存在しないので、DxLib::MakeScreenを使ってサイズを拡大/縮小したアイコン用のグラフィックハンドルを作ってから、DxLib::DrawCircleGaugeで描画している。

DrawCircleGaugeは三角形の組み合わせを描画することで実現している模様。
ちなみにそのままではこの関数で矩形を描画することはできない。

作ってから思ったのだけど、銃本体をスキル扱いにしてしまっているので、今の仕様だと左手にマシンガン、右手にショットガン、残りスキルスロットにも重火器スキルを設定すると、スキルスロットの数だけ武器が同時発射可能になってしまう。
色々バランスが崩壊することが予想されるので、”装備している武器を使う”スキルとして実装する必要がありそう。さらに、スキルの再使用時間以外にの追加のパラメータとしてスキル使用後の硬直(他のスキルも使用できない)時間を設定する必要もあるか。

次回更新までに、スキルの種類増やしつつその辺を補強しようと思います。

2012年2月17日金曜日

UI作成中

HUDと言うのだろうか、よくわからない。
Hellgateの配置をそのまま参考にしている。

これを前提に設計されていなかった事による作業量の意外な多さと、マスク関係の難しさと、体調の悪さによりほとんど進んでいない。

とりあえずHealthとPowerの数字抜き版のみを表示。少し透過させるのが好み。

Hellgateのそれに加えて、残弾数表示と、再使用時間の表示をLoL風にする予定。ゲージを時計回りに増減させて表示するのって、三角形を組み合わせてマスキングしていく方法でいいのだろうか。負荷高そうなんだけどw

2012年2月14日火曜日

敵の動きの追加

最も単純なAIを実装した。

【アルゴリズム】
a.敵プレイヤー間の距離が一定の範囲内である
b.敵プレイヤー間に射線が存在する(間に壁が無い)
・条件aかつbを満たした時、敵はプレイヤーに向かって移動する

敵をすり抜けられないので、敵の移動速度が速いとあっさり囲まれる
条件aの実装は割と簡単。b2Distance関数に両者の座標を入れるだけ。
条件bの調査にはb2WorldクラスからRayCast関数を呼べばいいのだけど、その引数のb2RayCastCallbackクラスがちょっとやっかい。

いつか書いたb2QueryCallbackクラスと同様にb2RayCastCallbackクラスはインターフェイスなので、自前でMyRayCastCallbackクラスを書く必要がある。



この純粋仮想関数は、b2WorldのRayCastから呼ばれると始点から終点にかけてb2Fixtureを発見する度に呼ばれる。つまりループに組み込まれるのである。ループを終わらせたい場合は0.0fを戻し、走査を続けたい場合は0.0fより大きい正の数(普通は1.0f)を戻せばいい。条件bのようなことをしたい場合は、RayCast関数の始点終点を敵とプレイヤーに設定し、ReportFixture関数の引数に壁オブジェクトが含まれることがあるかどうか調べればいい。
大体そんな感じで実装した。

ただ、奇妙な問題が発生した。上の画像のものは両者間の距離が最短5.0m~最長50.0mの範囲にあるときに接近する、と設定したのだけど、実際はかなり密着している。これは外側の敵が内側の敵を押し込んでいるためである。

ただの赤丸でしかない敵だけど、動きを加えたらなんだか可愛く思えてきた今日この頃。

AoEの実装

範囲攻撃を1つ実装した。
大した内容ではないのにやたら大変だった。

クリック後、その地点を中心に攻撃範囲が描画される。
しばらくすると攻撃判定が発生する。しばらくすると自動で消える。


【範囲攻撃】
クリック後、任意の時間経過後、クリック地点から任意の範囲に任意の期間攻撃判定を与え続けるもの。
【追加で必要になったもの】
①ゲーム内時間の管理
②時間をトリガーにして発動する処理
③接触している限り攻撃判定を出し続ける処理

①に関しては既に雛形があったのでそのままクラス化した。
②は既存の処理と整合性をとるのが面倒だった。色々書き直した。
③はb2ContactListenerは接触開始と、接触終了しか教えてくれないので、その間の処理を自分で書く必要がある。Bulletは連続hitしてほしくないが、AoEは連続hitするものもあるので場合分けが必要。
更に言うと、物理接触は無いけど攻撃判定はあるっていうのが面倒だった。

結局全パターンあるということか。

別の話。
Orc Must Dieが今までプレイした何かに似ていると思ったらテクモの影牢シリーズの蒼魔灯だった。あのゲーム、今思えばかなりの良作だった。攻撃面(罠)の種類や強化手段が多いので、敵をどう倒そうかとゆっくり考えてる時間が楽しめた。ただ、血と断末魔の表現が苦手だったので1週しかしなかったな。

2012年2月12日日曜日

散弾銃っぽいの実装した


前回b2Filter設定したので一度に沢山の弾が出せるようになった。上画像は16発に拡散したもの。
そのままだと、近距離で密集した敵を蹴散らすには物足りなかったので、貫通オプションと反射オプションを実装。近距離では弾が貫通する、みたいに設定するといい感じ。反射は自殺してるようにしか見えないので微妙(笑)

反射は単純な接触カウントと、前回当たったオブジェクトかどうかの判定のみで実現している。
貫通は上に加えて、接触対象が敵の場合、弾側は物理衝突の影響を受けない、とした。
普通にゲーム作ったら反射の方が複雑そうなのに、物理エンジンの上だと貫通の方が特殊だという事例。

b2ContactLisner使っている限りは連続Hitしないので、現状「前回当たったオブジェクト かどうかの判定」はいらないのだけど、弾に当たった敵が弾より速い速度でふっ飛んだりするとアウトなので、とりあえず付けた。便利そうなので親クラスに持たせてもいいかもしれない。


以下、その他の話題。

Googleのスタイルガイドが大変参考になります。C++は色々ハマりやすい言語らしいので、迷ったときはここの規約に従っておけ!ってなるのがすごく楽。親→子とするのにdynamic_castを使いそうになったけど、設計に問題がある可能性があると言ってくれているので省みるきっかけになりました。

あと、ETERNAL CITY 2とがOrc Must Dieが気になってる。目指したいノリとして結構近いのでどっちかプレイしてみようかな。商業の壁に心折れてしまうかもしれないけどw

2012年2月10日金曜日

進捗まとめ動画


進んでいるような後退しているような(笑)
密着かつ同時破壊はくっそ重いという、処理落ち動画。

多分、破壊表現はリアルタイムで処理すると低スペックPCはフリーズするかも。
雰囲気とノリで付けただけなのですぐ剥がす。
GPUが演算してくれるグラフィックにしよう。


今後の方針

・プレイヤーのアクションを増やす
弾幕バリエーションだったり、AoEだったり、何か攻撃的なスキルだったり

・敵を動かす
処理の限界を知る上では先にやったほうがいいかもしれない

・リソースは自作しない
グラフィックと音楽のセンスが致命的に無いので、それらは借りるか買う。
つまり、しばらく画面に劇的な変化は無いだろう。

・エフェクト知識を充実させる
ゲームの気持ち良さはエフェクトと音と操作性が8割占めると思う。
自作はしないだろうけど、利用できるくらいまでは知っておこう。

・C++の知識
細かいことで悩む回数が減ってきたので作業スピードを意識してみる。

2012年2月8日水曜日

ゲームのデータをどう扱うか

ゲームのデータを全部実行ファイルに入れるのではなく、必要なときだけ読み込んで使いたい。
あわよくば書き出しもしたい。
どうするか。

予想されるデータ群。

 ・ステージの情報   : 地形、敵の沸き
 ・キャラクターの情報 : プレイヤー、敵、弾、壁
 ・道具の情報     : アイテム、武器、スキル
 ・描画の情報     : (どこに紐付けるんだろう…)
 ・セーブファイル   : ユーザーの進行状況、環境設定情報


後でどうとでもなるようにする、と連呼してきたので、資源が充実しているXMLを使ってみようと思う。
html分かればすぐ使える…よね?

名前をつけておけばいつでも引っ張り出せるのは楽しそうだ。まだ良く分からないけど。

2012年2月7日火曜日

セミコロンがないだけで3時間も悩んだ

T/O

…で済む話だけどあまりにf***************kなので後世に語り継ごう。


Visual C++ 2010でのお話。
コンパイルするとこんなエラーが出た
error C2236: 予期しない'class' 'b2Body'です。';' が入力されていることを確認してください。
エラーにしたがって";"セミコロンの欠如を全力で探すべき。素直に。
間違ってるのは前方宣言とかテンプレート引数じゃないよ!!
…と、当時の自分に伝えたい。

具体的にはエラーが出たファイル自体じゃなくて、インクルードしたヘッダで宣言されたクラスのセミコロンが抜けてたりした。


でも、おかげで前方宣言の知識が強化されてファイル間の依存関係が若干減った。
そんなことより早く完成させるべきなのだが…。

2012年2月2日木曜日

色んな物体を自由に生成できるクラスを製作中

まだDxLibで描画できたよー、ってだけのレベルです。

テストコード(スパゲティ関数郡)書いて、テスト。
後で読めるようにクラス化して、テスト。
機能追加するために構成変えて、テスト。
あとで変更しやすいように書き直して、テスト。

確実に進んではいるのだけど、わりとまったり速度です。

今は色んな物体を自由に生成できるクラスを製作中。
Factory Classって言うのだろうか。

早く動かしたいなー。

2012年1月28日土曜日

誤差も積もればバグとなる

整数以外の演算は誤差が出るんだよな。
計算は一箇所にして、参照させないとダメだな。
たまに弾が巻き戻ったり残像拳発動したりします。
(´・ω・`)はあまじはあ

2012年1月27日金曜日

半透明なテキストエディタ

製作とはあんまり関係無い話。
UNIXとかそうゆう文化に全く触れてこなかったのでEmacsとかvimとか扱ったことがない。しかし、半透明なテキストエディタでコーディングしてる人の画像をみて、あぁなんてクールなんだろう自分も使ってみたいなぁと思い、反射的にWindows 7 64bit環境へNTEmacsさんをインスコさせて頂いて、.emacsファイルとやらとせっせと弄って、起動して、いざ見てみるとやっぱり透明なウィンドウ格好いいなぁ、と。たぶんこれは便利だなぁと。世の中にはこんな素晴らしいものを作ってくれる人がいるんだなぁと感じた次第であります。

Coooooooooool!!!
でも、Emacsの操作体系覚えるのメンドクサイです。
いや、覚えたら早くなるのかもしれないけど、Windowsしか使ったこと無くてVC++でマウス使いーのインテリセンス頼りーのってGUIに慣れきった状態だと、果たしてキーボードでガシガシ書いていくのが本当に効率的なのかどうか良く分からないのです。そうゆうシーンはなかなか様になってると、かっこいいのはそうなんですが。

ただ、HHK(Lite2)使ってるのにこのままってのも邪道だよなーと勝手に胸を痛めていたり。

しかし、別に悪いってわけでなくて、むしろこれが良くて、キーボード右部分が無くてコンパクトだし、カーソルキーとPgUp,PgDown,Home,Endが右下に集まってるからマウスと連携しやすかったりするわけです。これはこれで動線短くて素敵だと思うのですがどうでしょうか。

2012年1月21日土曜日

postしてないけど進んでないわけではない

…という弁明。

成長のスピードが急だと今日の自分から見て昨日の自分が拙く見える。
振り返って修正してばかりいると一向に前に進まない。

細かい進展は明日書く。
本当は弾撃つぐらいまではやりたかったけどなぁ。

作ったこと
・dxlibの入力関係のラッパ、及びキーコンフィグ
・キャラクターのwasd移動(実装の詳細は超適当
・それにあわせた画面の移動と描画
・画面の拡大縮小

キーコンフィグにかなり自由度加えたらものすごく時間かかった。
でも、最近のゲームってこの辺充実しているし、便利だから真似たかった。
一度作ったら再利用できるしね。

2012年1月15日日曜日

車輪の再発明~衝突判定編~

色んな形同士で衝突判定する部分を書いた。
正しくは書いている途中。
絶対どこかにあって誰か書いてるよなこれ(笑)。
強いて言えば小数部分も保有しつつ、衝突・包含は整数型でしか判定しないのが特徴?
普通は小数部分に適当な閾値を決めてやるのだろうけど。
めんどくさかったので、また必要になったら考える。

点と線分とベクトルと三角形と矩形と円とそれらの組み合わせの図形についてそれぞれclass化した。
それぞれの包含と衝突の操作書いたら再利用できる部分は多いものの結構な分量に。
一度書いてしまえば楽だと思うのでさくっと書いてしまおう。

2012年1月12日木曜日

重すぎて動かない

関数オブジェクトが良く分からない。

std::for_each(hoge.begin(), hoge.end(), piyo());

だと、piyo()が関数オブジェクトである必要があるのは分かった。
でもclass A内のB関数の中で、同class内のC関数を入れたいときどうするのだろう。
適切な関数アダプタがわからないし、そもそも用途が正しいのかも分からない。
結局全部while文です。まぁ、困っては無いのだけど。

auto it = hoge.begin();
while (it != hoge.end()) {
  piyo(*it);
  ++it;
}

とある開発画面。
( ゚д゚) 606666msだと…。


1FPS分の処理に600秒かかっているという壮絶な糞ゲー。
全く最適化せずに2万キャラクター操作したらこうなるよっていう話です。
とりあえず今は1000分の1くらいにはなってます。それでも遅すぎですね。
画面外の処理をもっと手抜きしないとゲームにならんなこれ。

2012年1月11日水曜日

製作どころじゃない

別に知らなくても作れるんだろうけど、これを期に勉強したいことが多すぎて進んで無い。
C++はこれほどまでに宝の山だったのか状態。

あと、話題のUnityはC++使うのに12万5千円かかるそうで。
無料版はJavascriptとC#のみ。
ビジュアルをどのレベルでどう実現するかは未定なので、まだ関わらないでおこう。
とりあえず基本的な部分を作るまではDxLibを利用させていただく予定。

2012年1月7日土曜日

偉い人達の技術を盗みに

C++0xもといC++11とそのライブラリで使えそうなものを探した。
全くノータッチだった。知らない間に世界は進んでいるのか。
色々変わっていて、まだ分からないけど、おそらくとても便利で強力になっているだろう。
使い易く標準化されたものは積極的に取り入れていこう。

週末はお勉強だけで終わるかもしれない。

2012年1月6日金曜日

頭の容量が足りない

実のところ前回に引き続き四分木で立ち止まっている。ほとんどIKDさんのとても素晴らしいsampleをコピペしてオレオレ規約に簡単に書き直して使おうとはしているのだけど、いくつかの不安要素が解消されない。動くには動くんだけど細かい流れが一度に追えないので怖い。頭のメモリが不足しているのだろうか。練度が足りなくて圧縮技術が無いとも言えるな。

【不安な点】
・生のポインタを使っている
・自作スマートポインタと自作リスト(コンテナ)を使っている
・多分後から読んでもすぐには理解できない


汎用性が高くて高速なのかもしれないけど。結局4分木空間分割自体が、そうゆうもの(自作コンテナ?)を作ることなんだろうけど、実行速度を見ながら部品をSTLで置き換えて書き直そうと思う。

…ということを考えただけで終わった。

それにしても「ゲームつくろー!」は大変参考になります。
学が無い私でも非常に分かりやすく、かつゲーム製作のクリティカルな部分が書いてあります。多謝。

2012年1月5日木曜日

2Dなので四分木で最適化した

元はと言えばWUXGA解像度の画面全てを使って、1pixelにつき1characterで描画するというあまりに無知で無謀な計画が最初だった。本当に何も知らなかった。全characterが毎Frame移動して衝突して、というひたすらrichな計画。

とりあえず書いてみたはいいが、全然動かない。1frameの処理に何秒かかっただろうか。適当なcontainerに無理やり詰め込んで、総当りでぶん回した。200万characterの負荷は2011年のPCにはあまりにも重過ぎた。

なので、まずは毎秒30frameは最低でも出せるくらいに頑張る予定。


4分木空間分割を最適化する、をオカズに遊んだ。

骨組みほとんどそのまま移植というか引用した。色々妥協してXGAに落として色々数値弄ってみたけど、1worldで200~300characterぐらいが限界っぽい。それでも弾同士が密集されると描画しなくてもけっこう重い。むしろcharacter数よりも密集度のほうが大事かも。

sampleの数字弄ったもの。この方法だと分散された弾の衝突判定と移動が高速。

とりあえず、algorithmは隔離しといたので、これで困るようになったらまた考えよう。

2012年1月4日水曜日

このblogの方針

詳細な内容はwikiでも作って自分ら向けに書くとして、このblogはその日の進捗状況だけ書いていく。
チラシの裏に書かずに公開するのはmotivationの維持のため。

開発は必要なものから順に実装していく予定なので進捗率とかは無し。
早めに動くα版公開して、feedback貰えるようにしたい。
100人ぐらい集まるといいな。