Hi! I’ll jump right in…
“Minor” is up to debate. And existing games would involve a lot more effort than starting one from scratch. With the prototype, there is a bit of work you need to do to get your actors to replicate across the cluster. It’s not difficult, but it does add some complications. In the final product, however, there would be no code changes required, or maybe some minor stuff involving setting up the cluster. I haven’t gotten there yet because UE4 is a behemoth and I’ve been learning it as I go. My tech was designed for XNA, then I ported it to Unity, and then UE4 went open source so I ported again. So it’s not as integrated as it will be, but I think the extra work involved is worth it.
Also, there are some areas where I haven’t gotten to yet, such as sessions. Right now, I don’t handle sessions. A cluster is just running a single game instance. For sessions, you’d want a higher-level system that created and destroyed clusters to service game sessions. That, and probably a few other loose ends, can be tied up if I can get help/funding/etc to take it to the next level.
Yes, the cluster currently does its own replication on the back end. Right now, you do this by deriving your actors/pawns/etc from my shim classes, which sit between the UE4 class and yours so they can get the data where it needs to go.
Players are split across the servers and which are hosting whom is up to the hosting solution, which would be specific to the game and business model. You set up the server configuration as you see fit. There are worker nodes and gateway nodes. The gateways let clients into the cluster (via standard UE4 comms/replication) while the workers run the NPC/physics/etc stuff. You can run as many gateways and workers as you want.
You bring up a good point of clarification. This doesn’t work like Cloudgine does (Crackdown 3). I do not segment the world and assign a server to handle each region. In my system, all servers cover the entire space and the objects in the space are distributed across the servers evenly. No load-balancing yet, but that is a possibility.
This tech is designed to be run across many machines but you can run an entire cluster on a single box if you can/prefer. The back end uses ZeroMQ to handle cluster messaging and it’s set up so multicast will benefit performance. So it’s recommended that you run a cluster on many machines, but it’s not a requirement. This tech is designed to run across dozens, hundreds, maybe even thousands of nodes if I can get help with turning the prototype into a product.
That depends on what you mean. The cluster runs on an internal network. This is important because the nodes need to have a lot more bandwidth and a lot less latency than the Internet allows. But the gateway nodes mean you can host the cluster online just like any other dedicated server. Players connect to the gateways over the Internet but the cluster itself is tightly bound.
I can’t tell you what the scalability curve looks like for certain because I’ve been working alone and I have no budget. I have run the cluster with up to 4 nodes on separate boxes and the scalability looks spectacular. The key is what I’m doing on the back end. The work there is itself distributed across multiple nodes so there’s no telling when the scalability will drop off. I’m sure there are limits but they are already very high, and this is a prototype so I think it could be even better if smarter people than I helped take it to the next level. There’s no minimum cluster size, but if you’re just running one server then the back end is pointless, so I’d say two is the minimum you’d require before this tech was of use to you.
The system should support hundreds or even thousands of players. The cluster back end doesn’t know the difference between players and any other object type, so the max player count should be the same as the max object count.
I’ve stress-tested the **** out of this thing and it’s stable. I don’t have a test server for you to try because I do not have the money to pay for hosting. I did that once or twice as I needed to do testing, but those were just hosted for a month or two and never went above two machines.
The prototype is pretty much ready to use. It might even be sufficient to support a release game. If you wanted to use it the way it works now, then it will be ready very soon. If you want it to be the ideal product that it will eventually be. then that depends on how much help/funding/etc I can get. It’s almost there now, but I still need to utilize UE4’s replication system to support the cluster back end instead of doing it myself.
This prototype has been evolving over 5 years so it’s hardly a good candidate for a code base. It needs to be understood by real experts and built as a proper product. On the bright side, the system isn’t all that complex so it shouldn’t take long to do that.
I’m not sure about pricing. I want this to get into as many hands as possible but I also want to see some payoff for all these years of effort and sacrifice. I was thinking I would charge a small upfront fee for the plugin and then get a piece of any games that did well using it. Like what Epic is doing with UE4. Additionally, I am interested in working with Epic directly. I think this tech would be something they’d want to build into the engine as a default . Then I would deal with them about compensation, I suppose. But the important thing to understand is that I care more about this technology being used than I do about profiting from it. If I have to open source it with a GNU GPL then that’s an acceptable worst-case. I won’t smother it in a struggle for fame and fortune.
So that’s all the questions. Thanks for the interest! If there’s anything else I can answer, let me know. I am working on a tutorial project now and I want to make a video going through it. Then you can see what it looks like inside and out. Unfortunately, I’m the only person working on this and while I may be a creative problem solver, I’m no UE4 guru – or even particularly brilliant for that matter. Then again, that hasn’t stopped me so far. 
