一定期間更新がないため広告を表示しています
★
緑色さんの多目的ブログ みろりえいちぴー(旧) 引っ越し先 みろりHP: https://www.mrrhp.com ★ 2016.02.28 Sunday
| カテゴリ:ゲーム |
真・女神転生4FINAL 3.徳川曼荼羅発動まで
● さて自分らが復活させてしまったクリシュナの企みで東京に徳川曼荼羅なるヤバイ結界が張られる。てめーのケツはてめーで拭かなきゃ…(使命感)と各地で多神連合の神達を精力的に叩き潰していくが、ついにハンター商会にクリシュナを復活させた件がバレてしまう。責任を問われた一行だが、徳川曼荼羅の破壊を条件に一時保釈を与えられる。 VS シェーシャ一戦目(新宿)
● 今週のダグザさん。 ダグザは何者にも依存しない世界を、ダヌーは他者と寄り添って歩む世界をそれぞれ望み対立。ただしダグザは実力者の排除、ダヌーは平和な世界の維持という理由で、両者ともメルカバー、ルシファーに対立しているので現在は協力している感じか。ダグザは多神連合を一体どうしたいんだという話だが、コイツは多神連合の生み出す新宇宙に用があるのだな。新宇宙を作ってもらったらあとは叩き潰すぜって感じか。気持ちいいくらい一本道だなホント。初期から自分の目的を宣言してるとこなんか、マジで少年漫画の主人公属性だよな、コイツ。 関連記事2016.02.27 Saturday
| カテゴリ:プログラミング |
Python レアリティの実装に挑戦する
● 複数のドロップアイテムの中からランダムにひとつ選ぶのは、randomモジュールを使えば簡単だ。だがそれら複数のドロップアイテムにはレアリティ差を作りたいのである。いくつか草案を書いてみる。 ● ひとつめ、まずこういうアイテムディクショナリを作っておく。"アイテムの名前":"ドロップしやすさ"という形式。
上のディクショナリを使ってリストを作る。そのリストには、アイテム名が"出やすさ"の数だけずらっと並ぶ。
あとは作ったリストからランダムにひとつ取り出すだけである。
この手口の気になるところはlisの長さだろう。ゲーム中なんども発生するであろう作業のたびに、クソ長いリストを生成するのはどうにもエコノミックじゃない気がする。 ● というわけで別の書き方をしてみる。はじめのディクショナリこそ同じだけれど、その後に作るのはディクショナリをもとにしたアイテムとドロップしやすさをそれぞれリストにしたもの。
出やすさリストの合計を上限とした乱数をひとつ出し、その値以上の数になるまでpopListの要素を積み上げていく。
リストを作らないといけないのは同じだけれど、内部的にとるメモリ量はだいぶ少なくなったろう。多分。しらんけど。ためしにこれを9000回行い、アイテムが何度ずつドロップしたか集計してみた結果が以下。
ビューリホー…。今回の最適解としてはコレかなあと思う。 ● ところでTwitterで、今回のような話題にちょっと応用できそうなツイートを見かけた。「x=1〜10 x=1〜x みたいに二重にした乱数は、数字が大きいほど出にくくなるので良さげ」とのこと。これはつまり何面サイコロを振るかをサイコロを振って決めるということだろう。今回のテーマに応用してみようと思ったが、そもそも、結果がどういう分布になるかが見当つかんのでそれを計算する関数を書いた。
これを実行してみるとこうなる。
グラフ上で自然な曲線をかけそうで便利ではあるんだけど、俺のように、アイテムごとに出やすさを自由に設定したい場合はちと向かないかな? ● 今回はレアリティを3段階に設定して考えていたけども、条件によってはレア度の高いものほど先にコンプできてしまうということはありうる。たとえばトレーディングカードで1パックにつき「ノーマル3枚、レア1枚」が入っているとする。もしレアカードは3種類で、ノーマルカードが30種類だった場合、目当てのカードを入手できる確率はレアが1/3、ノーマルが1/10になる。そういう条件で考えると、レアリティの数値と実際のレア度が逆転することになってちょっと面白い。 2016.02.21 Sunday
| カテゴリ:ゲーム |
真・女神転生4FINAL 2.神田の社まで
● 成り行きで上野の妖精たちに恩を売った主人公らが、手柄欲しさに悪魔の甘言にホイホイのせられクリシュナなる謎の悪魔を復活させちまうところまでのボス戦メモ。アサヒちゃんの頭の足らなさがマッハ。 VS キングフロスト(妖精の森)
さらっとアサヒちゃんをディスってしまったけども、パートナーとしてかなり優秀だ。とくに最近メディアを覚えたのでめちゃめちゃ助かっている。彼女の回復スキルを前提として戦ってるところがあるので、この先パーティ脱退とかあった場合ちと面倒なことになるな。 ● 今週のダグザさん。 今のところシナリオは完全に一本道で選択肢もほぼ与えられてないんだけど、主人公はダグザに操作されているというエクスキューズがあるため、まったくストレスになっていない。むしろストレスレスに一本道を進むのがラクラクで良いし、事あるごとにコメントをくれるダグザさんは俺の好感度を着々と稼いでおり現在いちばん気に入りのキャラはコイツかもしれん。 今作ではびっくりなことに、「全滅してもその場でダグザが復活させてくれる」というマリオだってもうちょっとペナルティあるぞってレベルの待遇だ。けど、まあ予想にすぎないが、多分ダグザと袂を分かつルートあるよなあ。そうなったらプレイヤーはシナリオ上の思想面だけでなく実利も含めてルート選択することになり、それはかなり面白いと思う。 2016.02.20 Saturday
| カテゴリ:プログラミング |
Python 相対インポートレポート
● 階層構造になってるディレクトリをインポートによっていったりきたりするスクリプトを書いていたら、相対インポートの仕様に咬まれまくって大変だったのでわかったことを書いておく。 以下のような構造のディレクトリで、main.pyからd.pyをインポートし、さらにd.pyからa.pyとb.pyとc.pyを実行したい。その際パッケージインポートを使うので、全ディレクトリには__init__.pyを置いてある。
● b.pyとc.pyをインポートするだけなら以下のような感じで可能だ。
この例のd.pyの書き方は、たぶん相対インポートと言っていいのだろう。なおびっくりなことに、d.pyは以下のような書き方でもよい。
つまりインポートのつながりによってディレクトリが階層構造になった場合、絶対パスのルートはカレントディレクトリになるのだろう。ちなみに、どちらの例でもd.pyは単体で実行するとエラーが出る。これはどうやらカレントディレクトリより上層を参照することはできないのが原因のようだ。 ● 上記のような感じでa.pyをインポートすることはできない。というのも、相対インポートでは、カレントディレクトリの参照およびカレントディレクトリを通過する参照はできないからだ。そこで、相対インポートは諦めて、d.pyでインポートパスにカレントディレクトリを登録し直接インポートを行うという手口でいく。
import文によって行われるモジュールの参照は、sys.pathに入っているパスに基づいている。だもんで os.getcwd() でカレントディレクトリのパスを取得し、sys.pathに登録しちまえばよい。さすればa.pyのインポートに相対インポートは必要ない。というかここまでくれば相対インポートがもはや必要ないな。
もうこれでいんじゃね? と思うほどラクだ。相対インポートに from なんちゃら import なんちゃら という記述を使ってしまうと、モジュールの名前空間のまるごとコピーを行う from module import * が使えないのが地味に気になっていたのだが、この手法を使えばその心配も消滅する。 相対インポート調査レポートの締めが相対インポート使わなくてもよくね? なのはアレだが理解が進んだのでよしとしよう。 ● 相対インポートの仕組みに関してはそこそこ知識が集まったけれども、実際にやってみたいのは、そうしてインポートしたファイル内にクラスを作り、その中で相互にいったりきたりするスクリプトなんだよなあ…。白状してしまうとそうやって作りたいのはゲームブックみたいなものなんだけど、いつになったらゲーム自体に取り掛かれるのかすこぶる不安だ。 2016.02.16 Tuesday
| カテゴリ:感想文 |
ボリス・ヴィアン『日々の泡』
● 我が家の学級文庫においてあったので読んだ。 ● お金持ちの青年コランは、素晴らしい料理人のニコラの料理を食べ、親友のシックとたまに楽しく遊んで、ステキな生活をしている。あるときシックがアリーズなるきれいな恋人を作るのをみて、コランは自分も恋がしたくなる。そんな折にクロエというきれいな女性に会い、ふたりは恋人になる。お金はありますから、盛大な結婚式を挙げ、貧乏から式を挙げられないシックとアリーズに援助もしてやる。うん、お金はみんなを幸せにするのですね。ところが結婚後クロエが奇病を発症し、その治療に莫大なお金がかかることになる。さしもの資産家コランでも払いきれないレベルの額なので仕方なく働きに出るコランであったが、労働の能力がないためあちこちで追い出されてしまう。そのころコランが援助をしてやったはずのシックは、そのお金をすべて趣味の本収集に充ててしまっていた。絶望したアリーズは本屋を焼き払い、自分も焼死する。シックは税金を納めるのを疎かにしていたため、警官に殺害される。コランの尽力の甲斐はなくクロエは病死し、おざなりな葬式で埋められる。可哀想なコランは毎日岸辺で水を眺めるようになった。ただし、それでコランが不幸かというと、そうでもないらしい。 彼らの暮らしをずっと眺めていたハツカネズミくんによると、「彼には苦しみがある」だけだと言う。それを見るに耐えなくなったハツカネズミくんは、自らも死を選ぶことにした。 ● なんぞこの話…? 物語を読むとき、俺は基本的にまず「登場人物は何をしたいのか」つぎに「作者はこれを書くことで何が言いたいのか」の順番で考えるのだけど、今回は後者がまったく分からんかった。「女はすべてを破壊する」と言いたいのかな? なにしろ物語初期の、コラン、ニコラ、シックの生活はとても清潔で繊細で素敵だった。ニコラの料理が他のふたりが大好きだし、コランはシックの貧乏さをして自分の裕福さに若干の後ろめたさを感じつつ、さりげなく彼を援助していた。シックの方もコランのことをよい友人だと思っている。それが、アリーズをはじめとする女性陣が現れた瞬間に、コランは貧乏の底の底まで堕ち、シックは狂い、ニコラはすげえイケメンだったのにそんなふたりを見てやつれてしまった。何よりおっとろしいのが、女性陣はとくに何も加害したりしてないことだよな。ただそこにいるだけで男どもを潰してしまったのだ。そのあたりが、まえがきにある「ひとりひとりだといつもまっとうだが大勢になると見当ちがいをやる」に繋がっているのかね。まあともかく、よく分からんかった。 が、この話の舞台は実在のパリのパラレルワールドみたいな架空の世界だと思うんだが、その世界観はけっこう楽しめたぜ。気に入った部分を以下に。
● ところで、ルームメイトがこの話を「ムーミンと雰囲気が似てる」と言っていた。言われてみればそう感じるかもしれない。主人公にわりとゲスなところあったり、周囲の人物がワケ分からないことをやりだすところ、架空のものごとが説明もなく当たり前のように存在しているところなんかが似ていると思う。 ルームメイト「ムーミンって結構性格悪いよね?」 俺「たまにゲスいよなアイツ」 2016.02.14 Sunday
| カテゴリ:ゲーム |
真・女神転生4FINAL 1.上野まで
● 始めたんでプレイメモを書いていく。 「シリーズ未経験者が難しく感じる難易度」「シリーズ経験者が難しく感じる難易度」「死のスリルを追求する奴が難しく感じる難易度」って難しいしかないじゃねーか! と大笑いしながら難易度は大戦に決定。
● とりあえず今回は、先輩の死に乗じ見事人外ハンターへの就任を果たした主人公らが、上野のチャレンジクエストをこなすとこまで。 VS フォルトゥナ(チャレンジクエスト)
以下雑多。
● あとダグザがわりとクエストに協力的でわらける。 2016.02.06 Saturday
| カテゴリ:プログラミング |
Python python3でウェブサーバを作る
● (2017.04.22.追記) これのリトライ「python3でウェブサーバを作る(Bottleでリトライ)」をした。 ● ウェブアプリケーション開発に適した言語であるPHPで自作のツールを作ったことがあったけれど、お気に入りの言語Pythonでもおんなじようなことってできねーかなあ。と思い手を出してみた。いや結構苦労したぜ、なにせ参考ページがなかなか見つからなくてなあ。それにPHPなら簡単にできたことが要領よくいかないのだよ。「ってことはつまりウェブスクリプトはPHPで書くのが最適であってPythonには向いてないんじゃねーの?」と気付いてこのプロジェクトを完全に放棄するまでに集まったtipsを書く(出落ち感がヤベエ)。 ちなみに、ページの構成は処理とhtmlを分けてスッキリさせるため、pyファイルとtplファイルに分ける。tplファイルにはhtmlを書き、pyファイル内から読み込む。 ● ディレクトリ構成
● こんなあたりでpythonウェブサーバで遊ぶのはヤメにした。今回得られた教訓としては「ネットに情報が少ないものは主流じゃないからヤメとけ」といったところか、いや、当たり前すぎるわ。 2016.02.03 Wednesday
| カテゴリ:プログラミング |
Mark Lutz『初めてのPython』つづきのつづき
● 先日からちょこちょこ読んでいるオライリーPython豆知識収集の続きの、続き。とうとうクラス、ひいてはオブジェクト指向の範疇に突入し、なんとか読み終えたぜ。今回の読書を通じてプログラミング初心者絶対殺すワード「オブジェクト指向」が理解できた気がするので、それもあわせて書く。 ●
● この本への取り組み姿勢は豆知識収集であり、すでに使い慣れている機能について「へーアレは(内部的には)こういうことだったのか」というのを楽しんでいたのだけれど、話がクラスに関連する高度なテクニックに至ってくると、「へーアレはこういうことだったのか」っつーか全部がはじめての学習なのでイチイチ収集していられん。やっぱりクラスはひとつの壁だよ。俺がプログラミングをネットのチュートリアルサイトで始めたときも、単元がクラスに入った瞬間なぜかピタッと理解が止まってしまったからな。の原因は、言うまでもなくオブジェクト指向プログラミングに対する不理解だろう。クラスはオブジェクト指向プログラミングのための道具なので、オブジェクト指向プログラミングがわからなかったらクラスもわからん。今回の読書ではオブジェクト指向プログラミングについてちょっと理解が進んだ気がするのでそれを書いておく。 思うに「オブジェクト指向プログラミング」っていう名前が悪いと思うのだよな。「オブジェクトをガンガン利用するプログラミング」とか「インスタンスをガンガン利用するプログラミング」ならわかる。つまりオブジェクト指向とは「複数の属性を定義したたくさんのクラスを階層化し、必要に応じて属性をカスタマイズしつつ(下位で同名の属性を定義しなおせば上書きとなる)それらを下位クラスで使い回すスタイル」だと言えるんじゃないかなあ。そしてそんなスタイルが有用になるのは大規模なプログラムにおいてのみだ。俺のような初心者はそんなもん作らん。その上Pythonでは数値も文字列もすべてオブジェクトという名前だから、とても分かりづらかったのではなかろうか。「オブジェクト指向もなにも、最初からオブジェクト使いまくっとるやん」ていう。そんなわけで俺の中でオブジェクト指向プログラミングは、「インスタンスをガンガン利用するプログラミング」と言い換えることにしてみる。 言うまでもなく、そのスタイルには以下のようなメリットがある。
関連記事
|
+ 閲覧記事
+ 過去記事アーカイブ
年ごと
カテゴリごと
+ 年月選択
+ カテゴリ
+ ブックマーク
+ 最近のコメント
+ アクセスカウンター
全体(since 2010.02.03.)
今日… 昨日… |