- アップデートしたときにセーブデータの構造変わることあるけど
そのときに前バージョンの構造から今バージョンの構造に変換することが考えられるけど
これがアップデートのたびに続くとこの変換コードが膨大になっていくけどどうしたらいいの？
- なんの話してるんだこいつ
- 詳しい人いないの？
- 解析部をラップしておけば良かったのに
- >>4
>>5
どういうこと？ - 一発抽象化しておけば？
- そこまで大規模な変更する前に企画の段階で練っておけよ…
- >>6
長期運営してたら何があるかわからないでしょ - まさか全パターンIF文書き下してるのか
- >>7
クラスごと変えるけど - アダプタ使え
バージョンごとに使うプログラムを切り替えればよかろ - >>10
クラスを切り替えるけど
プログラムを切り替える？
この変換クラスが膨大になるんだけど - アップデートしたときにセーブデータの構造変えない
- >>13
大規模プロジェクトになるとそうはいかない - 古典的に言うとアダプタパターンな
どんな形でセーブデータ作ってるのよ - >>14
セーブデータクラスのオブジェクトをjson形式に相互変換する感じ - 例えばセーブデータのクラスが
バージョン1
int a
int b
int c↓
バージョン2
int a
int b
int dこうなったとき
バージョン2のセーブデータクラスが必要な上に
a = a
b = b
d = c + 1という処理も必要になるわけだ
- で、このバージョン2のセーブデータクラスのようなのがバージョンアップでセーブデータ構造が変わるたびに必要になっていく
膨大に
それをどうするかって話 - バイナリデータで保存してんの？
xmlやjsonじゃダメなのか？ - >>17
jsonでセーブしてる - その場合は、
int a
int b
int c（未使用）
int d
になるだろうな - >>19
アップデートのたびに未使用が増えていくじゃんアップデートでバージョン2のセーブデータクラスが
バージョン2
int x
int y
int zのように大規模に変わる可能性もある
- アダプタパターン使えよ
- >>22
アダプタパターンにしてもクラスは増えていくでしょ - 変換クラス数が膨大になるって話なら設計レベルの話じゃね？
- >>24
変換クラスというかセーブデータクラスね
その中で変換をするにしてもデータ構造が変わるたびに新しいクラスを用意する必要がある - >>28
ロードしなけりゃクラスなんかいくら増えても害にはならないと思うが、どんな問題が発生してるのだ - >>30
確かにそうだけどセーブデータクラスが膨大になっていく例えば1つのバージョンのセーブデータクラスが100個のクラスファイルで構成されているとすると、100回アップデートでクラス構造が変わったら1万のクラスが生まれることになる
そしてそれが残り続けてしまう - >>40
何で毎回全部のクラスを更新するんだよ
100回のアップデートだったらせいぜい1000とかだろ - >>45
まあそうだけど最悪の場合も想定しないと
どっちみち長期運営したら肥大していく - 未使用が増えてもいいだろ
- >>26
それだとすべての構造が変わるような場合、変数が倍になる
そしてそれが繰り返させると膨大になる - なら最初から設計をミスってる
諦めろ - >>27
大規模の長期運営を想定しないとこの悩みはないだろうなあ - バイト単位で書き込んでるって事？
使わない領域再利用するのは管理大変だし最悪データ壊れて死ぬぞ - >>29
クラスとjsonの相互変換 - まずバージョンアップで頻繁にデータ構造が変わる時点でおかしい
管理できないほど膨大になるって何が起きてるのよｗ - >>31
大規模の長期運営をしたことがない人にはこの悩みはわからないだろうなあ - >>42
普通大規模化すればするほどデータは柔軟に設計するんだけど…
やっちゃったもんは仕方ないが… - >>49
その柔軟な設計を今考えているわけで
少なくともセーブデータ構造が変わることはないとか少ないとかいうのは設計でもなんでもない
小規模短期しか想定できない設計 - C言語だとセーブデータを構造体にして描き出し、読み込み
C++だとクラスにして丸ごと書き出し、読み込み
だから、描き出し、読み込み部分のソースコードは何も変わらない - >>32
その構造体のクラスがセーブデータクラスが変わるごとに新しいのが必要になるって話
ちなC#ね - 文字列キーのMapつかえば？
- >>33
どんなセーブ方式にしてもバージョンアップでセーブデータ構造が変わることによって整合性を保つための変換作業は必要になる
セーブデータクラスがいらなくなってもこの変換クラスは必要になるから同じこと - そんなに構造を変えないように
本体の方で調整しろよｗｗｗｗ - >>36
本体の中にこのクラスもあるわけだが - そりゃ仕方ないだろ
- もうその状態なら変換プロセス別に起動するようにすれば？
スマホアプリならしらんけど - >>39
初めて想定していた案が出たね
PCならセーブデータの変換プログラムを別にするってのも考えた
スマホだとどうするのがいいのか - >>56
え、まさかお前会議で
「5chで募集した最強の設計がこれだ！」
って発言するの！？ - >>56
セーブデータの変換プログラムを内蔵すればいいんじゃね？ - 膨大になるっていうけど実際古いデータが膨大にあるのは事実なんだからしょうがなくない？
まさか古いデータ切り捨てるわけじゃあるまいし
大きいシステムでそんなにコロコロデータ変わると思えないんだが - セーブデータにバージョン持たせれば？
- >>43
当然持たせる>>44
PCならそれでいいけどスマホアプリだとどうする？ - 俺もそう思う
ちょっと想像つかないが、開発に支障が出るほど肥大化してるならコンバーターを別のプロジェクト(プログラム的な意味でなくて)に分割するのが正しいんだろう - どうしても増やしたくない場合、「常に直前バージョンからのアップデートのみに対応する」っていう手もある
それ以前のバージョンからの修正は有償サービスとする - >>47
スマホアプリのような場合しばらくアップデートしない人も出てくるしなあ>>48
ユーザーを失う - >>61
データを全部サーバー側に持たせておけばマイグレーションで一発だったのになぁ - 肥大化してきたら適当に理由を付けてリニューアルすれば良いじゃん
- HTML living standardのバージョンアップに関する考え方を参考にするとか
- 古すぎる箇所は削除すればいいんだろうけど古いバージョンも完全動作保証しますっていった営業を恨め
- 素人意見ですまんが、こういうことが起きないようにするのがクラスの役割なのではないの？
- 変換処理はサーバー側に持たせるとかしか思いつかんなあ
スマホアプリでアップデートはするけどオフラインでしか使えないし、他人とデータ交換もする！とかだとそもそも後方互換性持たせることに無理がある - きっと最初は長期運用を深く考えてない設計だったんだなきっと
プログラミング詳しい人ちょっときてえええええええええええええええええええええええええええええ
VIP
コメント