Important: some of these are out of date and superceded by later notes I took after talking with Microsofties. I’ve tried to mark them as such where I remember with a [*].

Visual Studio 11

No release date of course, same as Win8. Feels like “definitely not this year”. Did you all download the preview yet? It’s available for everybody. Win8 and the dev tools (VS11, Blend 5, etc.) are online.

Anyway, what’s new…

• After 10 years they finally updated the image editor. Now it supports transparency and DDS’s.
• VS has an FBX viewer w/ property editor. Right in the IDE you can open a 3D model, select meshes, set properties like color and transform.
• They put a lot of work into a new thing called DGSL that is your typical shader graph.
• Preview rendering at different stages of the pipeline, things like pins and wires connecting them to output a final render.
• Good for the XNA crowd I guess? Seems like a distraction for the VS team.
• Pix is integrated into VS.
• You can debug a 3D app, take a frame grab, then in VS walk the drawprim calls backwards from a pixel. Get call stack per graphic event and all that.
• Being integrated into VS means that this this will have a nice, consistent UI, yay.
• There is this great DOM Explorer (JS/HTML only)
• Reminds me a lot of the tools built into Firebug or Chrome’s dev mode, except it runs through VS.
• Even on a server web app you can hover over a rendered web page and it will point you at the aspx line that generated it.
• Productivity Power Tools are part of VS now. You probably already know this. Well, perhaps they’ll fix some of its many bugs if it’s an in-box addon.
• Nice random improvements to the VS UI like categories for Intellisense (“commonly used by you” vs. “all”) and minor new features in snippets.
• Maybe now R# will pick up this much-needed feature that VisualAssist has had for a while..
• Await/async is deeply supported in the debugger.
• Step through async code (like WinRT’s ShowDialogAsync) procedurally without needing to get confused by all the underlying thread context switches. I like.
• Tons of new unit testing support. Now is the time when I remind myself to look into unit testing again..
• The Kernel Debugger can now run from inside of VS. Sure to come in handy next time you’re developing a device driver (har).
• Static code analysis is now a plug-in architecture.
• He talked about, for example, the kernel mode driver validation static analysis tools that just show up as part of the compile.
• Works on C++ or C# or whatever.
• I expect we’ll see the same type of integration for FxCop/StyleCop
• Javascript in VS now has a REPL command pane, just like the browsers have had.
• Full support for ECMAScript 5. I’m only familiar with 4, which added (I think) static typing. Well, fake static typing. Anyway, now we have 5! That’s 1.0 better than 4!
• No word of improving E&C like supporting altering a function containing a lambda..I’m going to ask them about this. [* answer: no]
• Ooh a nice new color picker for CSS. Probably for Xaml as well.
• VS11 projects are going to be the same format as VS2010.
• No upgrade required, forward/backward compatible. That will make testing the beta on our stuff easier.

WinRT (Windows Runtime – the Metro API)

• “Language Projection” is what they’re calling the layer between the language and the kernel services. It maps a language onto the underlying API’s, reflection and type system (the metadata).
• They are dropping the least-common-denomenator “CLI” system and instead are mapping things as close as possible to the language you’re using.
• Example: on an array returned by the core, C# uses “.Add()” to add an item, whereas Javascript uses “.append()”. I like this. Least common denominator probably wasn’t working out for them anyway because nobody really cared about making things VB-compatible when writing libraries in C#.
• WinRT types are automatically adapted to the language. For example getting an array back from WinRT will come back to C# as an IList<T>, done through adaptors but not by making a new list (no copying). In C++ they have adaptors to get it into STL iterator form, etc.
• Async is embedded very deeply.
• Martyn said that in .NET when they provided a sync and an async version of the same function, people would just use the sync version and then get crap behavior and experience.
• New stuff heavily encourages use of async, though not sure if that means the sync functions are unavailable [* they are].
• New Windows Metadata format that is used sort of like the Reference Assemblies, sounds like, except this metadata IS the OS. Not libraries on top, but the actual Windows API’s.
• Format is based on .NET type system but extended to meet the new needs.
• Metadata catalog is extensible (again, Metro apps only, for custom WinRT objects) but only privately. No publishing of shared assemblies. Not that they are using the word “assembly” any more…
• Sharing across apps is done exclusively through “contracts”, which are part of the OS. If you want to communicate across apps it must be done through a preexisting contract, looks like.
• YAY! A new string type!!! This one is called HSTRING and is probably the 15th string type I’ll have used.
• It gets mapped onto whatever the local language thinks of as a string but sounds just like a .NET string – immutable, and so does not copied.
• WinRT is heavily interface driven, as is now common in the rest of the programming world
• IUnknown is now IInspectable. They said IUnknown confused people or something. Anyway, IInspectable -> ISpecificInterface -> ConcreteClass (runtime, private).
• C++ binds statically as usual.
• C#/VB binding is mostly static but also uses some runtime metadata (very cheap though)
• JS/HTML binding is dynamic dispatch at runtime, works completely through metadata as you expect a dynamic language to operate
• Some MC++ changes, like “gcnew” is now “ref new”. [* turns out this is not true. See later notes.]

Other

• Lots and lots of stuff about Azure, which is pretty neat but I’ve heard is very expensive for large-scale use.
• Pithy statement I just made up: “swipe is the new right click”.
• TFS marches forward.
• The new stuff looks really cool, and I’d consider using their hosted TFS if I had a small studio. They even support scrum directly.

Expo Floor Queries

WPF

• What’s New in WPF Version 4.5 Developer Preview: http://msdn.microsoft.com/library/bb613588(v=VS.110).aspx
• WinRT is definitely Metro only.
• We cannot embed Metro in WPF, and vice versa (well we can, but they said it would be awful, dirty, and please run away).
• Metro really is a completely independent sandbox that has little to do with Windows.
• [* Some of the above is a lie, as I found out on Friday. WinRT is definitely useable outside of Metro. See later notes I’ll post.]
• Very little work has been done in WPF. It still exists! Visual Studio and the Expression suite are all WPF apps and will remain that way. But for 4.5 they focused exclusively on perf and stability. I suppose that’s ok.
• I lost track of how many times I’d ask someone about desktop apps (WPF) and would get asked why we didn’t just “rewrite it all” for Metro. Ah, Microsoft, never change!

Blend/VS

• The reason Silverlight has data-binding breakpoints is because the Silverlight team put the hooks in there independently and VS was able to use them.
• Until someone does that for non-SL Xaml (whether Metro or WPF) we will not have this functionality in VS.
• The reason JS/HTML has such freaking awesome debugging support (like interactive mode) is completely provided by the hooks already developed independently in IE over many years.
• Again, work that Blend/VS did not have to do.
• So they’re waiting for debug hooks in Xaml frameworks, which may never appear. Complicated problem to solve and limited resources/initiative to do it.
• We should use DynamicResource and not StaticResource as a general rule.
• They know that debugging resources sucks.
• They want to work on the problem. They aren’t working on the problem. They have no plans to do so.
• They recommended using DynamicResource (again) and binary-search style commenting out stuff to narrow down problems. Yeah, so, nothing new here.

I sent out notes about the conference to my team and figured I’d post them here as well in case it would be useful to anyone. Stripping out any Bungie-specific commentary that wouldn’t be generally applicable of course.

Important: some of these are out of date and superceded by later notes I took after talking with Microsofties. I’ve tried to mark them as such where I remember with a [*].

Notes From Tuesday

I’m writing these up while it’s still fresh in my head..

Two big takeaways for me:

1. Windows 8 will actually be really awesome. Seriously.
2. It won’t matter to production tools developers. Business as usual.

As a consumer, I am really looking forward to Windows 8. They did what needed to be done in order to live in the modern world: new API, breaking of backwards compatibility, heavy integration of touch and gestures, complete guidance provided for new design, large library and protocols for connecting apps together, support for web development on the desktop to bring in all those crazy kids, plus some really forward looking design…

But only for Metro – “the new stuff”. Windows 8 will run all the apps that 7 did, but there are now two classes: desktop apps and Metro apps. Desktop apps are 3DS Max, Photoshop, Word, Notepad, etc. Metro apps are 100% new. It is a brand new platform in just about every way. Really don’t even need to call it Windows.

Metro has clearly been the focus of Build and therefore Microsoft. So far today, the only thing I heard about ordinary desktop apps is that “they will still work great”. They all run within a context in Metro called “Desktop”, which is already seeming very antiquated, almost like Windows XP Mode was with Vista. Everything MS is talking about here is geared towards Metro. And it’s seriously cool. I look forward to switching all my home machines over to it, especially my girl’s Dell Duo. Win8 is fast, lean, and cool as hell.

So I don’t have much to report on the future of our platform: Win32/64 + WPF/.NET. I’ll be finding out what I can over the next three days.

I did take some notes, though. Here they are in no particular order:

Non-Metro:

• No mention of WPF all day. Not even whispered. Is WPF rolled into Silverlight? Is WPF on life support? What about frogs? No word yet.
• New C++ standards compliant compiler is shipping with Visual Studio vNext. I saw the “auto” keyword being used for duck typing.
• They kept making a big deal about performance as a top priority, over and over again. This is a pillar of Win8.
  • Perf is even more important than in Windows 7 due to touch support, because people are unwilling to put up with any latency whatsoever when using a touch interface. So look for a lot of async support integrated at all levels.
• Cider is gone. Blend’s designer is now integrated into Visual Studio. Big yay. Always annoyed me that something would work in one place and not the other, or vice versa. (Now we can have things not work in both places, but at least it will be consistent.)
• There’s a new debug view that lets you view parallel stacks of async/TPL tasks as well as the program flow through the tasks. I’m going to ask them if this can be applied to our own scheduling system (or if we should switch to Task in order to take advantage).
• Looks like they upgraded the remote debugging, way easier to set up. Even have remote Javascript breakpoints. Definitely won’t need Firebug in this world.
  • There is even a DOM inspector for JS that works over remote debugging. Not only are the UI elements hot as you hover/touch them (like in Snoop or Chrome dev) but you can modify properties on the fly while debugging. Remotely! OMG!
• Blend has a crazyass new interactive mode where you can run the app inside of Blend, fully interactive, then pause it on the screen you want to modify and switch to design mode to update the Xaml. Sort of like play-in-editor. (Think Expanders or other state-dependent stuff..a bit of a pain to do right now.)

Metro:

• XAML is coming to C++ which compiles down to native x86/ARM. Appears to be Managed C++ due to use of ^ ref modifier [* nope]. Makes sense. Don’t know how they’d make any of this work with pure C++.
• Thankfully they’re not just copying Apple but fixing a lot of stupid UI problems on the iphonepodpad. My favorite is how they said that the modal rearranging of the home screen is crap and how folders bury things too far. Couldn’t agree more.
  • They are also expanding the “touch language” beyond existing standards of swipe-to-scroll and pinch-to-zoom/rotate. Selection, context bars, app switching..
  • Totally eliminating the “mouse-ish” stuff like holding down a touch to bring up the context right-click. All of those old Windows 4 Pen-isms are gone. This is why touch sucked on Win7/Vista and is finally usable on 8.
  • BTW if you have any time at all, be sure to watch Jensen Harris’s “big picture” talk from today (should be posted online sometime on Wednesday). I thought it was superb.
• Metro apps do not have access to Win32 api’s (such as MessageBox or anything in GDI)! – no overlapping windows etc
  • All graphics are done through DirectX only.
  • Metro apps are totally different. Don’t even have a message loop. [* not true]
• I saw examples of the “await” and “async” keywords a lot in the demos. This is a key part of delivering high perf UI. Their expectation is that nothing is synchronous.
• WinRT (windows runtime, the new API) appears to be a true new API and not just a forms/.net style wrapper.
  • This one appears designed well from the start! Takes advantage of modern design patterns and not held back by obsession with backwards compat.
  • They said several times that this is definitely not a “layer on top” (like how winforms wrapped up user32 etc.) but talks straight to the kernel. [* mostly true]
  • Fully object-oriented, has reflection, even in C++.
• Async support features are implemented in all languages.
  • For example in Javascript, known as “promises”: mediaCapture.initializeAsync().then(function() {…}) type stuff.
• The javascript integration is pretty damn cool. Has data binding even. Hope this brings web devs in to make things for Win8 (obviously MS does too).
• Can write native C++ to reference-in from javascript. They gave a demo of HLSL compute shader-based image processing lib written in C++ and used in Metro javascript app. Neato.
• Single file .appx package for distro. Yay finally. No more installers! Turns out this is just a zip file too, like Java did with jars. Yay, no more proprietary package formats!
• They have a very cool Metro simulator that runs your app through a fake local RDP session that makes it easy to test different rez / dpi / orientation without needing a VM or separate computer with the correct display.

Oh, did I forget to post on here that our game shipped? Wow, I totally did! Well, we shipped in September on 360, PS3, and Wii. Become a fan on Facebook!

The reviews have generally been in the B range, though Metacritic’s average is a little depressing at ~70. Nearly every review uses the words “Katamari” and “clone” which makes me think they didn’t really give the game a chance. The similarities with Katamari begin and end at the concept of “grow bigger”. Might as well call Call of Duty a Doom clone because they both involve shooting things to get to the end of the level.

But whatever… I’m proud of our effort, and I think it’s a super fun game. Hell of a job for a small team with a tech base built from scratch, to ship on time and on budget on three platforms.

Wwise Tour

One of the reasons we were able to ship on time was Audiokinetic’s Wwise. I’ve been evangelizing this excellent sound engine to everybody I meet. I just can’t say enough good things about our friends up in Montreal. I’d use Wwise on every future game if I could.

On Tornado Outbreak, I did most of the engineering and the initial audio rig design and prototyping. Robert and his team did the actual audio work, and took over management of the Wwise project. They probably did 95% of the audio related work on the project, which is awesome! As everybody knows, engineers are really slow and are pulled in 20 directions at once, so the more I could step out of the way, the better.

Audiokinetic asked me to put together a talk for the tour they’re doing right now to promote the product, particularly the new features they’ve been adding. I invited Robert to join me and we presented the two halves of our audio solution for Tornado Outbreak. We split the presentation roughly along the lines of our responsibilities.

The event was recorded, so at some point we may see video clips showing up online. That will be necessary to get Robert’s part of the talk, because he was exclusively walking through the Wwise project, using elements of it to tell his story. So no slides, you’ll have to get the video if it comes out. Anyone using or considering Wwise should try to get a hold of that – his talk was really interesting and includes some great tricks on saving memory without sacrificing variety.

Now, all I know how to do is present slides, so here they are! Tornado Outbreak + Wwise = Love [PPT 2.5M] [PDF 1.4M].

Our Project

I also got approval from the bosses to release the Tornado Outbreak project file for Wwise. This is really generous of them to agree! Here it is. [ZIP 1M]

Note that this doesn’t include any content (wav files) but is only the project itself. That should be plenty though.

The point of releasing the project is to help out other studios who are integrating Wwise, in hopes that the favor will be returned. Everybody benefits from information sharing like this. With Wwise, in order to get a good rig set up you really need to have experience and good examples to draw from. As I say in my presentation, Wwise is different. Every other SDK out there is a “play samples + DSP” library. Getting the Wwise rig right is hard, and it’s not going to be right the first time. Just as if you were to build a Maya rig and had no experience with it before. You’ll screw it up for sure.

Audiokinetic provides some synthetic examples to help get started, but it’s not from a real, shipping game, and besides, every game is different. Tornado Outbreak has an enormous amount of unique objects that produce audio (over 400) and all those crashes and shakes and panics can become very difficult to manage. It would have saved a lot of time if, when I started building the initial rig, I had some examples to draw from. To that end, we’re releasing our particular solution for this situation. I hope that it inspires even better solutions and ideas on how to tackle these kinds of problems in the future.

Enjoy.

Special note: I was slightly drunk when I gave my second talk (optimizing the dev process), and moderately drunk by the time the panel started. Not my fault! People kept buying me drinks! Maybe that biased me, but I think the people I met at Game Camp were among the coolest and friendliest I’ve met at any game conference.

As promised, I’m posting my slides. PowerPoint 2007 and PDF format are available at my Googlepages site on my Publications page. Which reminds me, I really have to find a better host than Googlepages. Also have to migrate all that old stuff from my Drizzle site as well. So much to do, so little likelihood that I’ll get to it…

Anyway here are direct links to the files:

• Do What You Want [PowerPoint] [PDF]
• Optimizing the Development Pipeline [PowerPoint] [PDF]

I’m pretty happy with how the keynote went but the Development talk was a mess. I think the slides have some pretty good material in them, though. The couple of beers I had before the talk might have been a little too much. Same as writing code – one drink helps (lubricates the neurons), but two drinks can only hurt. Ah well.

Q: Could you describe some of the ” countless optimizations ” based on the world node graph?

It’s been a very long time since I worked on DS so I’ve forgotten most of the optimizations. We had stuff for physics, shooting arrows, pathfinding, all of which I didn’t work on much unfortunately. One big one I do remember is the “AIQuery” system. Most AI-capable objects would query periodically to ask what’s near them and what they’re doing. So a shaman may ask for dead krugs near it so it can consider resurrecting them. Or the hero waits until an enemy enters a certain radius and auto attacks if so. This can be ridiculously expensive, worst case being n^2 distance calcs per frame (where n = # active game objects). In DS’s case it’s even more expensive due to the node/world transformations required to get the distance.

A normal game just does a space partitioning scheme like quadtrees (DS was essentially a 2D game, we usually dropped the ‘z’ component). In DS the whole game is already partitioned based on these siege nodes, so we did tricks with that, where a database would track who’s in which node, watch when transitions were made, and cache queries. So it may have a stationary object asking for enemies every frame. This would get cached as a query that returned instantly, only getting invalidated as either the object moves past a certain distance, or if the membership state of any affected nodes changes. Or of course if a new node enters the world or a current one leaves it, based on world streaming.

I think some more of the optimizations we did were trying to work in local space as long as possible, and then getting notified when the focused (camera) node changed. Looking back, that’s absolutely how we should have done everything, assuming we kept the node system (which many on the team didn’t think was worth the cost). I would have wrapped up the concept of a position in a class owned by a manager, and updated for the new transform on entering a new node, everybody all at once. Then have individual objects check in/out positions from the list as needed for real-time updates. But I really would try to do everything in my power to discourage using a node-based system like that again. Very interesting engine but that feature cost us a couple million dollars at least.

Q: Could you explain the curious “spherical traits-based occupants queries” used by AI? Some kind of walk through the graph?

Ah, that’s the AIQuery system. A few where spherical but most were just radius based. I think we always referred to them as spheres, because that’s how the debug engine drew them. Anyway, occupants were members of siege nodes. So for example, a call might look like this:

gAIQuery.GetOccupantsInSphere(
  GetGo()->GetPlacement()->GetPosition(),
  r,
  GetGo(),
  NULL,
  output ? 0 : 1,
  OF_PARTY_MEMBERS | OF_ALIVE,
  output,
  !IsRidingElevator() );

This says to do a query based on the current component’s owner Go’s position, of a certain radius, with a source used in the filter part, up to 1 member, where we only want alive party members, and only cache it if we’re not riding an elevator. So this one finds the closest alive party member. The filter (OF_*) checks against traits in the Go set at load-time and updated as needed during runtime. In this case the cache would probably be a sorted list of Go’s relative to the current Go out to the max radius asked ‘recently’. So on a cache hit it just has to walk through that short list, testing max radii and the filter to see who to include in the output. Cached queries would expire after too much had changed (distance, occupancy, etc.) or after a certain amount of time (around a second or two I believe).

It was a difficult system to get right, had a lot of bugs until the very end. I would never do it this way again. Uncached queries using normal space partitioning (like quad trees) is a much better way.

Q: Could you describe some of the “self-healing” features used by the logic? I imagine things like event checking to suspend execution etc.

I think I used ’self-healing’ with a couple meanings.

First, it would repair bad content. Stuff like values out of range, handling where someone typed in the class of an object wrong, or parse errors in the spec files. My attitude was that the game should never ever crash. It should complain loudly and then try as best it can to keep going. The most important thing is to keep the content developers moving. They’re making the game, and try to keep out of their way. A crash is going to stop them completely. Then log the errors and deal with them separately.

And second, and I think this is the more interesting one, it would gracefully handle severe failures in the game related to objects going missing. In DS, an object you’re working with – shooting an arrow at it, have a “daze” spell cast on it, whatever – may simply disappear next frame. Happened all the time, due to world streaming. We did some tricks with putting objects in purgatory and deferring deletes and such but we needed to release these things to get the memory back. In DS, programmers were getting the rug pulled out from under them pretty much constantly. And it is pretty painful to write code where you are checking if an object exists or not all the time. In script code it’s easy – I could detect a NULL and just abort the script. Simple. In C++ code it was more work, and honestly most of the time we did just end up testing for IsValid on everything. But most of the game’s AI was done in script so this handled it pretty well.

Q: Could you provide an overview of the loading process and some of the optimizations and special cases you discovered?

If I remember right it went something like this. We’d check to see if one of the world frustums had moved (there were up to 8, one for each party member) and if so, see if that encompassed any new siege nodes. If so, we queued the geometry and textures etc. to load on another thread. Once those work orders were complete we’d populate them with game objects based on the SCID’s in the level’s .gas files. Again, on another thread. It was nuts – everything was multithreaded in this game, which is easy to screw up. We’d run script, do initial pose animations, whatever. Game objects would calculate parameterized content (such as their starting inventory) on this thread too, and then recursively load them. On the main thread we’d also get orders from the server in multiplayer games to construct Go’s.

There really wasn’t much we could do to optimize the loading process beyond the usual stuff you do in a game – reduce the size of the data to transfer, reduce how long calls are blocked due to fighting over resources controlled by critical sections, write a little assembly, use different types of specialized allocators, etc. Memory usage was a huge concern, so I had to do things like making a string database that stored unique strings, where things like the template name would reference off that.

After all that, we’d figure out which siege nodes were no longer in any world frustum, and queue them for deletion, which would in turn queue their occupants for deletion. Not super interesting but this is where the self-healing code came in. Old references were still often valid for about 15 seconds if I remember right, before they’d finally end up colliding and point at a real (but the wrong) object instead. That had more to do with the size of the magic # I used in the ID (5 bits I think) than any timer.

I remember on the siege node loader we had a lot of pathological cases to deal with, from the way the worlds were constructed. Every major area in DS was very different. We couldn’t optimize for a single type of level, such as the farmhouse to Stonebridge route. That had nodes that were a couple meters square on average, and they were all rectangular pretty much. The castle on the other hand had enormous nodes of weird shapes, which was another set of special cases we had to do (I remember lighting info being one of them, just storage space). And then there were these really long crazy high up nodes in the dragon cave that had yet another use pattern. This game was the opposite of simple.

Well that’s about the contents of my brain, everything else has fallen out!

Scott