New poll

For the first time in ages I've added a poll: this one is on the redesign of the AGS website and forum. Let us know your thoughts!

Just me and my shadow (module)

Well, back in 2006 when we were carefree and full of happiness and we all thought credit was a good thing I wrote the Shadow module. Since then, the world has moved on, we're all depressed about the economy and newer AGS versions have mildly broken the module. So I've fixed it! No, not the economy, the module! So check out the modules' thread on the forums and give me your praise and adulation.

Room template

A little-known AGS feature for a long while (at least 2.72 had it) has been the "New Room" template. If you create a room that you want to be the default for your game whenever you create a new room, then save it as _blank.crm in the game's main directory then whenever you hit "New Room" in the editor, it will load that as the basis for the new room. So, if you find yourself as irritated with the new AGS 3.0 script interaction controller (the lightning icon thing) as I am, why not create a default room that has all the room interactions already added?

Also, if you load up your normal game template, save a new _blank.crm and then create a template from that game, you can have that as the default room for all future games and your frustration can be channelled into making awesome adventures instead!

AGS 3.0+ annoyances

Over in the forums, there's a wee debate about why people haven't upgraded to newer versions of AGS. This has come up before in this blog and on the forums. Snake stated his dislike of the position of the project tree and starting debug games in a window, but he didn't realise there were preferences options to change both of those! If there's anything about AGS 3.0+ you don't like, comment here or on the forum thread, and I'll see if I can point out a way around the problem!

Dynamic Arrays

This post is about a couple of things that changed in AGS 3.0. First, the AGS_MAX_SOMETHING #defines were removed becuase CJ removed the editor/engine constraints on characters and other things. This made some modules break. Now, as I'm lazy its taken me ages to get around to a proper fix for this. One way is to use dynamic arrays, another new AGS 3.0 feature. Well, monkey_05_06 has already written up a great forum post on this issue, so I'll just link to his awesome posting. In short, you check if you're using AGS 3.0, define the AGS_MAX_WHATEVER to be blank, which declares a dynamic array instead of a fixed size, and then initialize the array to be the right size for the actual number of characters in the game (e.g. Game.CharacterCount) in game_start (surrounded by appropriate #ifdefs). Bob's your Uncle!

How to import a module in AGS 3.0

It seems that for the very new to AGS, even importing a module that someone else has made is a scary business. So, lets try and demystify it a bit. First, download the module. If it's in a zip file, you'll need to unzip it. There may be various files inside, the module proper has extension .SCM . To import the module, you need to scroll to the Scripts section of the editor hierarchy panel and right-click on the word "Scripts". Then you get a menu, where you should choose "Import script..." You are presented with a standard windows file dialog, where you can choose the module file and import it. It is added to your Scripts section and you can then read the documentation to find out how to use it. In my modules, the documentation is always in the script header, at the top.

Pixel Perfect Collision update

Way back, I made a module of a "team effort" bit of coding to provide Pixel perfect collision detection, something that AGS doesn't handle natively, due to the way that characters can usually walk behind each other, etc. Recently, mport2004 reiterated a bug that SticMann had spotted ages ago but I hadn't realised was a problem, that if a character is not "on top" of another character (and similarly with objects) then the module didn't work correctly. All to do with baselines and stuff.

Anyway, now I've fixed the module, updated the forum thread, replied to mport2004, and also added extender functions for those using AGS 3.0 or better, so the pixel perfect detection is even more perfect!

Version poll result

I suppose that I should have done this for the last poll when I took it down, but the results weren't very interesting: nearly everyone used AGS forums.

Anyway, this last poll (Which version of AGS do you use?) was a bit more interesting. One person registered as using AGS 2.62 (last DOS engine - probably either Yahtzee or Gilbot!) and 5 people (10%) said they don't use AGS (wow, I'm flattered that you're reading my blog!) . Of those that use AGS, its pretty much one thrid each to 2.72, 3.0 and the latest beta (now 3.01, I guess).

Now that 3.01 is officially out, I don't think there's any gotchas in upgrading, so probably 3.0 will fade out (as have 2.70 and 2.71). But probably most of the people on the 3.01 beta will move to the 3.02 beta (or whatever CJ comes up with next) as they are "early adopter"-type-people.

And I guess gradually 2.72 users may slowly move over to the latest 3-series version, but its a quite a bit of an interface change so that will occur more slowly. There's also a thread discussing versions used in the AGS Forums.

Pretty Module Updates

If you fiddled with the compile options in AGS 3.0 (and 3.01) then my Hypertext and SpriteFonts modules did still work. However, now I've updated them and they work natively AND still work in AGS 2.72. How cool is that? As I mentioned before, these should work more efficiently in AGS 3.0 because they now use the DrawingSurface functions and don't have to keep saving off the whole screen to use it as a scratchpad as they used to.

AGS 3.0: The Editor

One of the biggest AGS events recently was the release of version 3.0. This is the biggest change in the editor since it moved from DOS to Windows! The actual script language has changed very little in this new version (see previous blog posts for those wee changes), and so that part is reasonably painless in upgrading, but the editor is waaay different.

First, you need to download the .NET framework, which gives the new editor its standard look-and-feel, and saves CJ re-inventing the wheel. You can then run the AGS 3.0 installer (yes, it now has an installer!) or there is a zipped version if you prefer DIY installation.

So now you can have multiple scripts open at once (via tabs at the top of the page), you ran set breakpoints in the code, and single-step through them with the editor and game side-by-side, you can import editor plug ins like the great Media manager and the whole thing has a much more modern look to it. I'd really recommend going in and having a play, and CJ is particularly open to fixing minor usability issues as new people come to use AGS 3.0, so the 3.01 beta already has a lot of things fixed in it.

Another major point is the support for version control systems, like Perforce and Subversion, so large projects with lots of people working can all gel together better, and you can keep track of all changes to your game so when you say, "Oh flippety-flop, I didn't mean to delete that" you can cancel your checkout or go back to an old version of your code.

Upgrading Modules to AGS 3.0

I've been going through the Hypertext, Credits and SpriteFont modules checking if they need to be changed to work better under AGS 3.0. Forrtunately, Credits didn't need anythign doing at all. If you turn off "Enforce object-based scripting" in AGS 3.0, they all should still work, but they would be, still, using the Room background as a temporary draw space, then restoring it, which less efficient.

So, it turned out to be relatively painless to move to the DrawingSurface commands I mentioned before, but I have yet to fully test the upgraded modules at all game resolutions, which can often be the tricky bit to get working. Also, since my own site is on the same server as the AGS forums, I can't upload it right now anyway!

But to make sure the modules still work under 2.72 (and 2.71 and 2.70, where possible) I have to stick lots of #ifver 3.0 and #ifnver 3.0 in all over the place, to wrap up the version-specific code. And then, if you have to support versions before 2.72, then you need to wrap those up in #ifdef AGS_SUPPORTS_IFVER as 2.71 and earlier didn't have the #ifver commands! So it can get quite convoluted. Then, I need to load up all the different versions and check they still work... Maintenance can be pretty non-trivial, sometimes.

Extender functions

One of the coolest new features of AGS 3.0 is the extender function. Previously, if you wanted to use a function to, say, make your character look at someone before saying their line (e.g. in a 3-way conversation) you could script it manually each time:

cFred.FaceCharacter(cWilma);
cFred.Say("Hello Wilma");
cFred.FaceCharacter(cBarney);
cFred.Say("Hello Barney");
cFred.FaceCharacter(cWilma);
cFred.Say("How are you, dear");

Which gets tedious after a while, so you make up a function:

function FaceAndSay(Character *speaker, Character *facing, String what) {
speaker.FaceCharacter(facing);
speaker.Say(what);
}
...
// in script header
import function FaceAndSay(Character *speaker, Character *facing, String what);
...
FaceAndSay(cFred, cWilma, "Hello Wilma");
FaceAndSay(cFred, cBarney, "Hello Barney");
FaceAndSay(cFred, cWilma, "How are you, dear");

But what looks even better is:

function FaceAndSay(this Character *, Character *facing, String what) {
this.FaceCharacter(facing);
this.Say(what);
}
...
// in script header
import function FaceAndSay(this Character *, Character *facing, String what);
...
cFred.FaceAndSay(cWilma, "Hello Wilma");
cFred.FaceAndSay(cBarney, "Hello Barney");
cFred.FaceAndSay(cWilma, "How are you, dear");

So, you are, in effect, adding a new method to the Character class. This is a noddy example, but it can really lead to much nicer code.

Drawing Surfaces

AGS 3.0 introduces a new type to the game author called the DrawingSurface which allows you to do the equivalent of RawDraw commands on an object other than the current Background. You can also use it for the background, too.

Previously, if you wanted to modify a sprite on the fly or do any complex drawing you had to save the background, clear it to the "magic pink" colour that turns transparent when grabbed, do your drawing, grab a dynamic sprite and then redraw the background how it was. This wasted time and could make things slower than they needed to be. The Drawing Surface concept lets you draw onto a Dynamic Sprite directly. Not only that, but it adds the ability to use hi-res co-ordinates within that sprite instead of the standardized 320x240 co-ordinates, if you wish. Further capabilities are added in the 3.01 beta where you can also grab the colour of a pixel within the drawing surface, just like the eyedropper tool in a paint program.

Modules like my Hypertext module, which allowed fonts to change in the middle of a piece of text (amongst other things) used the drawing-on-the-background extensively in version 2.72 but now they can be much more efficient and organised, and draw on dynamic sprites, which is great. If only I could get around to updating the module... and all the others that are affected by this: like SimpleSnow, SimpleRain, SpriteFont and Shadow...