Messages

Correct me if I'm wrong, but wouldn't the phaser recharge endlessly after the timer is set once?

So what you want is to have the phaser only recharge when it drops to zero, and then continue until it's at 100, right?

Then you could use a bool for that:

Code: ags

bool charging = false;

  if (Phaser1Charged < 1 && !charging) {
    SetTimer(1, 600);
    charging = true;
  }

  if (IsTimerExpired(1)) {
    Phaser1Charged += 5;
    if (Phaser1Charged > 100) {
      Phaser1Charged = 100; 
      charging = false;
    }
    else SetTimer(1, 600);
  }

+1

I'd be quite happy about this issue being fixed!

Fun little game Not bad for two days of work!

I needed a minute or two to figure out that I had to get the bones back to the basement  I didn't encounter any bugs though.

I think it's a good idea to participate in a MAGS-competition and do a small game within a month (something I should've done a long time ago instead of starting several large projects that never got finished). Just go for something small and plan a game with a few rooms and few characters and see how much you can accomplish in time. This might help to estimate the amount of work and the time you need for something larger. I recommend playing a few MAGS or other short games to see how people design small games.

I think Crimson asked if you properly linked the room_AfterFadeIn()-event via the room's properties panel (instead of just copy-pasting it for example). Does it look like this:

You can manually change the object's description using a variable. If you have a hotspot label like this:

Code: ags

l_Hotspots.Text = Game.GetLocationName(mouse.x, mouse.y)

.. and e.g. object "table" needs to be changed, because it's broken, you can do something like this, using a bool "table_broken":

Code: ags

if (l_Hotspots.Text == table.Name && table_broken == true) l_Hotspots.Text = "broken table";

She's huuuge ! She wouldn't even fit in any game using a standard pixel-resolution.

If you're going for such a high resolution (and little detail) I wouldn't recommend drawing on a pixel-level. I'd keep the art in 3d (and maybe use some toon-shader?), draw with soft brushes or use a vector art program.

If you really want to do pixel-art, use a lower resolution and make the character much smaller. Most pixel art games have a 320x180, 320x200 (or 320x240) resolution. Wadjet Eye's latest game Unavowed has a resolution of 640x360. If you go much higher than that you can't distinguish the pixels anyway..

sorry to disappoint you, but it's not, in beneath a steel sky you use/pick up with RMB and walk/look with LMB. both mouth buttons let you talk to a character. I took these notes a thousand years ago

Oops, I always thought it was the other way around My bad for not having played the game..

Perhaps surprisingly, a lot of modern gameplayers have never played (or barely heard of) BASS.

As several AGS authors have discovered, numerous players will not realize that the right mouse button does anything, unless you make this abundantly clear in a tutorial (or perhas with a config switch like this one). It's not good design to assume that players will be intuitively familiar with the interface of one particular classic.

I know, but I'm talking about adventure game players, and regardless of whether they've played BASS or not, I thought that left click = interact / right click = look is pretty common two-click interface. Maybe it's just me, but the majority of games that I've played that use a two-click interface have left click as interact.

I've read about those young, modern players not using the right click at all , but the question was only about the two options. And wouldn't it be even worse if right click was interact, but the players wouldn't use it at all? Anyway, as long as I don't work on something commercial, I refuse to make an adventure suited for people playing it on a subway train trip on their smartphone..

Left click INTERACT / Right click LOOK

That's the classic BASS interface and people are used to it. Doing it the other way around is very counter-intuitive and might confuse players a lot. Of course, adding a switch would be ok, but I'd make BASS the initial/standard setting.

Yeah, I tried out yEd a few days ago, too, and I like it (mostly because it's really easy to use).

Thanks for the links, snarky, I didn't really follow the discussions back then.

Sawyer, it's a game in production and it was last updated in 2012, so..

What editor version are you using? As of 3.4.0 the GUI control limit has been removed.

They seemed to be jumping up and down quite a bit for me.

Now that you mention it I see it too. Before I didn't

Hell of a bump! I thought Rui was back

Me too

Changing the Z property does work. Here's the situation with the normal blocking rectangle (second image) and changing the Z property to -4 (third image):

[imgzoom]http://ags.pics/gjW9.png[/imgzoom]
(blue is the walkeable area, the yellow lines indicate the character's basline)

If objects would have a Z property this could fix the problem. I'm not sure if this will cause other problems though and I already noticed that I have to alter the walkeable areas, because now the character is walking a few pixels into the area because her shoes go beyond the baseline. I also have to get used to the fact that now she is walking right into the cursor (and not above) when walking around.

Beautiful background, I'd love to see the other versions! Must indeed be a lot of work to have different day time in your game.

It's always a pleasure to see updates of your game

Monsieur OUXX, I started a thread in the editor development forum. If you want, bring in your ideas there.

[SetTimer]

I'm not sure what you mean by hidden timer, but if you look up SetTimer in the manual I think you will find what you need.

Yes, that is a workaround and in my case (where the object isn't supposed to move) I can just cut a hole into the walkeable area. I just think that either way it's rather annoying having to do this for every solid object.

Also, the blocking areas of the characters are off. With a perspective like this where characters aren't flat and have a few rows of pixels in depth, the blocking rectangle should have a lower y-value.