Messages

player.SayAt(...) (or <any character>.SayAt)
Type SayAt in your script, highlight it, and press the F1 key to get the details

- Set your brush to scatter
(...)
- add some size and rotation jittering

Are we talking Photoshop settings here? I'm so bad at Photoshop brushes. Every single time I have to check Google to even remember how to create one.

If you're keen on using Photoshop trickery, have you considered using photo textures over scenes and then reducing colours? It's not an "automated process" but it's a very fast way of working, and is pretty common.

That's indeed the kind of things I'm discussing. I've suggested a similar solution in the first post; but I was thinking that maybe someone had actually pushed their research further than I.

I agree with everything above, except (maybe) these:

* Non-anti-aliased TTF fonts

Don't know about aliased ttf fonts, some might be designed to look good, assuming font hinting is in effect.

I am also not sure about this

Me neither. Don't some people use this to generate multi-colored fonts? if there is an automated antialiasing it might mess uptheir carefully crafted font.

* Being able to set for every individual sound and music file if it should be inside the EXE or not

I don't this topic well enough : Couldn't that be helpful to upgrade just the EXE of a game without downloading the entire game again? I favor the principle of storing the resources outside of the EXE.

For the final image, this would be pretty simple to replicate using photoshop brushes, using pencil mode to stay away from soft edges, as this is basically what they've done. Just start with darkest shades, and work up through your ramp as you paint layers. I suggest some editing afterwards to lose the obvious copypaste look, though some don't bother with this.

Edit: Something similar I've done in the past is painting one small piece of foliage very carefully, then copying and pasting it around the image on all areas of foliage. Then I paint the seams in and add variety. This saves a lot of time and if you paint it in enough, it's basically impossible to see any repetition.

I understand what you're saying, and I totally agree that it is the "manual" method that gives the best results. I used to do that all the time with Deluxe Paint.
BUT I'm trying to find powerful new tricks to semi-automate the processes.

[- Messy artifact-y foliage :]

Hello,

Normally Critics Lounge is to sho something that you've made and ask for constructive criticism.
But it's also a space for discussing the drawing techique used -- so, not to set a precedent, but I'd like to ask you tips on a specific topic : drawing foliage in pixel art.

Foliage in pixel art looks differently for every pixel-artist, but in the end I still think you can categorize the result in 3 families :

- Messy artifact-y foliage : That's usually when the artist simply scaled down a picture of a tree.      Caracteristics :       x There are almost as many pixels as there are leaves       x There are almost as many shades of green/brown as there are leaves       x The contrast is usually very high and there are way too many black pixels -- because in the original tree picture, the areas that were in the shadows (especially the self-cast shadows of the tree) were rather dark, and the artist failed to adapt that original shading to match the overall shading of his/her pixel scene.           Example 1 (background foliage): PLEASE NOTE: I'm not criticising the guys who drew the backgrounds for this "Tanis" demo as I think they made an outstanding pixel art job for everything else. Only the foliage bothers me.       Exampe 2: these ones were probably drawn by hand, and yet they still have this messy aspect and exagerated contrast :       - Overdrawn/overstylized foliage : That's when the artist actually drew the leaves one by one and got carried away with the shading. It gives everything a cartoony look or a "pillow shading" look.           Example 1: (see the leaves in the foreground)       Example 2 :  (notice how each leaf is drawn one by one in the middle tree) (The crystal shard team produces amazing graphics but that's not the style we're aiming for)       - The magic look : (the look Id like to achieve) the foliage has exactly the right level of detail and number of colors. It has a crisp ascpect and yet it's not busy.                 Example 1 (Fate of Atlantis as always      Example 2        Strangely, FotAQ artist succeeded here. Even though there's a lot of copy and paste.

So, now, the discussion: any ideas on how to achieve that render effect?


I was thinking the following transformations/filters in photoshop:
- gaussian blur (to remove unnecessary details)
- color quantizer (it's like a better posterize) to reduce the number of colors
- denoiser to remove the few rogue pixels remaining and giving an overall smooth (yet crisp) aspect
- and of course at the end a brightness-contrast (or better yet: curves) adjustment.

Any better idea?

Issue with Cat/Washing needs looking at...

Spoiler

Need to get closer... This is the issue

[close]

Spoiler

the cat needs to go on the same level as the bag

[close]

the goal isn't being able to survive AGS upgrades, but to survive a game upgrade.

I phrased it badly but that's what I meant. So I still mean what I wrote.

If the goal is to implement saved games that can "survive" the upgrade of AGS, then I would recommend targetting something very primitive, or else you're either targetting madness or failure.

I would suggest saving only the things that are relevant at room change. Like some sort of autosave. That would bring the player back at the beginning of the room, before fade in.

This way:
- all you need to do is to save the player's room and some room-related or global variables,
- you don't need to save everything related to characters states (IsWalking, current frame and all that), you don't need to save everything related to sound (current sounds being played, their current time position, etc.)

Since you can't access the values of all your internal variables (without having them at hand at all times), you might want to use the Ultravariables module for every relevant variable in the game (especially: character's progression and adventure states)

And as Snarky suggested, you may choose to use monkey0506's Stack module, for massive serialization.

A difficulty remains, though: the player will still see the broken saved games in the folder after upgrading AGS. Is there a way to intercept that? The only solution I can think of is to generate your custom saved data alongside the regular one every time the player saves his game, and then when your external tool upgrades the game, the formerly saved games are deleted. Only your custom saved data remains (and is offered to the player for loading)

If you just do some "minor" changes in code, it won't break the savegames. However if you add/delete any assets like variables, sprites, objects, rooms, characters, etc. It will break the savegame. You can though take some precautions to avoid it breaking if you add dummy assets to your game, that you can use later on in case of an update.

Good to know! What are the "minor" changes? Is it if you only modify modules scripts? When you said "variables" did you only mean AGS built-in "global" variables?

how do you get the alpha of a pixel in a drawingSurface? By parsing the highest bits of the value obtained through GetPixel?

[@Crimson Wizard]

SOLVED: the sound's name was too long. A shorter name did the trick.
@Crimson Wizard, if you have time you might want to add some sort of safety check on that.

Scenario :
- I import a sound into the game
- In my room_load (before fade-in), I call aMySound.Play(eAudioPriorityNormal, eRepeat);
- I am able to play that sound fine from the "sound" panel
- the game compiles properly. I then run it from within the Editor, with F5.
- when I enter the room, the game crashes with error "an internal error has occurred(...) Error: Unable to create local script (...) Unresolved import 'aMysound'"


Why?

Note: I've tried compiling it for real ("build EXE") beforehand, but it didn't help.

Is there a thread you can link me to where this question has been discussed before?

Yes, several, but it's not easy to find because the keywords are not obvious. I would suggest this, for example: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54372.0

Check out the other results with this Google search: site:http://www.adventuregamestudio.co.uk/forums/ what is your process

32 bit all the way.
Export the phylactere sprite...?

If it was 32-bits all the way, then you don't need to do that. But still, my comment about studying the flaws of RGB handling (by studying the Trublu code and related discussions) should help if not everything useful has already been said here.

I'm almost sure the answer is in the source code of the Trublu module : http://www.adventuregamestudio.co.uk/forums/index.php?topic=43966
Check out what corner cases monkey0506 is dealing with, and you'll see how to avoid fualty RGB combinations.


PS: just to be sure: is your game 16-bits or 32-bits? On a related note : Did you start your game directly from a demo game that was 16-bits and did you change it to 32-bits? If yes, then you should export the phylactere sprite and re-import it! Moving directly from 16-bits games to 32-games and keeping the original sprites as-is is never a good idea.

[Scenario 1)]

ValI'm actually not sure what you're asking. I'm hesitating between two scenarios :
Scenario 1) you want to flatten your scene (you want your camera to be closer to the ground) which makes it necessary for the player character to walk at 30° angles instead of 45° angles when he's walking NW, NE, SW or SE.
Scenario 2) you want to have 8 more angles for your player character, for him/her to be able to turn in all those directions instead of the 4 basic ones : 0°, 30°, 45°, 60°, 90°, etc. all the way to 360°.


If it's scenario 1 : are you absolutely sure that the following solution isn't "good enough"? :
- enable the extra four "45°" loops. In them, use sprites that look 30-degrees oriented instead of 45-degrees oriented.
- in the game, reduce the vertical walking speed, for the player move faster in the left/right direction and slower in the up/down direction.
- See if the corner-cases where the engine detects a theoretical 45-degrees walk angle under the hood, but displays either your custom 30-degrees loop or the two neighbouring loops (0°, 90°) makes it really look awkward. Is it really shocking? I'm imaging it could totally fool the eye.

If it's scenario 2 : I think eri0o is a bit over-enthusiastic when he suggests to implement A* (your game would need to compute the walkable areas and perfom some calculations based on their raster mask, since it's pixels-basedand not vector-based). But you can probably implement something cheaper : whenever your game is supposed to call "player.Walk", you could have a custom "walk" function inbetween that computes the angle between the player's starting position and the destination, and then locks the corresponding view during the entire time the player is walking. You can easily detect when the player has finished walking, by testing "player.Iswalking" in repeatedly_execute.

[It is close to impossible.]

Allow me to reprhase the answer : It is close to impossible. (if you want the player to continue using his/her previous saved games without starting the entire game again)
When I write "close", I mean "unless you can program in C++ and are able to dig deeply into the game's engine code".

Here is why :
- Let's suppose you overcome the non-neglectible difficulty of creating an online repository for updates, managing versions, etc. It wouldn't be too hard if you did an external download tool (like a game launcher) written in C# for example, that would download any new version of the game that you would put in your online repository, and install it in place of the current game version. If you're a pro you can even push this solution further by making patches available -- which would save the trouble of re-downloading the entire game. Side note: it's probably impossible to implement that directly in your AGS game, because even if you managed to download the update material (using the Sockets plugin for example), then the game still could not overwrite its own files I believe.

- But then another terrible problem would arise : all the saved games would be lost. Indeed, downloading a new complied version of the game makes all the previous saved games incompatible. So the player would have to start over the entire game. You might consider this a minor issue, or a major one. This is the reason why eri0o said "you need to implement your own save module". He makes it sound like it's totally casual. Maybe it is for him, but from my perspecive it's an unbelievably complex task.

This question has been posted many times.
I have a more down-to-earth answer: First, ask yourself: "how many rooms in my game?" and "how many people working on it?". the subsequent answers will depend on those.

[About the game freezing :]

I've run some tests.
Just to be clear : The point in this thread was not to say "AGS is flawed in this way or that way", or even to request some fixes. I just wanted to try and find some dirty hacks to get more from my buck and push the limits.
Display seems to be one of these dirty hacks. Read below.

About the game freezing :

Apparently, when the game is in an infinite loop, especially inside repeatedly_execute_always, then clicking on the "pause" button will not be taken in account until a Display or game loop occurs. I don't know how it's coded internally, but maybe pressing "pause" sends a flag to the engine, which in turn waits for its next global internal refresh (actual game loop or the closest similar event) to take this flag in account and be ready to pause next time it encounters a game loop start.

It means that "pause" does not work the same way as breakpoint.

More importantly, it means that pressing "pause" in the editor, or trying to close the game window while the game is inside an infinite loop (with absolutely no instruction causing a game loop or a Display), will just freeze the Editor or the game until you kill the game process.
Another proof of this supposed behaviour is that while the game is in that so-called infinite loop, you can't add a breakpoint in the Editor window.

The curious case of Display

In a nutshell, my research suggests that :
- Display(""); does strictly nothing
- Display("some text"); does a half-baked game loop (updating game and GUIs) but without calling repeatedly_execute or any player-customized script tied to the end of a game loop. It makes Display a perfect alternative to Wait(1), even in repeatedly_execute_always where Wait(1) can't be called.
- The drawnback is that you'll need to display the Display popup on top of your GUI to benefit from the Display behaviour

========================================


Consider this code, placed in a script:

Code: ags

void repeatedly_execute_always()
{
  for (int i=0; i<10; i++)
  {
    gBlockingGUI.Visible = true;
    LabelTest.Text = String.Format("i=%d", i);

    bool exit;
    while (!exit)
    {
        mouse.Update();
        if (mouse.IsButtonDown(eMouseRight))
            exit=true;        
    }
    //Display("");
    Display("Done! (%d)", i);

    gBlockingGUI.Visible = false;   
  }  
}

int frameCount=0;
void repeatedly_execute()
{
    LabelTest2.Text = String.Format("frame=%d", frameCount); //This is never executed
}

If you execute it you will see that the Display instruction forces the game to refresh all its internal variables and animate the game (GUIs) BUT without ever going into repeatedly_execute. It's like some sort of half-baked Wait(1), that forces a game loop without call all the related functions normally hooked to a game loop. That's pretty cool. Also it refreshes the game TWICE, I think: once before displaying the Display popup, and once after (not sure about that, but I'm 100% sure that it does the resfresh at least once before Display).

Another undocumented feature of Display is that calling Display("") doesn't make any popup appear on-screen and doesn't even block the game. It's like a totally useless instruction because it's doesn't refresh the screen in any way.

Finally, I wrote just above that the game refreshes the in-game scene like in a normal game loop. Well, it's not true with the script above (character doesn't move when you click, only the GUi gets refreshed) BUT I swear there was a situation where it was happening for me even though I can't reproduce it. I've searched, and it was happening in some specific conditions, and now it doesn't happen anymore. Maybe someone will be luckier than me. I'm less and less sure that it actually happened. I might have gotten confused in all my tests.