Lab Surprise: building a game bundle store with 2 cloud functions

Hi everybody!

Here’s Lab Surprise, a game bundle store built with just 2 Google Cloud Functions (and an integrated payment service API!).

The idea: Get a surprise bundle of 3 VR apps from 19 games (the more you reveal, the lower your discount). 19 choose 3: that’s 969 different bundles, with 4 discounts possible for each bundle 😂

VR Scout explain it nicely: https://vrscout.com/news/app-lab-bundle-major-quest-discounts/

What is it?

We couldn’t find any platform or store that would allow us to have the mix and surprise elements we wanted to have (we searched!), so… I build it over the course of a month, testing and iterating with the group 😅

I set up our own API endpoints with Google Cloud Functions, storing data using Firestore, and using the Paddle API to add a programmatically priced integrated checkout. The web front-end is very simple, basic HTML, CSS and a dash of JavaScript just doing requests to these custom APIs and replacing the elements as needed. I’m old and didn’t do browser work in a long time, so I just went straight to jQuery for DOM manipulation and JSON requests and, well, it works and the jQuery API still feel nice to me…

Now for the dirty, shameful secret: the first version of the drawing-and-revealing custom backend was actually built with a Google Spreadsheet and an App Script. It worked quite well for the ball of strings and glue it was! Moving to Cloud Functions helped remove a lot of specific code for Sheets, in addition to making requests much faster. Apps Script is actually fun to use and the web editor itself is really nice. Sheets are also a great way to sketch your data structure very quickly and change it as you prototype. There’s even a hack/Chrome extension to version you Apps Script with GitHub. But ultimately, it’s not good enough and it feel too cumbersome compared to Cloud Functions.

Tip: use Cloud Shell if you are new to Cloud Functions, it allowed me to get going in a minute without installing anything on my local machine.

What are the parts that make it work?

We are using the fact that Paddle can split a sale automatically between sellers to immediately route the money to the vendor account of each developer in a given bundle, calculating the split for each bundle. That means that we had to onboard all 19 developers into Paddle in a record time. It was a totally new use case for Paddle, and they were really open and helpful about it.

Technically, Lab Surprise is made of just 4 parts, all exchanging through web APIs and decoupled:

- The web page itself, the front (it’s not doing a lot really 😂 just updating the graphics and price on the page depending on the bundle and revealed apps)

- The drawing-and-revealing custom backend (one cloud function drawing a random surprise of 3 games, updating the reveal status of the surprise and sending back the price, discount and paylink)

- The Paddle service (Paddle does a lot here: checkout, reporting, tax remittance, emailing the keys we pass them to buyers, even first level support)

- The key fulfillment custom backend (one cloud function checking if keys are available and passing them to Paddle)

The custom backends are using a few collections and sub-collections in Google Firestore: games, promotions, keys, surprises… The Firestore API is not perfect, but simple and well documented.

There’s also a couple of other custom back-office functions: one function that handles adding a batch of keys for a given game (with a very simple form for devs to use) and one private function to generate the bundles for a promotion.

I’m very happy that I didn’t try to go the route of setting up a traditional monolithic web application.

Cloud functions force you to think in a decoupled way (even if there’s several ways that you can couple them via the data) and at this stage it allows for easier updates and explorations. For example it’s really easy to deploy just a variant of the draw function to test new features.

There’s also benefits in thinking the API-first way. I’m very senior as a creative and a prototyper, and I started programming when I was maybe 9 or 10, but I’m not a developer by trade. API-first design is helping me greatly in designing my architecture, by focusing on the relationships of the parts.

The update puzzle

I had to first make the fulfillment function accept both types of messages, old and new (and now in a more extensible way😅). Then I could create a new version of the drawing function, passing only the new message format, test it against the live, production fulfillment function, and deploy it once everything was tested. I can ultimately go back to the fulfillment function and remove the legacy code.

If both parts had been consolidated into a single app, I might have been able to update both of them in one go. But in many cases, you are not controlling the pace of updates of some parts of the system anyway, for example is you have a client app that your user download. It was an interesting update lesson, one that fortified my views on decoupled updates: we are going to have similar issues with our VR game Peco Peco, and additive updates like that might be the way to go more often than not.

What’s next?

We were able to add 5 more games in the middle of Lab Surprise without issues or interruptions. We just created a new promotion and switched to it.

The way we built it, it is also easy to create evolutions: we could include all paid App Lab games if their developers were interested 😃. We could add an official Quest store games for a 2-days period as a special event… We could create a version with 6 games in the surprises, or 20, or just 1.

In term of business, we have gained some autonomy in terms of experimenting with marketing our apps. And I think this is good for the whole indie VR ecosystem, as it shows that we don’t need to wait for the stores to evolve, we can build our own experiments in terms of marketing.

OK, but why build a surprise machine instead of a classic bundle store?

As our group grows, we need to find ways to reach out to players that don’t exclude or sideline one developer or the other. We don’t need to replicate what others are doing, we need to find new ways to market and sell our games that reflect our own position in the VR and indie game market.

Creative technologist. I build creative-tech formats & communities: #museomix co-founder • ArtGame weekend • @codinggouter • Fête #codecreatif. ➡@SavoirsCom1.