Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Topics - Gilbert

Pages: 1 2 [3] 4
"Me is hangury!"

Jon Arbuckle is away from home, but he has forgotten to feed his adorable kitten. Now, the starving kitten is on his own, looking for a way to open teh only edible piece of relic at home...

Help the kitten fulfil his quest, be it successful or not.

  • You can draw your own versions of the sprites if you do not want to use the supplied ones, as long as it is about a fluffy animal that purrrrs, who tries to open some sort of food sealed in a container (so it's not limited to a tin of tuna; it can be a box of biscuits, a bottle of pickles or whatever you can think of).
  • It is not necessary for the animal to succeed at the end. He may fail. Hilarity takes precedence.
  • You can add any objects to act as tools, or if you're imaginative enough, you can also do it without adding any objects.
  • No size, colour or frame limits.
  • You may modify and animate the supplied sprites or draw and animate your own sprites, within the guidelines mentioned above.
  • All entries must be posted in this thread by or on the 28th of July 27th of May.
  • The host of the competition will judge the winner, mainly on aspects including creativity, funniness and skills.
  • Excessive cuteness RECOMMENDED.
  • Have fun and be gentle to cute animals!

I don't know whether this has been fixed in V3.2 as I'm not checking due to the stupid installer, but I think this problem is still here, judging from the change log.

It seems that, say when you let character B follow character A (with FOLLOW_EXACTLY set at least), some of the settings for B will be taken over by those of A's.

This is sometimes not desired, as we may need to control those properties ourselves for some reasons.

One typical example is to add a shadow below the player character (this isn't what I was going to do, but I think it's easier to explain this problem in this way) and say we draw a black oval shape as the shadow and assign a view containing this sprite to a character. In this case, we need these:

1. The shadow should follow the player at exact position and should be placed behind the player.
2. In fact the shadow should be behind everything, including objects and other characters.
3. The bottom edge of the shadow sprite should be placed a bit below the player's feet.

So, under this logic we may do something like this when a room loads:
Code: [Select]
cShadow.FollowCharacter(player, FOLLOW_EXACTLY, 1); //1
cShadow.Baseline=1; //2
cShadow.z=-7;  //3

We expect the result would be like this (the key is an object):

However, if we use the above codes we actually have this:

Turns out the Baseline and z properties (and possibly other properties as well) of cShadow are being overridden by player's, so 2 fails as the key is drawn behind the shadow and 3 fails also as we see the bottom edge of the shadow just touches the character's feet.

So, I tried to enforce the settings by putting the last two lines of the above codes into repeatedly_execute_always() and it didn't seem to do anything. HOWEVER, ironically, when the game is paused (such as bringing up the icon bar in the default interface) these properties are (temporally) set and the display is correct (I guess this is because the characters are not moving, so that tyrant behaviour of FollowCharacter() is not triggered).

Possible solution:

From the manual entry of FollowCharacter():
If you use FOLLOW_EXACTLY, then EAGERNESS has another meaning. If you pass 0, CHARID will be drawn in front of CHARTOFOLLOW; if you pass 1, it will be drawn behind.

Clearly, in the above example EAGERNESS has to be set to 1 for the shadow to appear behind the player. However, this is not enough as we want it to be behind everything, not just the player.

To avoid breaking existing codes I'll suggest adding the choice '2' to EAGERNESS of FollowingCharacter() when FOLLOW_EXACTLY is used, in which case properties such as Baseline and z won't be overridden.

(I'll create the respective Wiki page and move this to the Module section later.)

As its title suggests this script module decodes picture resource files that were used in Sierra's classic AGI game interpreter. Note that this module is NOT tested exhaustively. If you have any problems, just drop me an e-mail or post in this thread.

I often use AGS for testing stuff, as it provides a simple environment without the need to say, setting up DirectX, OpenGL or including any libraries for small things to show up. This is no exception. It was not meant to be anything used in AGS games but I considered to release it anyway.

- Decodes AGI picture resource files, with optional priority screen.
- Works under ALL colour depths supported by AGS.
- The colour used for each slot can be changed if required.
- A simple demo is included.


Just import the module into your game via the AGS editor. Remember that AGS V3.1.2 or later is required.
To decode an AGI picture resource file (say, with filename "street.agp") in your game, just use the following codes:
Code: [Select]
You can then get a DynamicSprite with pointer AGIPicDecode_Picture which you can use in your game. Consult the included document for more information.

You can download the module from my blog entry or download it directly here(Mediafire).

Edited on 29-6-2017:
Fixed dead link since my blog has been moved.

Since AGS was updated to Version 3, the editor was completely rewritten, and it wouldn't be surprising that the highly under-used, publicly-hated and untested 8-bit colour support may no longer work as intended.

I recently got some spare time to update my 8-bit colour tutorials to AGS V3 and I noticed some oddities in the editor. To make sure of this, I made some tests using the newest test version (V3.2 RC3) and found that most of these problems still exist.

1. The "Remap colours to game palette" setting in the sprite import dialogue is not saved properly. When using 8-bit modes seriously this should always be turned off. Currently, when you want to import another sprite you need to uncheck its checkbox again, which is very, very annoying. This is a step backwards, as this problem also existed in V2 initially and was supposed to be fixed since V2.61, but now it resurfaces in V3 of the editor. I haven't tested this extensively, but I have a feeling that the "Lock to room background palette" setting may suffer from the same problem. If this is the case it should also be fixed.

2. When palette entries are changed the effects aren't reflected in the editor immediately. For example, I want to set the palette properly and then import these sprites in their exact details. I first import the appropriate colour slots of the palette by grabbing them from the image file and have this:

Then, I import a sprite using 'exact palette import' (i.e. turning off "Remap colours to game palette"):

We see that the image is okay during import, but after import the image displayed in the sprite list is all messed up:

The colours are correct if you restart the editor or see them in-game. My guess is, that the editor would only use the colours when it first loads the game. Any changes in the palette would not be reflected immediately in the same session.

3. Colours of the backgrounds would not be reflected in the palette. In previous versions of the editor, when you edit a room, the "room dependent" colour slots (i.e. "Background" slots in recent versions) would actually change to match the current room (well, especially for the DOS versions of the editor this was trivial, as the editor operated natively in 8-bit mode, loading a room would force the system palette to change to match the room), which could be checked by (temporally) changing the room-dependent slots to "Gamewide". This was actually a good feature in verifying whether a background is imported correctly, but since V3, when you change the "Background" slots to "Gamewide", you'll see that these slots only carry some random colours (probably whatever colours that were assigned in the initial palette). Say, when you import this background into a room, which has the following palette:

You'll expect that after import the last two rows of the palette contain a red slot and a gradient of green, but after changing the "Background" slots to "Gamewide" I only see this:

At first, I thought that this was because of the change in interface of the editor, so that we can edit two different rooms at the same time (in previous versions, only one room could be loaded each time) and if this is the case it would be impossible to have the palette accurately reflect the room colours. However, after further testing I find that the current editor cannot edit two rooms at the same time either, so it's still reasonable to have this feature. The editor can edit the scripts of two different rooms at the same time though.

4. After importing a sprite with the "Lock to room background palette" setting turned on, the sprite may not be displaced in its correct colours when you put it as an object of a room. For example, I want to import this sprite to use in a room having this background. However, when I place the sprite as an object in the room I get this:

I think this is somehow related to problem #3 above, that the object is not using the correct palette colours (current "Gamewide" slots + "Background" slots matching the current room background). Again, when you restart the editor and reload the room, or test the game you can see that the colours are perfect.

Since the above annoyances do not prevent games from working properly and I don't know whether they can be fixed in the current incarnation of the editor, I'm not sure whether they should be considered glitches or limitations. Anyway, as they're introduced since the editor rewrite and the problems are somehow related, I'll just make this new thread instead of reporting them in the beta version thread (some of these may have been reported already but I think it doesn't hurt to have related problems put into one single thread).

P.S. I notice that SaveScreenShot() stores files in the save game folder (this is now written in the help file), but DynamicSprite.SaveToFile() stores files in the game's folder. I understand the reasons for this, as the DynamicSprite one could probably be used to store some temp. files for future loading, etc. (though personally I think that BOTH functions should write to the game folder instead). The problem is, it's not written explicitly in the manual where the DynamicSprite one would store the files, so it would be good to have a reminder on the entry just like the ScreenShot one.

P.P.S. I understand the reasons to discontinue support of PCX files in favour of BMP and PNG. However, because of the following problems PNG is not (quite) usable in 8-bit modes, so instead the awful BMP format unintentionally becomes the preferred format for development of 8-bit games (as seen in my updated tutorials):
  a) In the palette editor of the editor, you cannot use PNG to import or export the colours, only PAL and BMP are supported. When making 8-bit games it's common practice to just import the colour slots directly from the image files (PAL files should be avoided as they're too ambiguous and it just makes you do an extra step to save extra files), so you're forced to save your images as BMP.
  b) The funny thing is, however, in the game engine the use of PCX files is still supported (check SaveScreenShot(), DynamicSprite.SaveToFile() and DynamiteSprite.CreateFromFile() ), but not PNG files (I understand that this may be related to the more complex compression schemes used by PNGs and this is to prevent the loading and saving of PNGs from impairing the games' performance).
Thus, I think if possible, it would actually be a good thing if PCX sees a comeback to the editor (as in fact, some good native 8-bit editors such as DP2E support saving and loading of PCX files but not BMP).

P.P.P.S. In the past, colour slots #0 through #16 were considered as "Locked" and they were used by stuff like system messages, debug mode overlays, etc., so they cannot be changed from the editor. Since V3, we don't have "Locked" colours any more, so every slot can be changed any time at will. Actually I like this much more as there are more freedom. The problem is, it seems that the manual is not fully updated to reflect this change yet. It doesn't mention what "Locked" colours are any more but in some pages (say, the description of the SetPalRGB() entry) it still mentions "Locked" colours, which is a bit confusing, and I think we should also put some warnings in it so that people won't get messed up when say using the debug functions after changing these colours.

P.P.P.P.S. The colour values in the editor have since been changed to use 8-bit per channel values (0-255) to work with the Windows colour picker, but for 8-bit games, SetPalRGB() and the palette[] array are still using the 0-63 range. This is a bit inconsistent and confusing but I don't have any better idea, so I'll say just keep this at the moment.

Adventure Related Talk & Chat / IndieGames Awards 2008
« on: 07 Jan 2009, 01:02 »
Didn't know whether this has been mentioned yet, but I came across this and found that in the Best Freeware Adventure Games 2008 of IndieGames.com, there are many AGS games, notably 2, 3, 6, 9, 10, 11, 12, 13, 14 and 15, i.e. 10 out of 20 games in the list.

As I haven't checked AGS games much lately, I may have missed some.

Anyway, congrats to the involved AGSers! :D

See full list here.

Today, after you woke up in the morning, you headed for the washroom as usual, but nearly stepped on an unfamiliar object in the following shape...


No colour limit.

You can interpret the above in whatever shape you like. You may just colour the shape or just do it with an outline.

The shape may be flipped and/or rotated, and small details (like capes or masks) may be added, but the shape should still be recognisable. 

Backgrounds are optional, and because of the theme it may not be interesting anyway as it should be the washroom floor.

An object that provides a shocking moment is a plus!

You have lost your way in the endless maze of the forest. Desparately looking for the way out you have a surprise encounter which makes you stop and have to think fast about what action you should take next.

This week's topic is: Encounter!

What you need to do is to draw what you meet in the encounter, which fits in the background above. Be it a helpful guard of a park, a small but fierce animal, a large but friendly monster, a robot, a serial killer, a fire hose, or whatever you can think of. There is nothing that constraints your imagination except the following rules:

1. There is no definite size or colour restrictions, as long as the sprite fits in well with the background above. Note that to test your skills the background cannot be re-scaled, you can make it a bigger one by expanding the space aound the image though.
2. Sprites that will merge well with the colours, size and the atmosphere of the background will have additional advantages.
3. You have to supply an image of the standalone sprite AND another image of the sprite put onto the background to show how it works. You can, however, save them side by side as a single image file. This does not break the rule.

P.S. You are right. I suck in drawing trees.

Edit: Extended deadline.

General Discussion / Release Something!
« on: 09 Mar 2007, 00:46 »
Since the last round of Release Something had been 4 months ago already (though it ended not very long ago), it's time for a new round.

You may find details here.

Individual Character Scaling
Released on:11th February, 2007

Set the scalings for individual characters according to given percentages
of Walkable Area scaling settings. It may be handy in case you have several characters with their sprites drawn in different scales for some reasons, and don't want to resize the graphics.

Requires AGS V2.71 or later. (note: the demo was saved with V2.72 so probably won't work with V2.71 but I think the module might still work)

Download V1.1 here.
(15-2-07: Link updated, I forgot to re-export the SCM last time, so the SCM file was still V1.1, you could re-export it using the demo game though)

Read the included icharscal.txt file for details on usage.

Normally I have no plan on making official script modules, I only mucked up quick modules for testing purposes when I thought I could help solving some people's problems. Since I never had time to read the official guidelines, my modules probably won't follow the naming conventions and formatting, etc., they can also be glitched, and may even clash with other module codes.
This one is no exception, it's originally an attempt to fix Samwise's problem. Thanks to Samwise's suggestions and reports, V1.1 fixed some small glitched. Anyway, use at your own risks.

(This is a restored post which was accidentally deleted, thanks to TK for the archived thread.)

OROW is now finished, games have been voted on, and winners decided.

OROW for newbies: The one room one week competition is a small games competition, focussed on making something fun or interesting, within a week.  No team management issues, no runaway design documents, no epics; just a bunch of finished and often innovative games. The games are voted on at the end, but it's not really about the competition, for most, it's about getting a little game done, so it's fine for everyone and anyone to enter. Examples of previous OROW games that have done well are Anna, Automation, Gladiator Quest, Tomb of the Moon, Alone in the Night... all kinds of things, but all small, don't think too big.

There's no theme, the rules are as before, but also here:

  • You have one week to submit your game to me.
  • It can have any number of rooms.
  • You may work with someone else if you wish, but working alone is encouraged.

Competition is over, download the games and later, vote on them.

Download Games (45MiB)
Split files, for dialup

And the Results...

33 people voted in all, and lots of categories were close, but I'll just announce the winners in each.  One game has taken most of the categories, but it's not quite an Automation style perfect win.  Here are the winners:

The highest scoring game for sound is The Heist!
The highest scoring game for graphics is The Heist!
The highest scoring game for writing is Heartland!
The highest scoring game for design is The Heist!

This OROW's Best Game is... The Heist! by AJA and Mad Reizka.

The game authors are as follows (correct me if I'm wrong, I don't always write down people that helped, especially):

A Gunshot in Room 37: Ishmael, with music by Vel
ASL: Edmundo with music by Trapezoid
Hallway: Mordalles
Heartland: LimpingFish
Keyboard Madness: BOYD1981
Rosella Wilson Meets Helm: Grundislav
Soren Quest: Erenan
The Heist: AJA and MadReizka
The Loathesome Man: Anarcho
Wooly Rockbottom and the Golden Beard!: ProgZmax

Well done to AJA and LimpingFish, all that finished and entered games. A number of people have told me they thought this competition was the best quality yet.

If you want to see how the voting went in detail, or how far your game was behind the winners, you can take a look here.

 What is a Photoshop ...Whensday?

Photoshopping isn't drawing a completely new image -- It's editing images to create a new image, such as editing one image or combining several images. The contest usually lasts for a fortnight. Also, you don't have to specifically use Photoshop -- Paint Shop Pro, MSPaint, or any other programs can be used. Please make sure your image doesn't exceed the width of the screen.

See this link:

And for other examples, see here:


This week's topic: Adventure game characters in sports

Choose any adventure game character(s), make him/them play whatever activity you may consider a sport. Be creative, it can just be normal sports like popular NBA or Football, but make sure they're played in funny ways!

Here is a quick and crappy example (looks like someone's cheating := ):

Whenever there're some notices or warnings in the editor they'll be recorded in agsedit.log, with time stamps. Just noticed that there seems to be a minor bug in the recorded date.

For example, today I checked out some game source (not mine) which required the agi graphics plugin but I forgot to put it into the AGS folder, so a warning was generated, telling me I didn't have the DLL in the correct place. Later I opened agsedit.log out of boredom and found the following line:

11/00/06 15:19 WARNING      The plugin 'ags_agi.dll' was not found, and this game relies on it. You can continue, but any plugin-specific settings will be lost if you save the game.

So the month was reported as 00th?2? I bet it's possibly a millenium bug (like the one in V2.62 engine which returned wrong year) that somehow the 100+th year gave a carry over to the month, OR, there's some glitch that the reported month is always one lower than the correct one (so it starts from 0).

Here is a very simple module used for automatically displaying the hotspot name under the cursor, using an overlay.

Just import for a game made with AGS V2.7 or above and all will be automagically done, if you want more controls, read the provided text file and the source code of the module.

Download here (Version 1.12)

Old versions:
V1.0 Initial release.
V1.1 Bounding box.
V1.11 Cleanups by Strazer.

Edited 2006-01-18:
Version 1.12 available, should compile now if you use AGS V2.71 and have the "Enforce new-style string" option checked.

Edit 2006-04-30:
Functionality now part of the Description module. The OverHot module will not be maintained any further.

Chris, actually it's related to this thread.

I'd tried doing the "only L/R loops for character trick" but it didn't work if "character turns before moving" is checked, examples are here (includes V2.62 and V2.7 testgames, created just by making a walkable empty room and deletes loop0 and loop3 of roger), just move roger around and crash.

Actually I'm not really sure if it is just some obvious or not-so-obvious problem (since it seems that no one was complaining since this is added, unless no one was actually doing it).

What I am thinking is, though it sounds meaningless to have that option on while you only use 2 loops for a character, it's not good in the sense that you may want to make a game with some characters have 4-way loops while some of the others have 2 loops, and you want those having 4 loops to turn before moving.

Since the last Artitude had been through more than a half year already, I decide to resurrect it once again.

What is Artitude? Well, it's a general art creating activity which any member can participate. Each time we have a topic and members can make their own pieces of art according to the topic. Note that, unlike Sprite Jam, Background Blitz, etc. this is not a competition, so there'll be no winner. The sole purpose is to motivate members to make something creative.

This time, I choose a theme without approval from any secret elite AGSers, and it is (as written on the subject line), your favourite animal(s).

You can draw your favourite animal(s) in whatever resolution, colour depth, and style, be it your pet(s), a dinosaur, yourself, an imaginary cyber monster or whatever come up in your mind which can be related to the topic, members can even join forces and cooperate in one piece of art. One more thing, is that I'll try to loosen the rules, so you can submit other stuffs other than drawings, as long as it's art created by you, so you can created things like music, songs or essays inspired by the topic. However, after some 3-second-well-thought-about, I'll exclude photos here, as I don't want to make this thread another 'post your pets' photo' thread (I'd like to see them though, maybe somewhere else).

Since you're not competing with anyone, you can also make as many pieces of arts and enter as many times as you want. :=

To encourage more people to participate, I'll extend the time limit to two weeks, with deadline set on Monday, 1st May, 2005.

Sex and violence encouraged restricted, as we would love not want to see you with some animals in such situations. Humour and moody art particularly encouraged. Go art!

Since we're still in a holiday mood, I'll make this Jam Christmas related also.

Your task is to draw a sprite of a Christmas tree...

Wait! Isn't that simple? Not really, that tree should not be made with a tree, i.e. it can be a "tree" make with scrapped metal, or by socks hanging from a pole, as long as it's creative and hilarious.

Oh, and the specs:
size: not bigger than 30x30 pixels
colour: unlimited

The reason I set the size restriction so small is that I also want you to use your skill wisely to have make your creation easily understable in such a small size.

So, happy spriting!

Pages: 1 2 [3] 4