XAGE on Android

Taken a few minutes ago, here's the very first screengrab of XAGE running on Android (via Monodroid and Monogame).



Unfortunately the Android Emulator is decidedly more clunky than iOS and WP7, so I probably won't pursue this further until I have the appropriate hardware and licenses. At the very least it has satisfied my curiosity over the potential of Android as a platform, if not yet the viability of it in a real-world scenario.

First fruits of new C# Scripting

As usual, most spare time is devoted to engine work (with maybe a spot of Joe Danger here and there) rather than writing blog posts.  The new scripting system is really starting to come together, and thankfully has been compatible with each platform the engine supports, including iOS:



I'm really happy with how this is coming along.  Hopefully I'll have more to show over the next few months.

Implementing AGS Script in C#

Previously for AGS conversions, XAGE would use a series of workarounds in order to shoehorn the AGS script into the XAGEScript. As discussed in the last post, this method was becomingly increasingly brittle and it was not easy to know how well a particular game would run until after a conversion was attempted.

Since moving to the new C# based scripting, there are still a number of workarounds required (offering index-based accessors, rather than XAGE's preferred unique string ID), though it is unavoidable that the two engines have converged even further. It makes sense therefore to offer an interface for much, if not all of the existing AGS script in order for our new C# script to compile. This has now mostly been done, and gives us a new metric for monitoring development progress.



Current progress stands at 8%, though in reality the figures will soon be somewhat higher. Much of the functionality already exists in XAGE (walking, talking, animating etc.), I just need to add the relevant hooks to make them usable via the new interface. A fairly low percentage implementation, say 30-50%, should suffice for the majority of games, with the more esoteric functions given lower priority.

A New Direction

It's fair to say that development on XAGE has slowed in the last eighteen months. This has mostly been unavoidable due to external factors, though there has also been a technical culprit - a thorny design issue I'd been struggling to overcome.

XAGEScript, which previously powered the engine, was XML-based and completely crafted from scratch. I'm quite proud of how far I took it - essentially it became its own bona fide programming language, supporting standard programming concepts like loops, lists, expressions and a call stack.

The trouble was, the more I focused on AGS conversions, the greater difficulty I had in adding additional complexity, not just within the script itself but the editor and the engine too. The more hastily functionality was bolted on the messier and more unwieldy it became to maintain. A hack built upon a fudge upon a hack soon results in an unpleasant programming experience. When your free time is limited to the late evenings, you cannot afford to suffer any impediments to your motivation.

Fortunately a workable solution has presented itself. For a while I have been been toying with the idea of abandoning XAGEScript in favour of using C# as a pure scripting language. This was especially attractive as AGS already uses a C-style syntax and so would aid any conversion substantially. However, the plan was not without its sticking points:

1. My original tests resulted in a large amount of garbage being generated. This is the bane of all Xna developers as it kills performance on Xbox and WP7.
2. With a hand-built scripting system, iterating through each command was easy and therefore blocking a script (to, say, wait for a character to speak a line of dialogue) is reasonably trivial. Doing the same in a raw C# script would require some horrendously complex & difficult to debug multi-threaded solution.

Regarding the first issue, after some experimenting with the Remote Performance Moniter I discovered a means of calling methods in external DLLs without generating additional garbage, including on the Xbox.

Resolving the second issue has taken much more time, but has ultimately proved much easier than resorting to running multiple threads. The C# yield keyword is such a strange beast that it took some time to wrap my head around it. Essentially it allows us to iterate through a block of code in the same way we would an array or list. Using yield return we can indicate whether a script is blocked and provide a mechanism for resuming it at a later time.

However using this keyword does somewhat complicate the code, so with the aid of the NRefactory Library I've added an additional step which automatically copies & updates your C# script to handle blocking, and therefore be usable within the XAGE engine:



The upshot is that it will be a TON easier for me to add new functionality - all I need to do is provide an interface and then implement it in the engine. Previously I'd have to laboriously built a new class for each function and then wrestle with the editor code to provide a means for users to make their changes.

It is a shame that in dropping XAGEScript we lose some ease-of-use and perks of solely using the Editor for scripting (for example, clicking on a background to very quickly set up a series of sequential Walk & Talk actions), but I'm convinced the benefits are absolutely worth it. If you are familiar with any flavours of Visual Studio Express 2010 then you'll know they're excellent (and free) tools for writing code, plus C# and .NET will provide game developers with a great many more options and flexibility. Just being able to step through scripts one line at a time using the debugger is a tremendous boost to productivity.

All the above is still experimental and is subject to ongoing work, although I do have a working prototype. Alongside plugging the new scripting system into the XAGE Engine, there remain a few outstanding questions I've yet to tackle:

1. Whether loading the script .dll at runtime will be supported on all platforms (iPhone & Android specifically).
2. Whether the Iterators for the blockable scripts can be serialised in a satisfactory manner (i.e. loading and saving).
3. How exactly performance will compare against XAGEScript (mostly likely it will far outstrip it, though I've not yet tested this explicitly).

"Time Gentlemen, Please" on WP7

In the words of the late, great Colin Loafshorts, "Blogs are for updating, not apologising on for the lack of updates". With that in mind, here's what I've been working on in stolen hours over the past six months:

It's not so much Point 'n Click as Drag 'n Tap.

Getting the TGP port functioning at this level has taken some doing, not least because of the optimisations required to get performance anywhere near acceptable on a phone. There's still a ton of work to do, but it's getting closer.

I'd dearly love to talk about C# Scripting in XAGE, and exciting projects like Exen and Xamarin but, golly, is that the time? See you in six months!

Bumper Update

Blog Updates have been quite scarce of late, as they tend to become a lower priority when development time gets squeezed. Yet progress continues to be made at a reasonable pace.

XNA v4.0

The latest version of the XNA has some changes to enable Microsoft to add Windows Phone 7 support. Most importantly, it splits the framework up between two profiles - 'Reach' (the lesser) and 'HiDef' (the greater). Fortunately, XAGE's current functionality fits neatly within the confines of the Reach profile, meaning it will continue to support Windows, Xbox as well as WP7.

There are also a number of changes which, to paraphrase Microsoft's Shawn Hargreaves, 'break it good'. Most of these have already been worked around, although there are some issues particularly around sprite rendering & IO. What further complicates matters is that the three open source libraries upon which XAGE depends to allow it to target other platforms are all still based on XNA 3.1 - it's possible to work around this whilst they are updated, though it means the engine code will be further muddied with additional pre-compiler directives. Until further notice, it's safe to consider all platforms officially broken until they're all fixed & re-tested.

Supported Platforms & Associated Costs

The website is also a little neglected and out of date, which has caused some confusion regarding the current status of platform support. Until now most of this information has been held loosely in my head, so hopefully this clarifies matters somewhat:

Where each image represents a required license (correct at time of writing):

• XAGE (£?): Required for any commercial games. Freeware/non-profit games will not require a license.
• Microsoft App Hub Membership ($99 annually): Required for any games released on Xbox360 and Windows Phone 7.
• MonoTouch / MonoDroid ($399 each, one-off payment with 1 year of updates): Required to deploy XAGE games (based on Mono) for iOS and Android platforms respectively.
• Apple iOS Developer Program ($99 annually): Required in order to deploy any game to the iPhone, iPad and iPod Touch.

To Summarise:

• It is completely free to create freeware XAGE games for Windows & Silverlight (in the future this will likely also include Linux & Mac OS X).
• It is not possible to create freeware Xbox360 games due to Microsoft's pricing model.
• The iOS platforms are the most expensive for commercial XAGE games, given they require three licenses (XAGE, Apple, MonoTouch) not to mention any additional hardware costs.

List Support

The most recent addition to the XAGE engine is basic support for Lists. The decision was made as they offer greater flexibility than standard arrays, and will automatically grow to fit the desired size. AGS Arrays will automatically converted as XAGE Lists.

Alongside this, basic string manipulation is in place (long overdue as absolutely required, not least for softcoded LucasArts style Verb GUIs). XAGE will understand C-style formatted strings and concatenate them as required.

As a result of this new data structure, in a stroke '!' went from being quite broken to fully playable from start to end. All of the puzzles now work (including that pesky DNA phone) and besides a few wonky quirks it's starting to look pretty good. As usual, the Editor itself is incomplete and I'll get around to this when needed. In the meantime there's still a few things remaining in order to complete '!':

• Three remaining AGS Functions need to be mapped (Character.SayAt, SetMusicVolume, SetMusicRepeat).
• Fix some animation oddities.
• Fix some GUI issues (GUI background colours)
• Fix the load/save mechanism as per of new Xna Framework version.
• Resolve music seek issue.

XAGE on iPhone

About a year ago if I'd been asked the likelihood of XAGE running on any of Apple's handhelds, I'd have said it was about as likely as Duke Nukem Forever being released.

However, after several weeks of tinkering, head-scratching and cursing, it's finally up and running on the iPhone/iPad emulator using the magic of MonoTouch and XnaTouch:



Caveats:

• Obviously, this is an emulator and not the real thing. It's difficult to say what performance will be like on the actual hardware.
• Audio isn't working yet, and various things are currently unsupported in the XnaTouch framework (RenderTargets etc - the usual suspects).
• Zero thought has been put into the touch interface. It's likely any game that uses more than one mouse button will need to have the UI re-designed.
• MonoTouch is a commercial framework, with a slightly eye-watering $400 one-off license fee (although thankfully Novell do offer a non-expiring free trial).

Apple's announcement yesterday that they're relaxing the Terms & Conditions of their Developer License could not have come at a better time, as it pretty much guarantees the safe passage of any XAGE game to the App Store.