音楽を聞くとき、あなたはDACを使いますか？もしDACを使っているのであれば、DACにいくらぐらいお金を掛けていますか？

音楽を愛している方であれば、DACに数万円掛けているという人も少なくないかと思います。ただその選択に合理性があるか、一度考えて見るべきです。

ほとんどのユーザーにとって、Apple製のDACは十分な性能を持っています。高価なDACを買う必要がある人間は、ほとんどいません。

https://www.apple.com/jp/shop/product/MW2Q3FE/A/usb-c-35-mmヘッドフォンジャックアダプタ

DACは、「デジタル信号をイヤホン・ヘッドフォンで出力できるアナログ信号に変換する」機能を持っています。逆に言えば、それしか機能がないということであり、最近の技術の進歩に伴い安いチップでもそれなりの音質が出力できるようになっています。

安価なDACが99.999%の精度でアナログ信号とデジタル信号を変換できるとき、99.9999%の精度で変換できる高価なDACを買ったとしても、違いは全くわかりません。高価なDACは、その金額のほとんどが装飾やマージンに持っていかれていると考えるべきです。

Apple製のDACは、音楽製品特有の高いマージンが設定されておらず、価格に対して性能の高いチップが搭載されているため、数万円するような高価なDACに匹敵する高価を出せます。

なおこのことは、海外の掲示板サイト「Reddit」でも多く触れられています。

https://www.reddit.com/r/audiophile/comments/em2m4z/the_9_apple_usbc_to_35mm_adapter_performs_on_par/

https://www.reddit.com/r/headphones/comments/ruc1iy/do_i_really_need_a_dac_if_the_apple_dongle_is/

先程述べたように、ほとんどの人にとって高価なDACは無用の長物である訳ですが、高価なDACが正当化できるいくつかのシチュエーションが存在します。

それは、バランス接続に対応する場合です。イヤホンのいくつかはノイズに対し非常にセンシティブであるためバランス接続が必要なケースが存在しますが、安価なDACではほとんどの場合バランス接続に対応していないため、このような場合は高価なDACを使っても、お金の無駄使いであるとは言えないでしょう。

DACにお金を掛けるべきでない理由

BungeeCordは、マインクラフトサーバー間を相互に接続するソフトウェアです。これを使用することで、プレイヤーはサーバーメニューを行き来することなくBungeeCordで接続されたサーバー同士を移動することが出来るのですが、mod入りマインクラフトサーバーの場合は、少々対応するのが大変です。

備忘録として、ここに方法を書き残して置こうと思います。

1. まずは通常通りにBungeeCordをセットアップする。

まず、BungeeCordのセットアップが出来ていない方は、BungeeCordのセットアップを先に行ってください。また、Forgeサーバーを立てる前に、Spigot/Paperを立てて、BungeeCordと接続できるか確認してください。最初にSpigot/Paperをセットアップしておくことによって、後に問題が発生した場合、原因究明が楽になります。

というのも、modが入っている状態だとマインクラフト自体の挙動が変わってしまい、接続できない場合、接続できない原因がmod側にあるのか、それともサーバー側の設定にあるのかはっきりしないからです。この点Spigot/PaperであればBungeeCordへの対応は特にプラグイン等入れずとも設定のみで対応出来ますから、簡単に設定が可能です。

BungeeCordをセットアップする際ですが、注意点として、以下の設定を有効にするようにしてください。

ここまでやって、２つのサーバーを同時に起動すると、デフォルトではlocalhost:25577でサーバーに接続することが出来るようになります（もちろんポート等の設定は自由に変えてOKです）。ここまで出来たら、Forgeサーバーのセットアップへ進む準備が整いました。

2. Forgeサーバーをセットアップする。

さて、次にForgeサーバーのセットアップですが、残念ながら、ForgeはデフォルトではBungeeCordに対応していません。そこで今回は、

https://spongepowered.org/downloads/spongeforge

上のURLから、適切なバージョンのSpongeForgeをダウンロードして、modsディレクトリに入れてください。次にサーバーを起動すると、config/sponge/global.confという設定ファイルが生成されますので、これを弄るだけでBungeeCordへの対応が可能になります。なお、このコンフィグファイルはサーバーをシャットダウンした状態で行ってください。サーバーをシャットダウンした際にコンフィグファイルが適用されている設定で上書きされるため、サーバーを起動した状態でシャットダウンすると加えた変更が全て吹き飛びます。

global.confの、以下の部分を書き換えます。

ファイルを書き換えて、サーバーを再起動したらBungeeCordに繋がるようになっていると思います。これで設定は完了です。

ForgeをBungeeCordと繋げる方法

KZE（Kaede Zombie Escape）でkze-plusというユーティリティmodを作っているのですが、KZEにおける被弾ボーナスの計算式について考える機会があったため、ここに備忘録として書き残して置こうと思います。

1. ゲームデータをひたすら集める

幸運なことにkze-plusには既にゲームデータの記録機能が備わっており、「被弾した回数」及び「被弾した総ダメージ」を記録しています。これを利用して、被弾ボーナスの推定を行うことができます。

今回は、今までのゲームのプレイデータ、344回分を全て使用していきます。

2. 推定被弾ボーナスの式を作る

被弾した回数及び総ダメージから、なるべく近い値を出せないか何回か試行錯誤した結果、

「被弾ボーナス」=「総ダメージ」+「被弾回数」x5

が一番しっくりくる感じでした。

こちらが推定防衛ボーナス（青）と実測値（赤）をグラフで表したものになります（横軸: ダメージ、縦軸: 報酬）。

報酬が小さいときにはそれなりに推定出来ていますが、報酬がでかくなってくると、そもそもの実測値のほうがバラバラになってしまうので推定がズレて来てしまいます。

現状正確な被弾ボーナス計算式に関してはわかっていませんが、実測値がバラバラであることを考えると被弾ボーナスは生存者の防衛ボーナスに依存していると予想できます。

3. 被弾ボーナスが本当に防衛ボーナスに依存するか検証する

もし被弾ボーナスが防衛ボーナスに依存するのであれば、

「被弾ボーナス」=「撃たれた回数」x「武器の防衛ボーナス」x 定数

となるはずです。ここで、横軸にゲームの開催時間、縦軸に「被弾ボーナス」/「撃たれた回数」を取ったグラフを作ってみます。

Python言語を使用してグラフを作ってみたところ、このようになりました。ARやSMGを含む大体の武器の防衛ボーナスは20-40円前後に設定されていますので、恐らく

「被弾ボーナス」=「撃たれた回数」x「武器の防衛ボーナス」* 0.333...

となっていると見て良さそうです。なお外れ値に関しては、２つとも数回のみ撃たれたゲームでした。

{'startedAt': 1691592339453, 'endedAt': 1691592757469, 'ended': True, 'humanWin': False, 'reward': 10638, 'exp': 2027, 'defenseBonus': 10000, 'hitBonus': 

, 'mainWeaponName': 'P90', 'mainHitCount': 281, 'subWeaponName': 'SAA', 'subHitCount': 52, 'shotCount': 

{'startedAt': 1692087199616, 'endedAt': 1692087326123, 'ended': True, 'humanWin': False, 'reward': 10733, 'exp': 2046, 'defenseBonus': 10000, 'hitBonus': 

, 'mainWeaponName': 'P90', 'mainHitCount': 314, 'subWeaponName': 'SAA', 'subHitCount': 0, 'shotCount': 

恐らくSRで撃たれたのではないかなと予想できます。

なお作成したソースコード及び使用したデータについては、以下からダウンロードできます。

ソースコード及びデータ.zip

KZEの被弾ボーナス計算

このブログサイトは、Next.jsを使用して作成しているのですが、デプロイにはVercelではなくSSTを使用しています。SSTを使った感想としては、「セットアップが複雑でめちゃくちゃイライラするけど、カスタマイズ性は抜群」といったところです。では、詳しく説明していきたいと思います。

これはVercelの悪いところだと思うのですが、Vercelは料金プランが

しかありません。ですのでHobbyを超えて使いたいとなると、無料からいきなり月2000円まで跳ね上がってしまいます。

その点SSTであればAWSに直接デプロイしているだけですから、月額固定料金はなく、完全に従量課金制となります。

2. 他のAWSサービスとの連携が楽

SSTを使うと単一のコンフィグファイルでデプロイメントの設定が全て可能になります。しかもSSTの設定ファイルで連携を行うと、デプロイだけではなく自動で環境変数の設定等まで行ってくれるため、コード側で環境変数を手動で追加するといった作業も不要になります。またこのコンフィグファイルではサイトの設定だけではなく、例えば「S3のバケットを作成して、サイトに管理権限を付与する」といったことや「AWS Lambdaを利用して定期的に処理を実行する（cron機能）」といったことが簡単に行なえます。

Next.jsにはcron機能がデフォルトで備わっていないので（ISRはあるのに！）、この機能はかなり役に立ちそうです。当サイトでは、画像アップロード用にS3との連携のみ行っています。

3. コールドスタートを排除できる

AWS上でNext.jsのサイトをホストするとなると、SST以外にもAWS Amplifyを使う方法などがありますが、AWS Amplifyではどうしてもコールドダウンが発生し、ユーザーエクスペリエンスに悪影響を及ぼしてしまいます。これはAmplifyの問題というよりかは、AWS Amplifyを実行しているAWS Lambdaの問題で、大体15分間に一度も呼ばれていない関数はアンロードされてしまうため、次回の関数呼び出しで3秒ぐらいの待ち時間が発生してしまうのです。

ただこのコールドスタート問題も、SSTであれば定期的に関数呼び出しを行うことで関数をウォーム（warm）状態に保ってくれる設定があるため、いくら時間が経過してもコールドスタートが発生しません（いきなり大量にリクエストが来た場合は別です）。

SSTの悪いところは、ほとんどデプロイメントに集約されます。これはAWS自体の複雑さもかなり影響している部分もあって、どうしようもなさそうな雰囲気があるのが残念です。

1. デプロイの設定が面倒くさい

SSTでは、SSTの制作者が作ったseed.runというサービスを使ってデプロイントをすることを推奨しているのですが、正直現段階だとあまり出来が良いとは言えません。

といったところがあります。デバッグのしづらさが辛かったため、最初はseed.runを使っていたところGitHub Actionsに変えたのですが、残念ながら公式サイトにはGitHub Actionsを使った説明がないため、手探りで設定を探していく必要がありました。

SSTがAWS CloudFormationを使っているため、スタックに少しでも変更があるとCloudFormationの更新で果てしなく時間を食います。一回のデプロイで、大体10分はかかると思ったほうが良いです。ですから手動で毎回デプロイすることなんてしていたら、果てしなく時間を浪費することになります。CI/CD必須で、それでもやっぱりデプロイが長いのは辛い。

3. しょうもないところで引っかかるところが多い

Vercelでは動くプロジェクトでも、SSTだと以下のような不具合が発生しました。

3. 1. Next.jsのミドルウェアが動かない

Next.jsではmiddleware.jsをsrc以下に配置することで、全体のページに適用される事前処理を追加することが出来るのですが、なぜかSSTでは正常に動作しませんでした。Open-Nextのissueにも既に上がっており、どうやらNext.jsのバージョンを13.4.12に下げることで改善するようです。

3. 2. Node.Readableを直接express.Responseにpipeできない

Vercelを使っているサイトではReadableのpipeメソッドでexpressのResponseを渡すことで、S3から読み込んだファイルのストリームを直接レスポンスとして返却できていたのですが、なぜかSSTでは正常に動作しませんでした。仕方がないので、一度Readableを全て読み込んでBufferに書き込んだあと、更にそれをexpress.Responseのwriteメソッドを用いて書き込む必要がありました。

2023/12/1追記: SSTが利用しているOpen-Nextに更新があり、実験中のStreamingモードを有効にすると、AWS LambdaのResponse Streaming機能を利用してバイナリデータをBase64エンコーディングせずにそのまま返却するようになりました。このアップデートにより該当のバグは修正されました。

3. 3. Next/Imageにてsrcにドメイン名をつけないと動かない

SSTではCloudFrontを使っているせいか、srcを単に絶対パスで指定しても動作しません。ドメイン名をsrcに含める必要があります。

Vercelを使うとAWSとの連携が面倒で、かつお金がかかりますが、だからといってSSTを使用してもデプロイで果てしなく時間を食わされつらい目に合うことになります。ちゃんとしたウェブアプリを無料でデプロイするには、苦しみが必要だということですね。

Data available, provided by Toshimichi