The Amazing Adventures of Me

I’ve not heard much about ASP.NET 4.0 yet. I don’t know if that’s because there’s not much information out there yet, or (more likely) because I haven’t been looking. We’re still very much in 2.0 land at work, so there’s not too much point getting excited about v.next features. But today I stumbled across a post on a post on an official asp.net blog called ASP.NET 4.0 ClientID Overview that details the support 4.0 will have for controlling the client-side IDs generated by server controls. Those familiar with ASP.NET will know that in current versions, all server controls that have specified IDs (thus enabling them to accessed from the code behind) generate corresponding client-side IDs containing their full naming-container hierarchy. This guarantees their uniqueness, but often means they’re very long and push up the page weight. It looks like ASP.NET 4.0 will do some work in this area to give developers more control over what IDs are generated and when, on a per control basis. Sounds pretty cool, roll-on 2015 or whenever that I can actually use this stuff in production!

Phil Haack has posted a couple of blog posts recently on named formatting in .NET. The basic idea is, instead of the usual numbered placeholders in a String.Format string like "Hello {0}, you have {1} unread messages", you have the name of properties, which are then reflected from some source object, e.g. "Hello {Name}, you have {UnreadCount} unread messages". He posted his own implementation, and a solution file containing unit-tests and a performance comparison with some alternative implementations. These posts in turn prompted a few responses from people who produced their own, even swifter implementations. So obviously, I had to have a go myself. I went for a simple, ugly, but fast approach, and at the time of writing I believe mine is the fastest (by a couple of hundredths of a second) except for one that uses some wacky Linq stuff to pre-compile property-accessing lambdas and assemble them for a particular format string. The code for mine can be found here. It’s not pretty, and I certainly wouldn’t write code like this for anything serious, but it was fun to do.

I’ve recently started looking into modding for Half Life 2 / the Source engine. On the whole, Valve provides quite a lot of help for modders. There is an official Source SDK that can be downloaded through Steam, a number of official forums on Steampowered.com that Valve developers are (occasionally) active in, and a wiki with relatively up to date information for developers on a wide range of topics. There are a number of active third party sites devoted to Source modding, the best of which appears to be Interlopers.net. All this is good. what is not so good is that the architecture Source and Steam appears is rather unfriendly to beginners.

Any beginner to modding a game has to start somewhere. The usual place to start is by making a small modification to the original game’s behaviour. For example, a beginner to Doom modding might take the game’s source code (or rather, a stable windows port such as ZDoom), make a change to a small aspect such as the player’s maximum health, recompile and play the game. Similarly, someone using the Quake engine might make a small change to game’s QuakeC code, perhaps to increase the number of gibs spawned when a monster is killed, recompile the code and test out their change. This approach, of tweaking a small aspect of an existing game, and quickly seeing the results is a standard and very useful one. It allows new developers to get in at the shallow end, so to speak, by gradually exploring the existing code base, learning to make more significant alterations at their own pace.

With the Source SDK, there is an option to create a blank mod, or to make one based on Half Life 2 singleplayer. You might imagine that choosing the latter option would produce a mod that replicated the Half Life 2 singleplayer game, while allowing the developer to start making code changes, but this is not the case. This option produces a mod with the source code from HL2 singleplayer, but no access to the resources of the game. Instead it uses what is called the “Source SDK Base”. This is a shared set of basic resources that is available to anyone who owns a Source engine game (e.g. Half Life 2, CounterStrike Source, Day of Defeat, etc). Getting the mod to a state where it simply modifies the default Half Life 2 singleplayer game is possible, but it involves quite a bit of work copying configuration and resources from the original game and modifying the code to mount the original HL2 resources within the engine’s internal file system.

The thinking behind this is clear enough, Valve want to enable and encourage people to make mods standalone mods that work across their product range, rather than reusing a load of resources from a single game and therefore being tied to it. However, this assumes the developer is ready and able to make a large standalone mod, whereas I would argue this is only a stage reaches after a large intermediate period of learning their craft and forming or joining a dedicated mod team. Until then, most people will want to product basic mods of a single game. If Valve wants to improve the learning curve for Source modding, thus increasing the size of the community and the associated revenue it drives, then they should enable a better route within the SDK for beginners. The option to create a HL2 singleplayer mod should do exactly what it suggests, creating a mod that replicates the normal behaviour of the game and can be played immediately, allowing the developer to start making changes at their leisure.