「オブジェクト」を含む日記 RSS

はてなキーワード: オブジェクトとは

2024-03-15

google map新規オブジェクト認証方法

anond:20240315052146

おまえは「ピンの話ばかりしている」と主張するが、

新しい建物申請はピン立てないことにははじまらないんだよ。

まず、大前提としてgoogle mapスパムによる虚偽の申請があまりにも多いので、机上で確認できる手段がないと更新されないことがある。

増田の言う「スルーされている」だな。

web前提だが、簡単申請方法を書いておく。

自分申請したいところをクリック

このとき既存建物のピンが立っているときは、ピンでないところをクリックして何もないところをクリックして灰色のピンを立てる。

で、右クリックして「場所を追加」を選ぶと、新しい施設登録ができる。

しかしたら、ここまでは増田はたどり着いている可能性がある。

で、ここから大事だ。

「マーカーの位置編集」でなるべく正しい位置にマーカーを移動してやってくれ。

もうないはずの既存建物のピンと同じ位置なら重ねてしまっていい。

更に、現在google認定されてるランドマーク申請したい建物が一緒に写っている写真を添付する。

まり、どの位置かというのを別の建物証明してもらっている状態だな。

近くにランドマークがない場合は、最新のストリートビューとなるべく同じ画角で撮った写真を添付する。

こっちはストリートビュー位置証明してもらってる状況だな。

これを逆利用して、ストリートビューに写ってるのに登録されてない建物申請するという方法もある。

これで無視されるなら、まず増田googleアカウントの信用が地に落ちてる可能性があるので、

ルータリセットしてIP更新してからgoogleアカウントを取り直すことをおすすめする。

2024-03-05

wordの図の扱いがつらい

ページの半分を超える図が多くある文書で、画像の左右に文字はいらないから折返しの設定で「上下」を選んで左右中央揃えしてる

ただそれだとときどき図の表示位置おかしくなる

基本は入り切らなくて自動で次のページ行くとき

その状態で図を少し動かしたりグルーピングして上に乗せてるオブジェクトをずらしたりするとおかし場所に図がジャンプする

しか関係ないページの図や本文に重なる

段落アンカーは全く機能してない

なんでこんな使いづらいの

 

結局「行内」を選んで段落内に図を入れてその段落は図だけにして段落を左右中央揃えにしてる

期待する動作にはなるけどなんかコレジャナイ感

2024-03-02

[]ラチェット&クランク パラレルトラブル PS5

とりあえずクリア

難易度は一番低いやつ

プレイ時間わからんが多分15時間くらいか

途中詰まりそうになったときもあったけどなんとかクリアできてよかった

ps2の1はラストステージで詰まってクリアできんかったからなー

ロックマンのワイリーみたいな立ち位置なんだなラチェクララスボスって

リベットがかわいかったなー

声もあってた

逆にラチェット眉毛ぶっといしもさくてきもかった

画面のきれいさとロードのなさはすぐ慣れて、後半は逆につまんなかったなー

クランクメインのパズルステージもつまんなかった

最初の1時間くらいの楽しさだけで十分だったかなー

まちとかステージオブジェクトもやたらリアルで数おおいけど、逆にそのせいでどれが壊せるものかとか、

大事な隠しアイテムかとかがすげーわかりにくくなっててイライラした

最後最後アクセシビリティってオプション設定あることしって、インタラクトできる箱とかゴールデンボルトとかギミックとかの色を変えたらすげープレイやすくなったわ

最初からしとけばよかった

距離レンチなぐりはなぐってる感あるからいいけど、

わりとメインのはずの遠距離武器の爽快感いまいちだったのは微妙だったなあ・・

イージーでも敵硬すぎたから余計にそういう感じした

距離攻撃とどかねえから遠距離必須みたいな敵やボスが多いから余計に感じた

ベルトスクロールみたいにエリア内の敵倒さないと次に進めないのが結構あるけど、

終わってるかどうかがすげーわかりにくくて、終わってないのに進もうとして死ぬってのも何回かあってうざかったなー

まあ1回やればいいかなって感じ

スターオーシャン6とかもこういう感じで交互に見せてくれればよかったのになと

ラチェットリベットで2週させられてたらクソうざかったと思うわ

こんな感じで1周で両方みせてくれたらいいんだよ

エクセルマクロのお作法計算用シートという諸悪の根源について)

前置き

この日記の内容は、会社の後輩から最近エクセルマクロ勉強し始めて(キラキラ)」という話を聞いて、先輩ムーブかますために話した内容になります

とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。

ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。

増田の経歴

この記事趣旨

エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。

3行でまとめます

〇 エクセルシートはユーザーインターフェースインプット)か出力結果(アウトプット)のためのものとすべき

〇 データ加工をする場合には、原則配列辞書配列連想配列)に格納して加工を行い、最後の結果だけシートに出力するべき

〇 何事にも例外はある。

計算用シートとは

この記事では、エクセルシートを下記の通り分類します。

エクセルマクロにも色々あると思いますが、今回は下記を想定します。

日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータ入力された値を基に加工し、加工後のデータをシートに出力する

この場合入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。

(もちろん、ユーザーインターフェースの別の欄(セル)に出力する場合もあるし、その場合ユーザーインターフェース出力結果が一体のものとみなします。)

また、データ用シートは同じエクセルファイル内に基となるデータが含まれ場合を想定します。

(これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…)

ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。

例えばイメージするのはこんなマクロです。

1.元となるcsvファイルエクセルに読み出してシートに格納

2.そのデータは日付が数値型になっているので、日付(数値型)の入った列を文字列に変換した日付(文字列型)列を新たに作成

3.その列をキーとして対象となるデータを取り出すvlookup関数を各行に格納した列を新たに作成

4.その列で特定された列をさらに加工した列を新たに作成し、…

これは極端な例ですが、とにかく変数配列定義せず(あるいはエクセルセルオブジェクト変数のように扱い)、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。

その舞台となるのが、計算用シートです。

なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。

ある程度マクロに慣れた気の利く人なら、このシートはロック非表示にして、ユーザーから触れないようにするでしょう。

・・・これ、やめたほうが良くないですか?

こいつが日本生産性を落とす諸悪の根源だと思います

駄目な理由

ある程度詳しい人なら同意してくれると思いますが、このやり方でダメ理由はいっぱいあります

後で説明する配列辞書配列連想配列)と比べると格段に処理が遅いです。

わざわざエクセル操作しているから当然ですね。

ちょっと詳しい人が知っている「画面更新非表示」を駆使しても、配列を使った処理からみれば止まったハエです。

(参考)VBAで作ったマクロの高速化① 配列を使う

  • 可読性が下がる

いったんエクセルシートにデータを格納して加工しているので、コードエクセルシートを両方見る必要があり、とても読みにくいです。

変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります

計算用シートを事前に用意して、別のセル関数を格納しておき、マクロ関数を使ってデータ加工をするものも見たことがあります

これは懲役刑に処したほうがいいと思います

まり知られていませんが、セルの最大文字数は32,767 文字です。

セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります

他にもエクセルの数値を丸め自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます

できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているか日本GDPは上がらないんだと思います

他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまリスクがある、などいくらでも理由は上げられます

(逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・

じゃあどうするの

配列を使いましょう。

配列とは何ぞや、という人はググってください。

配列データを入れて、データ加工は配列変数に対して行い、一番最後の出力だけセルに値を格納する。

他のプログラミング言語なら普通にやっていることです。

個人的オススメしたいのは辞書配列連想配列)で、うまく使うとデータ管理簡単になり、処理も爆速になります

(参考)【VBA】大量データから高速で値を検索【Dictionaryを使う】

csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。

直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。

エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ますエクセル開くと処理もめちゃ不安定です。

(参考)Excel VBAでCSVオープンするときのパフォーマンス比較

いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分コードを書き始めたころは全部シート上で操作していました。

冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロやらせる、というマクロ本来趣旨にはあっていますし。

途中の計算過程もすべて目の前で展開されるから分かりやすいです。

ただ、それではダメなんです。。。処理は遅いし挙動不安定だし後で改修・保守する人が死にます

あと、エクセルシートやセルは当然エクセルしかないので、エクセルマクロVBAから他の言語に移れなくなります

自分エクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列辞書配列連想配列)のスキルはそのまま他の言語に活かすことができました。

配列の中身を見る方法別にある(ローカルウィンドウやDebug.printを使うなど)ので、リハビリに取り組んでほしいです。

(参考)VBA デバッグの仕方

もちろん例外もあります

計算用シートを許容できる、使うべきケースもあると思います。。

個人的には、

最後のは、なんでも自分確認しないと気が済まない上司発注で、意味不明と思いましたしたがしぶしぶやりました。)

などの場合計算用シートを使ってもよいと思います

この場合インプットエクセルシートに直接加工するのは論外なので、計算用(加工用)のシートを用意してそこで操作を行うことは必要だと思います

他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。

最後

そもそもツッコミとして、「データ加工するならエクセルマクロを使わずpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。

ただ、個人的にはエクセルマクロVBA)は大好きですし、初心者にもおすすめしたいです。

自分のような非エンジニアだと、セキュリティ関係などでPythonの開発環境とかすごく用意しにくいんですよね。

(あと、コマンドプロンプトの真っ黒な画面が怖かった)

その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セル挙動を追えば視覚的にプログラム理解できるし、初心者に優しいです。

(そのやさしさが上述したとおり悪魔の罠なわけですが。)

最初計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。

さらに本格的なデータ処理を行うために、PythonやRなど別の言語習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います

2024-03-01

anond:20240301163703

もしかして生成した画像をそのまま出してくると思ってんのけ?

生成AIレースの模様とかオブジェクト作らせて部分的剽窃されたらぶっちゃけわからんやろ

2024-02-27

ワイの精子数億オブジェクトバラまいてもフレームレートが下がらないこの世界すごい

2024-02-25

[] 全部を書き直す必要はない

コードエントロピー機能追加によって増大する傾向にある。

「この関数にこういうパラメータを使ったこういう処理を追加してくれ」などと言われたら、コードは複雑化するのは当然だろう。

かといってこういう要求が来た時に、コード全体を一から作り直して簡潔にしようと思うのはナンセンスだ。

コードの量にもよるが、一定程度の量のコードがそこにあるときは、やはりリファクタリングの方が効率よく進められる。

「僕はリファクタリングなんてしませぇん、一から書いた方がいいでぇす」というのは、特定現場・状況だけにあてはまるものだと認識しておこう。

かにコード全体をリファクタリング」なんてしようと思ったら大変すぎるが、通常は「修正担当する部分をついでにリファクタリングする」でOKだ。

ユニットテストさえかけていれば、そのリファクタリングによって、バグが見つかりやすくなるだろうし、保守性も上がるのである

なお、本当にコードベースが酷いカオス状態で、ゴッドオブジェクトを使っているような状況になったら、「書き直す」という利点が少しはあるかもしれないが、そういう場合関係各位に同意を取らなければやってはいけない。

そういったカオスな状況でさえ、平均的なプログラマーは「良いコード」よりも「慣れているコード」に愛着を持つ傾向にある。

もしあなたが「コードを綺麗にするためにすべてを一から書き直そう」と、無断でそのようなことをやったら、彼らが慣れていないという理由批判の嵐が殺到するだろう。

もう一度言うが、最善の方法修正担当部分だけをついでにリファクタリングすることだ。これだけにとどめておけ。

2024-02-21

[] 数学は量子物理学と同様に観察者問題がある

量子力学における観測問題についてはよく知られるように、人間主観性が量子実験の結果に重要役割果たしている。

ドイツ物理学者ヴェルナー・ハイゼンベルクによる有名な引用がある。

私たちが観察するのは現実のものではなく、私たち質問方法さらされた現実です。」

例えば有名なダブルスリット実験では、スリットの後ろに検出器を置かなければ電子は波として現れるが、検出器を置くと粒子として表示される。

したがって実験プロトコル選択は、観察する行動パターンに影響する。これにより、一人称視点物理学の不可欠な部分になる。

さて、数学にも一人称視点余地はあるか。一見すると、答えは「いいえ」のように見える。

ヒルベルトが言ったように、数学は「信頼性真実の模範」のようである

それはすべての科学の中で最も客観的であり、数学者は数学的真理の確実性と時代を超越した性質に誇りを持っている。

ピタゴラスが生きていなかったら、他の誰かが同じ定理発見しただろう。

さら定理は、発見時と同じように、今日の誰にとっても同じことを意味し、文化、育成、宗教性別、肌の色に関係なく、今から2,500年後にすべての人に同じ意味があると言える。

さて、ピタゴラス定理は、平面上のユークリッド幾何学の枠組みに保持される直角三角形に関する数学声明であるしかし、ピタゴラス定理は、非ユークリッド幾何学の枠組みでは真実ではない。

何が起こっているのか?

この質問に答えるには、数学定理証明することの意味をより詳しく調べる必要がある。

定理真空中には存在しない。数学者が正式システムと呼ぶもの存在する。正式システムには、独自正式言語付属している。

まりアルファベット単語文法は、意味があると考えられる文章を構築することを可能にする。

ユークリッド幾何学正式システムの一例である

その言語には、「点」や「線」などの単語と、「点pは線Lに属する」などの文章が含まれる。

次に正式システムのすべての文のうち、有効または真実である規定した文を区別する。これらは定理である

それらは2つのステップで構築されれる。まず、最初定理証明なしで有効である宣言する定理選択する必要がある。これらは公理と呼ばれる。

これらは正式システムの種を構成する。

公理から演繹は、すべての数学コンピュータで実行可能な印象を生む。しかし、その印象は間違っている。

公理選択されると、正式システム定理構成するもの曖昧さがないのは事実である

これは実際にコンピュータプログラムできる客観的な部分である

例えば平面のユークリッド幾何学と球の非ユークリッド幾何学は、5つの公理のうちの1つだけで異なる。他の4つは同じである

しかしこの1つの公理(有名な「ユークリッドの5番目の仮定」)はすべてを変える。

ユークリッド幾何学定理は、非ユークリッド幾何学定理ではなく、その逆も同様。

数学者はどのように公理を選ぶのか。

ユークリッド幾何学非ユークリッド幾何学場合、答えは明確である。これは、単に説明したいもの対応している。

平面の幾何学であれば前者。球の幾何学であれば後者

数学は広大であり、どのように公理選択するかという問題は、数学の基礎に深く行くと、はるかに感動的になる。

過去100年間、数学集合論に基づいてきた。

すべての数学オブジェクトは、いくつかの追加構造を備えたセットと呼ばれるものであるということだ。

たとえば自然数のセット1,2,3,4,...は加算と乗算の演算を備えている。

一般的なセットとは、数学で正しく定義されたことがない。

集合論特定正式システムによって記述される。Ernst ZermeloとAbraham Fraenkelと、選択公理と呼ばれる公理の1つに敬意を表して、ZFCと呼ばれる。

今日数学者は、すべての数学を支える集合論正式システムとしてZFCを受け入れている。

しかし、自分自身を有限主義者と呼ぶ少数の数学者がいる。

彼らは、無限公理と呼ばれるZFCの公理の1つを含めることを拒否する。

言い換えれば、有限主義者正式システムは、無限公理のないZFCである

無限大の公理は、自然数の集合1,2,3,4,...が存在すると述べている。すべての自然数に対してより大きな数があるという声明(「ポテンシャル無限大」と呼ばれる)よりもはるかに強い声明である

有限主義者は、自然数リストは決して終わらないことに同意するが、いつでも自然数の集合の有限の部分集合のみを考慮することに限定する。

彼らは一度にまとめたすべての自然数の合計が実在することを受け入れることを拒否する。

したがって、彼らはZFCから無限公理を削除する。

この公理を取り除くと、有限主義者証明できる定理はかなり少なくなる。

正式システム判断し、どちらを選択するかを決定することができるいくつかの客観的基準...なんてものはない。

主観的には、選ぶのは簡単である

時間空間を超越した何かを象徴しているので無限大が大好きだ」と言えば無限大の公理を受け入れることができる。

ゲーデルの第二不完全性定理は、十分に洗練された正式システム(ZFC等)は、自身一貫性証明することができないと述べている。

数学者は、今日のすべての数学の基礎であるZFCが確固たる基盤にあるかどうかを実際に知らない。

そしておそらく、決して知ることはない。

なぜなら、ゲーデルの第二の不完全性定理によって、より多くの公理を追加することによってZFCから得られた「より大きな」正式システムにおけるZFCの一貫性証明することしかできなかったから。

一貫性証明する唯一の方法は、さらに大きな正式システム作成することだけだ。

数学を行うためにどの公理選択すべきかについて、実際には客観的基準がないことを示唆している。

要するに、数学者が主観的に選んでいるというわけである自由意志に任せて。

公理のための主観的基準というのは、より豊かで、より多様で、より実りある数学に導くものを選ぶという人は多い。

これは自然主義と呼ぶ哲学者ペネロペ・マディが提唱する立場に近い。

自分自身制限する必要がないので、無限公理を受け入れる。

特定公理のセットを選択する行為は、量子物理学特定実験を設定する行為に似ている。

それには固有の選択肢があり、観察者を絵に導く。

これが、一人称視点とそれに伴う自由数学において正当な場所を取る方法である

2024-02-19

[] モジュール

コードを簡潔に保つにはモジュール化が必須であるしかし同じモジュール関係のない機能が含まれていたりすると混乱の元になる。

モジュール内の関数機能的関連性は凝集度という。

一方で、関数というのは引数の細かな仕様依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊情報で処理を行なったりすると、関数オブジェクトが互いに依存しあってしまう。

これはモジュールの結合度と呼ぶ。

高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。

さらモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。

そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。

2024-02-10

継承ダメっていう話ってオブジェクト指向オブジェクトを物と思ってるのが諸悪の根源で、オブジェクトは物のことだと思ってるから物を継承させたがる。DigitalClock extends Clockとか。

継承は、というか正確にはオーバーライド機能だけど、インスタンス化したクラスが何であるのかで実際に実行される処理が変わるわけだからインスタンス化したクラスが条件になってる条件分岐みたいなもので、ifとかswitchで同じ条件が何度もプログラムに登場するのを消す目的使用するのが継承の正しい使い方だと思う。

2024-02-08

パクリじゃないけどゲームとしてオリジナリティがあるわけでもない

anond:20240207085106 の続き

 

意外なほど反応ついてたけど読まず返事せず続ける。というか言いたいことの1割も書いてないので返事してたら続けられない。

読み返しててアズレンとブルアカが混ざっててどっちの話だかわからなくなってるが、すまん。

 

神バハだって当時すごい盛り上がって楽しかっただろというのは自分もそうですはい

三目並べだって楽しめれば別にゲームとして欠陥あっても関係ないというのもその通り。

 

この場合ゲームデザインとして実際のゲーム内容とゲームルックが嚙み合ってないのが、よろしくないと感じる理由になる。

まり、なんか雰囲気ドルフロに似てるなあという類似が、ゲーム性質からくるのではないと考えるからだ。

ゲームジャンルが同じだと見た目が同じになるのはむしろ当たり前。ファイアーエムブレムラングリッサーが見た目が似てると言って怒るのは…譬えが悪かった。

艦これアズールレーンでいうと、艦これジャンルけが難しいオリジナルジャンルだがああいゲームで、アーケード艦これは3Dのアクションゲームアズールレーンは2Dシューティングアズレンアーケード艦これルックにあえて似せる必要特にない。が、実際、なんかそれっぽくなってしまってる。

パクリではない。キャラクター独自の2Dに落とし込んであるし、ゲームシステムも違う。別物である

ただ、軍艦モチーフのヒット作の後追いで出た軍艦モチーフゲームゲーム画面の全体のルックが、ゲームシステム上の要請によるものでなく、なんとなく似てる。

おそらくは、参考にしました、ということだろう。

アズレン場合、一番近いのは二次創作同人ゲーだと思う。キャプテン翼やおい同人誌を商業向けに絶愛にしました、みたいな…譬えが悪いか

気にする奴は気にするが、気にしないやつは気にしない、ただネタ元へのリスペクトは本当にあるんか? と思いたくなるような微妙な感じだ。

この場合、似てるから悪いのではなく、似てないことが気持ち悪さの原因になっている。別にネタ元のニュアンスをあえて残す必要がないのに残ってしまってるのが、単なる素材として雑に扱ってるんだろうなと感じるのである自分は。

 

ブルアカでも、同様の、パクリではないけど…を感じ取ってしまう。

基本的ゲームシステムは生煮えである。2Dキャラがちょこまかと動きまわり、いろんなアクションを取るところが一番のセールスポイントであるのは間違いないが、それを使ってゲームシステムとしてうまくできてるかというと、見た目がちょっと豪華になっただけというのが正直なとこだろう。

プレイヤー操作可能範囲ゲーム画面のルックがうまく繋がってない。範囲攻撃範囲指定ぐらいだろうか。回避指示はごく少数の特定キャラしか使えないし。AIオートにすると本当に頭が悪すぎるのでスキル使用プレイヤー操作するしかないのだが、正直、ここまでオートが使い物にならない理由がわからないぐらい使えなさすぎる。なんとかゲームっぽさを演出しようとして、プレイヤーのやることを無理やり残すためにオートをあえて役立たずにしたのではないかと疑っている。

美少女が実銃で銃撃する動作を頑張って作ろうという熱意は凄くある。あるが、ゲームにはならなかった。

銃と美少女という組み合わせだけが先行してて、後が続かなかった。

 

さて2D銃撃部分ではグラフィックが先行してゲームデザインが追い付かなかったという話なのだが、そうなると気になるのが「もう一方のゲーム画面」であるフロアマップ

メインと銘打ったステージで見れるのだが、これは完全に、まったく、寸分の違いもなくドルフロそのまま。ユニットの動かしかたまで同じだし、マップ上のオブジェクトも似てる。

で、これがまた、ゲームとしては意味が全くない。

 

ドルフロでは、マップゲーム中心部分として機能していた。最初に見ると艦これ海域マップみたいに見えるが上手くアレンジしてあって、要は戦術シミュレーションマップの簡略化した形だ。ゲームデザインとしての中心部分なので先に進むほどマップが大きくなり難易度が上がり、そのうちスマホだとマップを見ることすら不可能みたいなことになり(ゲーム公式PCエミュでのプレイを推奨してたぐらい)、ライトユーザーが引くぐらいなことになるのだが、そのぐらいゲームとしての意味ちゃんとあった。

ブルアカでのマップは、ドルフロの凶悪マップ反面教師としたのだろう、基本的戦術シムみたいなことは一切ない。というかやらせてくれない。代わりにボタン押しギミックがやたら増えた。

結果、マップはあっても、実際のユニットの移動ルートは実質1つだけ、というのが現在のブルアカマップである。この部分はトライアンドエラー運営の用意した正解を引くパズルみたいなもので、プレイヤーのやれることはほぼない。こうなってくると、マップ攻略はほぼ作業しかなく、こんなことやらせ戦闘だけ抜き出して置いておけばいいだろ、という気分になってくる。

書いてみて思ったが、自分ドルフロとブルアカを対比してしまうのは、かなりの部分ここだと思った。ドルフロは艦これフォロワーとして作られたがゲーム部分は独自性が強く、艦これから受け継いだように見える部分でも自作品に合わせるように作り変えてあり、ゲームルックゲームデザインの間に乖離がない。ブルアカドルフロから全く変えずに完コピしたが、(おそらくソシャゲとして楽に遊べるようにするためにという思惑もあって)その完コピした部分はゲームとしての機能を失い煩雑なだけの盲腸となってしまってる(かといってマップをなくすのも微妙かもしれない。先述したように2Dキャラ銃撃部分はプレイヤーがやることがあるように見えて少ない、基本的キャラを愛でるためのパートだ。形骸化してるとはいえマップをなくしてしまうと、ただでも少ないゲームっぽさがさらに失われてしまうことになる)

ドルフロと同じなことについて「真似した」以外の理由が思い浮かばなくなってしまっている。このへんの真似っぽさは「銃と美少女」というセールス部分からは外れたとこなので雑にやっつけちゃったんだろうが、ここがあるからこそ、「銃と美少女の組み合わせなんて過去いくらでも前例がある、別にドルフロは関係ない」と言いづらくなっている。ゲームシステムとしての合理性がありプレイヤーゲーム体験としてうまく昇華させていれば、同じジャンルから似てるだけと言えてたはずだ。

自分がブルアカゲームデザインが雑なのが、単に雑であるよりあかんとこだと思う理由は、上記となる。

 

まだまだ続きます

見た通り基本お気持ち表明なのでそのように。

 

続き https://anond.hatelabo.jp/20240213200258

2024-01-26

各位、久々の大型新人の予感がするので可愛がってください

https://twitter.com/shims_ag/status/1749925004236779961

午前7:40 · 2024年1月24日

「型」という概念存在しないプログラミング言語存在しません。

https://twitter.com/shims_ag/status/1750300836113342567

午前8:33 · 2024年1月25日

メモリ上のデータの種類を表す情報が「型」(type)です。

プログラミング言語側に組み込まれている「型」だけでなく、プログラマー独自に「型」を定義する方法も用意されています

struct、classinterface、type, enumなどを使って独自の「型」を定義します。

開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります

多数の「型」を分類し、組織化するために名前空間を利用します。

近年「クラス」が「型」の定義であるという基本概念理解していないエンジニアが増えているので、エンジニア採用する際には注意しましょう。

https://twitter.com/shims_ag/status/1750346589431042157

午前11:35 · 2024年1月25日

ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています

例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。

業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります

上記の「型」は、構造体やクラスを使って定義します。

これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます

現代ほとんどの言語にはis-a関係を明確にする方法が用意されています

上記のような「型」の知識プログラミングの基礎です。

https://twitter.com/shims_ag/status/1750014081648779450

午後1:34 · 2024年1月24日

CPU機械語しか理解できません。一方で人間機械語プログラミングすることは困難です。

人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。

CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまます

そこで、人間にとってプログラムを読みやすくすることと、CPU意図しない演算をさせないために、データの種類を表す「型」という概念プログラミング言語に用意されるようになりました。

金融ECサイトなどのお金計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。

まとめると、可読性向上と、プログラムの誤動作防止のために「型」が不可欠な概念になりました。


https://twitter.com/shims_ag/status/1750507533536760000

午後10:14 · 2024年1月25日

プログラミング初心者は、

プログラミングを以下のようにシンプルに考えましょう。

(1) データメモリ記憶する命令プログラミングする。

変数配列構造体、クラスなどを使って、メモリ上にデータ記憶させる命令設計し、コーディングする。

(2) データ操作する命令プログラミングする。

上記(1)でメモリ記憶したデータに対して、計算、変換、表示、出力、保存などの命令設計し、コーディングする。

https://twitter.com/shims_ag/status/1750534515616059749

午前0:02 · 2024年1月26日

「型」という概念数学に由来しています

メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります

分かりやすく言えば、データの種類、分類の話です。

例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。

オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。

クラス」とは「型」の定義であり、メモリ上のデータの「分類」(class)です。

is-a関係」ではないのに継承すると、当然破綻します。

逆に、明らかにis-a関係」なのに、継承せずに委譲すると、スパゲッティコード化を誘発します。

2024-01-23

anond:20240123161225

これだから3Dオブジェクトコピペゲーをなんとも思わず消費するSteamユーザーは嫌いなんだ

ゲームってのはパン作りのように粉からこねて自分で作ってこそクリエイター思想が反映されるってもんだ

アセットひとつだって世界観構成する重要なパーツなんだ

それすらこだわる気がないのに、見栄えのするゲームを手抜きで量産していくことに、意味はあるのか!

それは最終的に、人がゲームから受けるセンス・オブ・ワンダーを損ね、薄味なゲーム文化体験を推進してしまうことになる

ゲームにおけるQoLが下がればゲームという産業それ自体パチンコのようなものに成り下がってしまうおそれがある!

事実買い切りからという紛い物の安心感のために、クリエイターたちの血と汗が数百円で安売りセールされる地獄がそこにあるだろ!

そういう環境を作ってるのはあんたらだ! そうなれば作り手もいかに手抜きしつつ一発当てるかしか考えなくなる! ソシャゲと同じだろ!!

同じ2Dスプライトドットキャラ、聞いたことあるBGMを使いまわすようなRPGツクールゲーばかりになった世の中を想像してみろ!

それはDLsiteでは現実になってるが、同人からこそ許されてるもんだろ

企業として多くの人が連携してものづくりをするなら、そんな域にとどまってコピペゲーで満足する志じゃいかん!

正しくスケールを大きくしていかないと、生き残れんぞ!バズ頼みの一発屋になるな!俺が言いたいのはそれだけだ!!

2024-01-22

anond:20240122111105

適切な粒度関数を分割しとけば生産性上がるけどね。

module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。

でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合分岐コードが増えて共通関数保守コストが上がる。

あとありがちなのは、php開発者関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。

とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスフィールド関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドメソッドを追加して、さらに進むとユーザーとは無関係機能も含めすべてをユーザークラス定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。

先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。

2024-01-15

ingressオーバークロックハックがクソつまら

ingressを離れた諸氏は知らないだろうが、最近ingressには、OVER CLOCK HACKなるものがある。簡単にいえば3D版グリフハックだ。

お馴染みのグリフが3DARオブジェクト上に表示されるので、それを解読・記憶して2Dのグリフを入力する。

そうすると、正解率に応じてとんでもない量のアイテムがもらえるというミニゲームだ。

私は元々ingressのグリフハックが好きで、グリフとそれらを組み合わせた頻出熟語(例:human + civilization)や、LV8のグリフハックのパターン(例:create + pure + future + human + civilization)も結構覚えてる。

しかし、そんなグリフハック好きな私でも、OC HACKだけは無理だ。

  • 3Dになって表示されるグリフがぐちゃぐちゃ過ぎて、全く解読できない(strongとか、他に似たグリフがないやつくらいしか、ぱっと見で分からない)
  • 解読が難しいくせに、制限時間が短すぎる
  • 出題されるグリフを観察するためにARオブジェクトを設置しないといけないのだが、それが画面外のどこかに飛んでいって、そもそもグリフを解読する段階にすらたどり着けない
  • そのさらに前段階として、ARオブジェクトを設置するために周囲をカメラスキャンする必要があるのだが、その精度が低く、よく失敗する(一応失敗してもOCHACKには挑戦できる)


難易度が高いからこそリソースが沢山もらえるってことなんだろうが、ミニゲームとしての完成度が低過ぎて、やっててストレスしかまらない。本当につまらん。

実装前にまともにテストしたのかを疑うくらいのクソゲーだ。

2024-01-11

マイクラグラフィック過小評価され過ぎてる

ドットを取り入れた独自3D表現により広大な世界を描いているのだ

オブジェクトがカクカクであっても解像度は高く細部まで描かれており(環境にもよるが)、美麗と言っていいだろう。ドット=低クオリティではない

anond:20240111115848

2024-01-08

anond:20240108104207

そういう事よ

奴らにとって女とは手に入らない事がほぼ確なすっぱいすっぱいぶどうなわけで一生触れられないまま人生を終える

そのへんに湧いてくるただのリスクはらんだオブジェクトと見る他がなくなってるんだ

2024-01-07

でもぶっちゃけ被災地観光旅行してみたいよな

石川能登は冷やかしどころかボランティアすら断るほどインフラが壊滅していて、現地入りした人が色々と叩かれてるけど、ぶっちゃけSNSにあげるかどうかは別として震災直後の現地を観光してみたいって気持ちはある

311とき東北津波で街が流されていて壊滅した瓦礫ばかりである意味圧巻だったようだが、残念なことにそれを見ることなく終わってしまった

なお、そこから1年後に現地入りしてもまだ瓦礫が残っていて被災地としての風情があった(意訳)と知人が言っていたけどね

例の奇跡の一本松とかは今は立派な観光名所になってるがあれはただのレプリカで、本物は震災直後の数週間でしか見れなかった(塩害で死んだので)

岩手大槌町では建物上に乗り上げた船とか風光明媚オブジェクトもあったがあえなく解体されたんだが、むしろあいうの残しておけば観光地として生きながらえて過疎地にならずすんだはず

まだ産まれてないが阪神・淡路大震災崩壊した高速道路とかああいうのもさっさと解体撤去されたけど、ああいう非現実的ものを見れた人が羨ましい

石川被災地は風情のある古民家が多いしプチ京都みたいな町並みだったが、それが倒壊しまくってる姿は、まさに東京大空襲関東大震災とき東京彷彿とさせてくれるのではないか

これは見たい・・・是非とも見てみたい・・・そういう思いがムクムクと元旦からこみあげてくる

というので連休はまだまだ続くので、被災地入りしてみようかなと思っている

今は関西の某所に住んでいるが、石川首都である金沢ほとんど無傷でインフラは生きているので、そこまで車や公共交通機関で行ったあとあとは自転車あたりで能登半島まで行ってみたい

例の倒壊した輪島塗の五島屋とか特に立ち入り制限されてないらしいから真っ先に見て写真とってこようと思う

でも炎上はしないだろうね

インスタとかTikTokアップロードしないんだから、そこが今の若者リテラシーの違いよ

2024-01-03

anond:20240102230512

PS3メモリが少ないかテクスチャ解像度オブジェクト数が当時でも全然足りてなかったでしょ

綺麗さだけではなく、グラフィック表現出来る事にまだ限界があった

2023-12-25

let hello = {hello: "hello"};

let bye = hello.hello;

hello.hello = "aaa";

console.log(bye); helloが表示

↑わかる。helloの値とそれに伴い参照が変わってもbyeの参照は以前"hello"を指してるから

let hello = {hello: "hello"};

let bye = hello;

hello.hello = "aaa";

console.log(bye.hello);aaaが表示

↑わかったようなわからんような…これ以上オブジェクトネストした者同士の代入の組み合わせされるといよいよ理解が追い付かなくなる

2023-12-17

プログラミング初心者です。以下のコードの誤りはなんですか

僕はプログラミング歴2週間の初心者です。キーと値を入力できるデータベースを作っています

以下のコードを実行してデータを追加し続けると、一定サイズを超えるとエラーが出てしまうみたいです。

理想は、データが追加された後にサイズが足りなくなったら動的に自動拡大されることです。

もし詳しい人がいたらご教示お願い致します。

import sys
import os
import mmap
import hashlib

def h(x):
    return int(hashlib.sha512(x.encode()).hexdigest(), 16)

def create_db(filename):
    with open(filename, 'wb') as f:
        f.write(b'\0' * 1024 * 1024)  # 1MBの空ファイル作成

def set_key(filename, key, value):
    with open(filename, 'r+b') as f:
        mm = mmap.mmap(f.fileno(), 0)
        pos = h(key) % mm.size()
        while mm[pos:pos+1] != b'\0':
            pos = (pos + 1) % mm.size()
            if pos == h(key) % mm.size():
                f.seek(0, os.SEEK_END)
                f.write(b'\0' * mm.size())  # ファイルサイズを2倍にする
                mm = mmap.mmap(f.fileno(), f.tell())  # ファイルサイズを反映させる
                pos = h(key) % mm.size()  # ハッシュ値を再計算する
        data = key + '\0' + value + '\0'
        data = data.encode()
        mm[pos:pos+len(data)] = data
        mm.close()  # mmapオブジェクトを閉じる

def get_key(filename, key):
    with open(filename, 'r+b') as f:
        mm = mmap.mmap(f.fileno(), 0)
        pos = h(key) % mm.size()
        while mm[pos:pos+1] != b'\0':
            end = mm.find(b'\0', pos, mm.size())  # 第2引数と第3引数指定する
            if end == -1:
                end = mm.size()
            if mm[pos:end].decode() == key:
                pos = end + 1
                end = mm.find(b'\0', pos, mm.size())  # 第2引数と第3引数指定する
                if end == -1:
                    end = mm.size()
                value = mm[pos:end].decode()
                mm.close()  # mmapオブジェクトを閉じる
                return value
            pos = (pos + 1) % mm.size()
            if pos == h(key) % mm.size():
                break
        mm.close()  # mmapオブジェクトを閉じる
        return None

def main():
    cmd = sys.argv[1]
    if cmd == 'create':
        create_db(sys.argv[2])
    elif cmd == 'set':
        set_key(sys.argv[2], sys.argv[3], sys.argv[4])
    elif cmd == 'get':
        print(get_key(sys.argv[2], sys.argv[3]))

if __name__ == '__main__':
    main()
 
ログイン ユーザー登録
ようこそ ゲスト さん