One engine, many games: how a small studio shipped 160+ titles
In 2014 MadSword turned from a studio with one flagship game into a contract studio for a Dutch publisher. The publisher needed a steady stream of casual games, and each one had to be cheap to make.
I wrote the game engines for each genre we took on — match-3, Pet Rescue-style puzzles, Gem Splash, Clash of Cards, a tower defense, a bubble shooter, a zombie shooter. After the third one it was obvious they shared most of their code: store and ad integrations, a world map of levels, server-side saves, analytics, daily bonuses. So I pulled that part out into its own repository, Engine. It served us for years.
With the core in place, a new logic game with a playing field took a couple of weeks. A tower defense in the spirit of Kingdom Rush was assembled on the Steam Defense engine by a content creator, not a programmer. A Jelly Splash-like game and a solitaire came out of the match-3 code with small changes. On top of that, a skin system let us release the same mechanics under new art: over the years, 100+ skins and thousands of levels.
In September 2015 the publisher’s founder, Vasco, came to Riga with a long-term deal: 12 updates and 2 new skins a week, plus a new game every quarter.
With Vasco (right), the founder of Vasco Games, in the MadSword office on 11 September 2015 — the day we agreed the long-term deal.
A slice of the release plan: two match-3 skins a week, alternating between two Google Play accounts.
| Week | Game | Store account | Gameplay |
|---|---|---|---|
| 24 | Fruit Jam Splash | Puzzle | Match 3 |
| 24 | Regal Mania Deluxe: Match 3 | Go Vuzzle | Match 3 |
| 25 | Finding Fish Frenzy | Puzzle | Match 3 |
| 25 | Toy World Fun Carnival Blast | Go Vuzzle | Match 3 |
| 26 | Blossom Jam: Flower Shop | Puzzle | Match 3 |
| 26 | Sea Mania Island | Go Vuzzle | Match 3 |
| 27 | Forest Frenzy | Go Vuzzle | Match 3 |
| 27 | Jelly Jam Splash | Puzzle | Match 3 |
That is how a team of up to 35 people shipped 160+ games with 20M+ downloads.
MadSword at its peak: the team at a New Year costume party, end of 2016.
The lesson I still apply: don’t design the shared core up front. Build two or three real products, then extract what they actually have in common.