Fontastic

Due to various commitments I've barely made any progress in the last few weeks, though I have implemented the font bank so you can import your own .xnb spritefonts and assign different ones to each character (useful if you want to make a narrator using a blank character, for instance). Any free time has been spent researching the best way to deal with that niggling Windows sound issue - at the very least I want to be able to support users importing their own .wav and .mp3s to be used as background music or sound effects. It seems that there are two remaining feasible options:

1. SlimDX: An open-source c# wrapper for accessing DirectX functionality through managed code. This is the right idea, though I cannot find any pertinent code examples that use DirectSound.


2. MCI/Mediaplayer: Invisibly use windows media player the audio. It's a bit of a dirty hack and I'm not sure if it will allow multiple sound sources, but it's definitely the easier of the two options.

At the moment it looks like I'm leaning towards the media player option - the wrong option, no doubt, but the easiest for now and it'll help tick things over until SlimDX matures. All this agonising over design decisions is just me thinking out aloud - when XAGE is done all the internal workings will be abstracted away from the user. It'll just work™.

Conditional Logic

Mercifully, plumbing in the conditional logic turned out to be a lot more straightforward than I'd anticipated. Adding the functionality for variables to the new XAGETOOL only took about 45 minutes, which is testament to the new design (even if do say so myself).

Scripts can now manipulate and act upon user-defined variables with simple IF, ELSE, ENDIF actions, as per this toy example:



It was possible to achieve the above by changing the attached script associated with the door's onOpen, however the more complexity you add to your game the number of scripts you require grows exponentially and it quickly becomes a complicated mess. The conditional logic is a simple way of negating this. I don't at present expect to need to implement nested IFs - besides, the user can always invoke new scripts depending on the outcome of the original IF statement.

Variables aren't type specific; XAGE will automatically determine whether the variable is numeric or non-numeric, so you can do things like "IF $MONEY is greater than 500". Also, the drop-down fields are pre-set with 'TRUE' and 'FALSE'. These are treated as strings but they essentially provide boolean functionality.

I've always wanted XAGE to include non-technical types amongst its target audience. The conditional logic is the only thing that remotely resembles code, but I can't see it putting anyone off as it is hard to imagine anyone not understanding the concept behind an IF, ELSE, ENDIF statement. For this reason, I've made it as verbose as possible: 'greater than' rather than '>'.

It is creating the sample game that will really put XAGE through its paces and expose its strengths and weaknesses. For example, it's already obvious that I need to add a popup to visually get x,y coordinates to make it easier and quicker to add various script actions (WALK actions inparticular). It's very important that I address any weaknesses before v1.0 is released, hence why I keep harping on about feedback from the alphas.

Once the oft-delayed dialogue system is out of the way, I only have two real headaches. Both relate to asset creation, and the previously mentioned .xnb file format problem:

1. Sound: For xbox development this isn't a problem. Anyone developing for the 360 will easily be able to convert mp3s and wavs to the required .xnb format using Visual Studio/XNA GameStudio. Windows-only developers however need to be able to import their audio files without converting to .xnb. This means I need to implement songs and sound effects using DirectSound alongside the standard XNA implementation. Unfortunately, as I don't currently have a dedicated internet connection, I won't be able to get my hands on the DirectX SDK (483MB) in the near future.
2. Fonts: As above, sprite fonts are converted by visual studio into an .xnb format. It's less of a problem however, as I can convert a bunch of free fonts myself in various sizes and include them with XAGETOOL. This way the user can simply use XAGETOOL to import the desired fonts into their game.

Allowing GUI customisability will be a bit of a pain to code but shouldn't be too difficult. I'm hoping the rest of the outstanding features are trivial and there'll be no showstoppers.

Up the TreeView

Some of the feedback I've had from the latest Alpha has been excellent - very thorough and thoughtful. It's much appreciated.

I didn't actually mean to lie when I said I'd be focusing on new functionality - instead I've completely redesigned the XAGETOOL user interface:

• I've replaced the numerous listboxes with a single treeview (think Windows Explorer) - this makes everything look much less cluttered and more intuitive to use, as the user can visually see how all the game content fits together, room by room. It also makes it easier to add new functionality via context-sensitive menus (e.g. I've added an 'insert new ...' option for items in which the order is important, such as script actions or animation frames). It also means that the UI is now completely resizable.
  
• The popup dialogs have now been replaced with a panel embedded into the front page. Now you can traverse the tree whilst editing items, and it also removes the size limitations of the popups.
• The load/save buttons are gone and in there place is a proper menu strip. This gives it a much more familiar look and feel, and consequently it all seems a bit less amatuerish.
• There's now a nice green, shiny 'Play' button which starts your current XAGE project game. XAGETOOL now also contains all the required files, so essentially you can create an XAGE project completely from scratch without having to cannibalise the example game as in previous versions.

All in all, I'm pretty pleased with how it is turning out. I have a vague design for my dialogue system, so it's about time I implemented that. There's also now a roadmap on the project status panel on this blog, so you can get an idea of where XAGE currently is and where it needs to be for v1.0.