Practical Unit Tests Screencast

I’ve finally recorded my unit testing talk from GDC. If you have questions, ask them under the video – I know youtube comments suck, but let’s see how it goes.

Advertisements

Practical Unit Tests, GDC 2014

I gave my talk yesterday on how bad unit tests can slow iteration, and how you can fix them. The turnout was fantastic, and we had a great roundtable afterwards in the wrap-up room. It was 8 years since the last test-focused GDC talk, and hopefully the organisers will now realise there’s an appetite for more on this topic.

I want to do a recording of the session next week (it’s only 25 minutes) and post it up here, but in the meantime the slides are below. Hopefully they make some sense without the audio.

Come see me speak at GDC 2014

Come see me speak at GDC 2014

That time of the year again, when I’m flip-flopping between wishing GDC was tomorrow, because I can’t wait to catch up with friends and colleagues, and just a few more weeks away, so I had just some more time to polish my talk.

This year I’m talking about unit testing, or more specifically how bad unit tests can ruin a project just as much as no unit tests. It’s aimed at devs who know what unit testing is – it’s not a tutorial session or a guide – but you don’t have to be an expert.

The talk is on Thursday, 11:30am in South Hall 304. See you there!

Your Favourite Free To Play Game Hasn’t Been Made Yet

There’s been a lot of criticism over the last few days of the new Dungeon Keeper free-to-play mobile game from EA. By all reports, it features some egregious and long countdown locks, that can be opened early with in-game currency, which can of course be topped up with real money in-app purchases. These types of IAPs are intended to both aid retention (as people come back to see their timers complete) and frustrate the players into spending.

Dungeon Keeper Ad

It’s a frequent pattern in high-grossing f2p games, and it’s not that weird to see it here, a high-profile title from a successful f2p publisher. The complaints haven’t been so much that this example is particularly bad, but coupled with a well-loved IP, it’s the straw that broke the camel’s back. I absolutely agree; as I mentioned above it’s a mechanic that has little to do with crafting an experience for the player. It’s a crutch for actually having a fun replayable game – if you make a good game, you don’t need to worry about retention mecahnics! I’m glad this kind of crap is being called out.

But let’s not go overboard. Here’s some quotes from the articles above:

“…if you are one of the very few developers who are still making real games (without the in-app purchase crap), I salute you. You are my heroes.”

“It’s greed, is all free-to-play games are.”

“Every interaction, mechanic, and screen must be expressly designed to convert scroungers into payers.”

We’re told that all f2p games are worthless, that any IAP is immoral, and that the designers of f2p games are borderline criminals.

Can everyone take a second and calm down?

There are design practices that we should shine a light on, and there are business practices we should frown upon, but we should not throw out a whole type of entertainment with the bath water.

Let’s ignore that there are high-profile f2p games on PC that always seem exempted from these arguments – maybe because they’re not aimed at the derided “casual” market? Let’s also ignore that there are successful but lower-profile f2p games on mobile that don’t use distasteful mechanics like countdown locks, despite me being lead developer for one. And finally let’s ignore the design reasons for creating a f2p game, like exploring the mechanics of large communities on a budget.

Instead, let’s explore an analogy.

CAUTION: ANALOGIES AHEAD

No one would argue that film and television are identical art forms. Many TV stations are free at the point of delivery, compared to the up-front cost of cinema, and are instead funded by ads. The individual episodes are shorter than films, yet have storylines that may last for years. Some shows, like soaps, essentially never stop. They both use sound and vision, but that’s about as much as TV and film have in common. The Sopranos is a very different masterpiece to Goodfellas.

You don’t think that ad funding affects how TV writers do their job? Do we stomp and scream at the writers of House because most ad breaks are prefixed by a mini cliffhanger? Aren’t they compromising their art for the sake of ad revenue? Why aren’t there blog posts decrying all television, ever, because Lost was designed to keep you watching week after week? Isn’t that as egregious as Dungeon Keeper’s countdown locks, which apparently condemn all other f2p games?

Actually I bet, if wordpress and medium had been around in the early 1940s, we would have seen posts complaining that television was nothing but a greedy cashgrab, compared to the “artistic purity” of cinema. But to shut down the medium then, when it was so young, would have robbed us of Cosmos, of West Wing, of the Simpsons, of Fraiser, of Monty Python, of Doctor Who, of Star Trek.

And is cinema really that artistically pure? Are the big releases not as commercially driven and “greedy” as any f2p game? Do they not compromise their vision for lower age ratings, or to include product placement? Let’s campaign to have them shut down as well!

In reality, upfront-cost video games and f2p games are different mediums, with different constraints. They’re both interactive entertainment, but don’t be fooled because they both have pixels and polygons. They serve different purposes, and have different potentials.

I must be clear I’m not arguing that Dungeon Keeper’s design is ok because TV has ads, nor that Dungeon Keeper should be given a free ride because f2p is a young medium. F2P is still finding its feet, and yes many of its baby steps have been in the wrong direction, but if we can bring it to a sensible maturity, we’ll have a richer world for all. Keep hating on bad f2p games, as well as on bad upfront-cost games, but don’t conflate them with the entire medium.

Edit: reworded conclusion slightly

How to build Unity3D scripts from the command line

I use emacs for day-to-day programming, including writing unity scripts. For a while I made changes then tabbed over to the unity editor to watch them compile and check for errors. This was, imaginably, tedious. Anyone not coding in MonoDevelop has the same issue, and even the MonoDevelop folks (god have mercy upon their souls) have issues.

It turns out there are multiple ways to compile your unity scripts from the command line, in such a way that most editors can be told to do it and parse the output for errors, greatly speeding up iteration time. I don’t think there’s anything new here, I’m just collating information that seems spread out across the net like horcruxes.

The first way to build your script files is the easiest to get working, but is cumbersome and slow. We’ll just pass a range of cryptic command line arguments to our Unity executable, it’ll launch without an editor front end, compile the scripts, dump any errors to the console, and quit. Cue up some regex and your editor can pull in the errors. Here is the command:

    path/to/unity -batchmode -logFile -projectPath path/to/project/dir -quit

On OSX you can find the unity executable at /Applications/Unity/Unity.app/Contents/MacOS/Unity.

You can read more about unity command line arguments in the unity docs, but let’s go through the options here:

  • -batchmode: stops any front end from loading
  • -logFile: tells unity what to do with any output. Without this parameter it’s all thrown away, which is of no use to our text editors. The docs above will tell you this argument needs a file parameter, but it’s undocumented that if you omit the parameter, all output, including errors, gets spat out to the terminal. That’s just what we want!
  • -projectPath: the path to the root of your project, where you find the sln file and the Assets directory
  • -quit: tells unity to exit straight after compiling.

This works on every platform, and has the nice feature of pulling in new files before compiling, so we don’t need a separate step for that. However it is slow as a milk cart going uphill, because it has to load and boot a lot of the unity runtime before it can do the simple thing of finding mono and asking it to compile a solution file for us.

It is also annoying because it doesn’t work if the unity editor is currently open. Even when in a heavy coding session there’s normally a need to run the game or tweak inspector values at regular intervals, and opening and closing the editor is not going to help you stay in a nice flow. Having said that, this drawback might not matter on a continuous integration server, so it might be the way to go.

So since this is just asking mono to compile for us in a round-about way, how do we cut out the middle man? The mono command-line compilation tool is called mdtool, and it ships with Unity. On OSX you can find it at /Applications/Unity/MonoDevelop.app/Contents/MacOS/mdtool. Here’s the command to give it:

    path/to/mdtool build path/to/project/project.sln

Here we just need to give mdtool the command build, and the path to the sln file. This is super-quick compared to the Unity approach, and works with the editor still open, but unfortunately won’t pick up newly added files. You’ll still have to tab to the editor for those to be picked up. However that’s relatively uncommon, so isn’t too much of a bother.

However when I tried this with the mdtool that ships with unity, I got very strange errors. They used to be relatively compact, but nowadays there are segfaults and all kinds of stuff going on. I did some casual googling over a few weeks, and couldn’t find a solution. But there was a workaround: install the latest Xamarin Studio (a free mono dev environment based on MonoDevelop), and use its mdtool. On OSX that’s at /Applications/Xamarin\ Studio.app/Contents/MacOS/mdtool.

So there you go: with one of these two approaches, you should be able to compile your unity scripts on the command line, find the errors and connect them to your editor of choice. These should all work on windows as well, but if someone can confirm in the comments that would be great.

If you’re interested, my emacs unity helper functions, including some flycheck compilers using both mdtool and unity, can be found on github.

Unity 4.2 features write-up

EDIT: Unity 4.2 is now available for download, and you can read a more comprehensive feature list on the official blog.

A quick google didn’t find anyone who had written this up beyond the headlines, so here’s the gritty details on what’s in 4.2, mainly taken from the Unite Nordic 2013 Keynote, here: https://www.youtube.com/watch?feature=player_detailpage&v=QY-e2vdPdqE#t=1246s

All of these are in all versions of 4.2, including the free version:

Edit: Seems I misinterpreted part of Lucas’s speech. All these features are free, they will appear in whatever version of unity is most suitable. Eg shadows are part of Unity3D Pro, so those improvements are available to all Pro users for free. Here’s the list:

  • Windows 8 Store export, to RT as well, so they work on RT tablets
  • Mechanim avatar creation API: no longer need skeleton at time of build, can be applied to new skeleton at run time. Helps with player-created avatars.
  • Anti-aliased render textures: useful for occulus rift because VR headsets use a render target per eye, so now they can be antialiased.
  • Stencil buffer access
  • Shadow batching: reduce draw calls of shadow-heavy scenes. ~50% reduction in shadow rendering in unity-internal shadow-heavy scenes.
  • Improved shadows on OSX!
  • Headless linux player: make linux servers from your game code. That’s pretty cool.
  • Fixed problems where lots of frequent garbage collection could interrupt audio.
  • Rigid bodies can capture shuriken particle collisions, so you can do cool things like receive forces from particles
  • You can cancel builds! And asset imports! And switching platforms!
  • Presets for colours, curves and gradients in the editor. Handy for reusing data across components.
  • Memory snapshot view now tells you the reasons an asset is loaded. The example shown is a texture loaded because of a material because of a bunch of meshes.
  • An import option to reduce white pixels in alpha’d fringes of transparent textures

And then there’s the headlines about the mobile add-ons becoming free, which everyone has heard by now:

http://blogs.unity3d.com/2013/05/21/putting-the-power-of-unity-in-the-hands-of-every-mobile-developer/

Of those new features, I’m excited by the headless player support. That’s going to be great for client-server games that want to run on AWS or something. The presets also sound interesting – I’m a huge fan of animation curves, and anything that increases their functionality is great by me. And I could have used the more detailed memory snapshot tool while optimising Sonic Dash.

So looking forward to the release of 4.2, and I hope you are too.

Context Behaviours Digest

I’m not sure how much more I’ll be writing about context behaviours (no, I still haven’t really decided between context steering and context behaviours), so I’ve made this post as a way to wrap everything up.

I started by discussing exactly where and why steering behaviours start to break down:

Steering Behaviours are Doing It Wrong

I then explain how context steering (see) fixes these problems:

Context Behaviours Know How To Share

I made both of these blog posts into a talk at GDC 2013 (see second half of video) as well as going into much more depth in an AIGameDev broadcast.

Finally I compare context-map-based navigation (no?) to an old paper, which seems superficially similar:

DAMN Behaviours and Context Steering

I’ll update this post with any more articles and how they fit in.