どうも。体に悪そうなお菓子が大好きな私です。
今回もつらつらと日誌を書いていくとしましょう。
これで動画にしない分はストックなくなったのですが。
VC2013便利すぎる!! ちょっと重いけど!
最近=と==を間違えなくなりました。めでたい。
リカバーHP(ダメージを受けた際、ダメージの半分は時間経過で回復していくシステム)の仕様がちょっと変わりました。
元々はダメージを受けたけども、その後無敵にならずにガチ避けで生き残ると回復していく仕様だったんですが、
戦術性を高めるためにチェンジ、魔法、ボムなどでガチ避けしなくてもリカバーHPがなくならない仕様にしました。
一番影響が大きいのはチェンジですね。片方がダメージを受けたら、チェンジで引っ込んでその間に回復、ということができます。
こうするとリカバーHPの回復速度を上げるスキルが涙目なわけですが・・・。
仕方ないね。
次。
ヤバイ。ゲーム中の雑談(テイルズで言うスキット)が1000行超えた。
このゲームどこに向かってるんだ。そして誰が読むのか。
エンディングもまた増えそうな気配ですし、シナリオがカオス度を増してきました。
フラグ管理が大変そう・・・。というより、何をフラグにするか決めるのが大変そう。
まーよくあるのは選択肢という名のフラグ立てですよね。
そして好感度も導入予定。ホントにこのゲームどこに向かってるんだ。
次。
最近シェーダーを使いたいと本気で思ってます。
その理由は、シェーダーを使わないと無理と思われるエフェクトが3つほどあるからです。
その一つが時間操作ですね。時間操作中はやはりそれが一目でわかるような表現が欲しいですが、
モノクロやネガポジ反転がよくある手法なんじゃないかと。
私はネガポジ反転が好きなのでそうしたいのですが、画面全体なら割と楽にできそうですが画面の一部だけとなると、一筋縄ではいかなそうです。
そこでシェーダーの出番かなと。HLSLなんかは勉強すればなんとかなりそうですが、問題なのはスペック。はてさて、どうなることやら。
ちなみにやりたいエフェクトのあと2つは、どういうアルゴリズムにすればいいのか微塵も検討がついていません。
いやねぇ・・・あんなのどうやって実装しろっていうんだよと。具体的に言うと水の波紋エフェクトと背景を歪めたゆらぎで画像が浮かび上がるエフェクトなのですが。
・・・・・・いつか根性で実装してやります。
次。
最近enumに型宣言をつけると間違った代入をしにくくなることに気がついたので、大体のenumに型をつけることにしました。
そうなると当然コンパイルエラーが頻発するわけで、その対応で丸1日潰れました。
でもそこを修正していく過程で間違った代入をしていることに気がついたので結果的には大きなプラスだったと思います。
特にAquaとWater。お前ら紛らわしすぎるんだよ。ちなみにAquaが水属性でWaterは水色。これは間違える。
あとWaterは水色でない件。Cyanとかにすればよかったか。
そして新しいことをしようとすると新しく身につけた技術でコードを書きたくなる
→既存のコードも同様の技術で書き変えたくなる
→大量のコンパイルエラーと格闘
→すごく時間かかるけどゲーム作成は1ミリも進まない
→あれ・・・何しようとしてたんだっけ?
ということが割とよくあります。
次。
さて、オーブの入手方法は装備を壊す以外にも何か欲しいですね。
特にLVが1~9まであるので、8,9はかなりのレア度でなければなりません。
装備から壊して手に入れる方法はランダム性なしで、同じ装備なら同じオーブが出る予定なので何かしらランダムでオーブが手に入る仕組みが欲しいです。
そこでクエストシステムです。それもオンラインゲームによくありそうなデイリークエスト、ウィークリークエスト、期間限定クエスト、緊急クエストの4種類を用意したいです。
このクエストをクリアすると報酬としてオーブが手に入ることがあるということです。
しかしここで一つ問題が浮上します。ランダムでオーブの種類、レベルが決まらなければいけないのですがそれはいつ、どのように決まるかということです。
クエストは受注前に報酬が見えるシステムにしたいのですが、その時点でオーブの種類やレベルが見えてしまうのは無粋というもの。
ここは未鑑定オーブということでいきたいです。例えば「禍々しいオーブ!!!!!」があるとして、禍々しいとついたらその時点でオーブの種類が数種類に絞られます。
そして!の数が多いほどレア度が高い可能性が高いことを示しています。!が1つならLV.3が20%、LV.7が0.01%で5つならLV.3が0%、LV.7が5%みたいな。
ではこのオーブはいつ決定しましょう。一番簡単なのは鑑定時ですが、これはダメです。
セーブ→鑑定→いらなかったら再起動 というリセマラができてしまうからです。私はリセマラが大嫌いなのでできるだけ避けたいところです。
次に考えたのはクエスト更新時に乱数で決めるやり方ですが、これは微妙です。
リセマラするとなるとデイリークエスト(+ウィークリークエストの1つ+たまに出てくる緊急クエスト)でしょうが、これはリセマラするとなると
起動→クエストクリアして確認→リセット ということが可能なのでいちおうリセマラする価値が出てきてしまうかもしれません。
特に!!!!!じゃなきゃいいやとなるとクリアしなくてもクエスト選択画面見たでリセットできてしまいますからね。あまり良くないような。
じゃあどうすりゃいいんだよ! ということで考えた第3の案が、擬似乱数を使うという方法です。
乱数はランダムではなく同じ条件なら同じ数を返すということを利用して、リセマラをできないようにしようという考えです。
その乱数の元になる数字ですが時間はもちろんダメですし、HPの値とかだとランダム性が薄れてしまいます。
ということでそこそこ頻繁に変化する値を元に乱数を求めようかなーと思っています。
しかし簡単に変化できてしまう値では困ります。例えばお金が元になる数だったとして、お金が少しずつ違うセーブデータをたくさん用意します。
日をまたいだら全てのセーブデータでクエストを確認すればリセマラができてしまいますので。
ということは、簡単には変化するけれども簡単には変化できない値・・・・・・
ってなんじゃそりゃ! そんなパラメータあるのか!?
こうなると専用パラメータが欲しいところですが、それを作ったところでどのタイミングで乱数変更を行えばいいんだ・・・。
・・・・・・あ
ゲーム開始時(初起動時)に時間に応じた乱数を乱数初期化変数に設定すればいいのでは?
これならプレイヤーごとのランダム性も確保できるし、クエスト生成時に今まで出現したクエストの回数だけ乱数を回してやればデイリークエストは何回リセマラしようとクエストが出現した回数に応じて決まることになる!
うーん、これでどうだろうか。これが第4の案。
これがダメだったらもう知らん。
次。
昔から度々思っていたのですが、プログラムって書けば書くほど上達しているのがよくわかります。
今見返してみると昔書いたコードがゴミにしか見えないということを何回も体験しています。
しかし随分たくさんコードを書いた今でもその頂は見える気配すらしません。
プログラミングとは奥が深いですねえ・・・。
まあ、何事にも言えることですが。
そんなわけで今日もシナリオを練ってはポイするのでした。
コードの整理で進捗ダメです
Re: コードの整理で進捗ダメです
いちいち乱数を毎回回さなくても、乱数の状態(例えばxorshiftだったらx,y,z,wの値)をセーブデータに保存すればいいのではないでしょうか?SAI さんが書きました:ゲーム開始時(初起動時)に時間に応じた乱数を乱数初期化変数に設定すればいいのでは?
これならプレイヤーごとのランダム性も確保できるし、クエスト生成時に今まで出現したクエストの回数だけ乱数を回してやればデイリークエストは何回リセマラしようとクエストが出現した回数に応じて決まることになる!
うーん、これでどうだろうか。これが第4の案。
Re: コードの整理で進捗ダメです
みけCATさん
ご指導ありがとうございます。
仰るとおりです・・・。毎回乱数を何度も回すのは無駄な処理でしたね。
xorshiftはよくわからなかったのですが、乱数の状態を保存すればいいということは、変数に「初回起動時に生成される元となるランダム数X」と「クエストが出現した回数Y」の2つを用意して、
毎回クエスト生成時にX+Yを乱数の初期値に設定すれば乱数が1回で済むということなのではと思いました。
ご指導ありがとうございます。
仰るとおりです・・・。毎回乱数を何度も回すのは無駄な処理でしたね。
xorshiftはよくわからなかったのですが、乱数の状態を保存すればいいということは、変数に「初回起動時に生成される元となるランダム数X」と「クエストが出現した回数Y」の2つを用意して、
毎回クエスト生成時にX+Yを乱数の初期値に設定すれば乱数が1回で済むということなのではと思いました。
Re: コードの整理で進捗ダメです
自分の趣旨とは違いますが、確かにそれでもリセマラ無効化の効果は得られそうだと思います。SAI さんが書きました:変数に「初回起動時に生成される元となるランダム数X」と「クエストが出現した回数Y」の2つを用意して、
毎回クエスト生成時にX+Yを乱数の初期値に設定すれば乱数が1回で済むということなのではと思いました。
Re: コードの整理で進捗ダメです
>今見返してみると昔書いたコードがゴミにしか見えないということを何回も体験しています。
激しく同感します。
そしてverアップする際にイチから作った方が早いやーという
結論に達して二の足を踏んでしまうのであります。
激しく同感します。
そしてverアップする際にイチから作った方が早いやーという
結論に達して二の足を踏んでしまうのであります。
Re: コードの整理で進捗ダメです
taketoshiさん
仲間がいてよかったです。
そしてコードを直し始めるとまた制作がストップするという・・・。
仲間がいてよかったです。
そしてコードを直し始めるとまた制作がストップするという・・・。