So I learned something this week.
In WinForms HamQuest (hereafter WFHQ, and to contrast with Silverlight HamQuest, which will be SLHQ), I made use of XmlDocument and XmlNode, both in the System.Xml namespace of the .NET framework.
At the outset, the issues seemed minor. XDocument has a static method for loading a file, whereas XmlDocument had a non-static load method.
Then I got into actual trouble. I use SelectSingleNode and SelectNodes to get subnodes. I didn’t find such methods for XDocument and XElement.
And I made the mistake of not examining the documentation better, and simply started looping through nodes, as I did in times before I knew of things like SelectSingleNode and SelectNodes.
So, I got the code to work, and was later perusing the documentation.
Turns out XDocument and XElement have members named Element and Elements, which do the same thing as the SelectSingleNode and SelectNodes functions.
In fact the whole conversion from XmlDocument to XDocument looks mainly like a bunch of stuff got renamed, but all of the usual stuff is there.
The question of “why?” remains. Or it would remain if I cared. I’m at the point in my development life that I just don’t really care if I have to manipulate my code to meet whatever new API there is.
I’ll probably go back and “fix” the XDocument/XElement code to use the appropriate finder methods, but it is not as high a priority as, say, getting the rest of the SLHQ code playing the game and displaying the game state correctly. I’ve got the main map and the minimap thus far. I just have inventory, status, and messages to go! (Oh, and shoppe implementation!)
And then I shall play HamQuest on my Mac.
Also in HamQuest news… I broke Shoppes in 188.8.131.52. They didn’t work at all. You could buy nothing. Your money was no good there. This has been fixed, and I should probably do a 184.108.40.206, but I’ll likely get back to that after SLHQ.
A final note: I’m not really clear where all of the art assets for HamQuest wind up when I build the application. I imagine it is in the client dll, but its only like 105k. The engine is 45k, and the board games utility dll is 13k. Granted, all of the art assets are a blizzard of little PNG files(I haven’t put the light source images in yet). And I just looked at the WFHQ files, and the application is only like 31k, with 40 and 11 for the engine and boardgame dlls. So I suppose this isn’t totally crazy. Just seems really small to me.
I’ve been thinking about sounds as well. Since one of the members of http://www.braincontrol.org/info.php has been giving me feedback on HQ, I’m considering approaching him for background music, and I’m going to likely use http://www.superflashbros.net/as3sfxr/ to generate other sound effects, which puts an interesting wrinkle into the design.
The HQ engine knows nothing of graphics(or sounds), with perhaps the exception of what color a message is. It still doesn’t actually do the rendering, so we can say that the engine is doing a “hint” to the rendering client. Effectively, in order to put sound effects into the game, there would have to be a queue of sound generation cues(i.e. a CueQueue), and some sort of configuration file for what those sounds are for use by the renderer. After each move by the player, the CueQueue would fill up with all of the cues from events within game, like picking something up, using something, hitting, getting hit, etc. The renderer would then go through that list, and play the associated sounds.
The really sad part is that, once sounds are brought in, the footprint starts to go through the roof.