アカウント名:
パスワード:
その程度の技術力しかない、というのはサービス開始当初からずっと言われている
技術力の話なの?事前に仕込むのはデータのダウンロードを集中させたくないからじゃないかと思うけど。
単純な話、毎日差分だけ更新したら運営の手間もかかるし、ユーザーも毎回ダウンロードの通知が出るしで、大変だからまとめて埋め込みたいわけですな。が、こうやってデータを抜き出す奴らがいるからそれが出来ないと。なので訴訟なりで黙らせるというのは理にかなっている。
分割するほうが集中はしないのでは?例えば1ヶ月間で10イベントあるとして一気に10イベント分まとめて仕込んでおくのと1イベントずつ2~3日に1回ずつ仕込んだデータを配信するの。一つ10MBとして、まとめてなら100MB一気に落とす必要がある。後者なら1回は10MBで済む。容量が少ないほど早く落とし終わるから渋滞的な事も発生しづらい。集中という意味では1ヶ月まとめてのほうが尚更そのタイミングで集まる上に容量も多いから時間もかかる=落とし終わる前に他のユーザーが重なる可能性が高いので集中という意味では前者の方が効率が悪くなる。
理由としてはどち
解禁の時間に一斉に必要なデータ読みにいかないのかな。イベント中だと切り替わりを待ち構えられそう。事前になんでもない日に配信始めちゃえば、そのタイミングを待ち構えられたりはしなそうに思う。ユーザー数少ないならこんなこと気にする必要はないだろうけど。
そうすると解禁時に「全然落ちて来ねー」って騒ぎになる。でも逐次差分なら当然、事前に解析される事は無いんだけどな。
つっても集中するのはAppStoreやGooglePlayのサーバだからな
データ配ってるのは自社サーバだと思うよ。ストアから配信できるファイルの総容量に制限があってそれがこの手のゲームには小さいので。
・アプリ本体・基本アセット・追加アセットがあり、滅多に更新の発生しない前者2つはストアサーバから配信されますが、追加アセットは自社で用意したAWSやAzure、AkamaiのCDNサーバから配信するケースがほとんどかと。
暗号化して格納しておいて、暗号キーだけ別に配信すればいいと思う。手間かけたくないのはわかるけど。
アプリの審査上、暗号化にも限界あるんじゃなかったっけ?暗号化を複雑にすれば重くなるし
外部データとしてひっぱってくれば審査関係ないでしょ。AES128ごとき、いまどきのCPUには負荷にもならない。
「鍵付き圧縮を展開してるんだろうな」って感じのアプリはあるな。イベントが始まってニューキャラとか増えるタイミングで、通信はしないが長いロードが1回だけ入るやつ。
てっきりそういうのがデフォだと思ってたけど違うんだね逆に驚いた
事前に仕込むのはプランとしてはありでしょう事前に仕込んだソレに十分な保護がかかっていないのは技術の問題
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
サーバントの正体は秘匿するのが聖杯戦争のセオリーだろ (スコア:1)
Re: (スコア:0)
その程度の技術力しかない、というのはサービス開始当初からずっと言われている
Re:サーバントの正体は秘匿するのが聖杯戦争のセオリーだろ (スコア:0)
技術力の話なの?
事前に仕込むのはデータのダウンロードを集中させたくないからじゃないかと思うけど。
Re:サーバントの正体は秘匿するのが聖杯戦争のセオリーだろ (スコア:1)
単純な話、毎日差分だけ更新したら運営の手間もかかるし、ユーザーも毎回ダウンロードの通知が出るしで、大変だからまとめて埋め込みたいわけですな。
が、こうやってデータを抜き出す奴らがいるからそれが出来ないと。なので訴訟なりで黙らせるというのは理にかなっている。
Re: (スコア:0)
分割するほうが集中はしないのでは?
例えば1ヶ月間で10イベントあるとして
一気に10イベント分まとめて仕込んでおくのと
1イベントずつ2~3日に1回ずつ仕込んだデータを配信するの。
一つ10MBとして、まとめてなら100MB一気に落とす必要がある。
後者なら1回は10MBで済む。容量が少ないほど早く落とし終わるから渋滞的な事も発生しづらい。
集中という意味では1ヶ月まとめてのほうが尚更そのタイミングで集まる上に容量も多いから時間もかかる=落とし終わる前に他のユーザーが重なる可能性が高い
ので集中という意味では前者の方が効率が悪くなる。
理由としてはどち
Re: (スコア:0)
解禁の時間に一斉に必要なデータ読みにいかないのかな。
イベント中だと切り替わりを待ち構えられそう。
事前になんでもない日に配信始めちゃえば、そのタイミングを待ち構えられたりはしなそうに思う。
ユーザー数少ないならこんなこと気にする必要はないだろうけど。
Re: (スコア:0)
そうすると解禁時に「全然落ちて来ねー」って騒ぎになる。
でも逐次差分なら当然、事前に解析される事は無いんだけどな。
Re: (スコア:0)
つっても集中するのはAppStoreやGooglePlayのサーバだからな
Re: (スコア:0)
データ配ってるのは自社サーバだと思うよ。
ストアから配信できるファイルの総容量に制限があってそれがこの手のゲームには小さいので。
Re: (スコア:0)
・アプリ本体
・基本アセット
・追加アセット
があり、滅多に更新の発生しない前者2つはストアサーバから配信されますが、追加アセットは自社で用意したAWSやAzure、AkamaiのCDNサーバから配信するケースがほとんどかと。
Re: (スコア:0)
暗号化して格納しておいて、暗号キーだけ別に配信すればいいと思う。
手間かけたくないのはわかるけど。
Re: (スコア:0)
アプリの審査上、暗号化にも限界あるんじゃなかったっけ?
暗号化を複雑にすれば重くなるし
Re: (スコア:0)
外部データとしてひっぱってくれば審査関係ないでしょ。
AES128ごとき、いまどきのCPUには負荷にもならない。
Re: (スコア:0)
「鍵付き圧縮を展開してるんだろうな」って感じのアプリはあるな。
イベントが始まってニューキャラとか増えるタイミングで、通信はしないが長いロードが1回だけ入るやつ。
Re: (スコア:0)
てっきりそういうのがデフォだと思ってたけど違うんだね
逆に驚いた
Re: (スコア:0)
事前に仕込むのはプランとしてはありでしょう
事前に仕込んだソレに十分な保護がかかっていないのは技術の問題