Messages

This still lives. It's been slow since it's a one-man project and I have other stuff I'm working on. Here, have some newer backgrounds!










Conversation menus in action:

Finished it earlier today! From a puzzle-design perspective, it's pretty ambitious and carefully constructed.

Mark Ferrari's backgrounds are pure eye-candy, though they mix a little oddly with the goofy bigheaded character art. Honestly, the biggest pang of nostalgia I got was

Spoiler

walking through the temp art at the end. That's when the style meshed the best, and I sorta wish the whole game achieved that look, which looks like what they originally planned. Can't really fault anyone for hiring Ferrari though.

[close]

The humor is even more wink-wink than Monkey Island ever was and that can get on your nerves. The plot has a similar weakness to The Cave in that you play a bunch of random grab-bag characters of different styles and genres and it kind of dilutes the overall atmosphere. Having a bunch of disparate goals made it hard to identify with any one, the way you do with "become a pirate" or "rescue Sandy."

Not to focus on the negative! I'm just worried about it getting overhyped. Ultimately, it's 10-20 hours of really well-designed adventure gaming with tons of charming callbacks and details. If you're on this forum of course you should get it.

If you have a key in room A and you don't want the player to pick it up until they've encountered the door in room B, put the key up on a tall shelf, and put a long stick next to the door in room B.

There will always be times when you use the protagonist's opinion as a no response-- "I don't want to do that." But generally it's an awkward type of puzzle when the player has to convince the protagonist to do something that would have no apparent consequences, like picking something up.

I'm bumping this thread to say that Dropsy is out!! I beta tested it and it was amazing. I was surprised by how much it reminded me of playing adventure games in my childhood, even though its gameplay style is fairly different from the classics. There's a wonderful sense of exploration, and apparently a lot of content has been added since I tested.
I think everyone will love it. Go, get it now!

Awesome! I did something similar for MI2 here (with some analysis.) I'm working on one for Day of the Tentacle too.

It's really interesting how much puzzle dependency charts have been talked about lately, and how rarely they were before. IIRC discussions about puzzle theory in previous years mostly focused on describing different types of individual puzzles (like that article GinnyFromThePast linked) and not the overarching structure; linearity, bottlenecks, player motivation.

Trying out the demos it looks like there's no pathfinding at all.

Sierra-style deaths were honestly pretty fun and I wish more games had them, as long as there's an autosave. Walking deads/dead ends can eat it, though.

All I've played is part of D. Duck 2, but it's very intriguing and impressive. So, yes.

For Icon Architect, after I came up with the broad strokes of my story's setting, antagonists, and conceit. Then I designed the protagonist as someone who doesn't know more than the player (and has the benefits of a blank slate), while still having explicit motivations and values. (Side note: Guybrush is the ultimate example of achieving this quickly and effortlessly. He wants to be a pirate, so he says so. The player is instantly in accord with him-- why else would you be playing a pirate game?)

When it came to actually writing the specifics of the plot and "chapters" of puzzles, I focused heavily on giving the protagonist--and the player--clear goals and motives that ramp up in importance as the game goes on. So, it starts out with an innocuous assignment, then the goals become more about saving herself, then saving her friends, then saving the world.

At every point in the game the player knows what they're trying to accomplish, and more importantly, cares about doing so (Well, I hope I write well enough for that to be true.)
Never assume that your player will want to solve puzzles just for solving puzzles' sake, or merely to progress. Adventure games are not puzzle games that reward you with story. Think of it as writing a story that motivates and manipulates the player into action. If the solution to a puzzle involves doing something cruel to a character, make that character someone the player wants to be cruel to. If a location needs to be explored, make sure it stokes curiosity.

Keep notebooks. I have a page where I just drew a ton of random inventory items that would be appropriate to the setting. I ended up using a lot of them in my puzzles later. You can do the same with ideas for characters and locations. Write freely and pick and choose from it later.

Here's a thread about puzzle dependency charts. My entire game is designed in one of these--I found myself writing out plot ideas and other non-puzzle nuggets into nodes as I went. But just for puzzles, charts are useful for pacing your game, avoiding dead ends, and designing parallel puzzle chains that interact with each other in interesting ways.

I haven't finished this game, mostly because of the oblique goal. You've created an awesome environment, the graphics and overall effort are amazing, but being plopped into a mysterious world with zero character motivation (other than a vague "get out there and explore!") is inherently unengaging. I hope that's not too damning a thing to say.

One problem with axonometric/isometric is interiors need to have high ceilings, unless you're okay with odd cutoffs and black space. It's definitely something you can embrace, I'm not sure what you can do if you want to avoid cutaways and cross-sections.

Hmm yeah, I think that would take some rewriting, might not be worth it. I was just wondering if the mousewheel events could be detected the same way keystrokes and clicks can.
One simple idea-- I'm already making a launcher wrapper for the game with Autohotkey, and I can code it to convert mousewheel events to up/down keystrokes whenever the game's in focus.

I have two custom menu systems in my game. One for verbs, one for dialog. They work pretty similarly: the menu pops up, enters a while loop sort of like this:

Code: ags

bool chosen;
while (chosen==false) {
    if (IsKeyPressed(eKeyDownArrow)) [[[scroll menu down]]]
    if (IsKeyPressed(eKeyUpArrow)) [[[scroll menu down]]]
    if (IsKeyPressed(eKeyReturn) || Mouse.IsButtonDown(eMouseLeft)) chosen = true;
Wait(1);
}

(They're more complicated than that, checking for mouse movement as well.)

Basically, I want to add the ability to scroll the menu with the mousewheel during this loop. But apparently eMouseWheelNorth and eMouseWheelSouth can ONLY be detected by on_mouse_click. And on_mouse_click does not fire during a while loop. Is there any workaround?

I checked a backup of my game (still in 3.4.0.4), and the problem wasn't there, so it must have been a mistake in my script, not an error of AGS. I use ProcessClick at other points in the global script (eModeLook interactions, for example, are repurposed to set verb names, like "open" on a door.) One of these must have been overriding the eModeInteract ones.

Figured out a workaround:
In the part of my global repeatedly_execute that checks whether the player's reached the walkto points, instead of running ProcessMenuClick right there, I made it set a "ProcessFlag" variable to true. Then, *above* that part of the code, I check to see if ProcessFlag is true, and only then does it run ProcessMenuClick-- thus delaying ProcessClick by a game cycle. It works every time now, although I still don't really know why.

I found a recent topic with a very similar problem: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51557.0 Unfortunately, they never solved it, they just ditched the template they were using.
It's a recent post, so they're probably using a newer version of AGS. I know ProcessClick recently renamed to Room.ProcessClick; was anything else about its functionality changed, or the script order it runs in?

1. Yup. The interaction works sometimes (for example, if the character is already standing at the hotspot's walkto point, it works. But if I move her away and then use the hotspot, it fails about 50% of the time.)
2. Here's the full function:

Code: ags

function ProcessMenuClick(int x, int y, int action) {

  InventoryItem *currentINV = InventoryItem.GetAtScreenXY(x, y);
	
  actionvalue = GetActions(x, y, action);
  if (GetLocationType(x, y)!=eLocationNothing) {
    SetActions(x, y, action, actionvalue+1);
    ActionClicked = action;
    if (action < 98) Room.ProcessClick(x, y, eModeInteract);
    else if (action==100) Room.ProcessClick(x, y, eModeInteract);
    else  Room.ProcessClick(x, y, eModeUseinv);
  }
  else if (currentINV != null) {
    if (action==1) {
      verbmenu.Visible = false;
      player.ActiveInventory = currentINV;
      player.ActiveInventory.CursorGraphic = player.ActiveInventory.GetProperty("cursor");
      
      int invitemcheck = Inventory.TopItem;
      int invitemsinrow = Inventory.ItemCount;
      
      while (invitemcheck < (Inventory.TopItem + invitemsinrow)) {
        if (Inventory.ItemAtIndex[invitemcheck]!=null) {
          if (Inventory.ItemAtIndex[invitemcheck].ID == player.ActiveInventory.ID) {
            MouseSetPos(HUD.X+(Inventory.X + (invitemcheck - Inventory.TopItem)*Inventory.ItemWidth) + (Inventory.ItemWidth/2) , HUD.Y + Inventory.Y + (Inventory.ItemHeight/2) );
            invitemcheck = invitemsinrow+99;
          }
        }
        invitemcheck++;      
      }      
      
      }
    else {
      SetActions(x, y, action, actionvalue+1);
      ActionClicked = action;
      if (action < 98) currentINV.RunInteraction(eModeInteract);
      else currentINV.RunInteraction(eModeUseinv);
    }
  }
}

The instance in question is the one after "if (action < 98)". Logically, nothing else in the script should be running. In any case, what functions following ProcessClick/RunInteraction could "cancel" it?

I have a custom system for interactions that involves Room.ProcessClick when the character reaches their destination. For some reason, there are a couple of hotspots in one particular room whose interactions don't run some of the time. I'm having trouble figuring out exactly what determines whether or not it happens.

Anyway, in my custom system, it runs Room.ProcessClick(x, y, eModeInteract) at one point. It's just not happening! The section of code it's in definitely is running. There's nothing disabling the hotspots.

To debug, I tried sticking the following code right above ProcessClick:

Code: ags

InventoryItem *currentINV = InventoryItem.GetAtScreenXY(x, y);
Hotspot *currentHS = Hotspot.GetAtScreenXY(x, y);
GUI *currentGUI = GUI.GetAtScreenXY(x, y);
Object *currentOBJ = Object.GetAtScreenXY(x, y);
Character *currentCHR = Character.GetAtScreenXY(x, y);
if (currentGUI!=null) Display("GUI %d",currentGUI.ID);
if (currentINV!=null) Display("INV %d",currentINV.ID);
if (currentOBJ!=null) Display("OBJ %d",currentOBJ.ID);
if (currentCHR!=null) Display("CHR %d",currentCHR.ID);
if (currentHS!=null) Display("HS %d",currentHS.ID);

This should tell me if there are any other hidden elements somehow stealing the click. Nope, none of them popup except the HS one, which displays the appropriate ID. By all means, ProcessClick should be succeeding every time, and I can't figure out what might be blocking it. I've also tried termporarily using currentHS.RunInteraction instead, but it's the same thing.

Running 3.4.0.4, so there could be some issue I'd need to take with the devs.

Yeah, I just ended up writing a function doing exactly that.

Code: ags

function GetTextWidthX(String message, FontType whatfont, int wrapwidth) {
  String line = "";
  String remaining = message;
  int maxwidth = 0;

  int ind = remaining.IndexOf(" ");
 
  if (GetTextWidth(message, whatfont) <= wrapwidth) return GetTextWidth(message, whatfont);
  if (ind==-1) return GetTextWidth(message, whatfont);
  while (ind!=-1) {
    String newremaining = remaining.Truncate(ind+1);
    line = line.Append(newremaining);
    remaining = remaining.Substring(ind+1, remaining.Length);
    int linewidth = GetTextWidth(line, whatfont);
    if (linewidth >= wrapwidth) line = "";
    else if (linewidth > maxwidth) maxwidth = linewidth;
    ind = remaining.IndexOf(" ");
  }
  return maxwidth;
}

Seems to work well enough.

I'm replacing the Say function using overlays from DrawStringWrapped. I'm able to pretty accurately mimic the way the built-in Say option wraps and positions dialog, but I'm having trouble getting the dialog to align to the edge of the screen if the character is standing there.



For example, the text displayed by DrawStringWrapped is set to wrap to 160px wide. This results in text that's actually 130 pixels wide, but I can't figure out how to get that number in script, so it's aligned based on the 160px value, which results in awkward placement.

Here's how .Say normally displays it:

(ignore the disembodied head)

Is there some way to do this?