堕天使の煉獄

Gallery
Comic
Story
Production
Work
Link
もうちょっと更新ペース上げていかないとなっ
と思った翌日から、寒気とうっすらと吐き気が……。
風邪の初期症状っぽい?

で、しばらく寝る。
ちょっと活動する。また寒気と吐き気再来。また寝る。

がしばらく続く。

最近、一度寝込むと長引くのでなるべく軽い症状のうちにとっとと寝ちゃって直したいなというのがあって。
で、結果なんにも手に付かん。
さらには花粉症の追い打ちがきて、さらにダウナー。

やっぱ春と言う季節はいつも体調悪い……。


Gyaoでやってたので、映画グーニーズを見る。
子供の頃にTVでやってたのを見た記憶はあるんだけど、食いしんぼキャラと顔が歪んじゃってるおいちゃんが仲良くなるのと、なんか木の枝みたいなのが鍵盤になってるオルガン弾く装置みたいなのが出てくる。
の2点ぐらいしか覚えてなかったりで。

今見ると普通に面白いですね。娯楽映画の王道って感じで。

んでも後からウィキとか見てみたら出演者。
主役のマイキーは後のロードオブザリングのサム。
お調子者のやつは、スタンドバイミーの眼鏡だとしって、もう一度見てみたら、たしかに黒縁眼鏡足したら同じ人だった。
アジア系の少年は、これも見た顔だなとおもてたら、インディージョーンズの助手ででてたあの子か。

で、子供の頃は全然気にならなかったのか、TVで見てたのでカットされてたのか。若いねーちゃんがワカメちゃんぱんつかってぐらい普通に後ろ向いただけでパンツ丸出しでなんだコレw

なにげにスタンドバイミーの眼鏡ことコリー・フェルドマンといえば、最近ハリウッドの、子役へのセクハラ告発とかでニュースとかになってたなと。

スタンドバイミーもそうだけど、美少年系キャラはもれなくそういう変態の餌食になってその反動か逃避か、薬のオーバードーズで死んじゃったりって話につながるんだよなーとおもうと、ほんとショービジネスの世界ってエグイ世界だなとか。

そして、スタンドバイミーでもこのグーニーズでも、そんな毒牙からは無縁だったとおもわれる食いしんぼキャラ役の人はその後、結構順風な人生おくってるんだよな。

そういう話聞いちゃうと、子役ものとか素直に愉しめなくなっちゃいますよね……。


話は変わって、すぐ寝込んだりして全然進まない作業。
ぺぺいと作ってしまいたいのになかなか時間をかけて作業出来ないのでやきもきしてるダンジョンRPGツクール開発。

マーケティングの世界の格言で「ドリルを探してた客がほしかったものは穴」みたいなのがあるけど、ツール開発の設計でも同じ事が言えるよなぁとか。

現実的に納期や予算が決まっていれば、どういう穴にするべきかと言うことを先に決め打ちするというのも有りなんだろうけどさ。

なんだかんだで、今後も別の作品で使い回すかもしれないから汎用性のある開発ツールを作ろうってと、結局単一の用途のツールを0からちまちま別で作る事のが多かったりする現実を経験として学んでる筈なんだけどね。
とはいえ途中の思いつきでこんなんいいんじゃね? とか思いついたときにそれを実現するのに全体に大きな仕様変更が必要じゃ困るので、ある程度は柔軟性が求められるわけで。
その辺のバランス感覚がなかなか難しい。

しかし、いまマップデータのデータフォーマットとか見直しているのだけども。

一応好み的に、昔のwizのような、壁がぺらぺらなタイプのダンジョンの方が好みなんですけど、作る側からすると、壁や扉も1マス使うタイプのがものすっごい楽なんだよなーとかおもたり。

壁も扉も1マスなので、壁や扉自体にイベントを埋め込むのがデータ構造的に単純に対応するので楽ちんなんですよね。たとえば一方通行だとか鍵付扉だとか。扉ブロックのなかにイベント付加するだけだし、開放フラグみたいなのも、扉ブロックの座標位置に対応出来るし。

かたや隣り合ったマスの間に壁や扉を設定するタイプのだと、どういうデータ構造を持つのかで一工夫いるわけで。

昔作ったやつは、各マスに上下左右で何も無し、壁、扉の状態をもったビットフラグで管理する感じのを作ってたのですが。
まだテストで作ってみたという感じだったので、まだ鍵付扉とかの事考えてなくてですね。

いざ今回ちゃんと考えて見ると、扉や壁自体にイベントを埋め込みたい時にどうすんべと。
各マスの中に四方分のイベントを持つのはなんだか無駄がおおい気もする。
そもそもイベントの無い所の方が多いわけだし。
また、ちょっと前にやったダンジョントラベラーズでもあった、向こう側からじゃないと開けられない扉(で一度開けたら今後はどちらからでも通れる)みたいなのを実現しようと思うと、1マスの四方の壁面の状態を持つだけなので、一方通行の場合、となりのマスの壁面の状態もあわせて状況判断には必要になるときにちょっとめんどくさい。
さらに開放フラグを設定する場合、壁は両面しかも、ブロックの間にあるので、扉一枚一枚にユニークなIDをというのが余りシンプルに実装出来ない。
それぞれ両面あるので。どっちの方向から見て一方通行なのかとかがシンプルに表現出来ないぽ。

そんな時にふと、やっぱ壁も扉も1マスタイプってお手軽なんだよなーとかささやくのですよ。おいらのゴーストが(ぉ

でも、これまたちょっと前にやったばかりの世界樹の迷宮はこの壁も扉も一マスタイプのダンジョンなのですが、このタイプ、穴掘りタイプというのでいいのかな? って、基本的には単純に右手か左手を壁に付けて歩けば必ず出られるっていう単純なものになりがちなんですよね。
世界樹の迷宮の場合はユーザーがマッピングするというのもゲームの内なので、マッピングしやすさという点からもこの方式のが向いてるってのもあるんだろうけど、結局構造が大抵似通っていて、入り口からぐるぐる遠回りして最後に直線距離では入り口近くの場所にある出口につながっている。で、出口付近に入り口側に初回のみ一方通行で出口側からしか開放できない一方通行の道が設置されているというパターンに大体なってたりで。

個人的にはやっぱ穴掘りタイプのダンジョンはあんまし魅力を感じないなーとかおもたりで。

あと、エディタ上でのデータ構造と、実際のゲーム上のデータ構造を同じにする必要はないんだよなという所もある。
エディタ上ではマップチップ単位でべつにいくらでも変数ぶっ込んでも良いんだよなーとか。
でもゲーム内では、なるべく省メモリかつ高速に読み込めるのが好ましいわけで。そうなるとバイナリでバイトどころかbit単位でギチギチに詰め込む必要がある。
逆にエディタ上ではメモリ消費量よりも編集のしやすさ、コードの書きやすさ(保守や改変に強いなど)の方が必要なわけで。
エディタ上でわざわざ1バイトにbitフラグで~とかやらずに必要なだけ変数つこたらええやんけ。という話に。

だけどもc++なんて言語やってると、少しでも使用メモリを減らしたい、切り詰められる物はすべて切り詰めたい。わずかでも速度低下する要因をつぶしたい……。
そんな病的な性質に自然となっていくのですよ。

そいえば「富豪的プログラミング」なんて言葉もあったな。

ちょっと気になって「富豪的プログラミング」でググってみたら……というのも最近、思っていたものが実は間違ってて覚えてたってケースちょいちょいあって、確かめる意味でもググって確認する癖が付いてたりで。
ここ最近で間違ってたのは……つべで関連動画で出てきたので何となく見てたFF5の縛りプレイ動画。機械読みのナレーションが付いてるタイプの動画なのですが、途中で聞き慣れない単語が。
「スリプル」……おいおい、それは「スプリル」だろ? 間違えてるじゃん……はい間違えてるのは私でしたw

FFシリーズは1からリアルタイムでプレイしているくせに(11とばして12までだけど)いままでずーっと間違えて覚えていたことを今知ったよ…_| ̄|○
てかググってみると、結構「スプリル」使ってる人いるみたい。間違えやすい部類の物なんだろうかね。語源的にはスリープ→スリプルなんだろけど、単純に読みとしてしっくりきちゃったのがスプリルなんだろうな。
てか、音(発声)として聞いたのが今になって初めてというのもなんだかなと。そもそも「眠らせる魔法」とか「あの敵眠りが効くぜ」とかで通じちゃうとか、そもそも話題に上るほどメジャーでもない補助魔法なので、子供の時分、たとえばゲーム談義なんかしてる時にも一度も出る機会がなかったってことなんだろうな。「バスナ」とか「ブラナ」とか「バファイ」なんてのも、声に出して読んだ記憶とか無いしな。

似たようなのだと、
(誤)柴田ヨサクル(正)柴田ヨクサル 
(誤)カルボラーナ(正)カルボナーラ
(誤)シュミレーション(正)シミュレーション
みたいなの。ほかにも一杯心当たりはあるんだけどすぐには出てこない……。

シミュレーションとかはすぐにそうなんやーとすぐ修正できたのだけど、カルボラーナ、カルボナーラは未だにどっちだっけ? と判らなくなるw
柴田ヨサクルは今では間違えなくなったけど、気づいたのはエアマスターの最終巻でた頃ぐらいだったなぁ……。

Typoglycemiaとは、単語を構成する文字を並べ替えても、最初と最後の文字が合っていれば読めてしまう現象のことである。
ttp://dic.nicovideo.jp/a/typoglycemia

これはちょっとまた微妙に違う話ですけどね。
人間の脳が「最初と最後の文字が合っていれば」読めてしまうという性質を持っているので、「スリプル」と描かれている文字を見ても「スプリル」と認識手しまう。とういう説明にはなるけど、なぜ「スプリル」と間違えたのかという説明ではないので。
単に音のリズムとか読みやすさ、似た単語との親和性から来る誤謬などが原因なんだろうけど。
例;柴田ヨクサル→人名→与作(ヨサク)から連想の誤謬→柴田ヨサクルみたいな?
問題はその間違いが、Typoglycemiaによって、誤謬と気づけないままになってしまう、と言うところなんだなと。

ちょっと脱線。
「富豪的プログラミング」は普通に自分が認識してた意味と同じでしたけど。対義語として上がってた「貧民的プログラミング」にはちょっと疑問が。
まあ組み込み系なんかではそのまま当てはまるのだろうけど、個人的にはもう一つの、裕福なんだけどもドケチを極めたような……なんと表現するのがいいのだろうか。

「守銭奴的プログラミング」?w

てのがc++erの落ちる暗黒世界のプログラミング作法にはなんか当てはまるようなw

でもまあ、現実的に考えて、保守や改変とかも考えると、エディタ上では「富豪的プログラミング」が大正義でしょう。ゲームで使用する方は、趣味のレベルですきにしたらええやんて感じで別けて考えるべきだよなとか。

そうやって割り切ると、ちょっとすっきりして吹っ切れるかも。

でもやはり気がつくと、ちまちまと省メモリ省スペース思考に。
やはり根が貧乏人だからだろうかw
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
気がつけば3月になってる
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
[春分の日]
22
23
24
25
26
27
28
29
30
31
花粉症シンドイ。
total:2081217 t:191 y:488
■記事タイトル■

■年度別リスト■
2024年 2024年12月(0)
2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年 2023年12月(3)
2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年 2022年12月(4)
2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年 2021年12月(8)
2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年 2020年12月(3)
2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年 2019年12月(1)
2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年 2018年12月(1)
2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年 2017年12月(2)
2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年 2016年12月(7)
2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年 2015年12月(7)
2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年 2014年12月(12)
2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年 2013年12月(15)
2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)

■レス履歴■

2023-09-26 14:59:38 - 久慈光樹

2023-09-26 14:29:10 - 織田霧さくら

2023-09-26 13:10:45 - 久慈光樹

2023-03-20 05:30:16 - 織田霧さくら

2023-03-15 20:42:58 - まうる

2022-12-26 19:14:57 - 織田霧さくら

2022-12-25 02:28:36 - まうる@まるるん

2022-09-30 04:29:01 - 織田霧さくら

2022-09-23 19:01:29 - まるるん

2022-06-16 21:06:34 - 山本


■ファイル抽出■

■ワード検索■

堕天使の煉獄

https://rengoku.sakura.ne.jp
管理人

織田霧さくら(oda-x)

E-mail (■を@に)

oda-x■rengoku.sakura.ne.jp

堕天使の煉獄バナー 堕天使の煉獄バナー