Transitioning to a Continuous, Evolving Game Model

Ahead of the Live Service Gaming Summit, we spoke to James Dobrowski, Managing Director at Sharkmob London. He discusses the significant considerations and challenges that studios face when transitioning from traditional boxed games to a continuous, evolving game model. He also delves into the role of prototyping, the influence of player data on development.

What do you think are the key considerations that a studio should make before shifting from traditional boxed game products to a continuous, evolving game model?

The shift is often bigger than most think. It requires a team-wide cultural mind-set change as well as changes to production process and technology. Content pipelines and creative aspirations need to be tempered to the needs of frequent release of new content, infrastructure and production needs to have smooth, rapid release built into its DNA, and the team need to be comfortable working with data, making quick decisions and often dealing with the hard consequences of some of those decisions.

What are the major challenges and strategies involved in changing the DNA of a company to embrace the forever game philosophy?

In my experience, the biggest challenge comes from changing the way in which a team thinks about development. As a live game, you either need an evergreen game loop where the community provide the content (PvP games are a great example of this), or a finely tuned content pipeline. Ideally both! The creative teams need to think and build in terms of longevity rather than short-term single-use experiences, and content teams need to balance creative aspirations with timeliness of delivery. Production teams need to consider the development process a marathon, not a sprint. Where traditional games delivery were incredibly busy just prior to launch, live-games are busy prior to, immediately after and for a long tail beyond launch. Traditional models of spiking team hours just doesn’t work anymore. Similarly, teams need to be comfortable with moving from ideation to shipping released functionality in short-time frames, and have the resilience to deal with sometimes harsh community feedback. There are a lot of similarities between the two models when it comes to development, but there’s an incredible difference in how your team need to think about what and how they create. How does prototyping play a crucial role in the early stages of development for a live game, and what are the key considerations to ensure the game is designed for scalability, adaptability, and ongoing player engagement? Prototyping is crucial for any new game endeavour, but there are a few key aspects that need stress testing in particular on live-game. Alongside finding the fun, developers need to ensure their loops carry longevity, and their content aspirations and pipelines can keep up with the needs of a live audience. Finding the fun in prototyping still reigns supreme, but the ability to prove out retention mechanism early pays dividends down the road.

In what ways does player data influence game development decisions, such as feature updates and content releases, and how do you ensure the game evolves in line with player expectations and preferences?

This is a big topic, but the short answer is “heavily!”. Good live-game teams are tracking player data on a daily basis, making daily tweaks to drive towards Key Performance Identifiers across key metrics, and using data to drive feature and content prioritisation for upcoming releases. That being said - data should never make a decision for you (it’s misled many a creative), but it should thoughtfully inform your decision making process. It’s also wise to pay close attention to quantitative and qualitative data, however it’s important to avoid being side-tracked by a vocal minority within your community. Often the biggest emotional pressures from a community on your team are not representative of the wider community, and this needs to be carefully managed. Really good teams know how to build good community infrastructure around this.

What discussions are you hoping to have with your peers at the Live Service Gaming Summit?

Personally, I would love to discuss and understand the key challenges others have made when shifting from box product to live game development, how they overcame them, and what they would have done differently if they had their time again. In particular, I’m interested in discussing the cultural and team barriers they’ve faced, and how they helped their teams make the transition successfully. I’m looking forward to it!