Mystery Case Files: The 13th Skull was made in Flash. Let’s investigate …

My wife and I have been big fans of the Mystery Case Files games for years. The first few were genre defining moments in gaming, and I’m sure made the developers (and Big Fish Games) an awful lot of money in the process. So it was no great shock when we bought the 7th in the series, 13th Skull. The game itself is good puzzle solving fun, with wonderful hammy acting and FMV that reminded me of old CD-Rom games like 7th Guest. Something that has gotten bolder as the MCF series has evolved.

Being a curious sort of person I had a poke around the installation directory, and was genuinely surprised to find that the game used hundreds of SWF files. Some more poking around revealed a really nice game structure that I thought was worth talking about. Obviously I’m not the developer, Adrian Woods takes credit for that (along with coding he also did voice acting, graphics and animation too!). So this is just investigative guess-work on the most part, but fascinating all the same.

Each location and puzzle in the game is an individual SWF file

Opening one of these SWF files (from the Assets/Location folder) into Flash Player reveals something interesting.  As you can see in the picture below (click it for the full res version) there are differently marked zones. The green boxes represent “Movement Link” and the Aqua Blue boxes are “Hit Masks”. This is tavernExterior.swf:

Some of the other SWFs contain yellow boxes with exclamation marks in them, usually above animated characters.

This whole scene is animated. The water at the bottom ripples, the tavern sign animates and the lights flicker. It looks beautiful, and further investigation reveals it to be simple timeline animated sequences. High quality CG assets and Flash can do some great things. The animation is cut-up into sections, the bottom puddles being a couple of frames, masked in such a way that only the water is sequenced:

The idea of having the Movement Links and Hit Masks as Sprites is of course extremely sensible. Simply hidden at run-time it means the designer can move them around and tweak them as needed, without having to bother a developer.

WeatherFields and Particles

Mystery Case File games make good use of particle effects. From mouse trails to rain drops, they are typically found in most scenes. It was interesting to see that they appear to be controlled by the use of “WeatherFields”. Visible in the top-left of the tavern screen shot, the icon appears to represent the effect in action across the scene.

Particle definitions are stored in an XML file. A ParticleTemplate controls the base particle with values such as Count, Spawn Delay, Velocity, Rotation, Scale and Color. Particles also appear to be able to have Keyframes, which is an interesting concept in its own right.

Some of the particle names include HiddenObjectFound, HintGlimmerTrail and Smoke2. These appear to be used for the generic particles. Weather is controlled by ActionScript. When a WeatherField is added to a scene a reference is created which controls factors such as the Flake Count and Velocity. I really like the way these weather events are part of the scene. It means you could drop in different weather effects to visually see how they look. In the tavern example above the effect of the rain is pulled off by a combination of parlour tricks – the great CG assets in the first place making the scene look damp and soggy, the timelined puddle animations, the WeatherField that splashes across the whole scene and finally there are raindrop “splat” animations placed randomly. Add all of these things together with powerful audio and you’ve got yourself a totally believable soggy setting.

Package Structure

The game has its own package called MCF7. This is split into sections such as:

  • MCF7.ActionState
  • MCF7.Assets
  • MCF7.Collectible
  • MCF7.Engine
  • MCF7.GameState
  • MCF7.Hint
  • MCF7.Location
  • MCF7.Quest
  • MCF7.StrategyGuide
  • MCF7.Vignette
  • MCF7.Util
  • MCF7.Weather

… and I’m sure many more that I’ve yet to see. What I find most interesting about this structure is the depth into which it goes. MCF7.Collectible for example contains classes such as CrownInsignia. This is an extremely well organised system. MCF7 appears to over-ride Flashes native MovieClip class and extend it, adding some extra functionality on the top. I love the fact that the HintAgent is a class all of its own. The Game Engine and State Manager are kept independent of the Quests or graphical effects like the Vignette.

There is real clarity in the design and structure used, something a lot of Flash developers would do well to emulate.


As you’d expect with a game release this big it was built to be easily localised. This is handled with XML as you’d expect. Those of you who have translated your games in the past (for sponsors such as Spil) have probably already gone through the pain of getting all your text into an XML document and then reading it in, making sure the TextFields are correctly replaced, that fonts are embedded, etc. So spare a thought for the MCF team, who’s localisation file is 180Kb alone!

The MCF localisation XML uses the Flash IDE MovieClip name as the reference. For example:

<tavernKitchenHiddenObject_limeWedge_mc>Lime wedge</tavernKitchenHiddenObject_limeWedge_mc>

Here we can see that the tavernKitchenHiddenObject_limeWedge_mc MovieClip will display as Lime wedge in my English version.

It includes the name of literally every single item in the game (did you know that in the fridge there’s a hidden pancake for example?). Every location and every puzzle is broken down in the same way. Quests, Quest Items and Conversation Topics are broken down in a similar way. As are all of the Puzzle Hints (some of which I wish I had known before playing the game!)

The method of tying the translated text to the MovieClip name itself is a good one, and one I would certainly consider for future titles. I just hope I never have to deal with a translation job this large :)

Sounds and Video

All of the sound in MCF7 is stored in external MP3 files. Literally hundreds of them. Over 600 sound effects and nearly 70 music tracks, as well as Ambient sounds and all of the characters in the game. I assume that the sounds are loaded at run-time as you move from location to location. Each scene probably only uses around 40 at most, so with the speed of modern hard drives you don’t even notice the fact they are loaded each time. From a memory management point of view, something for which Flash has a pretty poor track record, it must be essential to be able to unload those sounds in order to keep memory in check.

Another interesting element about the sound is that MCF uses cuepoint files to control sub-titles. Here is a cuepoint from a piece of conversion you have with Charlotte:

I really like this technique! Something well worth exploring to hook events to sound. Video uses the same technique. As you’d imagine by now all video in the game are FLV files. When looking at the video files I found that there are 4 possible endings. On my play-through I figure I got one of the better ones!

Exe Wrapper

The main MCF EXE is a UPX packed file. Somewhat annoyingly I couldn’t manage to unpack it using any of the usual means (NsPack, UPack, etc). Obviously it has Big Fish Games shell wrapped around it for license management and protection. Being unable to do this last step I wasn’t able to confirm exactly what lives in the final EXE, or indeed if it was the standard Flash Player, or a custom build (such as used in the likes of ScaleForm). From all that I’ve seen while digging through the assets and AS3 code embedded in the SWFs, I believe that the whole game is made in Flash. I may be wrong of course, and even if I am the asset management and location handling most certainly is.

What can we take away from all of this?

As a Flash game developer there are several things that this made me realise:

1) Commercial grade Flash games are possible. The Mystery Case Files series is a massive multi-million selling franchise, expanded out into books and other platforms. To think that even in their 7th release they are still building the games in Flash is really quite something. For me personally I find that very inspiring actually. For web games I wouldn’t have doubted Flashes ability for a second, but for a download title I’d have been highly sceptical previously.

2) Be organised with your code and your assets! This is something I strive to do in my personal and professional work alike. But it’s not always easy, not when deadlines loom or you just want to get finished and released. I guess after 7 iterations the MCF team have finely honed their game engine, but I expect that clarity and fastidious tidyness was there from the start.

3) Break your assets down into small chunks. I do this in my own games already, especially so for the ones I build at work. But it really does pay dividends if you’re building something big or asset heavy. Having all of the locations as single files was a bold move. It means very little asset sharing could take place between locations, but with today’s multi gigabyte hard drives being standard what do they care about a few MB saved? For web games we have to think differently, but there are still lessons to be learnt. There is no reason at all why you can’t keep your background items / scenery in one FLA, and your sprites in another. Flash CS5 moved towards working like this with its XML based FLA structure.

4) Great graphics really help :) The MCF games have always had beautiful graphics, and this release is no different. Their clever combination of CG, video, timeline sequences and particle effects all combine together for a lovely end result. Never under-estimate the power of good assets!

My full respect to Adrian Woods and the rest of the team at Big Fish Games who worked on MCF7. It’s a great game and highly entertaining. I’m sure it will be another massive title for them. For me personally I’m both inspired and still somewhat in awe of the fact it appears to be created in Flash. And even if the core game itself isn’t, all of the asset handling and management certainly is. And that’s pretty cool indeed.

Mystery Case Files: The 13th Skull is available from Big Fish Games.

Posted on November 28th 2010 at 2:50 am by .
View more posts in Experiments. Follow responses via the RSS 2.0 feed.

14 Responses

Leave a comment
  • November 28th 2010 at 4:16 am

    Great stuff as usual!

    “Commercial grade Flash games are possible.”

    I never doubted this in the first place! Many people who only know Flash marginally write it off as some sort of technology only suitable for small web games or ad-games. In particular like the fact that with AIR we can develop some decent desktop-based games. There’s the notion that you got to have the AIR runtime installed (or install it on top to install the game) but that’s a weak argument IMO. Compare installing the Java runtime to the AIR runtime! Java is almost as bloated and annoying as … malware! AIR on the other hand is slick and a breeze to install. There’s also the .net framework which is a runtime on which many games are based, although Microsoft has the advantage there that it can pre-install it on Windows.

  • November 28th 2010 at 4:39 am

    I have to disagree slightly as there are many genres Flash is totally unsuitable for. In fact I’d go so far as to say that the vast majority of gaming genres it can’t handle in a desktop arena. I always figured it could do hidden objects, just had no idea it was responsible for easily the Grand Daddy of them all.

  • November 28th 2010 at 6:17 am

    Richard, what games would that be where you think Flash isn’t suitable for desktop games? Of course, anything with more advanced 3D is difficult right now but that seems to be remedied with the upcoming Flash/AIR update mostly. Other than that I could make a bet with you to stomp out of the ground a full featured, large scale RPG or Strategy game made in Flash/AIR, provided I had a source for all the media assets required.
    Other than that: simpler games like platformers, racing games, anything 2D really. Maybe 3D flight sims? .. But that should be possible as well. Where would be the problem? The technology (speak: Flash) isn’t really the bottleneck for all this anymore.

  • Viza
    November 28th 2010 at 11:32 am

    I created two casual games in Flash, an it is not a completely unmixed blessing using flash for desktop games…

    There *are* issues with performance even in 2d games, since a desktop game must be at least 800×600 (or 1024×768) in resolution, and that already stretching flash’ capacibilities (not to mention todays casual players expect a lot of special effects, particles, moving parts etc).
    But yeah, that can be overcome more or less (with clever design, and some (well… a lot of) optimalisations).

    But most of the problems come when you have to deal with differences between the flash player and a “normal” desktop applications behavior:
    Fullscreen mode – the “fullscreen mode” in flash is not what you expect from a desktop game. A desktop game should switch the monitor resolution, appear correctly in the application switching menu (alt-tab), and stop correctly when minimized.
    Player plugin – You can’t ask the user to install the plugin. Yes I know 99.9% plugin penetration and all, but the portals still don’t want to hear about the possibility of forcing the user to install something other than the game.
    Other regular desktop application behaviors – We got bug reports because the game not appeared in the task manager in it’s own name (but under the exe wrappers name). Saving could be problematic (when using pure flash), shared objects generally won’t do, because there are standard locations where you have to put the save files.

    These issues are extremely frustrating to deal with, because they are not in our program/control (but in the creators of the exe wrapper for example).

    So I still not throughly convinced of they using pure flash for everything…
    I already saw that the MCF games are using swfs, but I always thought they just using it for storing data/assets, use the Flash editor as a game level/ui editor, and they own (C++ or whatever) program just reads the swfs as data files. The hit location rectangles, particle effect or localization XMLs are not proof of they are using flash for the main program, those are all more or less easily readable from other languages too. I don’t know about the flv videos, but I guess it is possible to play back them without flash too (VLC player comes to mind).

    The main argument for they using flash could be all these things together anyway… It seems too many work to do all that “by hand” and *not* using the flash player, with the not-that-much benefits of using Flash as an editor…

    Hmm… Thinking about it a little more maybe the best tip would be that they are using Scaleform… I don’t know the capacibilities of Scaleform, just judging from what I read on their website, most of my above issues are not applicable to it. They would have the speed, the regular desktop behavior, etc. (and surely the MCF games have the budget too, to allow licensing Scaleform :) )

  • November 28th 2010 at 11:45 am

    Viza, I admit your points are valid, the screen resolution matter being the biggest problem. Although I first complained about that the screen resolution cannot be changed with AIR I somewhat changed my mind over that because I learned to loathe screen res changes. They should best be prevented and instead fullscreenRect being used to ‘scale’ an area to the fullscreen, although this has the drawback that graphics might get blurry if they are scaled from a small area.

    Another bugger is that there’s no way to fully customize the keyboard layout. Security limitations my a**! I want to be able to change the ESC key so that players not always get thrown out of fullscreen mode if they accidentally hit ESC.

    But most of these are rather minor issues.

  • November 28th 2010 at 12:59 pm

    sascha – I would say that with the exception of MCF not one of the games I have installed could be done in Flash. It can’t even do consistently smooth scrolling mate! The internal timers are so shite you get unavoidable visual tearing. It just doesn’t have the speed in the renderer for most of the 2D games effects I see, especially not at the desktop resolutions we are accustomed to. For casual games, or games with very little actual animation / interactivity, sure it’s a contender. But the majority? I’m just flicking through my steam library now and I don’t see one it could do.

    Viza – You’re right, I don’t prove MCF7 was coded in Flash. But it strikes me as odd that if Flash was used purely for asset management why do they have classes for handling things like play state, quest logs and hint managers? If someone could help me unpack the main exe we’d know for sure :) You’re bang on right about your points though, And I too wondered if it could all be running from a Scaleform player (although the game never changes your desktop res, its alway 1024×768 scaled up, with black borders for edges. Fascinating stuff all the same :)

  • Viza
    November 28th 2010 at 4:30 pm

    sascha – Yes, since the advent of LCD monitors the screen resolution switching less important – stretching the graphics to full screen from software gives much better results than what the LCD monitors produce in lower resolutions.

    rich – I understand that the article doesn’t want to prove MCF was coded in flash – I just tried to do it for my own entertainment :) Skimming trough the article second try, it catch my eyes that you mention AS3 code – Are you sure it is AS3 and not AS2? Because I read the Scaleform website, and it seems that AS3 support is not available yet (but not far away). So if it is definitely AS3, than we can exclude Scaleform from the detective work. :)

  • November 28th 2010 at 5:56 pm

    The code is definitely AS3, and all the swfs are published for fp10

  • November 29th 2010 at 10:54 pm

    I like the part that you describe about weather and particles, I think my team should experiment with that sometimes. I also found pH hidden object game to be made in flash, and drawn series bonus are in flash too (maybe, just maybe, the whole game is in flash too).

    Ever wonder to try asking the developers instead attempt to unpack the game? :)

  • February 6th 2011 at 9:03 am

    Hi, I’m the lead programmer on MCF: 13th Skull. One of our developers on the MCF team pointed me to this article, and I thought I’d answer some of the questions you guys have posted (albeit about 2 months late, sorry!).

    Yes, the entire game was written in Flash and AS3. We use a combination of internal and external tools to get it into the form we distribute on our website in order to solve many of the issues Viza posted above. The executable comes bundled with the player so we don’t have to worry about the customer having it installed. We can also leverage Flash’s ExternalInterface class to communicate between the game and our wrapping layer to implement things like filesystem access. But it is entirely possible to play the game using the standalone Flash player.

    Splitting up the scenes into separate SWF files was done for many of the reasons you’ve observed above. Since the player can only be in one scene at a time, it makes for a very convenient and logical structure for splitting up the assets used in the game. We weren’t that worried about wasted space, as scenes rarely have shared art assets between them (The most commonly shared asset between scenes is sound effects, and this is why they are kept as separate mp3s.). But this also lets us easily unload all of the assets from a scene we no longer need. We keep a small cache of previously visited scenes in memory, as players tend to move between a small set while solving a puzzle or completing an objective and this keeps transitions smooth.

    The MovementLink and HitMask sprites were to solve a problem we encountered with the previous MCF: Dire Grove. When opening a scene in the Flash authoring tool, it was difficult to understand what parts of the screen were clickable and what clicking on them did. By making these dedicated sprites instead of attaching code to arbitrary display objects, it’s easy to see where all of the clickable areas are at. This also allows us to know which scenes are adjacent to the current scene at load time, so we can prioritize loading nearby scenes into memory and unload scenes that are farther away from the player.

    Anyway, thanks for the kind words about our game. Programming is always one of the more transparent parts of game design for players, so getting some feedback from fellow Flash programmers about our architecture and design decisions is always nice.

    Feel free to post any other questions you might have. It’d be fun to have more discussions about technical details like code structure and architecture, as it seems to be one of those topics that Flash programmers tend to either gloss over or keep to themselves.

  • Viza
    February 6th 2011 at 9:49 pm

    Hi Michael!

    Thank you for sharing these infos!

    I have a couple of questions:
    When you say: “The executable comes bundled with the player” does it means that the game comes with an “official” flash player installer, or with a “pure” flash plugin built in? (maybe the one which is used by Firefox/Chromium/etc or the ActiveX one)

    What are the mentioned “external tools” you use?

    What were the main reasons to choose flash to create the game in?
    What were the main challenges during the development when you were pissed off with flash, and how do you overcame those?
    (Well… I guess the last two questions are forming a kind of postmortem :) What went good/what went wrong, but only from a technical/flash developer viewpoint)

  • March 29th 2011 at 7:18 am

    I’ve tried to play MCF: The 13th Skull on numerous occasions but the developers haven’t taken into account screen resolution changes and it’s ridiculously resource heavy, so no matter what I change on my desktop the game won’t play. A pity, particularly as its’ the only BFG game I’ve ever had problems with like this. Luckily, I downloaded the 60 minute trial before I wasted money on it.

  • March 29th 2011 at 11:17 am

    Leo – I know for a fact BFG have an extensive QA period which it would have passed before being released. This isn’t BFG Tech Support, take it there.

Make yourself heard