In the broadest sense, what can you tell us about how we're facing those challenges [of running an MMO in the cloud]?

Yes. So the way we look at it, we want to implement what's currently known as the event-driven data center. The more I provide what we call sometimes fluid resources, the faster deployment time; they call these the main buzzwords in our business, DevOps, the time to market: how fast would it be for me to scale a game server for you? How easy would it be to obtain resources that I need? How can I repurpose resources? Because the cloud is mostly utility computing. You pay for what you use. And that's a completely different approach than when you own your data center and built it, and now this stuff is yours, and then you use it or you don't use it. That's a different story. So back to my original idea: we want to implement the event-driven data center, where every piece of software that goes through a major event that the infrastructure should know about would fire an event through a wide channel of info buses that have reactors reacting to it and acting upon it. That's the big picture. And we can orchestrate this the way we want, because orchestration is the word here. You need to make all the logic that Jason and Tom and the gameplay guys are writing report what it needs, and my infrastructure reacts to it. Whether by expanding, by replacing, by, oh, that's a bad member of our cluster, we should take it out. Oh, no, this is not going to get auto-healed or self-healed, we've got to wake someone up. That's the plan. Moving to that: the way we usually do it in DevOps and even in backend services shops, you cannot really sit in a room and get this amazing big white paper and draw everything. It's impossible. You will definitely have bad designs. So we go through the MVP, the minimum viable product. Okay, this will deliver my idea. I'm going to scale right now, or I'm going to make the players get in the game. And watch, because maybe there might be a new feature I'm not really putting in my mind. It's the same concept that all the successful startups follow, like how Facebook believes that you should move fast and break things. Until you go out to market, the market corrects you. That also goes really well with your point in the beginning about persistence. If we laid out persistence before seeing the game itself, we'd be just breaking walls and moving around them. While right now, we are more mature. We can start from a point where we understand this is what the game looks like. The game designers had their time. They discussed some ideas, back and forth. The implementation is going to be a lot easier when you have something to test with.

At one point, we didn't even have any of the game data designed. Nobody knew what we had to persist, for example. So we had to actually go through several meetings to figure out what are we going to persist and how are we going to do it.

I remember those meetings, sitting there like, no, I guess the players have this and the players have this, and this needs to sync up with Turbulent and this needs to be pulled down and live in the universe.

Oh yeah, and there's a lot of transitioning on ownership and communication of all that data. I mean, that's still evolving today.