We catch up with Fred Galpern and Russell Miner to learn how they are building a Live Games in Unity 3D
PuzzleNation started in the mid-2000s with the goal of offering digital solving experiences utilizing licensed puzzle content from Penny Press and Dell Magazines. Initially, PuzzleNation was a subscription website containing several Flash puzzle games. In 2013 the website was transformed into a marketing site as PuzzleNation began offering mobile apps for iOS and Android devices. PuzzleNation has released many apps over the last 8 years, with two notable successes - Daily POP Crosswords and Penny Dell Crosswords.
We were looking for a way to create the “table stakes” type features that a modern mobile app requires, without having to pay the large development costs required to reinvent them. These features tend to require complex robust back-end services, along with client-side systems, not to mention an ongoing cost to monitor and maintain those services. As a small developer, we are faced with the unhappy choice of leaving those features out or having to invest less in the gameplay and features that make our product our own. Beamable offers a third option, which is to provide fully functional features or features that require less of our development time to get them in front of our players.
As we wanted to give Beamable a try, we decided that the shortest path was going to be incorporating it into our live Daily Pop Crosswords product, and seeing how things worked out. Our plan was to, over time, add new Beamable features as makes sense for that product. This led to the natural first step of choosing login/identity as our first feature to integrate.
This decision was further encouraged by two more factors. Firstly, Apple Sign-In was a looming requirement. While we had found means to implement this with a lone third party script solution (and did so in our non Beamable sister app Daily Pop Word Search), this felt a bit kludgy and is ultimately not extensible. Secondly, our only means of authenticating a user prior to Beamable was via the Facebook plugin for Unity. Facebook itself was being questioned in the media every day, and our reliance on this as our only means of authentication of a player identity was becoming untenable. Thus utilizing Beambale login provided us with both a proper first-party authentication means, as well as a bevy of other authentication providers to give more choice to our players.
If this had been a brand new, unreleased App, we would have had a working login and identity system up and running in literally minutes, but our integration presented a few challenges. There were essentially three major issues.
First, our app was live, and as mentioned, already utilizing its own Identity system. This system supported zero first-party authentication scenarios, and one-third party: Facebook Login. We would have to figure out a way to have the Beamable Identity and the PuzzleNation Identity live happily together, all while upsetting as little as possible for our existing players.
Second, Beamable Identity provides players with the means to swap identities on devices, even switching back and forth between identities, even local-only ones. This ability was not something that we had in our app, and much of the coming integration was spent making our game support this reorganization of data.
Third, Beamable’s login interface, which we knew we did not want to re-invent, was written using Unity’s most recent UI systems. Sadly, our app used a third party UI system called NGUI, which was quite dated. Our challenge here was to devise a way to have them interact with each other in a passable way and get the Beamable interface to adopt insofar as possible the look and feel of the existing app.
The details of solving all these problems are long, varied, and honestly took quite some time to resolve. The lion’s share of this work was spent on the adaptations to our app to support multiple identities. We worked regularly with Beamable engineers to map out plans of integration, sometimes making feature requests of Beamable. And when we got close to each other, in the integration process, we would do co-development sessions online to work through issues. As an early partner with Beamable, we also pushed some of the boundaries of how far some of their systems could go, such as their UI Skinning system. During those times we iterated with Beamable team members to get to a place that was acceptable to us for our needs.
We initially planned to make some sort of a monthly pass feature. We had wanted to add something to our game that could both allow players to spend dollars to remove ads for a period of time, as well as drive more incentives for daily play. The initial discussions with Beamable started around the idea of using their “Calendar” system. This system functions like a daily reward system.
The more we went back and forth about what the calendar system could do and could not do, and with issues with our app’s lack of catalog depth to provide “rewards” that we can comfortably hand out to players, we ended up changing our direction quite a bit. In the end, we decided to add a new free daily puzzle product to our game that would be ad-supported, as well as increase the frequency of ads in the existing daily puzzle product.
On its own, none of that would have leveraged new Beamable functionality. But to further monetize this new ad pressure, we also wanted to allow players to purchase a 30-day pass that would remove ads for that period. This was our opportunity to use Beamable’s Inventory Feature.
Lessons from the specifics of our UI system and Beamble’s prefab UIs, also the fact that this system would be a low touch user interaction, told us that it was probably not worth trying to leverage Beamable’s UIs here. So we focused on using client code to wrap Beamable’s inventory system and add a new item to that system that players could purchase.
In a matter of hours, I had wrapped up the Beamable Inventory system for interfacing with our client, created our pass that self expires, and made it so that pass hides ads if a player-owned one. My work was mostly focused on doing the initial wrapping of the Beamable inventory system to work in this product (which wasn’t much), on the pass itself, and finally on the UIs to execute the purchase of that pass inline. What I did not work on, was the underlying inventory system itself. It just worked.
As a plus, the wrapping groundwork that was done will effectively serve as the ready-to-go wrapper for any other inventory items we decide to leverage in this product going forward, putting us that much closer to implementing say, another type of pass.
Part of what we envisioned for Daily Pop Crosswords and Beamable was to leverage some other Beamable features such as some form of social gameplay, limited time offers, and events. These all would require some more serious alterations to our existing game, and possibly getting more gameplay content in place to support them. Additionally, when it comes to social features such as any form of competitive play (however light), we are a bit reluctant to open the can of worms on competition because the content and the existing player base are focused on solo-play. With more social features a bit murky, the next likely feature we would explore in Daily Pop Crosswords is a Limited Time offer for initial players to encourage early monetization. We also will likely continue to explore passes at different value points with different effects.
I think what has us more excited is our next product. Codenamed “Bulldog” (for no particular reason). We are currently in the design phase of what a more modern product will look like for PuzzleNation. A the time of this survey, we are imagining a product that is:
1. Capable of delivering many puzzle types in one product.
2. Centering on two-game loops: one organized around Daily Play, and one organized around progressing through a “journey map” of sorts where a vast content library of puzzles and puzzle types can be explored.
3 Leverages some modern tricks of the trade such as multiple currencies, a deeper storefront, limited time offers, and events.
While things are still early, our laundry list of feature requirements has a slew of things that Beamable, could help us accomplish, and this time around, we would not be burdened with outmoded UI technology and a pre-existing data infrastructure that has to be worked around. I expect that before long we will have our thoughts a bit more organized, nailed down, documented, and then a conversation with us and Beamable can take place wherein we can explore what Beamable features make sense to utilize in this product.
When considering making a mobile game, the table stakes of many features are a hurdle that is almost too high for a small team to overcome. Once a team decides they aren’t going to take on the burden of rolling their own back end infrastructure, then often the choice comes down to a few middleware providers that still only take you to 50%. They may provide say, cloud storage, but you are still rolling your own inventory system that leverages that cloud storage. Beamable is attempting to provide a solution to game-specific and mobile-economy-specific problems all within Unity and have that solution start at 90%, sometimes even 99%. This frees us to develop our game and not another inventory infrastructure. I am hoping that Beamable can continue to provide useful game-ready solutions, at as close to that 99% as possible, and do so with a reasonable price tag for a small studio.