Mind Candy

Over here at Moshi HQ, we’ve spent a fair bit of time looking at how to reduce the size of the SWFs we publish to ensure that the game loads quicker for all our users (and to cut down on bandwidth cost!); here’s our quick checklist that we rattle through to get the most bang for our buck (or in this case, Kb)

Joa Ebert’s Apparat.
Joa is an ActionScript hero (in fact he won an award to prove it); one of his tools is Apparat – a Scala application which optimises SWFs by tinkering with the compression they use. Apparat is a real quick win as once you’ve integrated it into your build process you will immediately being reaping the rewards.

Sothink SWF Decompiler
Yes, number two on my list is a decompiler; this is not a mistake. Sothink SWF Decompiler is an essential part of the optimisation process as it allows you to explore all the assets, ActionScript classes, fonts, bitmaps, etc which are lurking around in your SWF – think of it like a visual Size Report for a SWF.

Making use of Run Time Shared Libraries
Flex developers seem very comfortable with Runtime Shared Libraries, but it’s something that most ActionScript dev’s aren’t so hot on. The MXMLC compiler provides a couple of ways to reduce the size of your published SWF by allowing you to automatically exclude duplicated class definitions across SWFs loaded at run time. The problem is a very simple one; you have a Main application which loads in a bunch of child “sub apps” into the same Application Domain; both of the SWFs end up with the same classes compiled into them (for example, you may be using famework elements in both) – because the Main application SWF has already loaded these classes there is no need to include them into the child swf as well.

The simplest MXMLC compiler flag you can use is, -runtime-shared-libraries, simply point it at the location of your Main SWF when compiling the subapps and it will do the rest for you. Alternatively, Those of you who worked in AS2 back in the day may recall the old exclude.xml; well it’s still alive and kicking with MXMLC, it just goes under the name of -link-report.

The process is pretty straight forward, compile your main application supplying the link-report flag, this will dump out an XML file. Next, compile all your subapps supplying the load-externs flag. Keith Peters goes into more detail on his blog.

Checking our Compiler Flags
This may seem pretty obvious, but it’s important to check; The MXMLC compiler which ships with the Flex SDK supports a crazy number of switches and options, the following options can impact on the size of the compiled SWF:

• -debug – Pretty obvious, if you set the debug flag to true when compiling, MXMLC will embed a whole bunch of debugging information to your SWF, bloating out the filesize. The main thing to watch out for is that you don’t end up deploying SWFs compiled with the debug flag set to true on your live server. Sames goes for the -optimise and -verbose-stacktraces flags
• -include-libraries – Make sure that you didn’t mean to use -library-path instead! include-libraries will compile the entire contents of a SWC into your final SWF file even if you never actually use any of it! Using library-path, on the other hand, results in only the classes which you import being compiled into the SWF

All of the above require no changes to our existing codebase, but combined have resulted in a massive reduction for the size, and loading time of our SWFs.

The latest figures show 1.7 billion people online every day, around the globe. In the US, 32 million young people under 17 are online every day (Nielsen 2009). If we think of the web as a virtual place (which it is), that’s approximately the physical equivalent of California’s total population.  That’s a lot of young people and a lot of virtual territory.

Monstro City’s population is 20 million strong; roughly Australia’s population. There are various government agencies to manage the country, including 14 federal and state law enforcement agencies. I’m guessing these agencies employ several hundred people, at a minimum  (I couldn’t find a number anywhere but I’m sure someone will email me with the information). We can’t consider Monstro City and Australia equal in terms of demographics, and the advantage we have on the web is that it takes quite a bit more effort to physically threaten or harm someone than the offline world. As several authors have noted over the years, “comparisons are odious.”  The point of the comparison, odious or otherwise, is that at the end of the day -  we are responsible for managing public safety for a population nearly the size of a country and continent. And the burning question is “How does Mind Candy manage 20 million people?”

Mind Candy employs about 30 full-time and 15 part-time people who run the entire Moshi Monsters operation. The team responsible for managing user behavior (or, online public safety) is the Community Team. We employ 22 staff members who are responsible for  community content, Social Media & events, Customer Service, Membership, Parent & Teacher contact, site moderation, behavior management, and online safety & education.  We couldn’t possibly manage 20 million Monster Owners with a team of 22 so we turn to 3rd party software providers for assistance. Thanks to technology (and the blood, sweat and tears of some forward thinking tech pioneers), we use 3rd party and proprietary software that allows us to manage the site efficiently and effectively with large concurrent populations.

In the early days, the Web 1.0 solution to online public safety involved staff responding to user-generated help requests or conduct reports. A staff member would be alerted to the report and then respond accordingly. It was all we had to work with at the time and involved hiring and training large numbers of people to respond reactively to problem behavior report, manually. Fast forward to 2009/2010 where we have available technology that allows the online public safety process more accurate, efficient and cost effective. The Web 1.0 method is not only ineffective and inefficient, it’s quite expensive. For example, World of Warcraft claims 1 million concurrent users on their English servers, alone. Using the Web 1.0 Moderation system would require WoW to hire at least 500 concurrent real-time, moderators just to keep up with user-generated reported issues. Why even consider this method when we have technology that not only catches problem behavior in real-time, but it analyses and prioritizes it, which allows your Community team to spend time on the potentially serious issues instead of issues such as “I need a boyfriend” and “What happens when I push this button” (95+% of user-generated reports I’ve witnessed at 3 major corporations over the past 16 years are frivolous or false, which wastes staff time.  This online false reporting issue is equal to “my cat is up a tree” calls to Public Safety offline).

Sites like ours, with a large populations, can no longer afford to use the Web 1.0 Moderation system. It’s not only expensive but it’s not as safe as content analysis via good technology. We couldn’t hire enough humans to follow every user around and watch them while they type. Thankfully, technology does this for us and allows our Community professionals to focus on the serious issues and to pay attention to and interact with the 98% of our population who are creative, well-behaved, good netizens and who contribute positively to our community. We’ll always need our lovely, professional humans – but we welcome advanced behavior management technology with open arms.

I feel certain parents, guardians and teachers want us to spend the majority of our staff time with kids online (kids of all ages, in fact)  by engaging, building, creating, and learning together. Moshi Monster’s Blog has more community interaction than any of our competitors – by a factor of 200 in fact. Monstro City is a vibrant, growing, excellent community – and we have technology (and our fabulous Monstro City citizens and roarkers) to thank.

For a while now I’ve wanted to write a blog post about how the game development process works at Mind Candy. We use an Agile development process called Scrum, and it suits our business very well.

Over the course of 3 months we recorded an essential part of the Scrum process at Mind Candy: the movement of tasks over our 10 foot tall scrum boards. We have these boards at the back of the office for everyone to see, and it’s a great way for the whole company to get a feel for what features are currently being developed and how well they’re going.

I had originally envisioned a mammoth post going into great detail about how wonderful scrum is for a creative startup like Mind Candy, the benefits it brings our awesome developers and how, as a management team, knowing that we’re always working on the highest priority work to keep our millions of users growing and actively engaged is a great thing, but the irony is that I spent so long thinking about the post that I never actually wrote anything, and that’s what the heart of scrum is all about: releasing the minimal marketable feature as early as possible.

So here you have the first iteration of my post about scrum, as well as the first of hopefully many time-lapse videos of how our processes work at Mind Candy.

If working in a fast paced environment using a process that empowers everyone on the team to create amazing products interests you, then good news! We’re recruiting and we’d love to hear from you.

Moshi Monsters is loads of fun, outstanding visually, and wonderfully creative. These are our best qualities, in our not-so-humble opinion. We know we have bragging rights in these particular areas and we duly exercise them (every chance we get). We can’t contain ourselves and why should we?

The entire Mind Candy team gets excited and is quite proud of Moshi Monsters and for good reason. We know that “like attracts like” and “birds of a feather flock together” and therefore we know that each of the aforementioned qualities attracts fun, creative, outstanding Moshi players.

It’s not that we’re lucky. 18 million Monster Owners didn’t fall in our laps. We work hard, work smart, work creatively, and we have FUN. We also realise the collaboration between Moshi Monster Owners (our lovely community) and the far-reaching Mind Candy staff is one of the keys to Moshi’s success. The Mind Candy way of working has generated nearly 19 Million Monster Owners. That’s a LOT of Monsters.

While we’re dedicated to the concept of fun, we are also dedicated to expanding brain power through education – both cultural and academic education. This week and next, we’re addressing a very important issue in Great Britain; the election of a Prime Monster…I mean, Minister! And we’re addressing it using our best qualities because we know we’ll attract the brightest, most creative, most fun minds.

We hope you’ll take a moment to follow and participate in our very own ‘Prime Monster Candidates Visit Monstro City‘ blog series. Children learn by seeing, hearing, and doing. We’re asking that each of us see, hear and do our best to help young people learn about the election process and the importance of voting in a free society where every vote counts and where we can have our say by participating as responsible, informed, citizens. And let’s have FUN while we’re at it. :)

It really does take a village,
The Moshi Staff