Monday, 17 December 2012

Like a Traction Engine

Ortis is currently being developed in two different continents using two different engines.  How does that work?  Like this:

Photobucket

It's a simplification of course - Ben has input on how the different user interfaces should work, and I chip in with some AGS code and the occasional ill-conceived plot device ("What if Madelyn actually suffers from hair loss and can only stimulate her follicles using the milk of human kindness?").

As the lead creative force, it's absolutely fair to say that Ortis is primarily Ben's baby.  One advantage of the approach we're taking is that, in the unfortunate event I'm incapacitated by one of the UK's many bad drivers, he'll be free to continue and complete the game to his own satisfaction within AGS.  Assuming my good fortune continues (thirty years free from being run over and killed), we'll end up with an attractive, interesting and accessible game available on three core platforms, with potentially up to six more should interest be sufficient.

Tuesday, 27 November 2012

Games 'n that

Ortis:

As mentioned on Ben Chandler's blog, we've been collaborating on a new game for some months.  It's being developed primarily in AGS, with a view to releasing an XAGE version of the game on as many platforms as we can.  It's early days yet, but the quality of Ben's initial artwork is very high indeed, and improving with each scene:

Photobucket

Rather than porting it at the end of the development cycle and being overwhelmed with hundreds of bugs, the game is being ported iteratively.  This means I can squash most issues as and when they occur, and being able to play early builds on the Xbox and Windows Phone has been important in making sure the interface is simple and intuitive across all platforms.

It's a massively exciting project to be a part of.  I'll try to blog about this more as things ramp up.

Prime Minister's Questions:

About eighteen months ago, I agreed to attempt a port of Mark Richards' then beta AGS game, Prime Minister's Questions.  It proved to be a good test case for the early C# scripting engine, though a chronic lack of free time and some unfortunate technical issues with third party libraries meant it was only about 90% complete.  Mark released the AGS version shortly after and got some decent coverage within the  mainstream press.

After recently taking another look at latest (and most likely, last) version of Silverlight, I found I was able to finally complete the job.  I'm quite pleased with the results - whilst there are still improvements to be made, general performance is much better than the original port of Awakener back in 2010:

Photobucket

Mark's now working on a new HTML5 & Javascript powered PMQs, so I look forward to seeing a smug, pixelated George Osborne receiving his parliamentary comeuppance.

Wednesday, 15 August 2012

More sweeping changes

These late nights are slowly killing me, but it's worth it - development has been progressing at its fastest rate in months:
  • The scripting engine has been revised for a fourth time, and now operates on C# scripts without the use of yield-powered coroutines.  This is, according to conservative estimates, about a zillion times better.
  • Runtime serialization is now powered by Google's Protocol Buffers (protobuf-net) as this works on all platforms and is ridiculously fast compared to XML.
  • Support for spoken dialogue has been added.
Also, many thanks to David Gouveia who very kindly sent me the source to his excellent A* & Clipper powered pathfinding system.  I'm hoping to be able to leverage this into XAGE as a direct replacement for the old, clunky Walkbox system, providing I can crowbar in some additional functionality:
  • Separate walkable polygons (that can be enabled/disabled at runtime).
  • Closest-point identification (when clicking outside of a walkable polygon).
As I'm happier with the current state of the engine than I have been for a long time, I've recently been collaborating on a little something with a gentleman who has been proven to be an impressive 30.4 times better than Ben10.  More on this over the next month or two.

Sunday, 17 June 2012

XAGE on Android

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

Photobucket

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.

Tuesday, 24 April 2012

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:

Photobucket

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

Monday, 10 October 2011

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.

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:
  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:

Photobucket

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).