Mr Watson, come here. I want to see you.

People have been asking why we’ve been silent, and quite frankly it’s because I’ve been extraordinarily busy.

So what’s happened in the interim. We competed in the NEAR Hackathon in Austin and brought home a 3rd place, which was cool. During the hackathon I came to the realization that when you do these things you either go to do biz dev or you go to hack. I tried to do both and that resulted in only having a day or so to compete in the hackathon. The folks at NEAR Austin are exceptional though, and it was a great experience. We’re significantly behind schedule so we won’t be doing that for a while.

We’ve been working on the bowels of the game server itself. While a lot of the game relies on smart contract for the economy and such, to have a real multiplayer game — you HAVE to build netcode of some sort and I hit a wall as soon as that became the primary function. Why? Because I chose to do it in Rust, not use the “easy button” of using Unity’s Netcode for GameObjects because I knew that it wouldn’t scale — and there are some components that simply shouldn’t be in Unity if you need to have deeper control over them. And so the grind began — library selection, architecture decisions, designs failing to meet standards, etc.

While I do know that our current approach to use WebSocket’s long term won’t scale (looking at ways to use WebRTC DataChannel but it’s crazy complex for what we needed), because the platform is built on the equivalent of Google’s ProtoBuffers it is easy to move data back and forth between the clients and the servers. That’s another piece — the backend is NOT decentralized the way that a blockchain would be. Why? It’s just too slow for any meaningful action game and kinda too slow for an RPG. So I’ve build an abstraction layer that will support multiple transports and WebSockets will just be the one that we go with for now while we start to scale up. I *KNOW* that the WS route will only scale so far because websockets are TCP based and they must maintain their connections to their server. So the more clients you want, the more a *single* server has to handle. There are ways for handling this a bit more scalable such as using AWS’s API Gateway — but that’s not on the near term agenda. Saving that for scaling conversations off in the future.

So that’s where we are…. deep deep deep in the bowels of netcode. Hasn’t been a point in showing off much on the visual front because all of the work… ALL of the work is on building a scalable backend to support games while also being tightly integrated with blockchains. While the plan is to deploy to NEAR, I’ve also been refactoring the backend code so that it will function over multiple chains as well — though that may never happen :)