[過去ログ] RPGツクールMZ (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
743(1): 2020/09/15(火)20:22 ID:PVfXfzJC(3/6) AAS
ん?
なんかおかしいな。三歩エンカに限れば0-2,2-0,1-1の三通りしかないから1/300か
三歩以下でエンカウントする確率は全部で6通りの1/150
攻撃をミスしたり一歩エンカとかは特に印象に残りやすいから、確率以上に遭遇し易いと錯覚する
特にツクールの場合だとエンカウント率を考慮せずに移動速度上げる事が多いから
移動速度を倍にするとエンカウントの猶予時間まで半分になる
744: 2020/09/15(火)20:25 ID:1gKjftHe(2/3) AAS
MZに15歩くらい確定でエンカウントさせないプラグインがあったな
745(1): 2020/09/15(火)20:28 ID:Y6Jo9zAT(4/5) AAS
>>743
その1/150が高確率で起こることない?
乱数が偏りすぎてるから最低歩数プラグインみたいなの入れてる
746: 2020/09/15(火)20:34 ID:IFo/O4WY(1) AAS
もうサガスカみたいに決まったところでのみ戦闘になるとかどうだ
747: 2020/09/15(火)20:36 ID:xPpOGt6b(2/2) AAS
>>732
最近は、本職の人がnoteとかに初心者でも分かりやすいような記事を上げてくれてるんで、
外れ記事もあるけど、暇なときにでもだらだら読むといいよ
専門書まで買うとエタる可能性が高まるから気を付けろ
748(1): 2020/09/15(火)20:47 ID:PVfXfzJC(4/6) AAS
>>745
技術的にはないだろうね
SFC時代なら乱数表、PS時代は「線形合同法」って言ういわゆる乱数の偏りが発生し易いアルゴリズム使っていたけど
MV以降のchromeでは「XorShift128関数」っていう
洗練された乱数生成アルゴリズムを採用しているから目に見えた偏りが発生するとは考えづらい
このテの話は実際の確率論よりも印象論の方が強いよ
有名どころだとFEでも表示命中率よりも当たりやすい「実効命中率」っていう二つの確率を使い分けてプレイヤの不満を軽減している
外部リンク:dic.nicovideo.jp
749(1): 2020/09/15(火)20:51 ID:1gKjftHe(3/3) AAS
>>748
MZでランダムを似非ランダムにしてるとは限らないんだが解析でもしたのか?
MZだと2〜3歩歩いてエンカウントなんて日常茶飯事的に発生するって分かるじゃん
750: 2020/09/15(火)20:55 ID:PVfXfzJC(5/6) AAS
>>749
解析もクソもコアスクリプトにエンカウントまわりの計算式くらい普通に書いてあるし
2015年以降chrome(ツクールMV/MZのベース)のに疑似乱数生成システムをXorShift128関数に変更したって出てくるだろ
プログラムはコードに書いてある通りの処理しか実行しない
コードに不具合がないならお前の勘違いだよ
751: 2020/09/15(火)21:37 ID:Y6Jo9zAT(5/5) AAS
でも実際にエンカウント50歩で設定して2連続3〜4歩で出てくることは良くあるからなぁ
ただあれ芝とか山のチップだとエンカウント率が二倍になる余計な処理入ってたよな?
752: 2020/09/15(火)21:47 ID:PVfXfzJC(6/6) AAS
茂み属性のタイルなら設定歩数の消費速度が2倍。船に乗っていれば消費速度が1/2倍。
特徴のパーティ能力エンカウント半減(なし)もこちらに掛かる係数。
デフォルトでエンカウントに掛かる作用はそれくらいだな。
一応書いておくけどエンカウント計算式はrmmz_objects.jsの8219行目
Game_Player.prototype.makeEncounterCount = function() {
const n = $gameMap.encounterStep();
this._encounterCount = Math.randomInt(n) + Math.randomInt(n) + 1;
};
で処理している。このthis._enconterCount = 1;に変えれば必ず一歩エンカになるし100にすれば100歩エンカ固定になる。
上で出ている「N歩くらい確定でエンカウントさせないプラグイン」っていうのも末尾の+1を任意の数値に変えてるだけで大した事していない。
753(1): 2020/09/16(水)01:31 ID:2NH1uRc1(1/2) AAS
誰かMZのプラグインを有料で受けてくれるサイトや人をしりませんか?
後、エロゲつくろうと思ってるんですけど、システムの根幹とウインドウ周りの調整
予算5万~10万じゃ足りませんかね?
ツクテマとかいろいろみたんですが、今MZでプラグイン受け付けてますみたいな
人がいなくて…
754(1): 2020/09/16(水)01:54 ID:3vqwhs4N(1/5) AAS
ココナラは?MVなら出てるけど質問出したらMZも対応してくれたりするかも
755(1): 2020/09/16(水)02:01 ID:kKqEC/d5(1/2) AAS
バグ出たらどうすんの?
フリーならまだしも有償ならめっちゃ博打やな。
756(1): 2020/09/16(水)02:09 ID:ULA3qnAb(1/9) AAS
>>753
>システムの根幹とウインドウ周りの調整予算5万~10万じゃ足りませんかね?
要求内容に拠るね……
他プラグインの競合対策を考えながら永久サポートとかやってられないし
他にどんな他プラグインを使用するのか、納期はいつなのか、サポート満期はいつなのか、を事前に設定して報酬の話はその後。
5-10万はまともなエンジニアを顎で使うには安い額だけど、まぁ話し合い次第だね。
額よりも誠意の問題だから売り上げ何か月分の内の〇%分、とかって取り決めの方がモチベが上がるかも。
757: 2020/09/16(水)03:15 ID:kKqEC/d5(2/2) AAS
あなたに必要なのは外注じゃなくて一緒に作る相手じゃないか。
見つかればの話だけど。
そもそもお金のやり取りを考えてる人にしてはあまりも書いてる内容が杜撰すぎるよ。
それにMZのフレームワークを理解してるPGがそもそもまだ居ないと思うけど。
758: 2020/09/16(水)03:28 ID:2NH1uRc1(2/2) AAS
>>754
ご意見ありがとうございます!
そうですね!MVのプラグイン制作の方が1名おられますね!
そのかたにMZ対応可能か聞いてみます!
>>756
納期はゆったりでしたが、
販売後もサポート頂くことを考えると着手金10万プラス
利益の%で提案するのが筋のようですね。
Revenue share方式で提案してみます!
>>755さん、そうですね!先方にご迷惑をかけないような
省1
759: 2020/09/16(水)04:27 ID:AM6TudPG(1/3) AAS
今ツクールえろげで外注ありで元取ろうとするならば
Live2Dや音声も入れんと新規参入じゃ厳しいかもしれんけどな
760: 2020/09/16(水)05:52 ID:fqOauEO/(1) AAS
いらんやろ
761(1): 2020/09/16(水)13:49 ID:gIoEvNlH(1/3) AAS
個人的には『売上のn%』は逆効果かな……
大前提としてそこそこ売れてる作品を完成させた実績がないと、売上が発生するかどうかが信じられないので基本的に0円換算だよ
そもそも、踏み倒されない保証もないし
仕様がふわふわしていなくて、作業が追加された場合は別料金が確約されてて、
技術的に無理なものは無理と理解してくれるのが一番嬉しいかな
契約料を払えとまでは言わないけど、作業が発生するかもしれない状況が続くだけで地味に負担というのを勘案してくれると好印象
ただまあ、最初の段階で「遊びたい!」と思うと全体的に甘くなる
762: 2020/09/16(水)15:01 ID:ULA3qnAb(2/9) AAS
>>761
結局のところ、自分の受け持ち作業した分だけリターンに繋がるって構造がないとダメやね。
でも、非業界人に仕事を正しく理解して評価しろってそっちの方がずっと厳しいと思うわ。
プラグイン素材はフリー公開が基本だから感覚がマヒしている同人屋が多いけど
もしもビジネスとしてフリーランスプログラマを雇おうっていうのなら駆け出しレベルで月単価50-60万は見なきゃいけない業界。
サポート込々ひっくるめて数十万程度でまともな取引が成立していると思われるのも困るんだよなぁ。
発売後しばらくまでサポートしてくれ、って要求は尤もなんだけど業務開始から満期完了までの期間に比例してコスト(負担)が嵩む。
短ければ短い程、お互いの為になる。
上下前次1-新書関写板覧索設栞歴
あと 240 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.028s