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.
12 comments:
How do you use "walkbehinds" (thats what its called in AGS). I've been trying to use the same method as AGS, by drawing a separate image and somehow masking out the pixels that cover the character. I've tried using a shader but I've never written one before and I can't get it to work :\
In XAGE, walkbehinds are implemented by creating a room object that has an animation frame (sprite) of the pixels that you want to obscure other objects with (so say if you had a tree in a background that you wanted to walk behind, you'd create a sprite using just the tree pixels). You then position the object in such a way that characters can walk behind and in front of it as desired. XAGE orders the way sprites are drawn on the screen by their Y (or Z) position.
Do you create that sprite in a image editing program or in the code? I thought it would be quite a bother to go in and crop everything thats a walkbehind and save as a own image.
An image editor. It is quite convenient to do this within the AGS editor, although I haven't found it any more difficult using an image editor. The problem with AGS separating all these different types is that they all have their own limitations and quirks. By using standard XAGE room objects to implement walkbehinds you're also able to perform all the other usual actions upon them - change transparency, position, name etc.
ah yes, well it might not be as much of a hassle as i thought it would be :P
love what you're doing, keep it up! :)
Thanks. It wouldn't be unreasonable to use AGS to quickly draw on and create some walkbehinds and then, using the conversion process, let XAGE create the room objects and required textures automatically - no image editor required.
How does the pathfinding work in XAGE? I've been messing around with A*, but if I'm running at 1024x768 and even after splitting up the room in a 3x3 grid its still way too slow... you get a ~.5s pause every time a new path needs to be calculated.
The pathfinding in XAGE isn't per-pixel, but rather between the walkboxes themselves. Therefore the resolution of the screen isn't a factor, just the number of walkboxes in the room.
Essentially, the A* algorithm is used in the Editor itself to generate a matrix to be used later in-game. It's a 2D array of a starting walkbox against an ending walkbox. The corresponding value held is for the next walkbox in the route.
So given Starting Box A and End box Z, the engine can find out intermediate box B (if any). Once you know box A and B, which will share a boundary, you can figure out a walking trajectory. Once the player is in box B, the process repeats until the player ends up in the final box. I based this on an article I found online, though I can't seem to find it at the moment.
If you're using a bitmap mask for walkable areas rather than boxes, you'll need to use an efficient algortithm. I read on the AGS forums that the inbuilt pathfinding struggles with very large textures, perhaps similar to the problems you're having. Maybe Chris Jones can give you some insight as to how pathfinding works in AGS.
Ok, sounds like whats described in this article: http://www.gamedev.net/reference/programming/features/precalcpath/
Also, from what I can tell, it's the same technique that lucasarts has been using... judging from whats said about the BOX MATRIX in http://scumm.mixnmojo.com/?page=specs&file=mmdata.txt
I think I will spend the night implementing this :P wee!
Yes, that article looks familiar. And I also based a lot of the original design from what I'd learnt using SCUMM Revisited, an application for looking at the contents of scumm resource files. It showed how the room walkboxes were organised and it made a lot of sense to emulate that design, given my original project was to make a scumm-esque adventure game.
:''((! I didn't get very far.. How do you check if a click/point is within a walkbox? And how do you render the walkboxes (for debugging/editing/fun)
1) Try here: http://gmc.yoyogames.com/index.php?showtopic=409110 (if I remember correctly, the algorithm XAGE uses doesn't cater for concave walkboxes).
2) I use the PrimitiveLine class posted in the Xna Forums (http://forums.xna.com/forums/p/7414/39338.aspx#39338).
Post a Comment