Microsoft Casual Games

At Arkadium, I worked on a team developing Windows 8+ games for the Microsoft Casual Games division of Xbox Game Studios.
When I joined the team, the core products had already been built and launched. My role was not to create the initial versions from scratch, but to help evolve and stabilize games that were already running at massive scale. That meant developing new features, fixing bugs, analyzing crash dumps, and improving shared technical parts used across multiple titles.
The lineup included products such as Microsoft Solitaire Collection, Microsoft Mahjong, Microsoft Jigsaw, and other games in the same ecosystem. These were not niche releases. They were iconic preinstalled Windows games that millions of people knew, launched, and recognized immediately.
Why this work mattered
One of the most striking things about this work was the scale.
At the time, the Microsoft Casual Games audience was enormous, to the point that it felt larger than the active audiences of Steam, PlayStation, Xbox, and other gaming platforms combined by a wide margin. Microsoft Solitaire Collection alone reached 100 million unique monthly users, according to Microsoft's own announcement:
Microsoft Solitaire Collection reaches 100 million unique users
Working on software with that kind of reach was both a huge responsibility and a real source of pride. These were the kinds of products that shipped with Windows itself, so almost every Windows user was familiar with them.
My role
My work focused on desktop .NET engineering in production at very large scale. In practical terms, that included:
- developing new features
- fixing functional and stability bugs
- investigating crash dumps and production failures
- improving startup time and runtime performance
- working on multithreading issues
- contributing to shared code and infrastructure used across several games
- helping reduce build size for Windows preinstallation constraints
Technologies
UWP, C#, .NET Native, TPL, Xbox Services
Key achievements
- I found and fixed a serious memory leak in Microsoft Jigsaw that multiple developers had been unable to identify for months. I traced it down in about a week.
- I improved Microsoft Mahjong startup performance by roughly 5x.
- I was part of the team that added advertising and video ads across the game lineup. People are free to blame me for that one.
- I fixed a large number of multithreading bugs, many of which were discovered through crash dump analysis rather than easy local reproduction.
- I took part in the effort to reduce build size so the games could fit strict requirements for being preinstalled on Windows media.
Engineering at massive scale
The work itself was incredibly interesting because products at this scale behave differently from ordinary applications.
When you have millions of users, even small percentages turn into huge absolute numbers. At one point, our crash tracking backlog contained around 40,000 issues. A large portion of those reports came from unstable Windows builds, problematic hardware, broken drivers, or duplicate crash signatures rather than from clean, actionable product bugs. That made the job much more difficult: improving stability was not only about fixing your own code, but also about understanding where the real signal ended and the platform noise began.
This was one of the most educational parts of the project for me. It forced very practical thinking about:
- telemetry quality
- dump analysis
- concurrency defects
- startup performance
- memory behavior
- release constraints at operating-system scale
What happened later
One disappointing part of the story is that my name, along with the names of many other people who worked on these games, was later removed from the in-game credits. I do not know the exact reason, but I still consider that unfair.
I do know that the wider situation around the project became difficult. A large part of the team, roughly 80%, was eventually laid off as Arkadium's contract situation with Microsoft deteriorated. In the end, the contract was closed and further development moved to other teams.
My best interpretation of what happened is this: Microsoft wanted the audience to grow even further, and that likely meant bringing the casual games portfolio to iOS and Android. At the time, there was no practical way to bring a UWP-based codebase to those platforms at the required quality level, and Xamarin was not mature enough to solve that problem well. Microsoft chose Unity instead and expected our team to learn it quickly, rewrite Microsoft Solitaire Collection in Unity, and also build Wordament and Ultimate Word Games in the same stack from scratch.
That plan did not work out within the expected timeframe. Whether the problem was execution, planning, or both, I cannot say with certainty. What I do know is that Wordament and Ultimate Word Games was eventually given to another company, that company succeeded, later rewrote Solitaire Collection in Unity as well, and, as I understand it, the other games gradually moved in the same direction too.
It is a pity that the story ended that way, because the actual engineering work on the original products was genuinely fascinating. Even so, I remain proud that I had the chance to contribute to such well-known Windows software used by an audience of truly unusual size.
The team itself was also a major part of why I remember this period so fondly. It was an exceptionally friendly and extremely professional group. I still miss many of the people I worked with there, and I genuinely hope I get the chance to work with at least some of them again someday.
