サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
雑学
castaneai.hatenablog.com
ゲームサーバー上でのマッチメイキングを想定したフレームワーク minimatch を開発した。 開発に至った理由 すでにこの分野ではOpen Matchというオープンな実装があり、活用例も世に出てきている。 そんな中でなぜ今新しく minimatch を作ったのか。 一番大きい理由は Open Matchを使ったローカル開発を考えるに書いた通りだ。 Open Matchはゲームのマッチングを作るための仕組みなので、ゲーム開発者はまずローカル環境で試しながら開発をしたくなる。 では早速と、Getting Startedを読むと いきなりKubernetesクラスターが必要になり、kubectlのコマンドが多数登場し、ゲームのロジックとは無関係のものまで準備しないといけない。 Kubernetesの扱いに慣れているインフラ寄りの開発者であればともかく、普段ゲームを作っている開発者からするとハー
Twitterの仕様変更などの影響でここ最近で分散SNSが再び注目されつつある。 分散SNSの利点は脱・中央集権な点にある、という文脈で語られることも多いが、 オープンな仕様・実装が多いというのもまた利点といえる。 そうしたオープンな分散SNSの仕様として有名なのが ActivityPub だ。 ActivityPub と難しさ オープンな実装はプログラムからのアクセスが容易なことも利点で、 たとえばTwitterは運営元が設定するAPIの制約が厳しく、開発者が気軽に独自のクライアントを開発したりBOTを開発したりするのが今は難しいが、 ActivityPub であればそういった制約はない。 そういう流れで、ActivityPub をベースにBOTアカウント的なものを作ってみたいと思い立った。 単一のユーザーとして投稿を発信するだけ、それくらいならサクッと実装できそうだと考えた。 しかし、
クラウド上でゲームを動かす場合、データ(ゲーム本体のデータ・セーブデータ)をどう管理するかは重要な課題のひとつだ。 そこで、自分が開発に携わっているOOParts のデータ管理を支える技術について紹介する。 ノベルゲームのセーブ事情 OOPartsで提供されているのは主にビジュアルノベルゲームで、セーブデータの形式や場所は実に多種多様である。 ゲーム本体と同じディレクトリにセーブデータを保存するゲームもあれば、ユーザーディレクトリ(マイドキュメント等)以下に保存するゲームもある。 とにかく様々な保存方式があるため複数メーカーのゲームを提供するとなると セーブデータの場所を機械的に特定できない。 唯一言えるのはほとんどのゲームはセーブデータをファイルに保存しているということぐらいだ。 ゲームタイトル毎に設定を持ち、「ゲームAのセーブデータは〇〇で、ゲームBのセーブデータは〇〇で…」とすれば不
オンラインゲーム開発などで独自プロトコルのデータを読み書きするTCPサーバーを作ることが時々あるが、 Rustのtokio を使うとそのようなTCPサーバーがとても簡潔に記述できる。 独自プロトコルといっても様々だが、TCPのようなストリーム指向の経路の場合ある程度のバイト配列のかたまりをひとつのフレームとして解釈することが多い。よってストリーム内で個々のフレームを区切る必要がある。 よく使われるやり方だとたとえば次の2つがある。 各フレームの先頭に長さの情報を付ける 特定の値を区切り文字とする 今回は1番目の「各フレームの先頭に長さの情報を付ける」パターンを例に考える。 たとえば先頭4バイトに長さがあり、その後にその長さ分のデータが入っているというプロトコルだとする。 +---- len: u32 ----+---- data ----+ | \x00\x00\x00\x05 | hel
Textractorというノベルゲームのテキストをリアルタイムに抽出するツールがある。 https://github.com/Artikash/Textractor このツールは起動中のノベルゲーム内のテキストをリアルタイムに抽出し、翻訳の結果も一緒に出してくれる。 海外のノベルゲームファンが日本語のノベルゲームをプレイするために開発されたものと思われるが、ソースコードがGPLv3ライセンスで公開されており使っている技術が面白かったので紹介したい。 https://github.com/Artikash/Textractor/blob/master/README.md の画像を引用 Textractorはテキスト抽出をどのように実現しているのか? OCR技術で画面上のテキストを認識していると思ってしまいそうだが、実際は違う。 起動中のノベルゲームのプロセスに潜り込み、テキストが渡される関数
ソケット通信は双方向で遠隔という複雑な条件下のためさまざまなエラーが発生する。 Goでソケット通信を書いていて、言語の力のおかげで記述は楽になっているが、下層で同じOSの機能を使っている以上エラーは避けられない。 そもそも、どんなときにどんなエラーが起こりうるのか、特にGoの net パッケージではどのようにエラーを扱っているのか、今まであまり考えずに正常系のみを実装していたので これはよくないなって思って調べた。 ソケット通信の基本 read と write TCPにおけるソケット通信は基本 read と write である。名前の通り、読み・書きを表す。 ソケット通信でエラーが起きるのは、この read/write の処理の中が多い。 net.OpError によるラップ Goでソケット通信中に起こるエラーはほぼすべて net.OpError 構造体でラップされる。 ただし io.EO
年の瀬になったので、あらためて今年学んだ技術を振り返っていく。 クラウドゲーミングの開発 2021年はほぼ全てOOPartsのクラウドゲーミング (Black Game Streaming Engine v2 )の開発に費やした。 経緯は id:oliver0521 によるCEDECの発表の通りで、Windows Serverのコストが高すぎるのでなんとか改善できないだろうかという話からだった。 迫り来る絶望的状況からの脱却物語 / #CEDEC2021 - Speaker Deck Windows Serverを捨ててLinux + Wineでやれたら素晴らしいなぁという発想は2019年からあったが、Wineでどれくらいゲームが動くのかも未知数なので踏み切れずにいた。また、Windows Server時代に使っていた映像配信のSaaSがLinuxに対応してなかったため、もしLinuxでや
AyameというWebRTC Signaling Serverの実装がある。 Web側のSDKとサーバー側の実装が両方公開されており、プロトコルの仕様も文章化されている。 GitHub - OpenAyame/ayame-web-sdk: Ayame Web SDK GitHub - OpenAyame/ayame: WebRTC Signaling Server Ayame GitHub - OpenAyame/ayame-spec: WebRTC Signaling Server Ayame Spec そして今回、Ayame互換のプロトコルを持つWebRTC Signaling Server "ayu" を開発した。 github.com 動機 Ayameはサーバー側も含めてオープンな実装があるのになぜ新しく互換サーバーを作ったのか。 大きく分けて2つの理由がある。 ステートレス カス
あるとき、ネット上でこんな事件の噂を発見した。 『みずいろ』 HDDフォーマット 事件 エロゲー業界を彩る悲惨な事件は数多あれど、威力と内容を考えて4番を張れるものといえば、やはりこれだろう。2001年、ねこねこそふとから発売された『みずいろ』初回ロット版に限り、アンインストールするとHDDの他のデータを巻き込んで吹っ飛ばす、という恐るべき不具合が発生していた。実はこの件、「インストールしたフォルダをまるごと消す」(当時は、自動で「mizuiroフォルダ」などを作らなかったので、たとえばProgram Fileフォルダに直接インストールしてしまうと、アンインストール時にProgram Filesフォルダそのものを削除していた)というものと、「インストールしたフォルダ外のデータを消すことがある」という話が出ていて、不具合な正確なところは私も把握していないのだが、とりあえずヤバいバグということ
TVTest というソフトがあって、PT3などのチューナーがあればすぐにTVを視聴できる。しかし、TVTest は Windows 専用である。 ということで、Mac で楽に見る方法はないだろうかと探した…けどなかったので作った。 Mac OS用のアプリを作ったのは初めてで、Swift も一切書いたことがなかったので結構たいへんだった。でも楽しかった。 github.com アプリの仕組み Meruru は起動したら、Mirakurun に接続して、Mirakurun が提供する HTTP API を使って番組切り替えと映像表示をしている。 といっても、普通 Mac にPT3などのチューナーは直接させないので、LAN内に別のマシン(Windows や Linux)を用意してそこで Mirakurun を動かす必要がある。 ▼自分はこのような構成でやった Mirakurun すごい Mira
.NET Core 3.0にgRPCのサポートが追加された。 元々gRPCのC#対応はされていたはず、何が違うのか?答えはgRPC公式のブログに書いてあった。 https://grpc.io/blog/grpc-on-dotnetcore/ Unlike the existing C-Core based implementation (Grpc.Core), the new libraries (grpc-dotnet) make use of the existing networking primitives in the .NET Core Base Class Libraries (BCL). The diagram below highlights the difference between the existing Grpc.Core library and the new
Step 1. コードの書き方を学ぶ コードレビューする際に気をつけるポイントをまとめた CodeReview Comments。 他の言語とは違っている Go 特有の事例をたくさん載せてくれている。 原文は英語だけど、日本語訳もある。 golang/go CodeReviewComments 日本語翻訳 · GitHub Go らしいコードの書き方を知りたいなら、Go 公式のコードを読むのが一番良い。オープンソースなのは良いこと。 GitHub - golang/go: The Go programming language Step 2. Go らしい API 設計について学ぶ エラー処理は、他の言語とは異なっていて、Go特有の考え方が多い。よってちゃんと学んでおかないとエラーが起きたときに適切に handling できておらず、苦しむことになる。 Golangのエラー処理とpkg/e
explorer.exe のCPU使用率がずっと25%ぐらいになって困った。しかし「とりあえずクリーンインストール」という考え方だと再発したときに対処できないので、原因が知りたい Linuxでは perf コマンドというものがあり、どのような関数が多くCPUを使っているのか ランキング形式で見ることができる。 出典元 : Using Performance Counters for Linux – Anton's Blog これに似たようなことをWindowsでもできれば、と思って情報を集めた。 結果、2つのツールが使えることがわかった。 名前 役割 Windows Performance Recorder 一定期間のパフォーマンス情報を記録するツール Windows Performance Analyzer Recorderで記録したファイルの中身を見るツール これらのツールは Wind
最近のプログラミング言語はたいていパッケージマネージャーがある。 よくある実装だと、vendor/ や node_modules/ といったディレクトリに必要なライブラリが全部入る。 しかし、この方式はDockerで開発する際に問題がある。 この記事では、実例のひとつして Node.js とそのパッケージマネージャ npm で解説する。 volume mount によって空になる問題 node.js - Docker-compose: node_modules not present in a volume after npm install succeeds - Stack Overflow docker image ビルド時に npm install する image の中に node_modules/ が作られてライブラリもインストールされる ここまでが docker build。そ
プログラミング言語には文法が正しいかどうか、悪い書き方をしていないかどうかといったことをチェックして指摘してくれるツール(通称 linter)がたくさんある。 機械的にチェックできるようなことは、人にチェックしてもらう前に直しておく。そうすることでレビューのやり取りコストが減るし、後々保守したりするとき幸せになれる。 では、プログラミング言語に限らず「普通の文章」つまり日本語をチェックしてくれるツールもある。そのツールをいくつか調査してみた。 RedPen http://redpen.cc/ 校正作業ツールとして最も有名?な感じ。 具体的にどのような指摘をしてくれるかは、次の記事などを読むとわかりやすい。 文書執筆の指南書で解説されている問題点を RedPen で発見する - Qiita textlint textlintで日本語の文章をチェックする | Web Scratch 比較的最近
C#で他のウィンドウのクライアント領域内部のスクリーンショットを撮ろうとした。 .NET Frameworkは多くのクラスライブラリが揃っているから簡単にできるだろう! とGoogleで探すこと数十分・・ 無いっ・・!!!圧倒的無いっ・・!!! Win32APIの呼び出しが必要 .NET Frameworkでは自身以外の他のウィンドウを制御する機能はあまりないようで、 どうしてもP/InvokeでWin32APIを叩く必要があるみたい。 できるだけこれは避けたかったのだが、他に方法が見つかりそうにないので仕方ない・・ (C#でWin32APIを今まで一度も使ったことがなかったのですごくためらった・・) 必要なWin32API関数 ■ClientToScreen(IntPtr hwnd, out POINT lpPoint); クライアント座標をスクリーン座標に変換する hwnd : クライ
このページを最初にブックマークしてみませんか?
『castaneaiのブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く