Having developed multiple successful puzzle titles, Incubator Games was commissioned to create the F2P matching game Block Star Battle. The basic premise was to replicate the puzzle mechanics of Panel de Pon while providing online multiplayer in the vein of Facebook-Tetris.

Tetris Online benefited from tremendous brand recognition, but it lacked built-in avatars for players to identify with and customize. There were some attempts to implement these after the game’s launch, but the attempts proved largely unsuccessful. Consequently, I made sure to designate a recognizable character mascot a starting priority for BSB.

The bloblings concepted by our artist were heavily customizable, allowing players to change their colour, victory quote, and various pieces of equipment. The bloblings were also one of the main driving forces for progression, so I decided to complement their aesthetic upgrades with additional special skills.

Once all the pieces of an outfit were unlocked, the player received an equipable emblem that could be used in-game. Only one emblem could be active at a time, and its ability only became available once a “super bar” filled up by making matches. The abilities themselves were thematic to the originating outfit and could perform functions such as pushing hostile blocks back up, destroying certain pieces present on the game board, and littering an opponent’s area with garbage pieces.

Panel de Pon contained a rather sharp skill-spike as its core mechanics eventually demanded that the player visualize the gameboard multiple moves in advance. To help alleviate this requirement, I pushed for a sophisticated look-ahead hint mechanic. Unlike the hint systems of other puzzle games, BSB’s favoured matches that would result in chain reactions and quickly moved on to the next possible match to help continue a combo.

An additional benefit of this system was that it allowed us to create AI opponents that could easily scale to the player’s skill level. The AI’s capabilities for how quickly it identified a match, the pace at which it moved the cursor, and how long it attempted to continue a combo created a lofty challenge for most players.

Although we implemented a modified trueskill system for matchmaking, it was only utilized for high-tier competitors. Most players never reached this skill-level, and trying to ensure a 50/50 win-loss split was not desirable for a casual user base. Instead, I funneled players to compete against friends and AI opponents, only presenting human challengers every time enough victories were obtained.

A 4-player free-for-all mode was also added for extra variety and to alleviate some of the issues of real-life challengers. In 4-player battles, at least one opponent was always a low-skill AI, and combos/emblem-abilities tended to target the player in the lead. This ensured a back and forth dynamic and framed player placement in an Olympic-style podium (1st, 2nd, or 3rd place — the AI rarely finished in the top-3) rather than the harsh scenario of seeing a lose-screen.

Despite BSB’s dedicated user base, a competitive, real-time multiplayer game proved to have something of a natural player-cap on Facebook. Instead of pushing it with more advertising, Incubator Games was commissioned to develop a second game in the series to attract a new audience and foster some cross-pollination.

The BSB sequel, Block Star Party, closely emulated Candy Crush Saga while introducing some new elements to the successful match-3 formula.

From the beginning, BSP was designed to be simultaneously deployed to Facebook and iOS devices. Using an internal build process, we were able to create platform-specific versions of the game while using unique assets and intelligent UI-positioning. This allowed us to have a singular end-user experience regardless of device, which wasn’t the case with King’s games — Candy Crush levels varied between Facebook and iOS, and updates were not released at the same time on all platforms.

While I prototyped numerous game modes, powerups, blockers, and boosters, these were largely based on CCS and implemented in a somewhat straightforward fashion. The real challenge came with replicating the flow and progression that made King’s games so fulfilling.

Thankfully a Candy Crush wiki provided lots of information based on the consensus of thousands of users. I used these progression-logs to map the overall journey through CCS, noting each level’s difficulty, goals, and obstacles. In addition, I recorded any unique map gimmicks and first-time appearances of powerups and boosters.

My main takeaway from analyzing the flow of CCS was its heavy emphasis on variety. Game-modes tended to alternate as soon as they appeared, rarely presenting players with more than 2 levels in a row that contained similar boards or used the same goals. Each episode also attempts to add something new to the mix, whether it was a new type of blocker or a rare but useful booster.

As CCS progressed, the rate at which new mechanics were introduced gradually diminished. A large part of this that overall complexity grew exponentially with each new element introduced, minimizing the need for new features in order to create novel scenarios. In addition, players that made it to the mid/late stages could be considered “hooked.” These expert players had overcome difficult challenges and dedicated a substantial amount of time to the game, so the focus for them shifted from engagement to game-mastery.

CCS also provided us with a template for IAP costs, notification frequencies, friend requests, and all other systems for player engagement and retention. These were still A/B tested to achieve the best results, but we were slightly more generous than typical King games. The main reason for this was keeping existing players satisfied as BSP was a new property that couldn’t afford to alienate its users.

With a sophisticated deployment process and plenty of experience developing F2P titles, Incubator Games was commissioned to create a superhero themed card-battler Wartime X.

To minimize the barrier of entry, Wartime closely followed the basic rules of poker. Players were dealt small hands and aimed to create pairs, triples, straights, full houses, and flushes to “attack” their opponent.

Each character started off with 20 points of health, and the winning hand’s value was subtracted from the opponent’s HP pool. Once it reached 0, a winner was declared.

Matches were quick, but didn’t necessarily end after a few hands were played due to blocking. Every character possessed statistics in one of the four suits: spades (weaponry), hearts (strength), clubs (psionics), and diamonds (energy). If a card’s value exceeded a statistic, it would only be used to block instead of causing damage.

Most characters only specialized in one or two suits, typically having very low values in the ones that remained. This resulted in plenty of hands where damage was simply blocked, saving attacking cards for an opportunity to unleash full damage with a proper poker hand.

On top of this core gameplay rested a very content-heavy progression layer partially modeled after Star Wars: Galaxy of Heroes. I was responsible for creating and balancing all of its modes, maps, characters, items, abilities, events, and powerups while keeping the game thematically rooted in a world of super heroes and super villains.

In the main campaign mode, the player progressed through 44 different episodes, each one consisting of 7 real-world cities. Entering a city caused the camera to zoom in and pan around, going through a list of scripted locations that contained one of the main event types:

Minions – A battle against a group of weak opponents with no special abilities.
Cache – A treasure that yields equipment or a temporary buff.
Ambush – A trap that launches multiple attacks that must be blocked.
Demolition – An obstacle that must be destroyed in just a few rounds.
Boss – A battle against other characters with their own stats and abilities.

Anywhere from 5 to 9 events took place in a city, and between each event the player got to choose which direction to pursue in order to provide multiple paths for replayability. Once enough episodes were completed, a whole alternate game mode unlocked, the villain campaign, where players attempted to capture cities instead of liberating them.

Whether hero of villain, every character in the game could level-up, capped by the player’s own level. Level-training cost money and various resources obtained by completing city missions, but unlocked additional equipment slots, abilities, and increased the maximum health and suit-statistics.

As the single-player campaigns progressed, enemies leveled up as well, obtaining new gear, super powers, more health, and deadlier attacks.

All character and city art was provided to us by the client, but it was our job to ensure that the planned campaigns contained enough content to last 10 weeks on release.

Working backwards from this goal, I took into account all free energy refills, bonuses from daily logins, achievement rewards, and extras bestowed upon inviting friends, and used these to calculate the currency, XP, and stamina costs for obtaining all rewards without using in-app transactions. This created a progression that took roughly 3 months to complete, ignoring extra time spent if the player failed missions or replayed episodes to gather extra loot.

Despite a relatively large content-spread, every play session still rewarded the player with upgrade currency and training equipment, and a full day’s playtime was guaranteed to provide a new character, a new ability, or some new equipment even after a month of continuous play.

While most players participated in at least a few matches of Versus and Arena modes, these proved most popular with the more dedicated user-base. In particular, the Arena’s tournament setup resonated with expert players, particularly its long-term unlockables not present in single-player campaigns. These proved great for bragging rights and kept the community engaged in between major campaign updates.