I use TinyXml for all of my Xml work and my project is fairly Xml-heavy (or will be), so there may be problems when loading/saving Xml files to the VFS. One possible workaround is that I change the way I load Xml files and pull them from strings which are obtained by calling the VFS. This doesn't solve the saving problem however, though it could be a non-issue due to the fact that the only real saving to be done will be player saves and during editing. Most edit-mode changes will need pulling into the Zip anyway and editing is not the normal course of play. Another fairly hackish way would be to modify the TinyXml library to provide override functions for the Load/Save methods of the XmlDocument. I'm fairly cautious about this approach though, mainly because TinyXml is a stable library and I don't want to knacker it with my tweaks; it'll also make it more difficult to just drop newer TinyXml versions into my base code without having to modify that again. I think the way to go is to use a workaround within my code base.
I also tweaked the particle systems, removing the alpha channel and putting additive blending in there. Whilst it's not as fast as the previous alpha blended version, it looks a hell of a lot nicer and allows for more groovy effects.
I've started on the mission planning for the first stages of the game. These are likely to be prototype missions that are played whilst I'm coding, probably won't make it into the final game but you never know. I've decided to have each mission break down into a set of objectives that can be conditionally set to mark completion. When an objective is completed, it can either trigger off more or set certain mission flags, so I'm going to have to design the system with this in mind. Mission files will easily collapse into Xml files for easy editing and parsing. The Xml action/event based scripting system I planned and tinkered with a few weeks ago should be perfect for this sort of scenario.
It's kind of ironic (points for guessing why) that this version (the prototype at least) will not be featuring an embedded scripting language per se (aside from the Xml system I mentioned previously). The reason for this is that I cannot see a perceivable situation where I'll need anything other than simple motion and AI behaviours to warrant the need for a full-scale language. Most of the enemy spawning will be done by triggers and the motion will be largely pathed, so I think this decision is valid.
Talking about scripting, I had a good hard think about how to recode the jsInvaders scripting base. I was creating/destroying aliens on the fly before, causing problems keeping the script up to date with the game. Whilst the SpiderMonkey engine could cope, it was the horrible way I wrote the demo script that couldn't (hey, it was a test!). I think that for now, I'll rewrite the actual script as the gamecode shouldn't need too much tweaking (aside from the new addition of templated JSObjects).
As a final point, I was mystified by the conversation in this thread - It's hard to believe that people actually use Internet language as part of their everyday life. It reminds me of an article I read in the newspaper about British schoolkids failing English exams because of their use of "TXT SPK" and Internet language in their papers. It's shocking how the line between real English and slang has degraded so much that people walk around saying "OMG POONED ROFFLES".
Maybe in a few years, we'll look back and all say "OMG I CNT BLVE THY USD FUL WRDS THN". [rolleyes]