I suppose I should probably tell you something about the site. People seem to expect this.

This is all done using ASP.NET and uses SQL Server as a backend for the role-based authentication. No great surprises there I suppose. The text-only Quake game is an exception to this - the hosting company provide mySQL and no one seems to be using that with ASP.NET so I thought why the hell not, let's see how well the ObjectDataSource integrates with a different database platform. The answer is surprisingly well although Visual Studio Tends to puke and crash while loading the DataSet designer so I probably won't pursue this much further.

Update - I trashed all the mySQL stuff, it's running far better in SQL Server.

The multi-user JavaScript games were a pain in the arse to develop. ASP.NET AJAX has the ability to allow client script to POST data to a web service, purely from JavaScript which opens up all kinds of possibilities for near real-time browser-to-browser communications without the need to perform a "hard" page refresh. All the business logic is handled by a web service and all the UI control is performed by client script. Needless to say, making this work reliably in all browsers can be a royal pain in the arse.

The main problem with the Quake game especially is managing race conditions in client script. Without this, it would be possible to click a control to leave a room then click another control to pick up an item before the server has processed the first instruction. This would result in the player leaving the room then trying to pick up an item from the last room. The only way to manage this effectively is to only allow a single request to be sent from the client at a time using a global BUSY_IN_CALL flag that gets reset in the callback functions.

If I had the time I'd consider rewriting some of the games in SilverLight with the new WCF web services but those things are just a colossal pain in the arse. Standard WSDL works well enough for client script.

Marry Shag Kill is slightly different. I wanted this to have a Flash interface but Flash is Utterly hopeless at consuming .NET web services. To get round this, all the server communication is done by POSTing XML data to a generic handler which responds with XML. Definitely a case for SilverLight there. Flash is shit, especially when you start writing ActionScript classes.

This site has a lot of non-static content that needs to be added to the page navigation. With static SiteMaps this is impossible but ASP.NET allows for the creation of dynamic database-driven SiteMapProvider classes. These are generated from the table of news items and the Chatlog Horrors section.

The Roles and Membership providers are also overridden - purely because ASP.NET defaults to creating a user instance database in the DataDirectory and I wanted to use a named SQL Server database. Fortunately this just means adding a line into web.config like this:

<membership defaultProvider="CustomMembershipProvider"> <providers> <clear/> <add name="CustomMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="CustomMembershipConnectionString" /> </providers> </membership>

One thing to remember here is that IIS will read the following settings from machine.config unless you specify them in web.config:

• enablePasswordRetrieval
• enablePasswordReset
• requiresQuestionAndAnswer
• requiresUniqueEmail
• passwordFormat
• maxInvalidPasswordAttempts
• minRequiredPasswordLength
• minRequiredNonalphanumericCharacters
• passwordAttemptWindow
• passwordStrengthRegularExpression

The defaults for these attributes are probably too restrictive for a simple web application like this one. Password hashing is a good security measure but the default strength Regex and non alpha character requirement are just a pain in the basckside.

Things like profile URLS and news item URLs are always more search-engine friendly when you provide a bit of URL rewriting. Apache has had this facility forever and it's one of the places where IIS has lagged behind a bit but web.config and IHttpModule's app.Context.RewritePath method make this a piece of piss to achieve.

This isn't perfect - IIS will throw up a 404 error if the rewritten URL points to a folder that doesn't exist and for ease of hosting I've had to include the .aspx extension but it achieves the objective of supplying readable URLs to the browser.

One of the drawbacks of ASP.NET is the ridiculous lengths you have to go to in order to create a simple upload progress bar. The solutions I've seen rely on ridiculous things like medium hosting permissions or access to the ASPNET worker thread or whatever bollocks the idiot developer thought up in his sleep. The simple solution is to use a Flash movie - this is in the Marry Shag Kill "add a b3tan" image upload section and it does some very clever shit indeed. In the client, all you need to do is implement ActionScript's Filereference class which raises a file browser dialogue box and processes the upload. Server-side processing is done in a generic handler which saves HttpPostedFile to the file system.

POSTing XML data from Flash is a simple matter of using XML.send() or XML.sendAndLoad() if you're returning XML to the Flash movie. The class to read the POSTed data is a piece of piss. Yes, it's in VB.NET, sue me C# snobs.

Imports Microsoft.VisualBasic Imports System.Web Imports System.Xml Public Class FlashXMLPost Public Shared Function PostedXML(ByVal contextRequest As HttpRequest) _ As XmlDocument Dim totalBytes As Integer = contextRequest.TotalBytes Dim buffer As Byte() = contextRequest.BinaryRead(totalBytes) Dim enc As Text.Encoding = contextRequest.ContentEncoding Dim postedXMLString As String = enc.GetString(buffer) Dim reqXML As New XmlDocument reqXML.LoadXml(postedXMLString) Return reqXML End Function End Class