FluidFramework VS Json.NET

Have you seen FluidFramework? It's open source (MIT): https://github.com/microsoft/FluidFramework

I think the first product they're building on it is Loop: https://www.zdnet.com/article/microsoft-introduces-loop-a-ne...

Full disclosure I work at MSFT and on the fluid framework.

If you are interested in this you may also be interested in the fluid framework, https://github.com/microsoft/FluidFramework

We use websockets and solve a lot of the state management problem called out here by keeping very little state on the server itself. The primary thing on server is a monotonically increasing integer we use to stamp messages, this gives us total order broadcast which we then build upon: https://en.m.wikipedia.org/wiki/Atomic_broadcast

Here are some code pointers if you want to take a look:

The map package is a decent place to look for how we leverage total order broadcast to keep clients in sync in our distributed data structures:

(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.)

That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is [MIT licensed](https://github.com/microsoft/FluidFramework/blob/main/LICENS...) and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.

I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. [Other open source backends](https://fluidframework.com/docs/deployment/service-options/) aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.

Within the context of the Microsoft-verse, Fluid Framework (https://fluidframework.com) is supposed to be solving similar problems in web apps, although I haven't personally played with it.

Microsoft recently open sourced fluid framework. It is a distributed, consensus based, real time collaboration framework written in typescript. Fluid would keep your clients synced up and your server code would only have to handle when someone hits submit. Fluid Framework

The official documentation and the github repository seem clear.

This bug and many others related to time: https://github.com/JamesNK/Newtonsoft.Json/issues/862 And they will never get fixes, because the project is kind of dead. Edit: and actually, the creator claim to have made it like this on purpose, so I don't trust it anymore.

There's a related discussion on the GitHub repo:

Nuget is where you'll get 3rd party libraries (such as Newtonsoft.Json for JSON processing)

Common convention (with rare exceptions) is to name your project the same as your assembly name and default namespace. For example, Newtonsoft.Json.csproj makes an assembly called Newtonsoft.Json.dll with the default namespace of Newtonsoft.Json. Inside that project directory (which usually also has the same name), subdirectories would match namespaces nested inside the default, like in that example there is a folder named Serialization which contains classes that are all in the namespace Newtonsoft.Json.Serialization. Classes in this nested namespace can automatically access classes defined in parent namespaces without extra using statements, like how JsonProperty.cs can reference JsonConverter from the Newtonsoft.Json namespace, but it needs a using statement at the top of the file in order to access classes from the sibling namespace Newtonsoft.Json.Utilities

As I said, I'm not familiar with C# but on a quick Google it seems there isn't one idiomatic way to handle JSON in C# - instead a multitude of different libraries/packages for doing so. This seems... ...irritating. json.NET (https://www.newtonsoft.com/json) seems to be one of the best (but again, I don't know C#).

MonoGame abstracts a lot of the rendering work and is easy to use for 2D games (I haven't tested its 3D support so far). It also provides you with a content pipeline plus audio and input handlers. All that's left for you to do is roll your own Entity Component System, physics, and game logic. If you're not interested in writing your own physics, there are libraries out there already. Additionally, if you don't want to get caught up in the details of data serialization, Json.NET is a great package for serializing data in JSON format. That makes it perfect when paired with a map editor such as Tiled, which can export to JSON.

Also file an issue report with Newtonsoft because IMO that should not be happening.