async/awaitの鬼門の一つとして、適切なキャンセル処理が挙げられます。別に基本的にはそんな難しいことではなく、CancellationTokenSourceを作る、CanellationTokenを渡す、OperationCanceledExceptionをハンドリングする。というだけの話です。けれど、Tokenに手動でコールバックをRegisterしたときとか、渡す口が空いてないものに無理やりなんとかするときとか、タイムアウトに使った場合の始末とか、ちょっと気の利いた処理をしたいような場面もあり、そうした時にどうすれば良いのか悩むこともあります。 こういうのはパターンと対応さえ覚えてしまえばいい話でもあるので、今回はAlterNatsの実装時に直面したパターンから、「外部キャンセル・タイムアウト・大元のDispose」が複合された状況での処理の記述方法と、適切な例外処理、そして最
C#大統一理論 - Qiita
C#大統一理論とは CySharpのneueccさんが提唱している理論で、ザックリ言えば サーバーサイドもクライアントサイドもC#で完結できるとよくね？ という理論です。 そして現状サーバーサイドとクライアントサイドの両方で使える言語はC#を除くとJavaScriptくらいだと思います（なんかあったら教えてください） C#でクライアントサイドを作るにはXamarinやゲームエンジンのUnityが筆頭になります。 C#のよさ いろいろありますが、個人的に上げるなら 比較的言語が若く（C++と比較して）、LINQなどモダンな文法仕様が遂次追加されている（というかLINQは単独で良い）。 単純に.NET Coreがクラスプラットフォームで安定して動作する。マイクロソフトが本気を出してるからサーバーサイド、クライアントサイドから機械学習まで使える範囲がめちゃくちゃ広い。 decimalみたいな型ま
CEDEC 2023
はじめに 現在進行形でC#のみを使って個人でソシャゲ作りを試しているyoship1639です。 本記事はQiita夏祭り2020「〇〇（言語）のみを使って、今△△（アプリ）を作るとしたら」のテーマに沿った内容となっています。 近年のソーシャルゲーム界隈は多様化が進んでクライアントサイドだけではなくサーバーサイドもあらゆる言語やフレームワークが試みられていますが、クライアントもサーバーも統一の言語で構成されているのはほとんどないかと思われます。言語にはその言語の得意分野があると思うので。 しかし、今まさに私が開発中の環境が好きな言語で開発しやすいという理由でクライアントもサーバーもC#で構成した作りになっているので、どのような構成でどうすれば最低限のソシャゲの基盤が作れるかを、解説が長くなり過ぎないようにまとめることが出来ればと思います。 三部構成で、クライアント実装、サーバー実装、AWS
【Unite Tokyo 2019】今すぐ現場で覚えておきたい最適化技法 ~「ゲシュタルト・オーディン」開発における最適化事例~
今回の記事はC#における構造体(struct)について。 複合的なデータを扱う際、多くの場面ではクラス(class)が用いられるかと思います。しかし、パフォーマンスが重要な場面や、GCによる影響が大きいUnityなどでは、状況に応じてクラスではなく構造体を使用した方が良いこともあります。 近年はC#においてもパフォーマンスが重視されるようになり、構造体が用いられる機会も多くなっています。またUnityのDOTSにおいても、C# Job SystemやBurst Compilerに最適化されたコードを書くために構造体を多用することになります。 ここでは構造体に関する基礎的な知識から、クラスと構造体のメモリ管理について、そして実際に構造体を用いる際の注意や活用方法についても解説していきたいと思います。 ただ今回の記事、調子に乗って色々な内容を詰め込んだ結果、めちゃくちゃに長くなってます。そのた
C# Advent Calendar 2021の参加記事となっています。去年は2個エントリーしたあげく、1個すっぽかした（！）という有様だったので、今年は反省してちゃんと書きます。 スクレイピングに関しては10年前にC#でスクレイピング:HTMLパース(Linq to Html)のためのSGMLReader利用法という記事でSGMLReaderを使ったやり方を紹介していたのですが、10年前ですよ、10年前！さすがにもう古臭くて、現在ではもっとずっと効率的に簡単にできるようになってます。 今回メインで使うのはAngleSharpというライブラリです。AngleSharp自体は2015年ぐらいからもう既に定番ライブラリとして、日本でも紹介記事が幾つかあります。が、いまいち踏み込んで書かれているものがない気がするので、今回はもう少しがっつりと紹介していきたいと思っています。それと直近Visual
C# Advent Calendar 2019用の記事となります。C# Advent Calendar 2019はその2もあって、そちらも埋まってるので大変めでたい。 さて、今回のテーマはT4で、この場合にやりたいのはソースコードジェネレートです。つまるところC#でC#を作る、ということをやりたい！そのためのツールがテンプレートエンジンです。.NETにおいてメジャーなテンプレートエンジンといえばRazorなわけですが、アレはASP.NET MVCのHTML用のViewのためのテンプレートエンジンなため、文法が全くソースコード生成に向いていません、完全にHTML特化なのです。また、利用のためのパイプラインもソースコード生成に全く向いていない（無理やりなんとか使おうとするRazorEngineといったプロジェクトもありますが……)ので、やめておいたほうが無難です。 では何を使えばいいのか、の答
去年に専門学校の学生さん向けに講演した資料で、それ以外には未発表のスライドです。デベロッパーのキャリアとしてのエモい話になっているのでデブサミ向けにいいかな、と思って公募したところ落ちた！（←微妙にショックだった）のでずっとお蔵入りで眠っていたのですが、このご時世ですし他で講演できるところもなさそうなので、ここで放出することにしました。 作ることが能力の向上に繋がり、キャリアにも繋がっていく。別にそれだけが唯一解ではないけれど、一つの道筋として力になれたらな、と思っています。 大量に作るというのは、いや、大量ではなくても、メンテナンスが回るわけじゃないから大変だったり、時に無責任に見えてしまう（そういうわけではないけれど大変なのです！ごめんなさい！）とか、Issueに埋もれてシンドイとか、そういう負の側面も色々あるのですけれど、それでもね、やっていくのはいいことだと思います。そしてやるから
他言語がメインの場合のRustの活用法 - csbindgenによるC# x Rust FFI実践事例
Rust.Tokyo 2023 https://rust.tokyo/2023/
C#使う人って全然外部プロセス呼び出して処理ってしないよね。というのは、Windowsがなんかそういうのを避ける雰囲気だから、というのもあるのですが、ともあれ実際、可能な限り避けるどころか絶対避ける、ぐらいの勢いがあります。ライブラリになってないと嫌だ、断固拒否、みたいな。しかし最近はLinuxでもばっちし動くのでそういう傾向もどうかなー、と思いつつ。 避けるというのはOSの違いというのもありそうですが、もう一つはそもそも外部プロセスの呼び出しが死ぬほど面倒くさい。ProcessとProcessStartInfoを使ってどうこうするのですが、異常に面倒くさい。理想的にはシェルで書くように一行でコマンドと引数繋げたstringを投げておしまい、と行きたいのですが、全然そうなってない。呼び出すだけでも面倒くさいうぇに、StdOutのリダイレクトとかをやると更に面倒くさい。非同期でStdOutを
次世代Rx「R3」解説 - Qiita
今回の内容 C#向けの新しいReactiveExtensions（Rx）ライブラリ「R3」について、従来のRxとの変更点を紹介します。 R3について リポジトリ R3 開発元はUniTaskやMagicOnionなどを公開しているCysharp社であり、メインの開発者はUniRxの作者でもあるneuecc氏です。 どんなライブラリか 「R3」はReactiveExtensions（Rx）を現代に合わせてより洗練した形に再定義/再実装した、C#用のライブラリです。 というのも、Rxは10年以上前に登場した概念であり、当時はまだ非同期処理に対するベストプラクティスが模索されていたタイミングでした。 そのためRxは「LINQをEventにも適用できる」という側面も持ちつつ「非同期処理にも用いることができる」という2つの側面をもった、少しややこしいライブラリとして登場しました。 そして2024年現
キューブ・ソフトは GitHub Sponsors 等によるスポンサー活動を開始しました - Cube Lilac
はじめに 今後の予定 活動実績 第8期 (2023-12-01) 第7期 (2023-06-07) 第6期 (2023-05-19) 第5期 (2023-01-11) 第4期 (2022-08-10) 第3期 (2022-03-29) 第2期 (2021-12-22) 第1期 (2021-09-08) この度、株式会社キューブ・ソフト (CubeSoft, Inc.) は GitHub Sponsors および Open Collective を利用して、企業として Open Source Software (OSS) やその他の有用な活動を行っている開発者のスポンサーになる取り組みを開始しました。現在、弊社がスポンサーになっている開発者の詳細は GitHub Sponsors 等の活動実績 を参照下さい。 はじめに GitHub Sponsors や Open Collective を通
この記事では、Unityを使って1人で開発したツールアプリ『リモートダイス3D』で対応したことや、使ったアセット・ライブラリなどをひたすら列挙していきます。 このアプリ特有の話はあまり出てこないので、ダイス系のアプリを触ったことがない方（が圧倒的に多いですよね）でも参考になるでしょう。いろいろな技術要素が含まれています。 「そんなアセット・ライブラリもあるんだ」「それは自分のアプリでも対応してみようかな」と知見を広げるきっかけになれば幸いです。 僕には売れるアプリの作り方は分かりませんがプロダクトを完成させる知識と技術だけはありますので、技術面を中心とした内容になっています。 各項目は詳しく説明しているものもあれば物足りない感じに留めているものも多いので「このあたりもうちょっと詳しく知りたい」というものがあればTwitterでシェアして頂くか、はてブのコメントを付けてもらえれば詳細記事が出
以前にMicroBatchFramework - クラウドネイティブ時代のC#バッチフレームワークという名前でリリースしていたライブラリですが、リブランディング、ということかでConsoleAppFrameworkに変更しました。それに伴い名前変更による多数の破壊的変更と、全体の挙動の調整を行っています。 github/ConsoleAppFramework 当初の想定ではバッチ、特に機能紹介にあるMulti Batchをメイン機能と捉えて作っていたのですが、最終的には汎用的なコンソールアプリケーション用のフレームワークとして出来上がっていたので、より適正な名前にすることで、多くの人に正しく捉えてもらって、届けられるのではないかと思い、今回の変更に至りました。 といったように、 Microsoft.Extensions の仕組みに乗ってLogging, Configuration, DIな
MemoryPackという、C#に特化することで従来のシリアライザーとは比較にならないほどのパフォーマンスを発揮する新しいシリアライザーを新しく開発しました。 高速なバイナリシリアライザーである MessagePack for C# と比較しても、通常のオブジェクトでも数倍、データが最適な場合は50~100倍ほどのパフォーマンスにもなります。System.Text.Jsonとでは全く比較になりません。当初は .NET 7 限定としてリリースしましたが、現在は .NET Standard 2.1(.NET 5, 6)やUnity、そしてTypeScriptにも対応しています。 シリアライザーのパフォーマンスは「データフォーマットの仕様」と「各言語における実装」の両輪で成り立っています。例えば、一般的にはバイナリフォーマットのほうがテキストフォーマット（JSONとか）よりも有利ですが、バイナリ
というのを、この数日をかけて勢いで作りました。ずーーっと昔から「enum は遅い」と言われ続けていたので何か手を入れたいと思っていたのですが、突然やる気になりました。久々にプライベートのコーディング意欲が爆上げしたー。勢いが強過ぎて毎日寝不足のまま明け方までのコーディングを繰り返し、しかも家庭を顧みませんでした...(超ﾖｸﾅｲ どのくらい速いかというと、.NET Core 3.0 よりも何倍も速いです。もう狂ったくらい速い。全てのメソッドがゼロ・アロケーションです。プログラミングする上で enum はかなり使うので、多少なり性能改善に寄与できるのではないかと思います。ぜひ使ってみた感想をいただければなーと思います :) 簡単に使い方解説 .NET 標準の System.Enum に近い使い方ができるように API を設計しています。以下のような感じで、とてもシンプル！ //--- Fas
ネイティブコードとC#を透過的に接続するために、RustのFFIからC#のDllImportコードを自動生成するライブラリを作成し、公開しました。Cysharp初のRustライブラリです！先週にプレビューを出していましたが、しっかりした機能強化とReadMeの充実をして正式公開、です！ Cysharp/csbindgen crates.io/crates/csbindgen めちゃくちゃスムーズにネイティブコードがC#から呼べるようになります。すごい簡単に。超便利。こりゃもうばんばんネイティブコード書きたくなりますね……！ただし書くコードはRustのみ対応です。いや、別にRustでいいでしょ、Rustはいいぞ……！ しかしまず前提として言っておくと、ネイティブコードは別に偉くもなければ、必ず速いというわけでもないので、極力書くのはやめましょう。C#で書くべき、です。高速なコードが欲しければ
拙作の Unity用DIライブラリ、VContainer の v0.9.0 では、ILコードをコンパイル時に生成することによるメタプログラミングの高速化が足されました。 Unity用DIライブラリ VContainer の 0.9.0 を撒きました。 コンパイル時IL生成による高速化機能をマージしました。(オプション) IL生成でさらに 当社比 3-6倍くらいは速くなりました。これできっと Unity用 DIコンテナでは完全に最速になったんじゃないかな-と思います。https://t.co/YkHXXgP7nD pic.twitter.com/NFUxvLVzKd— ハダシA (@hadashiA) 2020年7月26日 この機能をつかうと、Zenjectのデフォルトとの比較でディタ上では50倍くらい、IL2CPPでは20倍〜くらい速い結果になっています。 また、グラフのとおり VCont
MVVM をリアクティブプログラミングで快適に ReactiveProperty オーバービュー 2020 年版 前編 - Qiita
前に書いた記事が 2015 年のものだったので 2020 年用に書き直していこうと思います。ReactiveProperty 7.1.0 を想定して書いています。また、WPF か UWP か Xamarin.Forms での MVVM 開発の基本的な知識と Reactive Extensions の基本的な知識があることを前提に記載しています。 5 年前に書いた記事 → MVVMをリアクティブプログラミングで快適にReactivePropertyオーバービュー 他の記事はこちらです。 MVVM をリアクティブプログラミングで快適に ReactiveProperty オーバービュー 2020 年版 前編 (この記事) MVVM をリアクティブプログラミングで快適に ReactiveProperty オーバービュー 2020 年版 中編 MVVM をリアクティブプログラミングで快適に Reac
ValueObjectは好きですか？私は大嫌いです。いじょ。 ざっくり言えばプリミティブ型に専用の型を付ける教義です。例えばUserIdをintとして扱っているとTeamIdと取り違えるかもしれないし、Hpに突っ込んでしまうかもしれない。StrengthとIntelligenceとAgilityとSpeedは別物なのだから全部intじゃなくて区別して欲しい、そうじゃないと間違った演算しちゃうぞ、と。まぁそういう自体を避けるために、それぞれラップした個別型を作るのです。int strengthじゃなくてStrength strengthだぞ、と。 これは一見正しく実際正しいのですが、問題もあります。一つに面倒くさい。ラップしたctorを作るのだけでも定形でウザ、と思いますが、更に等値とか実装するのは面倒くさい。また、そのままだと計算できなくなるので、算術演算のために生の値を.Valueで取り
このブログでもSource GeneratorやAnalyzerの開発手法に関しては定期的に触れてきていて、新しめだと 2020/12/15 - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips 2021/05/07 - 2021年のC# Roslyn Analyzerの開発手法、或いはUnityでの利用法 という記事を出していますが、今回 MemoryPack の実装で比較的大規模にSource Generatorを使ってみたことで、より実践的なノウハウが手に入りました。また、開発環境も年々良くなっていることや、Unityのサポート状況も強化されているので、状況を一通りまとめてみようと思いました。Source Generatorは非常に強力で、今後必須の開発技法になるので
と、いうものをリリースしました。Web UIとなるDFrame.Controllerと、負荷テストシナリオをC#で書くDFrame.Workerの組み合わせで成り立っていて、DFrame.Workerをウェブ上のクラスターに配置することで(Controllerと接続するただの常駐アプリなので、配置先はオンプレでもVMでもコンテナでもKuberenetesでもなんでもいい)、1から数千のワーカーが連動して、大量のリクエストを発生させます。また、テストシナリオをプレーンなC#で記述できるということは、HTTP/1だけではなく、あらゆる種類の通信をカバーできます。WebSocket、HTTP/2、gRPC、MagicOnion、あるいはPhotonや自作のTCPトランスポート、更にはRedisやデータベースなどが対象になります。 DFrame.Workerは通常の.NETの他に、Unityにも対
C#パフォーマンス勉強会 https://cs-reading.connpass.com/event/309714/
MessagePack for C#のVersion 2を本日リリースしました。出る出る詐欺で、一年がかりでリリースまで漕ぎ着けました！とにかくめっちゃ時間かかった、死ぬほど私のリソースが取られていた、ので本当にリリースまで持ってこれてよかった……。めでたし。 今回はとてもOSSっぽく開発していて、メインの開発はMicrosoftのVisual StudioチームのPrincipal Software EngineerであるAndrew Arnottさんが書いています。私はそれに対してひたすら、APIデザインが好きじゃないだの、パフォーマンスが私の基準に満たしてないだの、文句つけまくる仕事をしていました。しかしコードのクオリティはさすがに非常に高くて、私だけだったらここには至れなかっただろうことを考えると、いい感じの共同開発ができたんじゃないかなあと思います。その結果として、一年前に掲示さ
「Unlimited Expansion」をテーマに、多角的に事業展開してきたからこそ見えた"選択肢"を伝えるDeNA TechCon 2022。ここで、ゲーム事業本部の崎氏が登壇。まずは、本セッションの前提となるゲームの内容と、ゲームデザインに合わせたネットワーク構成・同期方式・言語について紹介します。 セッションの概要と自己紹介 﨑健悟氏（以下、﨑）：それでは「Unityによるマルチプレイヤーアクションのための別解C#統一理論」ということで、セッションを始めます。 はじめにセッションの概要です。本セッションでは、最初にネットワークゲームシステムの構成について、さまざまな選択肢やその選び方の話をします。続いて、協力型MO（Multiplayer Online）アクションを実現するために採用した、よりタイトル固有の技術についてお話ししたいと思います。 得られる知見としては、Unityでネッ
Game Developers Meeting Vol.61 GDM × Born Digital
.NET 5も控えていることだし、というのは関係ないのですが、CLIアプリケーションや大量のバッチをC#で簡単に作れるフレームワークであるところのConsoleAppFrameworkを思い立って更新しました。 github - Cysharp/ConsoleAppFramework 基本的な構成である、Generic Hostの上に乗っかるCLIフレームワークというコンセプトには変更ありません。 メソッド定義がそのままコマンドライン引数になって、ヘルプなども自動生成してくれます。Host(ASP.NET Coreなどでも使う)の設定によってロガーやDIの設定、オプションの読み込みとバインディングも可能なので、細かいコンフィグレーションもそれで行えますし、基盤が一緒なためASP.NET Coreなどとの共通化なども可能になります。 一番単純な例を出すとこんな感じになります。 public
UniTask v2も2.0.30まで到達し、いい加減そろそろ安定したと言える頃合いです（ほんと！）。GitHub Star数も1000を超えて、準スタンダードとして安心して使ってもらえるレベルまで到達したと思うので、基盤部分から入れ込んで設計するとこんなことができますよ、という一例を出してみます。 UnityWebRequestはかなりプリミティブな代物で、そのまま使うよりかはある程度はアプリケーションに沿ったラッパーを被せることがほとんどなのではないかと思います。しかし、ライブラリ単体でアプリケーションの要求を全て満たそうとするとヘヴィになりすぎたり、というかそもそもアプリケーション固有の要求には絶対に答えられない。というわけで、理想的なラッパーというのは、それ自身が極力軽量で、拡張性を持たせたプラガブルな仕組みが用意されているものということになります。プラガブルな拡張性がないと、例え
ValueTaskSupplementというライブラリを新しく作って公開しました！ Cysharp/ValueTaskSupplement これは、ValueTaskにWhenAny, WhenAll, Lazyを追加するという代物で、それだけだとヘーそーなんだー、としか思えないと思われます。しかし、ValueTaskを使っていくと、めっちゃくちゃ欲しくなる機能になってます。ないと死ぬレベルで。 と、いうわけで、なんでこれが必要なのか、っていうところから説明します。 C# 5.0にasync/awaitが導入された当初はTaskしか存在しませんでした。標準APIのあらゆるメソッドにasyncメソッドを生やすなど、Microsoftの多大な努力により、C#はいち早く非同期時代を迎え、async/awaitは多用（濫用とも言う）されるようになりました。しかし、多用された結果、当初思ってたよりも
今年はどういう年だったかというと、うーん、まともに会社として動き出した年、ですかね。去年Cysharpという会社を作りましたが、その時点では一人だったので会社感も全く何もなかったのですが、今年から何人か入ってきたので、やっと会社として体をなしてきました。 ブログの本数があからさまに減ってますが、Cygames Engineers' Blogに書いている分もあるのでそこはしょーがない。今年は講演も結構した気がします。CEDECやUniteなど大きなイベントでも話してきましたし、特にUniteのUnderstanding C# Struct All Thingsは好評だったようで、アンケート結果でも実質一位(正しくは4位、1~3位はUnity Technologies Japanの人だったので、それを除いたらという謎基準により）だったので、嬉しみがあります。 ライブラリは、なんか一年中ずっとM
タイトルはここぞとばかりに全盛りにしてみました！今回NATSの.NETクライアント実装としてAlterNatsというライブラリを新しく作成し、公開しました。 github - Cysharp/AlterNats 公式の既存クライアントの3倍以上、StackExchange.RedisのPubSubと比較して5倍以上高速であり、通常のPubSubメソッドは全てゼロアロケーションです。 そもそもNATSとはなんぞやか、というと、クラウドネイティブなPubSubのミドルウェアです。Cloud Native Computing Foundationのincubating projectなので、それなりの知名度と実績はあります。 PubSubというと、特にC#だとRedisのPubSub機能で行うのが、StackExchange.Redisという実績あるライブラリもあるし、AWSやAzure、GCP
本記事は MagicOnion v2 の環境構築の方法を紹介しています。 MagicOnion v3 の環境構築については以下の別記事で書き直しています。 Unity + .NET Core + MagicOnion v3 環境構築ハンズオン 更新履歴（2019/10/19） MagicOnion v2.6.3 が公開されました。 それに合わせて gRPC のパッケージへのリンクの修正や、スクリーンショットの更新を行いました。 動作確認は下記の環境で行っています。 - Windows 10 - Unity 2019.1.14f1 - Visual Studio 2019 v16.3.5 - MagicOnion 2.6.3 はじめに MagicOnion は一度環境を構築してしまえば、触り心地が良くてとても使いやすいフレームワークだと思います。 しかし初期構築がやや複雑で、特に Unity
あまりシェルスクリプトを書かない私なのですが（小物でもなんでも書き捨てC#で書くスタイル）、CI だの .NET Core だのなんなので、全く書かないというわけにもいかない昨今です。まぁしかしcmdは嫌だし今更(？)PowerShellもなぁという感じもあり、bashねぇ、とかブツブツ言いながらしょっぱいスクリプトを書く羽目になるわけです。 そこに颯爽と現れたのが google/zx。素敵そうだなーと思いつつJavaScriptを日常的に書くわけでもないのでスルーしてたのですが、こないだもちょっと複雑なシェルスクリプトをJavaScriptで書くで紹介されていて、なるほど色物じゃなくて便利なのか、そうだよね便利だよね！と思い、私は日常的にC#を書くので、C#だったら便利だな、同じ感じで書けるなら、と、思い至ったのでした。 というかまぁzx見て思ったのが、これぐらいの内部DSL、C#でもい
VContainer v0.0.1 - Unity用の速くて軽いDIライブラリをリリースしました - @hadashiA
github.com Unity (ゲームエンジン) で動作する自作DIライブラリを公開しました。 特徴は、 速くて薄くて軽い GCゴミがとても少ない コードファーストでスコープを切れる機能 (Autofac の影響) MonoBehaviourに依存しないカスタムクラスをUnityのライフサイクルに割り込ませる (Zenjectの影響甚大) 独自の PlayerLoopSystem のサブシステムを利用しているので、不特定タイミングでつくったスコープの IInitializable とかも動作する。 コンテナがイミュータブル なのです。 Zenject と比較すると、メソッドチェインをつなげるとなんでも宣言できる(Fluent API) は最低限に、使い方の迷いようがなく透明度の高いAPI を心掛けています。 APIの比較表をつくりました Scopeの親子関係はある程度(ていうかかなり)
Cygamesから4/1にリリースされたプリコネ！グランドマスターズのサーバーサイドとインフラ開発をCysharpが開発協力しました。リアルタイム通信を含むオートバトラー系のゲームです。 Cysharpはサーバー側のアーキテクチャ設計と基盤実装、クラウドインフラ構築、一部サーバーロジック実装を担いました。リアルタイム通信部分だけではなくてAPIサーバーからマッチメイキング、インフラまで、構成されるあらゆる要素がC#で作られています！ クライアント (Unity) API サーバー(MagicOnion) バトルエンジンサーバー (リアルタイム通信; MagicOnion, LogicLooper) マッチメイキングサーバー (リアルタイム通信; MagicOnion) バッチ(ConsoleAppFramework) デバッグ機能サーバー (Web; Blazor) 管理画面サーバー (W
TL;DRSlideshareの仕様変更で、Scribd会員ではない方が、資料の閲覧やDLできる数に上限ができたのですが、それを回避する方法です。 いつの間にかSlideshareが有料化されていた私もSlideshareで過去にコミュニティで登壇したときのプレゼン資料を公開しているのですが、 https://www.slideshare.net/KosukeEnomoto いつの間にかSlideshareのサービスが有料化されて、無料の会員や非会員の方が公開されている資料の閲覧だったりDLできる数に上限が設けられることになったそうです。 Slideshareサイレント実質有料化されてしまったので（月々閲覧数制限が投下されてる）、資料のアップロード先にSlideshare使うのは禁止令。特に企業はSlideshareにあげてはいけない！見れないし！ pic.twitter.com/U4YH
以前にCircleCIでUnityをテスト/ビルドする、或いは.unitypackageを作るまで、それとCIや実機でUnityのユニットテストを実行してSlackに通知するなどするという記事を書いたのですが、時代はGitHub Actionsということで、私も全体的にCircleCIからGitHub Actionsに移行を始めてまして、それに伴ってビルドスクリプトも最新化したので、紹介します。コンフィグ作成にあたっては【Unity】GitHub Actions v2でUnity Test Runnerを走らせて、結果をSlackに報告する【入門】とUnityをGitHub Actionsで動かす際にライセンス認証周りで注意するべき点も参考にしました。 実際のコンフィグは ZLogger/.github/workflows にありますが、Unityの部分だけ取り出して実行可能な形式にすると
C#のAnalyzer、.NET 5時代の現在では標準でも幾つか入ってきたり、dotnet/roslyn-analyzersとして準標準なものも整備されてきたり（非同期関連だと他にmicrosoft/vs-threadingのAnalyzerも便利)、Unity 2020.2からはUnityもAnalyzer対応したり、MicrosoftもUnity向けのmicrosoft/Microsoft.Unity.Analyzersという便利Analyzerが登場してきたりと、特に意識せずとも自然に使い始めている感じになってきました。 Analyzerって何？というと、まぁlintです。lintなのですが、Roslyn(C#で書かれたC# Compiler)から抽象構文木を取り出せるので、それによってユーザーが自由にルールを作って、警告にしたりエラーにしたりできる、というのがミソです。更に高度な機
CA.unityはサイバーエージェントが運営するUnityをテーマにした勉強会です。サイバーエージェントのサービス開発者と社外の開発者を交えて、Unityに関する知見を共有します。森哲哉氏は、「Unity Package Manager と Addressable Assets System を用いたプロジェクト分割について」を発表しました。 日本で唯一のMicrosoft MVP for Developer TechnologiesとUnity Ambassadorのダブルホルダー 森哲哉氏：それでは「Unity Package ManagerとAddressable Assets Systemを用いたプロジェクト分割について」というタイトルで、キッズスター CTOの森哲哉がお話ししたいと思います。よろしくお願いします。 今日はこんな感じのアジェンダを用意しました。まずどんなことを話すか
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
neue cc - async/awaitのキャンセル処理やタイムアウトを効率的に扱うためのパターン＆プラクティス
CEDEC 2023 モダンハイパフォーマンスC# 2023 Edition
C#のみを使って、今ソーシャルゲームアプリを作るとしたら - Qiita
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
【C#】構造体(struct)を完全に理解する - Annulus Games
neue cc - .NET 6とAngleSharpによるC#でのスクレイピング技法
neue cc - .NET Core時代のT4によるC#のテキストテンプレート術
neue cc - ライブラリ作成のすゝめ - 40以上のOSS作成事例から見る個人OSSによる効能とキャリアの開発
neue cc - ProcessX - C#でProcessを C# 8.0非同期ストリームで簡単に扱うライブラリ
スマホ向けオンラインツールアプリ開発で対応したこと・アセットなど総まとめ【Unity】｜アマガミナブログ
neue cc - ConsoleAppFramework - .NET Coreコンソールアプリ作成のためのマイクロフレームワーク（旧MicroBatchFramework)
neue cc - MemoryPackにみる .NET 7/C# 11世代のシリアライザー最適化技法
FastEnum - 世界最速の enum ライブラリ - xin9le.net
neue cc - csbindgen - C#のためのネイティブコード呼び出し自動生成、或いはC#からのネイティブコード呼び出しの現代的手法について
Unity界最速DIコンテナVContainer が速い理由の解説 - @hadashiA
neue cc - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips
neue cc - 2022年(2024年)のC# Incremental Source Generator開発手法
neue cc - DFrame - C#でテストシナリオを書く分散負荷テストフレームワーク
R3のコードから見る実践LINQ実装最適化・コンカレントプログラミング実例
neue cc - MessagePack for C# v2によるC#における最新のI/Oパイプライン最適化
多人数安定性・チート耐性などを考慮したシステム構成の選び方 協力型アクションゲームにおける、ネットワーク構成・同期方式・言語の検討
.NETの非同期戦略とUnityとの相互運用
neue cc - ConsoleAppFramework v3 - より強化されたC#のためのコマンドラインツール用フレームワーク
neue cc - async decoratorパターンによるUnityWebRequestの拡張とUniTaskによる応用的設計例
neue cc - TaskとValueTaskの使い分け、或いはValueTaskSupplementによる福音
neue cc - 2019年を振り返る
neue cc - AlterNats - ハイパフォーマンスな.NET PubSubクライアントと、その実装に見る.NET 6時代のSocketプログラミング最適化のTips、或いはMagicOnionを絡めたメタバース構築のアーキテクチャについて
Unity+.NET Core+MagicOnion v2 の環境構築ハンズオン - Qiita
neue cc - C#でgoogle/zx風にシェルスクリプトを書く
neue cc - プリコネ！グランドマスターズのサーバー開発をCysharpが開発協力しました
#Slideshare にアップしたプレゼン資料の閲覧制限について【制限解除の方法】｜coosuke
neue cc - GitHub ActionsでUnityでunitypackage生成とビルド＆実機(Linux)ユニットテストを実行する
neue cc - 2021年のC# Roslyn Analyzerの開発手法、或いはUnityでの利用法
大容量ファイルによる“マジで仕事にならない”を回避 UPMとASSでUnityプロジェクトを分割する方法