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.
Monday, 10 October 2011
Sunday, 11 September 2011
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:
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:
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:
- 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.
- 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.
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:
- Whether loading the script .dll at runtime will be supported on all platforms (iPhone & Android specifically).
- Whether the Iterators for the blockable scripts can be serialised in a satisfactory manner (i.e. loading and saving).
- How exactly performance will compare against XAGEScript (mostly likely it will far outstrip it, though I've not yet tested this explicitly).
Tuesday, 14 June 2011
"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!
Subscribe to:
Posts (Atom)