How Do Good Ideas Spread?

We yearn for frictionless, technological solutions. But people talking to people is still the way that norms and standards change.

What makes a successful company? People and culture must be at or near the top of the list. Sometimes company cultures need fixing. If you’ve ever been involved in an effort to change culture you’ll know that it’s hard. Really hard. Atul Gawande has a great article on changing social norms in the world at large in the context of medicine. Culture is a social problem. Forming it and changing it is as low tech as you can get.

… people follow the lead of other people they know and trust when they decide whether to take it up. Every change requires effort, and the decision to make that effort is a social process.

Atul Gawande’s Slow Ideas

Playscript: Actionscript For .NET

Miguel de Icaza:

PlayScript is a superset of ActionScript and it was based on Mono’s C# 5.0 compiler. PlayScript is ActionScript augmented with C# 5.0 features.

Zynga’s PlayScript allows developers that have some ActionScript/Flash code to bring their code to any platform that supports the ECMA Intermediate Language (Microsoft .NET and Mono) and blend it with other .NET languages.

But the PlayScript has a fabulous feature, it allows mixing code in both C# and PlayScript in the same compilation unit.

Playscript

There have been a bunch of interesting new languages on the .NET platform which haven’t reached critical mass. Are there enough ActionScript developers and code out there to make PlayScript viable?

Syntax Coloring Shader Files in Xamarin Studio 4

Since Xamarin released the renamed MonoDevelop 4 as Xamarin Studio I’ve been using it alongside Unity 3D for all my development. It’s definitively better than the Unity-bundled version of MonoDevelop (2.8 with Unity’s patches) for C# development on a Mac. I think I’ve found my new favorite IDE – a title that MonoDevelop has previously never quite taken. There’s still a few rough edges though. The ones I care about most are Unity related. The Unity debugging plugins are missing, but I can live with that for a while. Unfortunately syntax coloring isn’t enabled for shader files, at least those with .shader and .cginc extensions. It’s amazing how hard code becomes to write when syntax coloring isn’t present!

Shader Code Fades to Black And White

Thanks to some helpful feedback on the Xamarin forums it’s clear that all the parts are there, but those file extensions need to have their mime type correctly for CG shaders. That requires writing a add-in, although it only needs to contain an XML file which gets compiled into a dll. Michael Hutchinson pointed me at the getting started documentation for add-ins. Add a dash of effort and out pops https://github.com/jools-adams/monodevelop-unity-mimetypes. Just compile it and drop the dll here (on Mac):

~/Library/Application Support/XamarinStudio-4.0/LocalInstall/Addins

Evil Merges in Git

What makes Evil Merges in Git … Evil?

The Git Glossary defines an “Evil merge” as…

a merge that introduces changes that do not appear in any parent.

To me that sounds like any merge with a non-trivial conflict. The sort of conflict that needs hand editing, rather than simply taking yours or theirs for each hunk. That’s pretty common, so why is it evil? To be honest I’m just guessing, but one feature of git that slowed me down considerably when trying to find out who had removed some lines from the file is that git log pretends that merge commits don’t change any files. Try

git log --stat

on a repository with merges. It says merges never change any files, even though they really do. Adding the options -c, --cc or -m to git log suddenly shows merge stats for files which had to change in a merge. When you do a search with git pickaxe the behaviour is the same; the search won’t find anything in merge commits unless you use one of those options.

To me that sounds totally crazy, but perhaps it makes some sense if you’re interested in where changes were first introduced. In that case you’re interested in the initial commit which created the change, not the merge-commit which is a later artifact of the revision control process.

However it hides the contents of Evil Merges by default and to my mind that is Git rather than the Merge being Evil.

Unity3D Live Code Reloading

After University I worked with 3 brothers. They’d written the software for an ISDN (remember that?) test system called the A8619. It was basically a PC, with a custom card in it, which contained (amongst many other things) another x86 processor. There was another team having trouble programming the x86 on the card. You wrote software for the card in C, compiled it to a binary, burnt it onto a prom, put it in the card, rebuilt the PC. It hurt; they were getting nowhere fast. So these chaps wrote a simple program for the card. It just sat there waiting for the host PC to send it another program.

Whenever host PCs program was restarted it would send the latest binary down to the card. Suddenly the development cycle became compile and run. I often felt that games I’ve worked on needed this – big titles take an age to load and then navigate to the area you’re trying to test. Only then do you find out that it works or not. Rubbish!

We can do better. Unity does – it supports live code reloading while running the game in the editor. There’s limits, of course, so code reloading broke at some point while we were developing Monkey Slam, and never got fixed. Next time I want to understand what’s acceptable, and keep it going all the way through. The code reloading uses Unity’s underlying serialization mechanism to preserve state while code is unloaded and reloaded. The only difference between ‘editor’ serialization and the normal case turns out to be that private variables are serialized for code-reloads.

This makes total sense to me intuitively. When you did a little deeper it become clear why Awake() is used instead of a constructor. The constructor is called after every code reload; Awake() is only called when the object is created. The correct values are serialized into each object after code-reload after each object is constructed. Breaking the game on code-reload simply means that something in the run-time state is not being correctly serialized. The Unity documentation covers the basics, but left me with a bunch of questions. Here’s a few more details:

  • Statics: are not serialized at all. Initial assignment and static constructors will re-run on code-reload.
  • Properties: all properties are not serialized. Counter-intuitively that’s what you want. Properties are code – they will work after code-reload as long as the object state is correctly serialized. For auto-generated properties the private backing field is serialized fine.
  • Collections: arrays and List are serialized are documented as being the only serialized collections. They work, but Queue and Dictionary do not. The loss of Dictionary is the biggest roadblock for me. Add Dictionary and I could imagine writing a game. Without Dictionary that’s … hard.

The good news is though that you can nest one of the supported collections within a class of your own and have it serialize correctly. So it’s perfectly possible to implement Queue on top of List and have Unity code-reload it. You could also do that for Dictionary if you’re prepared to settle one of the performance compromises possible implementing it while relying on List serialization. I suspect in many cases one of these implementation strategies and compromises would be acceptable:

  • a linear search over unsorted List. For relatively small numbers of entries this is probably fast enough. Assuming List uses a contiguous block of memory internally it may even faster for less than about 100 items as it’s cache friendly.
  • maintain a sorted List. In this case lookup is fast, but insertion is linear as list entries after the insertion point need to be moved. Great for read-only data.
  • use a contained Dictionary and in the Unity editor maintain a backing List which all Dictionary entries are appended to. You can avoid slow lookups on the List by blinding appending new values. On code reload you take the last value for a given key from the list and insert it into a clean Dictionary. To avoid an arbitrary size overhead of the List you could “garbage collect” the List if it’s size became bigger than a certain multiple of the Dictionary size.

All of the above would make a great projects for GitHub. I’d be tempted just to implement the Dictionary with a linear search over a List first, until there was a clear performance reason for other solutions. Years ago, when people wrote their own collections routinely I wrote a lot of software that just used lists and it was almost always fine!

I guess the question is whether that’s all worth it to maintain code-reloading? Alternately @Unity3D could we get Dictionary serialization working please?

Post Script

Recently there have been a couple of great blog posts about Unity serialization, both worth checking out. The main Unity blog has a lot of serialization details posted, and Jacob Pennock wrote a great post on leveraging Unity serialization for game configuration. I’d love to see all this detail wound into the Unity documentation.