Wednesday 22 April 2009

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.

Saturday 18 April 2009

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

Tuesday 14 April 2009

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.

Friday 10 April 2009

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.

Tuesday 7 April 2009

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.

Sunday 5 April 2009

The 8 Minute Trial Test

It seems that there's a mixed reaction over the revenue generated by the indie developers on Xbox Live Community Games. Generally the bedroom coders are happy about making a few thousand dollars from their hobby, whereas the teams behind the larger projects seem more disappointed with the returns so far. There are a number of reasons offered - lack of marketing, lack of visibility, lack of quality, lack of achievements & leaderboards. All seem pretty valid.

There has been some discussion on the XNA forums about the impact of the 8 minute trial on actual game sales. Some of the problems facing small puzzle games aren't really applicable to the point and click genre, but that has its own set of issues.

As I'm in the process of fleshing out plot ideas for my own game, it seemed like a good time to get some pointers over what works and what doesn't. To help in this, I've downloaded five games built with AGS and treated them as if they were targeting XBLCG.

Colour Key: Green = pre v1.0 functionality, Orange = post v1.0, Red = unlikely to be implemented.

Disclaimer: The following are not reviews, just an analysis of their introduction and suitability for Xbox Live & XAGE. Granted, it's a slightly unfair critique as none of these games were designed with a time limit in mind. A few I've played before, the rest are new to me. XAGE capability of each title excludes GUI Customisation and Conversations.

1) Murder In a Wheel


The Good: Interesting Day of the Tentacle-esque art style. The murder occurs within the first 8 minutes. The player gets a few minutes of playing the game.
The Bad: Characters slide as they walk (more a matter of personal preference).
Not yet possible in XAGE: Nothing I'm aware of.

2) A Second Face - The Eye of Geltz is watching Us


The Good: Higher resolution than most Adventure Games. Very good use of audio.
The Bad: Slow pace of the intro is a bit of a killer. Art direction a bit wonky. Pronunciation of "Realm". Suitability.
Not yet possible in XAGE: Talking heads, Text Parser.

3) A Tale of Two Kingdoms


The Good: Comes across very much as a labour of love. Interesting zoom technique in the preamble.
The Bad: There is a LOT of dialogue, with barely a few seconds of play in the first 8 minutes unless you skip a lot of scenes. This is likely to appeal to a certain type of player and alienate the rest. Possible size limit issues.
Not yet possible in XAGE: Talking heads, Autonomy.

4) Annie Android


The Good: Low colour palette makes for a very striking, NES-esque, retro art style. A bit kitsch. Nice, simple GUI & polished animations.
The Bad: Length.
Not yet possible in XAGE: Nothing I'm aware of.

5) Blackwell Legacy


The Good: The art style and general presentation is strong. The story is intriguing. The player gets an early chance to see the game's play mechanic (Rosangela's apartment).
The Bad: The central plot revelation is not exposed within the first 8 minutes (unless the player skips through much of the dialogue).
Not yet possible in XAGE: Character transparency, Speech, Talking Heads

Conclusion: It's important for the player to get a clear idea of the plot, characters and game mechanic within the first few minutes, which isn't as easy as it sounds. The player needs to get sucked into the gameworld sufficiently to part with a few hundred microsoft points. Also a trial detection needs to be scripted into the game itself, to prevent users from repeatedly skipping cutscenes on multiple playthrough. Loading & Saving must be disabled.