AGS's 'Demo Quest' on Xbox360

The bulk of the conversation system is now in place, and there will be further refinements when I tackle the last major component (GUI customisation). Here's a new video detailing the following:

• New Editor appearance (themes).
  
• New Script Action creation method (popups).
• XAGE again converting and running AGS's sample game, Demo Quest (demonstrating a short conversation between Cris and Beman).

This time we don't cover exporting the graphics from AGS, but you can see that the conversion process is mostly painless. The only changes necessary here are to place the Player character, Cris, in the same room as Beman, to whom we scale up and add an onTalkTo script to initiate the conversation. A side-by-side comparison of AGS and XAGE:



From the video and picture above, the following is evidently missing or incorrect:

• GUI (Reason: Not yet implemented in XAGE).
• The character scaling is off (Reason: Room XML required - cannot access walkable areas to automatically determine correct scaling).
• Wall Panel missing (Reason: Room XML required - cannot access information on room objects).
• Cris is darker in AGS (Reason: Not sure. Either there's some filtering applied by AGS that I'm not aware of, or the room's palette is affecting the sprite).

Also, the Cris character has no animation for walking up (away from the screen). AGS is happy with this and just substitutes with an appropriate left/right walking animation, whereas XAGE currently expects the animation to be there, hence the odd sliding effect in the video. This will be dealt with at some point.

So far all of the conversion work is based around what is required for Demo Quest, so it would be very interesting to hear about other people's experiences. Once XAGE v0.4 is released I'll see about placing some sort of official feature request with AGS/Chris Jones for AGS Room XML export functionality, providing there's demand for it.

Edit: Ags Forum thread here.

Dull Technical Post

Real life events have again made it difficult to contribute time to XAGE, but there has been some small progress in the last few weeks.

I remember now why I put off implementing the conversation system for so long - there are a lot of design ramfications of doing so. The basic structure is in place and its now possible to initiate and select various conversation options in a similar way to a LucasArts game.

The reason it is incomplete is a long one. I've found that the more time I've spent on XAGE, the more inclined I am to want to do things right, rather than use any cheap or ugly hacks. One such case is that the dialogue system requires new Action Types in order to initiate conversations, amend option visibility etc. Rather than plumb these in as before, I wanted to completely rewrite how the Actions are organised both internally and externally.

Internally: At the moment, actions are simply stored as a type and a string of associated content, which is delimited by the tilde character. This is simple to implement but is quite brittle. After discovering Nick Gravelyn's post about serialization, I realised that it was actually possible to put Action types in their own class and still serialize them. This is a much cleaner and correct OOP way of doing things.

Externally: The original Action editor relies mostly on combo boxes. Given that the number of action types was swelling to thirty and beyond, it was becoming obvious that this list would become daunting to any unfamiliar users. It's also quite a backwards thing to select the action type before the item it is being performed on. By selecting the item first, you automatically narrow down the number of possible actions you can perform. Its also more intuitive:

(old) Walk -> (Character, ToXY, Direction, Pause)
(new) Character -> Walk -> (ToXY, Direction, Pause)

Its not especially easy to illustrate using text alone, but the benefits should become obvious after a few minutes of use. The above also means I can wrap up each piece of information into a seperate class and re-use as necessary for each Action (e.g. Pause after action is used in various). Certain items are now selected via popup buttons rather than combo boxes, as this is more visual and easier to understand.

All of these changes require quite a large rewrite. One problem is that, previously, I've completely seperated the codebase of XAGE and the Editor itself, as they only shared a dozen or so classes. As the number of classes has grown massively due to the new Action structure, it has become obvious that I need to wrap all the shared classes into a Global project, and expand any functionality in XAGE or the Editor via partial classes.

None of these required changes are particularly exciting in any way, and will take some time to complete. The end result will be a cleaner, more flexible XAGE v0.4, which should be the first wholly public alpha.

Editor Appearance

One of my gripes with the XAGE Editor was that the toolstrip looked bad on Vista - a sickly pale colour as opposed to XP's vibrant blue. It seems to be a recurring problem for Winforms developers.

When looking for solutions for this I came across a useful, free component framework, Krypton Toolkit, which is a lot more lightweight than the likes of DevExpress but looks good and seems to perform pretty well. I've spent the last few evenings making the Editor play nicely with it - there are a few workarounds due to various limitations, but I'm now at the stage where I'm satisfied it has been worth the effort:



I like it. It has a smooth WPF-esque feel about it whilst still being plain old Winforms. The new Editor Appearance preference allows the end user to choose between a number of presets. If I get the time I'll add a few custom ones - for novelty value alone I'm interested to see how it looks in an eye-watering pink.

Refactor, Bugfix, Itch

The overall response to the AGS converter, despite its infancy, has been pretty positive so it's something I'll continue to work on. It's probably worth reiterating that my little engine is not an official port of AGS, or in any way affiliated or endorsed by it; they are two seperate engines that share some general goals & functionality. Also, the conversion only ever takes place at the developer's project level, not with the compiled AGS game as this would be unethical (and also really hard).

I've taken a closer look at AGS's file structure and it is in fact possible to glean quite a bit more information than I originally thought. I've started a component that picks out all the dialogue options and then parses the associated dialogue script for the associated behavious, which map quite nicely to XAGE's Actions.

This cannot be ported over just yet as there's no equivalent functionality in XAGE - as much as I'm itching to dive in and start work on the Conversation system, there's a whole bunch of bugfixing and refactoring to do first. Walkboxes are now (fingers crossed) feature complete, and the graphics control in the Editor is more user friendly with mousewheel zooming and right-click scrolling. It also better illustrates which pixel you're selecting and a few other handy things like showing WalkBox connectivity. Here's a mini-changelog:

• FIXED: Character Panel slow due to obsolete links
• FIXED: Anim Frames getting width & height out by one pixel
• FIXED: Removed clumsy indexing for Anims, CustomAnimSteps & Actions
• ADDED: New IF Actions (Variables & Objects)
• ADDED: Graphic control - change get pixel depending on what we're getting (with new icons)
• ADDED: Graphic control - drag image via right mouse button
• ADDED: Graphic control - zooming controllable by mousewheel & cursor position
• ADDED: Graphic control - zoom buttons no longer originate around 0,0
• ADDED: Graphic control - show when walkboxes are connected
• ADDED: Basic in-game debug window
• ADDED: Active flag for WalkBoxes, amendable in scripting, resets WalkBoxMatrix
• ADDED: onEnter event for Walkboxes - script to run when Player enters
• ADDED: Basic AGS -> XAGE conversion
  

AGS -> XAGE Conversion

Over Easter weekend I finally got around to taking a proper look at Adventure Game Studio. The first thing I discovered was that the main container for an AGS Project (*.agf) is in XML format.

More as a proof of concept than anything, I've added an option to convert AGS projects to XAGE. The process so far only takes a few minutes - here's a quick video of Demo Quest 3-1 being converted to and running in XAGE:



As above, the sprites and room images need to be exported first (the player character is currently bald as AGS seems to export to 32bit bitmaps instead of 8bit). XAGE gathers up the exported sprites into a single texture for each character and creates the animation frames automatically.

It's a nice start, but there are quite a few limitations:

• As AGS and XAGE are both engines for the same genre, there's inevitably a great many similarities. There are also, however, a number of crucial structural differences. For this reason there will never be a 1 to 1 perfect automatic conversion.


• Unfortunately the individual room data (objects, walkable areas etc) is not wrapped up into XML but some other format (.crm?), so I'm not currently able to convert any of the scripts over - the real meat of the game.

At the very least, the conversion process removes some of the donkey work for anyone who may want to port their finished AGS game to the Xbox360.

Scripting example - Clouds

Here's a real world example of scripting in XAGE. One of the locations in my game is on top of a mountain and some moving clouds would help bring the room to life.



Let's break this problem down into managable steps:

• There must be several different clouds
• They must be obscured by the mountain and all other objects
• They must start in randomised locations
• They must slowly scroll to the left & reappear at the right of the screen

Ok, so now we can tackle these steps one at a time.

1) There must be several different clouds: Using the editor we add five new objects to the MountainTop room. So we can identify them within the editor, lets give them IDs cloud to cloud5. We don't need to give them a name as we don't want the user to be able to interact with them in any way. For each cloud we need to create a single AnimFrame. For consistency, lets tag them all as show, and set each cloud's current frame to the show frame.



2) They must be obscured by the mountain and all other objects: In order for the clouds to pass behind the mountain, we create a new object called mountainCover which has an animframe of the mountain itself. We then set the y position and hotspot of mountainCover so that it perfectly overlays the actual room background image. Because of the hotspot, this object will not obscure any other objects (our player character, for instance) but will obscure the clouds, as we'll ensure these always have a lower Y position.

3) They must start in randomised locations: Every time we enter the room, we should set the positions of the five clouds to random locations. We then set each cloud to run its own move script.



4) They must slowly scroll to left: Each cloud's move script checks whether the cloud has scrolled offscreen (i.e. the xPosition is more than 200 pixels beyond the left side of the display). If so, the cloud is repositioned at a random position to the right of the screen so it can scroll back on. At each iteration, the scripts pauses, moves the cloud one pixel left, and then repeats the whole process.



Now if we repeat this for cloud2 to cloud5, we get the following:



Excluding the artwork, the above takes only a few minutes to achieve but really helps to add an organic feel to the location, without a single line of code being written.

There is an obvious improvement in that I could implement script paramaterisation and use the one script for all five clouds, passing each cloud object as a paramater. I'm not sure yet whether I'm going to want to implement this, as you can pretty much achieve the same affect using Global Variables.

Update Clickety DBP

Time's been short recently, but here's the most recent changes:

• REMOVED: zPos - object occlusion now works purely by Yposition & hotspots.
• FIXED: WalkBoxMatrix not always generating correctly.
• FIXED: Characters getting stuck when three walkboxes interesect.
• ADDED: Reporting Tools now use progress bar (can be cancelled).
• ADDED: Character WalkSpeed customisable and affected by walkBoxscale.
• ADDED: Visible (True/False) character/object option (removed 'Invisible' option from inRoom).
• ADDED: "Make Player" button on Character Edit panel & scripting.
• ADDED: Changeable Walking Speed (handy for mapviews etc.)

I cocked up with ClickOnce insofar that I hadn't realised that, whilst the XAGE Editor installation works fine, the bootstrapper (setup.exe) was being blocked by my hosting, and they are unable to change this for the time being. This means that everyone who already had the XNA 3.0 redistributable installed already had no problems, and anyone without it ran into bother.

As a workaround, any future alpha requests will get a zipped up version of the ClickOnce package to ensure that the requirements are definitely met. I'm debating whether to switch off the auto-update feature too, as various changes for v0.4 break the scripting for previous versions (at one point fatally so, as enumerations break the xml serialisation, so I reverted back to the previous system). This isn't so much of a problem at the moment, but will be in the future if people are regularly having to regression test their games to make sure new features don't make them fall over. I'll have to have a think about it.

Finally, anyone hoping to release their XAGE game to the Xbox360 might want to register for the Dream Build Play competition, which entitles you to a free 12 month creators club membership. This means you'll be able to deploy & test your game on the console itself to your heart's content, though you'll still have to cough up for a paid membership when it comes to XBLCG peer review.