After our article on the frequency and length of events was published, a new question arose: how to organize a continuous LiveOps workflow so events are released one after another, alternating in content and visuals.

Currently, we’re actively engaged in optimizing the process, and discovered several new insights. Here are some of the conclusions we've drawn.

Let’s start with the hidden benefits of events beyond boosting monetization, and then move on to organizing the team’s workflow, because these points are unexpectedly connected.

Events as a platform for experiments

Besides the simplest types of events, where the core gameplay is preserved and only the setting changes, events are also a great way to diversify gameplay and mechanics. This can lead to results that impact not just new events but the core gameplay as well.

Everyone knows the benefits of A/B tests, but the unique thing about events is that we can conduct experiments on the entire audience at once. Events are designed to diversify gameplay, increase interest, and provide a varied experience. So, things that might not work in the regular gameplay loop can perform well during events, allowing for bolder experimentation and new growth opportunities.

For instance, Idle Outpost was initially created as an idle game without managers. Traditionally, idle games feature stations that generate currency, managed by characters who enhance their efficiency. We deviated from this in Outpost, resulting in a highly successful project with excellent metrics, as noted by the founders of Rockbite Games.

Core gameplay 

We then created an event with gameplay similar to the main game (without managers), but the metrics fell short. Adding managers to the event boosted monetization significantly. What didn’t fit into the core gameplay turned out to be an excellent feature for the event.

Event

Events also serve as a testing ground for new mechanics.

For a game to thrive long-term, regular updates are essential. The best place to introduce gameplay updates is through events, which can then be applied to other events or even integrated into the main gameplay.

For example, in Idle Lumber Empire, we held a seasonal event with a jackpot mechanic. We liked it so much that we added it to all regular events, which can be considered part of the core gameplay due to their constant presence.

The same happened with temporary leaderboard mechanics. Initially introduced in an event, they are now part of Lamber Empire's core gameplay.

So, how do experiments relate to organizing the workflow within a team?

Workflow for event creation and employee growth in LiveOps

We spent a long time analyzing how operational projects should differ from those in the development stage. We've now settled on a workflow used in large productions.

If the team is small, say 10-15 people, they must create new events, work on monetization, and develop core gameplay. But if the project has taken off and is generating significant revenue, it's crucial to organize a second development stream. This way, you can make the most out of the moment because you don't have to choose between making tactical improvements and pursuing strategic development that ensures the project’s long-term success. 

Our teams are divided into streams:

1. A stream focused on creating future new big features for events. This team creates new gameplay layers, mechanics for events, and events themselves. 
2. The second team operates events within the framework of existing mechanics. People working in this stream also polish primary monetization and UX. 

To break it down further, the task of one team (let’s call it the big features team) is to create an event framework. Once ready, it's handed over to the “LiveOps team,” which then draws new skins, adds new rewards, adjusts the balance, and tweaks offers within the existing structure, primarily working with configurations.

If we want a new type of event, we go back to the big features team to develop, for example, new combat mechanics with skills and abilities. This is then passed to the LiveOps team, which experiments with duration, balance, and other variables within the established framework.

You might wonder if this causes burnout. It’s a valid concern.

Firstly, people can periodically switch streams.

Secondly, the LiveOps team often acts as a bootcamp for employees looking to grow and move on.

To be honest, the LiveOps team frequently produces the most skilled specialists. Why? Because they have a super short feedback loop with the market. Hypothesis, test, hypothesis, test. While big features can take months to develop and might miss the mark, LiveOps offers a fast-paced environment that helps build personal expertise quickly.

A short feedback cycle always means faster learning. After testing numerous hypotheses and conducting many experiments, specialists begin to understand how the market works and what players truly want.