Fundamentals first, gameplay second
We’ve already gotten to work designing our first game. Of course the gameplay is the exciting bit, but we’ll keep this a spoiler-free read for now.
While it’s plenty easy to get swept away in gameplay, we don’t plan to waste the rare opportunity of starting something from scratch. There are some structural elements that are hard to incorporate if you get too far down the road with building a game, so we’re doing them upfront – multiplayer programming being one of them.
Keep in mind we’re coming at this as digital service designers and developers. Since we see from such different eyes, there is a lot about gaming systems and features that we’re excited to revamp, upturn, and reimagine as we go along.
Coding a multiplayer universe
From a structural and methodical standpoint, multiplayer network code is way more difficult than single player. It’s also really hard to do retroactively — you need to do it from the get-go, before you’ve made any final decisions about your gameplay. That was the first decision we made, that we want to start with the multiplayer functionality.
The beauty of multiplayer is that it enables you to be as competitive as you want, the game will always be as challenging as the next brilliant player you get matched with. And in a world of 3.2 billion internet users, there is a sea of competition out there to keep you on your toes. It’s inclusive too. Your great aunt can play, and a career gamer can play, and they’ll both have an awesome time.
It’s also just straight-up fun (we think). In the development of our first game, our Gothenburg and Stockholm offices will be prototype-playing against each other to test the game. The inclusiveness and ruckus energy of multiplayer really fits us perfectly.
