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.