Silverlight Progress

Whilst the Windows PC and Xbox builds remain XAGE's priority, the Silverlight version is the route to greater platform compatibility. Bill Reiss has continued his sterling work on the SilverSprite library with a new release supporting Xna's RenderTargets. This inclusion allows us to utilise scaling of games within a web browser.

As part of SilverSprite there are now two rendering methods - the old Silverlight Canvas style and the new Bitmap-based rendering. They both have their pros and cons, so I've hacked in a quick toggle to change renderer mid-game. This is how Awakener looks playing in Google Chrome at x2 scale using both styles:

Canvas Rendering:

• Pros:

1. Quicker - runs at 100% on my atom netbook.

• Cons:

1. Ugly aliasing, makes text harder to read.
2. Visual glitches (transparency especially).
3. Outstanding memory leak when using bitmap fonts(?).

Bitmap Rendering:

• Pros:

1. No aliasing or visual glitches, looks practically identical to xbox and native pc.

• Cons:

1. Much more processor-intensive - choppy performance on my netbook but runs at 100% on a fairly low-spec dual core pc.

Bitmap rendering adds (at the moment) a higher hardware requirement than I'd like, but it's really helping push XAGE's cross-platform viability. Again, it's likely that there are further optimisations to be made in both SilverSprite and XAGE, and perhaps the recently announced Silverlight v4 will offer further performance improvements.

Edit: There exists a third option that hadn't occurred to me - using bitmap rendering for the backbuffer and canvas rendering for the rendertarget. This provides a happy medium - a few visual glitches but looks better than pure canvas and runs faster than pure bitmap. This translates to three Silverlight visual quality options - Low (canvas), Medium (canvas/bitmap) and High (bitmap).

AGS Conversions: Manual amendment example

The process of identifying what needs fixing or improving in the Awakener conversion is mostly done by comparing the original AGS version alongside the XAGE version. Usually a problem corresponds with an unhandled scripting error, of which there are currently 163.

For example, the Awakener intro screen fades some textual images in and out before presenting the player with the menu. This doesn't currently work in XAGE. Examining the scripts reveals that AGS relies on a While Loop to fade the objects in and out.

So at first glance it looks like a simple case of implementing the While Do Loop structure into XAGE (essentially a specialised IF). However, the While condition also uses a local variable "trans". Local script variables are not currently supported in XAGE, so that has to be added too. Plus the While structure is to be based on IFs, which itself need to be updated to be able to handle multiple conditions (i.e. if flag== true && count > 5). Which also reminds me that I should probably merge the IF_OO and IF_OV Action Types for greater flexibility going forward.

All of which is a lot of work, just to make a few objects fade in and out. Sometimes working on the conversion feels like running down a rabbit hole of missing functionality and outstanding features, but the effort will eventually be worth it.

The above is also a good example of where manual amendments are required. AGS uses a Transparency property, where 0 is opaque and 100 is fully transparent. XAGE uses the Alpha channel, similar to drawing applications, where 0 is fully transparent and 255 is opaque.

For a line of AGS code where the transparency is set explicitly, e.g. cFadi.Transparency = 0, it is trivial for the converter to map this properly in XAGE as setting cFadi's Alpha Channel to 255. However, when the Transparency is set using a variable, as in the above example, XAGE has no simple number to convert. It's safe to say that the converter will neve be sophisticated enough to identify all possible values for the variable that stage and amend their values accordingly (which itself could introduce other bugs). The best it can do is alert the user that the value has been amended by a variable and needs to be checked that it's within the correct paramaters.

This complication leads me to believe it would be useful to have a mechanism for identifying certain scripts that are not to be updated if the conversion is run again. That means a user could manually fix various scripts in XAGE and not have them reset should the conversion be run a second or nth time (certainly useful for development and perhaps useful to anyone else who is developing their AGS game concurrently). More work. This is why it's unlikely there'll be any interesting updates for a while.

A Short History

It's coming up to 18 months since I started work on XAGE. During that time the focus of development has shifted so much, it seems like a good time to recap how XAGE began, where it currently is and where it is going.

The Past:

The original project started as an effort to get my own adventure game on the Xbox Live Indie Games channel (then 'Community Games'). After a few months work the engine was in a playable state and, using Monkey Island 2 placeholder artwork, I was able to hardcode a small demo room. It was obvious that I needed to develop a tool to enable me to quickly create all the game content from scratch, whilst the engine itself essentially operated as an interpreter (similar to SCUMM).

Soon after the original Editor had been created, it struck me that other people may be interested in the tools I was creating. Posting in a handful of forums prompted a positive response, and I started to receive emails with comments, suggestions and general feedback - all of which has been incredibly useful and a good source of motivation. And thus, the Xna Adventure Game Engine was born.

From that point on, focus shifted from the engine to the editor itself. Numerous revisions and improvements have meant that the editor is fairly straightforward and easy to use. I took a look at the competition - AGS, Wintermute and later Visionaire2D, all of which have their strengths and weaknesses. I found myself most drawn to AGS, of which I already had a passing familiarity, as it had a lot of similarities and it seemed to have the most active and friendliest community.

As development progressed I began to think more long term about possible game projects. As I'm a slow and clumsy pixel artist, I felt that it may be a better use of my time to instead think about converting existing games to XAGE for release to the Xbox. I contacted the author of a short AGS game tentatively asking what he thought of the idea, and again the response was favourable. I have since spoken to two others, and been contacted by about a dozen or so more developers, some indie, some commercial. It is pleasing that through only a few forum posts, blogs and youtube videos XAGE has caught the attention of the handful of people I had hoped it might. I have a good idea of who I'd be interested in working with in the future and there are no end of interesting games to port.

Along the way I discovered the open source Silversprite project, and in an afternoon had XAGE up and running in a web browser. This has added a complication insofar that all new functionality has to be supported across all three target platforms - Windows PC, Xbox and Silverlight. On the other hand, it broadens the scope of compatibility to otherwise C# unfriendly platforms such as Linux and Macs.

Eager to put the maturing Editor through it's paces, I spent four or five weeks making my own short game, The Fourth Wall, for Microsoft's DreamBuildPlay competition. It was a useful exercise, leading to a lot of bugfixes, as well as proving (to me and the four or five people who played it) the viability of the engine.

The next shift in development focus came when I discovered that it was possible to automate a large part of the work when converting an AGS game to XAGE, drastically reducing the work required for the end user. Numerous improvements later and I am now tweaking and altering a few outstanding aspects of XAGE's design in order to aid the AGS conversions. This has only been possible by using the few Open Source AGS games available, and more recently Awakener.

The Present:

I'm working on getting Awakener to convert as accurately and simply as possible. I'm having to plumb in new functionality to support this, such as local script variables, script paramaters, GUI customisation etc. This is a lot of work, but the end result will be worth it, vastly improving the feasibility of running complete AGS games on the Xbox.

The Future:

The roadmap on this blog is periodically juggled and amended. Once the work on Awakener is complete, I'll look at other AGS games to help finalise the XAGE GUI design. ETA for this is 8-12 weeks depending on how much time I get to spend.

Following that there will be three main milestones:

• Rework The Fourth Wall to work with the latest version & release to XBLIG.
• Release XAGE v0.5 (or whichever version is current) as Beta on a swanky new, dedicated website (i.e. begin the PR).
• Identify & negotiate rights to the first AGS game to be released on the Xbox360.

So ... there you have it. I'd like to thank everyone who has shown an interest in XAGE so far - your support and encouragement has always been appreciated. To that end, XAGE will always remain completely free for non-commercial use.