Giving Web3 Game Devs More ‘Shots on Goal’ With Beamable
Video game industry lore reveres characters like Jon Carmack, the creator of Doom and a genius programmer whose pioneering adaptive tile refresh and ray casting techniques made the first-person shooter genre possible. For decades, coding your own backend tools from scratch was a necessity, if not a point of pride, for game devs.
But over the past 10 years, teams have increasingly shifted to using third-party solutions: 3D engines like Unity and Unreal, cloud services providers like Amazon, and now generative AI tools. Those changes translate into dramatic increases in the industry’s creative capacity.
One of the reasons we have not yet seen mass market success in blockchain gaming is that Web3 is just at the start of that journey, argues Jon Radoff, an industry veteran and the CEO of Beamable. Early blockchain games were slow and hard to make in part because they were trying to recreate from the ground up some of the traditions, code and systems available to game developers.
“Making games is a craft, so the more time you can spend on the truly creative elements -- features, storytelling, the narrative and the artistry -- you're gonna increase the likelihood of success,” Jon said. “The more shots on goal you have for a game, the more likely you are to actually ship a game that people are gonna wanna play.”
Jon sat down with Will Matteson, Games Product Lead at Polygon Labs, to discuss the state of play in Web3, non-financial uses of blockchains in gaming and advice for teams just starting out. The interview has been edited for clarity and brevity.
On not reinventing the wheel and where to focus your innovation budget
When you are building a blockchain game, I believe that you should start by thinking about the player experience. Like what's the actual game that you're making? Then think about how asset ownership is going to change the way you design the game from an experiential standpoint.
The areas of true innovation, where you're actually differentiated from other products, is where you should spend your time. Focus your innovation budget on just that piece. Building servers, reading wallets to see their content -- all of these things are the worst use of your time because not only do they take time, they permanently slow down your velocity.
That is the insidious killer of far too many games -- people just investing in things that are not only slower, but they get slower and slower over time because the tech debt accumulates. And then before you know it, every feature is a real pain to add and suddenly your product managers and your game designers are getting super frustrated because you gotta get the backend team to build that.
On one-programmer-per-feature rule
Anytime you need more than one programmer for a subsystem of a game, your velocity goes down a tremendous amount. It doesn't just go down by half. When you go from one to two, it goes down to a small percentage of your speed and therefore you have enormous risk. And maybe that feature is never even gonna ship. So I really encourage people to try to keep teams as tight and small and focused as you can.
Most features should be implementable by one programmer, not these really complicated jigsaw puzzles that I see a lot of blockchain game developers get caught up in. You've got some blockchain engineer that you've brought into the team who's never built a game before and they're just trying to figure out how to get this stuff running. And then you've got game developers who know about Unity and Unreal and delivering a player experience. Just bridging the gap between those things is so complicated.
Blockchain integration is just something that federates alongside everything you're already doing. You could just start building whatever game you've imagined and at the point you're ready to add blockchain to it, we have this whole inventory management system within Beamable so that you can build up your economy and your game, the types of items, the types of interactions that you wanna have, etc. All of that is done right inside Unity.
On the amazing dream of interoperability vs reality
Interoperability is an amazing dream that many of us share, but the reality of interoperability is people haven't even mastered interoperability inside their studios, let alone multiple studios interacting and exchanging stuff with each other.
So at the economic level, there's a certain amount of interoperability you gain by being on chain because you now have established the interoperability of asset ownership. But when you start looking at all of the complexity that involves game development, you've got inventory systems data, you've got player accounts, you've got all of these different things.
What we're trying to do is bring a lot more standardization to the way game developers can approach that inside their studios so that you've got the right abstraction layers around all the different kinds of data objects that you work with on a day-to-day basis.
On match history, identity and non-financial uses cases for blockchains
There are a lot of interesting non-financial applications of blockchain. It's not all about asset ownership, although that's what people tend to talk about the most. It's also about identity and histories and all these other things that are important for games.
A big opportunity around blockchain is saving records of match histories. There's a whole range of non-financial applications of blockchain tech where it would be very desirable to the player community to have transparency and accurate records you can trust. You can build a whole ecosystem of applications that look at that and process the information, visualize it in interesting ways, none of which you have to build as a game developer.
Identity, reputation, match histories, tracking toxic behaviors -- all of that are potential applications of storing data in a publicly trustable format that any game can make use of. Even games that are not inherently blockchain could benefit from access to this data.
An internal reputation system is never going to be strong enough. Where it really gains a lot of power is when a lot of companies, including companies that ordinarily wouldn't trust each other, cooperate. You're able to have blockchain be the way to synthesize, store all that information in a way that they don't have to actually trust each other.
On trust, transparency and zero knowledge proofs
When I ran free-to-play mobile games like Star Trek Timelines and Game of Thrones Ascent, there was always a portion of the player population that were absolutely convinced that we rigged the random number generator for a nefarious plot to optimize into needing them to make purchases.
It's not unheard of for social casino products to in fact optimize the “random number generator” around how to maximize engagement with the game. So everybody gets drawn with the same brush, since there are some people that will approach game development that way.
We had a normal random number generator and we tested it a lot and we tried to show people, but if only we had a way to point to something and say, look, we don't even run the number generator, that would be an interesting solution to a set of problems there.
Zero knowledge proofs solve an inherent problem in blockchains, which is that games of asymmetric information are hard to implement. The same thing that makes blockchains really powerful, which is that everybody has the ability to inspect data, is not so fantastic for a poker game. Also, when you've got a server that contains all of that data, you've just opened up a whole other set of incentives for bad actors.
Advice for Web3 game devs
Number one, you have to start with the fun factor of the game experience itself. No matter how clever your blockchain ideas may be, it's going to come back to how fun the experience is. So I really urge people to start from that.
First, build a top down experiential layer to the game that just maximizes fun. Some people call it the core loop, but it should be the overall slice of functionality that you engage in so that you know what you're building is fun.
The second piece is bringing blockchain into it. It’s important to ‘why blockchain’ actually. I would really encourage people to think in terms of what is my thesis about ownership in this game and how that is going to bring a qualitatively different experience to the player -- that psychological difference of what it really means to own something.
On what Beamable can do for game devs
Beamable a platform for building any kind of game with online components, things that live in the cloud. At the highest level, it's the liveops dashboards for scheduling content, for managing your customers, for segmenting audiences, for looking at what's going on in your game and actually managing it on a day-to-day basis. But then through a whole set of integrated components, including everything you need to get it up and running inside Unity and Unreal. So it's drag and drop components that work really nicely within that as well as a very extensible set of backend components.
You can do blockchain integration, all the things that you need to build any kind of online game -- it's right there for you. It's fully integrated and on day zero, setting it up, you can be building an online game without messing around with the stuff that isn't creative, that isn't core to your game system.
Instead of having to build middleware to connect these systems together, which is the traditional approach, we have more of a federation philosophy. It means that the various objects within the environment have events associated with them. Microservices are essentially hyper-scalable code that you can run on your server in our serverless platform using the languages that you know.
We have well-defined data interfaces so that you could invoke a microservice in these different circumstances. So for example, you've got an item, you give it to the player, that item now needs to be minted. You don't actually have to write any code to mint -- you've essentially dragged into your project and the microservice for Polygon implements all of that for you.
Everybody builds these silos and, they don't realize this when they're getting into it, they're essentially signing up for a lifetime of building middleware and connecting these systems and a lot of technical debt. So we're trying to get out of that silo mentality and instead create an ecosystem where modules are plug and play, they work with each other out of the box, they just snap together and function the way you'd want. That's the approach we brought to not only blockchain, but things like analytics and purchasing systems, account systems, and various forms of login. All of that is this plug and play architecture.
Get started with Beamable by reading the documentation and signing up. Follow Jon and Beamable on Twitter.
Read more about gaming #onPolygon, tune into the Polygon Labs Blog and our social channels to keep up with updates about the Polygon ecosystem.
Together, we can build an equitable future for all through the mass adoption of Web3!
Website | Twitter | Developer Twitter | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn