About that interview with Peter Molyneux

When I stood up this morning, I wanted to write about that game I’m working on. But I’m not going to do that. That’s because I’ve finally come to read that interview with Peter Molyneux everyone’s been so furious about yesterday. Now, I am, too. But I think for completely different reasons.

That interview with Peter hurts me. It really, really hurts me. Not because of the things Peter did say and didn’t achieve. Not because of how he’s acting throughout the interview, trying to defend himself. But because of the way he is questioned here. Everybody who has to make like 1k business decisions each and every day will be aware that some of these decisions will inevitably be wrong.

And holding such a person up for this is not fair. Don’t get me wrong: It’s true he should apologize for these mistakes.

But he shouldn’t be taken on for them like this. Nobody should.

“Now I wish that every single idea you ever had when you’re developing a game works first time, but they don’t.”

Everybody who does not agree with this either hasn’t seriously been working on any game before – or they’re a fool.

Kudos to you, Peter Molyneux. There’s someone out there who’s on your side.


Game Analytics for Windows Phone 8.1 & Windows Store

Game analytics can help a great deal in improving your games. By tracking downloads and in-app purchases, player demography, average session length, player progress and performance, as well as quality metrics such as crashes, companies are constantly trying to be one step ahead of their competitors.

At slash games, we’ve been using GameAnalytics for about a year now. It’s easy to implement, easy to use, and it provides great visualizations, custom reports and funnels. Oh, and it’s free.

While GameAnalytics already provides integration for Unity, iOS, Android, Corona and Flash, there’s been no native integration for Windows Phone and Windows Store apps so far.

Based on their REST API and on the work by Jason Ericson, I’ve succeeded in creating a native plugin for Windows Phone 8.1 and Windows Store apps. You just have to include a single source code file in your project, and sending an event to the GameAnalytics backend becomes as easy as

The plugin automatically generates unique session ids, uses the app package version as build id, and the Application Specific Hardware Identifier (ASHWID) as user id by default. However, you can change these at any time.

The library is open source, works out-of-the-box with the standard Visual Studio “Visual C++ Windows Phone DirectX App” and “Visual C++ Windows Store DirectX App” templates, and is tested to pass store validation:


EDIT: Works with Windows Phone 8 apps as well now! Enjoy!

C++ Windows Store app validation fails

If  you’ve recently run the Windows App Cert Kit for your C++ Windows Store app, you might have encountered these or similar failures of the Supported API test:

You’ve ensured you’re not building in Debug mode. The error persists. And you could swear, a few days ago, everything was fine.

Clearly, msvc dlls are not the type of code you would have written yourself. So what to do about this?

Luckily, the friendly folks over at the MSDN forums have isolated the issue, verifying that it can (temporarily) be resolved by uninstalling the recent Windows update KB2976978. This is the officially recommended workaround by Microsoft for the time being, as well.

Note that the above errors won’t cause your app to fail submission.

I’ll update this post as soon as there’s anything new!

Lua in C++ Windows Store Apps

Many games support script languages to be able to change their logic with having to re-compile: Blizzard allows customizing your World of Warcraft user interface with Lua, for instance, and CCP built EVE Online around Stackless Python.

I’ve been messing around with C++ Windows Store Apps recently, more specifically with DirectX games for Windows Store. It required quite a bit of an effort to get Lua to run (and validate) with Windows Store apps, and I’d like to share my learnings.

  1. Download and install Microsoft Visual Studio Express 2013 for Windows, and create a new Visual C++ Windows Store DirectX App.Create a new Visual C++ Windows Store DirectX App.
  2. Download and extract the Lua 5.2.3 source code.
  3. Copy and include the contents of the Lua src folder in your project.
  4. VC++ does not support C++/CX extensions in files compiled as C. Select all Lua C source code files, and open the properties dialog. In Configuration Properties > C/C++ > General, change Consume Windows Runtime Extension to NoChange Consume Windows Runtime Extension to No.
  5. The precompiled header file (pch.h) for the Windows Store App is C++ and can’t be used from C. With all Lua C source code files still selected, open the properties dialog. In Configuration Properties > C/C++ > Precompiled Headers, change Precompiled Header to Not Using Precompiled Headers.Change Precompiled Header to Not Using Precompiled Headers.
  6. Some of the functions in Lua call system and IO functions that are not supported by Windows Store Apps – but we’re not going use them anyway:
    1. First, we need to disable deprecation warnings for these functions treated as errors. In the properties of your C++ project, in Configuration Properties > C/C++ > Preprocessor, add _CRT_SECURE_NO_WARNINGS to your Proprocessor Definitions.Add _CRT_SECURE_NO_WARNINGS to your Proprocessor Definitions.
    2. Next, in luaconf.h, remove the LUA_DL_DLL define in the #if defined(LUA_WIN) section.
    3. In lualib.c, remove the io_popen and io_pclose functions, and remove the popen entry from the iolib array in the same code file.
    4. In lua.c, loadlib.c and loslib.c, replace all calls to the getenv function by NULL. These functions are designed to handle NULL as a failed call to getenv.
    5. Finally, in loslib.c, remove the os_execute function and its entry in the syslib array in the same file.
  7. In the source file luac.c, remove the main function.
  8. Build and deploy the solution, and observe that validating it using the Windows App Certification Kit succeeds, except for the Branding validation test that requires you to replace the app icon images.

Congratulations, you’re good to go! Go ahead, and take your first steps with the overview of the Lua C API!


1. Justin M. Chase. Embedding Lua into a Windows Store app. January 13, 2014.

Unity3D Windows Store – Part 3: Reflections

In the first two parts of this series, we’ve talked about how to build and run a Unity3D game targeting the Windows Store platform, and we took a look at the limitations of .NET for Windows Store apps and how to pass the Windows App Cert Kit tests with our game.

One of these major limitations is the .NET for Windows Store apps Reflections API. Many of the methods you’re used to call for accessing types and type information are not available here, so we were forced to re-write them for our current Windows Store game. In this article, I’d like to summarize our learnings, hoping that I can spare you some headaches in this regard.

Accessing basic type information

In .NET for Windows Store apps, some functionality of the System.Type class has moved to the System.Reflection.TypeInfo class. The official explanation for this from the .NET documentation is as follows:

Type object represents a reference to a type definition, whereas a TypeInfo object represents the type definition itself. This enables you to manipulate Type objects without necessarily requiring the runtime to load the assembly they reference. Getting the associated TypeInfo object forces the assembly to load.

So basically, many things you were used to do with Type objects need to be done with the associated TypeInfo objects now:

 Retrieving all loaded assemblies

One might think that this might be a fairly easy task. Usually, you can refer to the current app domain using the static property System.AppDomain.CurrentDomain and call the System.AppDomain.GetAssemblies method to access a list of all assemblies that are currently available. As we learned in the previous part of this series, there’s a workaround out there on StackOverflow. This approach uses File I/O to find all libraries in the install location of your app, loads these libraries, and refers to the loaded types of those. Obviously, doing so every time results in an immense performance hit, so you’re better off caching these assemblies, which are very unlikely to change during app run-time anyway. Furthermore, trying to load an assembly for which the C++ compiler stripped the relocation addresses, such as Unity dlls, fails with a BadImageFormatException you might want to catch. Our final solution, getting rid of the nasty async keyword, looks like this:

 Finding a type by name

Sounds even easier than the previous one, doesn’t it? We first ran into issues doing so in the general .NET framework when we started using multiple assemblies in a single project. The default Type.GetType method requires you to pass the assembly-qualified name for finding a type. However, in our project, we were

  • storing some type names in XML data files for instantiating these types at runtime, and
  • automatically increasing the assembly version in each build.

Thus, every build would have invalidated all of our data files, because the assembly-qualified name would have changed due to the new version number. Thus, we were using Assembly.GetType instead, just passing the namespace-qualified name of the type we wanted to look up. With .NET for Windows Store apps, finding all assemblies was a problem, but we solved that in the last section. Finally, we wanted to get rid of the version, culture and public key token of all types that were used as type parameters for generic types (e.g. System.Collections.Generic.List`1[[System.Int32,mscorlib, Version=,Culture=neutral,PublicKeyToken=b77a5c561934e089]]). Doing so with regular expressions was crazy slow on our Windows RT devices, so we’re doing that the good ol’ substring way now:

 Accessing the members of a type

Finally, if you wanted to get the field, property or method of a type, you’ve been using the Type.GetField, Type.GetProperty and Type.GetMethod methods before, respectively. In .NET for Windows Store apps, none of these is available. The TypeInfo class mentioned before offers a method called System.Reflection.TypeInfo.GetDeclaredField, and similar methods for properties and methods, but these don’t look for the specified members in the base types of the type you’re accessing. Thus, you’re forced to recursively look up the member in the base types yourself:

As always, feel free to share your thoughts or ask any questions in the comments below!