エロゲのシステムまわりを考える(A・H・OP ver.8)
■ このスレッドは過去ログ倉庫に格納されています
発売前は話題にならないが実際に遊んだ人からはしっかりと評価されるシステム周り。
システムが良ければ売れるわけではないがシステムという土台がしっかりしてないと、良い絵やシナリオ、濡れ場の魅力も半減。
そんな縁の下の力持ちであるシステム周りについて語りましょう。
「ここのメーカーのシステム使いにくいんだけど。こんな風だったらよかったのに・・・」
「このゲームのこのシステムは(・∀・)イイ」
「エロゲにこんな機能があったら便利」
そういった情報の検討・蓄積を行うスレです。
ここの地道な意見がシステムデザインの参考にされることを願ってやみません。 画像のデコード速度なんて他のエンジン使っても一緒な気がするけど
早くしたいならキャッシュしたり先読みしたりすれば良い
アクションゲームだと読み込みは少ないが
高解像度の端末で派手なエフェクトを出すと描画面積が増えて
GPUに負担が掛かる
大量のオブジェクトをCPUでバッチ処理するとCPUにも負荷が illusionの3DゲーもUnityだが
上で出てるのは2Dなのにそれより重いからなwwwwwwうぇwwwえうぇうぇうぇ 変な使い方してるのでは・・・?
エロゲー如きにメモリ2GB使用はおかしい エロゲ如きって考え方が根本的に間違ってるんだよ。
3Dのテクスチャーなんて小さいし処理後の画質が荒くても許されるでしょ。
エロゲの画像がどれだけ大きいか分かってるよね。
今時の3D処理はGPUが完全にサポートしてくれてるし。
自分で作ってみれば分かるよ。 自分でリソースの解放忘れてメモリリークさせてるだけでしょ? リソースの解放を忘れたところでメモリはリークしないし
そもそもメモリリークが発生したら重くなるんじゃなくてバグるだけ('A`) Unityは知らんが
C#でも参照を持ち続けるかアンマネージドのメモリの解放を忘れればメモリ使用量増え続けるでしょ
何でもかんでもUnityのせいって非論理的すぎない 画像がでかいといっても、未だ1280x720が多いからなあ
内部的にでかい画像で拡縮演出とかするくらいなら、そろそろ1920x1080を標準、出来れば4Kに対応して欲しい
無理ならせめてソフトウェアフルスクリーンの拡大にbicubicやlanczosを選べる機能がないと辛い >Unityは知らんが
>何でもかんでもUnityのせいって非論理的すぎない
Unityはそういうもん
同じUnityで作られた比較的有名なこのゲームなんか背景は2Dでキャラこそ小さめの3Dだが同じくらい(1.8GB)メモリ食う
http://cdn.akamai.steamstatic.com/steam/apps/291650/ss_e13fb5d2fcdcb5aeb4b17aeaff195c2a77ea74b0.jpg >>745
メモリを大量に食ってもそれで重くなるわけがないじゃん。
そりゃ常識レベルを超えたらPCの場合はフリーズすると思うけど、2GB程度ならぜんぜん。
Unityが重いのは別の問題でしょ。 >>746
いや、無関係じゃないでしょ
GCがやる仕事の量が増えるから
ゲーム内容の割にメモリ使い過ぎなら他にも変な事しててもおかしくない
スマホの旧機種でも動くくらい軽く出来てるゲームがあるなら単に開発者の努力不足だろ 何で3Dゲーム用のエンジンでわざわざ紙芝居作ったのか謎すぎる
最適なエンジンたくさんあるだろうに >>747
GCのせいなら最初から通して重くなるってことはねえわな。
メモリが一定量になってGCが入るタイミングでカクカクするだけだろ。
てか、他のエンジンのほうが楽なんだからUnity使うメリットがねーんだよ。
なんでそこまで無理筋でUnity擁護するんだよw それにガベコレの対象ってオブジェクトだべ。
なんで画像に対してガベコレが掛かるんよ。別管理じゃないの、あれ。 そんな重いのにiPhone4Sでも動くの?
てか重いって具体的にどの部分? そのうちUnrealEngine4でエロゲー作る会社が出てきそうやなw >>752
iOS7以上が必要とは書いてある
iOS7はiPhone4以上のみ対応
脱獄したら3GSにもiOS7入るかもしれないが
そんな事するやつあんまり居ないと思う
入ってもアプリが正常に動くかは分からない >>754
なるほどね、動きはするのか
ただ今使ってる5でも最近のゲームはカクカクするから辛そうね Denuvoは完全に護るのではなく発売何ヶ月か持たせるという触れ込みだから、元々そういう想定なんじゃないの
毎回素早く割られるようになるなら終わりだろうけど ※今後の修正パッチについてのご報告(2016/08/15)
Laplacianのデビュー作『キミトユメミシ』をご購入頂いた皆様へ
現在、32ビットOSでの動作不具合、その他にも動作が重いなど、ご迷惑をお掛けいたしまして、誠に申し訳ございません。
このバグを修正するパッチ開発に取り組んでおりましたが、現時点ではパッチ対応での改善はすぐには難しいという結論に至りました。
ご報告が遅くなり、重ねてご迷惑をお掛けしまして大変申し訳ございません。
現在社内にて、以下の方法での対応を検討しております。
・Windowsマシンでの安定した挙動実績がある別エンジンへ移植
・新システム移植版を購入者の皆様に無償配布
・Mac版は現時点では対応保留
配布方法や日時は、決定次第公式サイト・公式Twitterにて告知させて頂きます。
Laplacian 開発一同
3D用のゲームエンジンを使ってしまったばかりに作り直すんやな
悲劇やな・・・ >3D用のゲームエンジンを使ってしまったばかりに
自分の失敗を人のせいにする無能w なんか異常に3Dエンジンを擁護する奴は学校でUnityでも使ってるんだろうか Unityはアホでもゲームっぽく作れるという利点しかないからな 紙芝居程度で重くするってエンジン以前にスクリプターに問題ありそうな 多機能と汎用性を備えると劇的に重くなるんですよ
2D-ADV用のエンジンを使ったほうが速くて楽なのは当たり前というか 機能の実装で劇的に重くなるって
プログラマが悪くないなら誰が戦犯だと言うんだよ 原因を調査しない・出来ない時点でまともなプログラマーとは思えない >>769
劇的に重くなる機能を実装したのはエンジンを作った奴な
戦犯はそのエンジンを選んだ奴だなw >>771
エンジン標準の使うと重くなる機能、か……
あれか、H2Oを沢山飲むと死ぬ並みに低レベルな話か
ぶっちゃけ紙芝居で重くするなんて画像や音源を全てメモリに展開するくらいしか思い付かないが、
それはリソース読み込む機能が悪いんじゃなくてリソース管理するコードを書けなかった奴が悪いと思う >>772
音楽はストリーム再生させるからともかく、
画像は全部メモリに載せるもんだろ 起動するだけで1.5GB食うのをプログラマーのせいにせず誰のせいにするのか
32ビットWindowsなら通常1つのソフトにつき2GBまでしか使えないので、クラッシュするのも当然だろう >>773
それが可能なら世の中のゲームからNow Loadingが消えてる http://forums.geforce.com/default/topic/937374
Microsoft Windows Vista support for GeForce GPUs
has been deprecated with driver branch R367_00 and onwards.
Driver 365.19 is the last driver to support Windows Vista.
http://forums.geforce.com/default/topic/957568
Microsoft Windows XP/Windows XP 64-bit driver support for GeForce GPUs
has been deprecated with driver branch R370_00 and onward.
Driver 368.81 is the last driver to support Windows XP/Windows XP 64-bit.
XPとVistaのGPUドライバが遂にワポート打ち切り >>775
ああ、まあ、このエンジンを使うのは無謀、絶対に酷いことになるから止めるべきだって
押し通さなかったのはプログラマーが悪いな。 ※修正パッチVer.1.10公開(2016/08/29)
http://laplacian.jp/kimiyume/patch.php
キミトユメミシのパッチVer1.10を公開いたしました。
主な改善箇所は以下です。
・32ビットマシンでクラッシュするバグ
・消費メモリの軽減
・一部バックログでの誤作動の修正
・誤字脱字修正
・一部CGの修正
・小鳥遊みこと立ち絵追加
※Ver.1.10のパッチは1GB程度のデータサイズになっております。非常に重いデータ容量となり、
ご利用の方には大変ご不便お掛けいたしますが、ご理解の程何卒よろしくお願いいたします。 公開日:2016/08/31 最終更新日:2016/08/31
JVN#85213412
有限会社AKABEi SOFT2 製の複数のゲーム製品における OS コマンドインジェクションの脆弱性
https://jvn.jp/jp/JVN85213412/
公開日: 2016/08/31 最終更新日: 2016/08/31
有限会社AKABEi SOFT2からの情報
脆弱性識別番号:JVN#85213412
脆弱性タイトル:有限会社AKABEi SOFT2 製の複数のゲーム製品における OS コマンドインジェクションの脆弱性
ステータス:該当製品あり
以下の情報は、製品開発者から JVN に提供されたものです。
https://jvn.jp/jp/JVN85213412/995740/index.html
影響を受けるシステム(ゲームタイトル)は下記のとおりです。
なお、初回版、通常版、ダウンロード版など、パッケージのバージョン、
販売形態にかかわらずすべての商品が含まれます。 どーせまたセーブデータだろと思ったらやっぱりそうだった なんか、設定ファイルが見つからないとか吐いて、インストーラが走らないぞ
どーなってんだこれ SandBurst
http://forest.watch.impress.co.jp/library/software/sandburst/
ウィンドウをリアルタイムに拡大表示できるソフト
マウス入力にも対応する、ゲームウィンドウのリアルタイム拡大ツール。
高解像度モニターでは、ウィンドウサイズが640×480ピクセルや800×600ピクセルなどのゲームをプレイすると、
文字などが小さくてプレイしにくい場合がある。
本ソフトを利用すると、指定した任意のウィンドウを、100%から300%まで任意の倍率で拡大表示できる。
描画にはWindows Vista以降のAero環境における描画エンジンであるDWMもしくはDirectXが利用でき、
DWMを利用した場合は低負荷で遅延のない表示が可能。
また、マウス入力も拡大したウィンドウに合わせて補正されるようになるので、マウスを利用するゲームも問題なくプレイできる。 最近一週間ほど昔のことを色々と想い出して古いエロゲーを最プレイしてるんだが
2002〜2003年頃までのエロゲはいきなり問答無用で全画面で起動するのが多くてブチ切れそうになる
懐かしい想い出に浸りつつもエロゲのシステムは昔に比べてずいぶんと進歩したなあと実感
それとともに古いエロゲの8割くらいはWindows10でも全く問題無くプレイできて
2割くらいの動かないものもアクセス権いじるとかで半分くらいは対応可能
結局9割くらいのエロゲが今もプレイ可能だったことにも驚いてる fullscreenwinでも最大化できないゲームがある
古すぎるのは対応していないのか
しかしツクール系のゲームはUI最悪なのばかりでせっかく好みのCGがあっても遊ぶ気になれない
ADVやSLG型なのになんでツクールで作るんだ
YU-RISの方がいいと思うけどな〜 そろそろOpus使ってもいいんじゃないの
ロイヤリティフリーだよ AHOPってなんだ? って話題があったおかげでこのスレは8まで続いた 15年ww
696 名前:名無しさん@初回限定 :02/07/20 21:44 ID:fxuFC9QG
(´-`).。oO(このスレもA・H・OPの謎が解けずに八ヶ月たったが
プログラマに手を拍たせることが一つくらいあったろうか……) なぜそのレスをチョイスしたのか
>>3でもう疑問上がってるだろ 吉里吉里Zが進化しすぎて旧吉里吉里を使う理由がなくなってきた ショートカットキーの割り当て変更って使ってる?
俺は結局いつも標準のまま……。 >>800
ゲームエンジン/ウインドウクラス名でまとめてマウスボタンをカスタマイズしてるから、その統一ルールにあうようにオート、スキップ、窓消しのキー割り当て変更することはある
スペースキーが窓消しで変更できないと地味にイヤ せっかくの休みを>>801のフリーソフトの翻訳改訂とベータテストに費やしてしまった
エロゲや専ブラその他で欠かせないってぐらいにお世話になってきたが作者さんに恩返しできたかな
積みゲを切らしてたからべつにいいんだけどとても疲れた(英語が苦手なので) 【速報】mp3の特許が切れてフリーに
http://www.mp3licensing.com/
>On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 related patents and software of Technicolor and Fraunhofer IIS has been terminated. SandBurst1.4
2017/05/20 01:38
http://eternalpaymenholiday.blog.fc2.com/blog-entry-42.html
SandBurstを1.4に更新しました。
http://ux.getuploader.com/MasterD/download/15/SandBurst.zip
Vectorでも公開しましたが、間違えて古いファイルで公開してしまいました。
Vector版だと今まで動作してたゲームの一部が動作しません。
Vectorはファイルの更新に営業3〜4日かかるので、最新版はこのブログ内のURLからダウンロードしてください。
■ 更新内容
@ 吉里吉里2 と LiveMakerの対応を強化
A 拡大率ボタンを可変に
B 非アクティブ時にウィンドウを戻す設定を廃止
@ 吉里吉里2 と LiveMakerの対応を強化
(古い)吉里吉里2とLiveMaker製のゲームが元のウィンドウサイズ分しか補正できてなかったところを修正しました。
動作モードに「吉里吉里2 & LIveMaker」と言うのを作りましたので、これらのゲームの場合はこのモードを使ってください。
A 拡大率ボタンを可変に
拡大率のところを右クリックで最大、最小、各ボタンの拡大率を変更できるようになりました。
B 非アクティブ時にウィンドウを戻す設定を廃止
ゲームが非アクティブになっても常に拡大を維持するようになりました。
設定としてあった方がいいんですが、@の対応でこの処理が変わったため、廃止です。 うん、Zに移行してくださいってことらしい。
https://internetcom.jp/203933/end-of-kirikiri
ゲーム制作アプリ「吉里吉里」公式配布が終了へ―「Fate」シリーズでも採用 aoTuV beta 6.03 (2018) リリース
https://aynote.wordpress.com/2018/05/02/aotuv-beta-6-03-2018%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/
本家のlibvorbisの新しいバージョン1.3.6がリリースされたため、それと統合したaoTuVを公開しました。
脆弱性の修正がメインとなっており、公式の1.3.5から1.3.6への変更点は以下の通りです。
Fix CVE-2018-5146 - out-of-bounds write on codebook decoding.
Fix CVE-2017-14632 - free() on unitialized data
Fix CVE-2017-14633 - out-of-bounds read
Fix bitrate metadata parsing.
Fix out-of-bounds read in codebook parsing.
Fix residue vector size in Vorbis I spec.
Appveyor support
Travis CI support
Add secondary CMake build system.
Build system fixes
新しいaoTuVについても以上の変更・修正点を反映しているため、ライブラリとしてaoTuVを利用されている場合は
旧バージョンからアップデートされることを推奨します。
もちろん公式の1.3.6の代わりに今回のaoTuVを使用することも問題なく可能です。 以下雑談
久しぶりの更新となりました。
今回は前回よりもアップデート作業自体はスムーズに進んだものの、その前段階でPCにトラブルがあったりしたため、
そちらの方に時間が取られてしまい難儀しました。(この辺のお話はそのうち書きたいです)
今回も相変わらずエンコードに影響するような変更は有りません。
コンパイラを更新したこともあり、リファレンスバイナリの出力結果は微妙に異なりますが、コンパイラや実行環境が同じであれば、
同じ出力結果になるはずです。
後は地味にエンコーダのvencの更新をしています。
今回は8/24/32bit整数と32bit浮動小数点のPCM形式の入力に対応したのが主な変更点です。
オーディオデータは32bit浮動小数点数で処理されるため、32bit整数は精度的にはオーバースペックになりますが、
対応してないよりは対応していたほうが良いでしょう。
aoTuV Beta6.03 (2018) (2018/5/2)
http://www.geocities.jp/aoyoume/aotuv/index.html
# The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.6. The part related to sound quality is not changed from previous version.
・ libvorbis 1.3.6を統合しました。エンコード品質については前バージョンと同様です。 ゲーム開発向けの統合型サウンドミドルウェアWwiseのOpusサポート
https://blog.audiokinetic.com/ja/wwise-2018.1/
OPUSコーデックが、全プラットフォームでサポートされています。Opusは、CPUを少し余分に確保するだけでWwise Vorbisに匹敵する品質を保ちつつ、さらに圧縮できるので、ファイルサイズを特に縮小する必要があるときは、Wwise Vorbisの代替案として非常に有効です。
これらのコーデックを組み合わせて使い、両者の長所を利用することで、ファイルサイズやCPUの競合するニーズに対応できます。
Opusを使ったループやシークについて
Opusでは、シークやループ用のシークテーブルは不要ですが、その分、CPU負荷が高くなり、ディスクアクセスが増えます(ストリーミングの場合)。
これを念頭に、Opusの利用はシークやループのニーズが最小限または皆無のサウンドに制限すべきです。なお、ファイル冒頭のシークやループは軽度なので、このような余計なコストがありません。
Resource usage - リソースの消費 - OpusとVorbisの比較: [http://listening-test.coresv.net/results.htm]で見る限り、Opusコーデックの方がVorbisよりも、同程度のビットレートでの音質評価がやや高いようです。
同じファイルサイズで音質が高い方が、一見、有利なように思えますが、品質が多少なりにも高い裏には、Opusの方がWwise VorbisコーデックよりもCPU負荷が4倍から5倍も高いという現状があります。
とはいえ、何千ものダイアログラインや、長いSFXや、ループなしの単一ストリームミュージックなどを圧縮するには最適の選択です。
Opusとほかのコーデックのオーディオ品質の比較についてさらに詳しく知るには、 [https://opus-codec.org/comparison/]を参照してください。 ■ このスレッドは過去ログ倉庫に格納されています