Topics - Gilbert | Adventure Game Studio

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.

Guidelines:

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!

#52

Advanced Technical Forum / [Bug/Limitation?] FollowCharacter() taking over settings

Thu 24/06/2010 03:08:07

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: ags


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():

Quote
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.

#53

Modules, Plugins & Tools / MODULE: AGI Picture Decoder V1.00 (for AGS V3.1.2+)

Mon 24/05/2010 18:14:22

~~(I'll create the respective Wiki page and move this to the Module section later.)~~
[imgzoom]http://i488.photobucket.com/albums/rr249/gilbot/AGIPicDecoder.png[/imgzoom]
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.

Features:
- 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.

Usage:

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: ags


AGIPicDecode.Draw("street.agp");
AGIPicDecode.ShowPic();

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.

#54

Advanced Technical Forum / [Editor V3+] Glitches or limitations - mainly 8-bit colour related

Sun 17/01/2010 11:34:58

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.

#55

Adventure Related Talk & Chat / IndieGames Awards 2008

Wed 07/01/2009 01:02:40

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!

See full list here.

#56

Competitions & Activities / Colouring Ball (11/10/2008 - 21/10/2008)

Sat 11/10/2008 16:18:01

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...

Rules:

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!

#57

Competitions & Activities / Sprite Jam (12 August 2008 - 29 August 2008) WINNER!

Tue 12/08/2008 02:53:28

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.

#58

General Discussion / Release Something!

Fri 09/03/2007 00:46:51

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.

#59

Modules, Plugins & Tools / MODULE: Individual Character Scaling V1.1

Sun 11/02/2007 09:53:23

Individual Character Scaling
Version:1.1
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.

Note:
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.

#60

Competitions & Activities / Results: One Room One Week Competition The Fourth

Mon 31/07/2006 05:22:12

(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.

Pages 1 2 3 4 5