Open-Game-Development and “just” sharing the tip of the iceberg

The concept of open development and its impact on the product/company perception is fascinating to me so I wanted to share more of my thoughts on it.

Arctic Theory just released the latest version of our code to our public test servers, and lo and behold we have critical issues. Basically, there is a small error in our network configuration related to how the game figures out how to connect to a server.

Our game is a persistent, single shard MMO. This means that all our players occupy the same game world and our technology handles ensuring that we have simulation servers for each area and each player as seamlessly as possible. For the past few years we have been pushing the envelope on how seamless this is for the player, but also how easy it is to work with. We (recently) found a way to enable the unreal server to answer traditional world queries natively from within Unreal Engine. This means that if the player wants to talk to a game system that exists within Unreal, but might be on a different server, it can communicate nativity (and through a seperate connection). The benefit here is that I can build my whole feature in Unreal and don’t need a traditional webserver.

This is hugely beneficial to development speed (and a key feature in blurring the server boundaries for the players), but we haven’t ironed out all the kinks yet. This is bleeding edge stuff and we have to test this rigorously in order to strengthen it. And we have a live server, with real people to do it so from a development point of view we are in the perfect position to harden and improve.

I worry people only see the tip of the iceberg.

If you stumble onto our public test servers (that are freely available on Steam) then people might dismiss Arctic Theory as a whole because the perception is that our servers are down. I know I could add disclaimers saying “If the servers are down… we are working on it” but I don’t want to make excuses. The nature of software development is that sometimes things are broken.

I believe that working software combined with iteration speed is the true recipe for success. It’s not how good your initial idea is, it’s how effectively you can execute on it. We are still early in our product building journey. It means that finding a bug does not mean that the feature is flawed or that the work put into it was bad. It’s an opportunity to iterate, strengthen the development environment add stronger foundations to the feature… and fixing the bug

In order to do open development the way I think it should be done I need to focus on communication. The easy part is talking about our victories,plans and goals. But it’s equally important to be honest and open out our challenges and stumbles because that is where the true magic is happening!