Messages

So, I've just managed to get a build of the "master" branch for the very first time, using the instructions at the address CW pointed me to.

There was only one change necessary, in the "Build Events/Post-Build-Event" property of the source "AGS.Native": It generates a DOS copy instruction where my source and target contain spaces, so the instruction wasn't parsed correctly by the operating system. Adding quotes solved the problem.
(To wit:

Spoiler

The original was: copy $(TargetPath) $(SolutionDir)..\Editor\References

This expands to: copy C:\Users\Peter G Bouillon\source\repos\ags\Editor\AGS.Native\Debug\AGS.Native.dll C:\Users\Peter G Bouillon\Source\Repos\ags\Solutions\..\Editor\Reference

This generates the error message: Error MSB3073   The command "copy C:\Users\Peter G Bouillon\source\repos\ags\Editor\AGS.Native\Debug\AGS.Native.dll C:\Users\Peter G Bouillon\Source\Repos\ags\Solutions\..\Editor\References
:VCEnd" exited with code 1.   AGS.Native   C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets   133

I changed this to: copy "$(TargetPath)" "$(SolutionDir)..\Editor\References"

This expands to: copy "C:\Users\Peter G Bouillon\source\repos\ags\Editor\AGS.Native\Debug\AGS.Native.dll" "C:\Users\Peter G Bouillon\Source\Repos\ags\Solutions\..\Editor\References"

[close]

)

So, do we have a standard way to check the build (such as a standard example project with known behaviour, etc.)?

Just a quick note:

I feel absolutely compelled to say how impressed I am by the support throughout the AGS forums and in particular right here. In less than a quarter of an hour after posting the question, I got thorough responses that really helped me on.

Also, waiting for my software to download, I read through the thread #448 “Moving to AGS 4.0” as well as through all of the long thread #403 “AGS4 and the death of legacy” that was referenced there. Contrary to the warning about “heated discussions”, I was very impressed by the thoughtful tone and the considerate way of interacting with each other on a touchy subject. Programmers of (probably) very different “generations” and outlooks managed to find a mature consensus, sometimes sharing their personal feelings and viewpoints with a surprisingly open heart on the way.

[really]

They are efficiently implemented, in that they do not contain properties or actions that you generally don't need (for an object).

I'm probably wrong, but my understanding so far was that objects have a hard limit per room because they really slow down the engine; characters, OTOH, do not slow down the engine that much and are unlimited.

As I understood, the recommendation is: If you need lots of objects in one room, use characters instead.

So I assumed that there's something with objects that eats computing cycles, whereas characters doing the exact same thing in the exact same way in the exact same quantity do not eat the computing cycles.

This is why I called objects “inefficient, dumbed-down characters” and wondered why those objects then were in use at all: After all, if the game writer can replace objects by characters, then the AGS compiler might do the same thing behind-the-scenes for them. That is, whenever the AGS code asks for an ”object”, hand out a character instead, and whenever the the AGS code wants the ”object” to do something, use the corresponding function that works with characters instead. Then the code that eats the computing cycles, whatever it is, wherever it hides, simply wouldn't be called.

I agree that this would be a stupid, memory-wasting kludge to short-circuit the object handling code. But if the object handling code turns out to be that klunky and deadweight and that's how it is...

[18]

Hi folks,

I'm a computer scientist and former programmer (I've worked in a different profession in the last years). I've become interested in looking under the hood of the AGS system with the perspective of regularly dedicating/donating some development time in the mean term. I've got a Windows 10 system that I could use for this.

The first step would be to set up a working development system for AGS.

I've found this github project: https://github.com/adventuregamestudio/ags. From there, I was pointed to this thread.

However, starting to read this thread, I've got some grave misgivings whether its information is still up-to-date. It starts off by talking about Visual Studio 2008, and we are half-way through the year 2018 by now. Also, the source code described seems to be version-2, even referring in parts to the original Chris Jones code from 2011. And as far as I understand, even the current version 3.4.1 is on the brink of being heavily revised behind-the-scenes.

So, beginning with a machine that doesn't have anything installed over and above Notepad++, how do I get to a development system with all the necessary sources and libraries where I can press a button and half an hour later, a shiny compiled AGS drops out?

since Characters are efficiently objects that can move between rooms.

This is slightly off-topic here, but I've always wondered: If objects essentially are dumbed-down characters that are inefficiently implemented, why does the AGS compiler use objects at all? Characters could be used throughout, and the language wouldn't need to be modified in any way for this: Whenever the programm would ask for an “object”, a malloc for a Character could be compiled behind-the-scenes instead: “So, here's a pointer to your ‘object', use that”. Whenever the program wants to move the “object”, generate a call to Character.Move instead of a call to Object.Move. All the inefficient Object methods thus would simply be ignored. Then the next step would be to drop all the Object methods from the libraries, retaining only the Character methods.

[show]

C: Limit the amount of objects you can pick up per visit to room.

If you do just that, players will briefly leave the room, come back immediately and continue picking up. So I think we're talking of some kind of knapsack limit to make that work.

The text adventures of olden times frequently featured a knapsack with limited capacity, IIRC. Those games had the advantage, however, of not having to show the DROP action. Players could simply empty their inventory at any place, and the subsequent room description would simply say: “You are in the throne room. … On the floor, there now is: a half-eaten apple, a shovel, …”

In a P&C adventure, OTOH, life isn't that easy. For once, if room X features the objects A, B, and C, then the objects will only be known in room X. Thus, when Ego walks to room Y, it's hard to show the object A lying on the floor. At the very least, the dropping functionality is a big hassle in P&C games.

This is relevant when limiting the number or weight of pickups per room. What is supposed to happen when the player chooses the wrong things to pick up whilst still staying within their limit? Perhaps even leaving the room with the wrong items? There must be some way to let them change their mind and drop what they have wrongly picked up. Tell them “You picked up that ballpoint pen back then back there in the throne room. Trudge back to the throne room if you want to get rid of it now”? I don't think that would make many players happy.

IMHO, that is the main reason that knapsack limits have fallen out of fashion. It's easier to code “I don't see any reason to lug that around right now. Maybe later.”, or variants thereof, and prevent players to pick up the “wrong” items upfront.

[need]

Here's an aspect that doesn't meet the eye at first glance:

A lot of walkthrough writers like to present the solution as a minimal sequence of steps necessary to reach the finishing screen. So if you let players pick up anything they want, whether they need to at the moment or not, then the resulting walkthroughs will contain just that

• pick up THINGUMMY,
• activate BRASS BUTTON,
• pick up the now appearing YELLOW PILLOW,

etc., without any reasons for any of the steps.

Later on, reporters will “evaluate” the game. They'll do that by stupidly following some random walkthrough they found on the Internet -- because professional article writers are much too time-pressed to think about the riddles on their own.

• They'll pick up the THINGUMMY and press the BRASS BUTTON and pick up the appearing YELLOW PILLOW just as they are told,
• they won't see why those steps make sense in context,
• they'll complain that “some riddles were completely illogical”,

and that exactly's what will show up in the evaluation.

If, OTOH, players may only pick up something when they have a reason to do so, then they will have to LOOK AT things, TALK to NPCs etc. in order to acquire this reason. These steps aren't optional any longer, so any walkthrough must list them one by one. The reporters that blindly follow these walkthroughs will be forced to read or listen to what Ego has to say when examining the THINGUMMY and the BRASS BUTTON: “So the solution is hinted at here and here and here and here? Wow, seen in that light, the riddle is really fair.”

[tell]

Efficieny might be an issue here:

If a sprites file can have gigabytes, it will probably be comprised of thousands of separate, tiny little files. Currently, we don't notice the sprite generation because it is done piecemeal, file by file as they are imported one by one. This will change, however, when the sprite file is generated in bulk at compilation time. Thousands of tiny files will have to be opened on each compile. The time needed might be significant.

So we probably need to cache the generated sprites file. But even that is not so easy as it looks:
If the user doesn't tell AGS that some file is „imported“, then at compile time, the AGS compiler will have to peruse thousands of tiny little files in order to find out whether new ones have shown up or old ones have changed their content. So that might mean, hash file contents and store that somewhere, e.g., in a database. This might start to become messy.

[could]

I hate it when I have to use a keyboard in adventure games (for example for […] typing in passwords)

I suppose one could code a game where passwords and savegame names have to be entered in Morse.

[might]

I swear some people played through The Fowl Fleet without right clicking on anything (even though it tells you how to do it), and then complained that the puzzles didn't make sense.

It just might be that bad walkthroughs explain the phenomenon:

Let's pretend you're a busy reviewer and that you need to play through a looong Point & Click. You'd probably need to expend lots of energy and brain juice to solve all those riddles. But the deadline is near, and, well, there's that internet so conveniently at hand, and, well, a walkthrough can be found.

Now here's the thing: A lot of (badly written) walkthroughs just list the clicks necessary for getting to the end screen:

“Pick up the YELLOW THINGUMMY behind the rose bush, then knock on the BRASS DOOR, when the POLICE OGRE answers, you get a DIALOG where you choose 3, 1, 2, 4, 5. The police ogre will hand you a BROKEN FLOOBY.”

Note that those walkthroughs DON'T usually tell you how you would deduce that knocking on the door was the right thing to do at that point in time. You might perhaps get that easily if you have EXAMINEd the door beforehand, but this examination isn't required to get you to the end screen, so the walkthrough doesn't record the right click on the door.

Also note that all the clicks you do for advancing the game (opening doors, responding in dialogs, picking things up) are usually left clicks; you need the right clicks for finding things out.

The effect is that the time-pressed reviewer is confronted with a riddle, can't be assed to think about the solution, consults the walkthrough, is given a list of left clicks with little or no context, exclaims “I'd NEVER have arrived at THAT solution” and complains that the riddles “don't make sense“.

[force]

That's why when I wrote "That Damn Dog" I added a timer and if the player does not right click after some time has passed I show a message box with "Did you know? You can right click on stuff". No idea if that worked, though.

What an interesting idea! I'll probably implement that.

I suppose one could force players to LOOK before INTERACTing, whether they want to or not -- by interpreting every first click on any interesting thing as a LOOK action and every subsequent click on it as INTERACT/TALK/PICKUP/COMBINE action. To make this work, you could introduce a property "EXAMINED" for characters, objects and hotspots. The on_mouse_click event would first read out this property and then set it to 1. Afterwards, it would trigger the LOOK event if the property had been 0 beforehand, or else the INTERACT event.

Thus you would only need the left button for both LOOK and INTERACT/TALK/PICKUP/COMBINE. So the right button could open/close the inventory GUI. That gui could contain the buttons for loading, saving, quitting, too.

Very minimal - I've thought about it several times. But I didn't follow through so far, because I feared that this might dumb down the game experience too much.

EDIT: Come to think of it, the two ideas could be fruitfully combined. Set a right-click timer at the start of the game. If it runs out and the game engine finds out that here's a player that won't use the LOOK action - well, it won't say a word about it and switch to forced look-before-interact mode silently for the rest of the game.

From a practical point of view, I don't mind at all using a verbcoin interface when it is provided, but I wouldn't currently it in my own projects. The reason is, a verbcoin makes the most sense when there are a lot of options: If you only offer LOOK and INTERACT, you could simply assign the one to the left mouse button and the other to the right mouse button and make away with the verbcoin.

But the trouble is, a lot of options means a lot of programming and wasted energy. It's the same as with lots of objects that can be picked up: You waste huge amounts of time coding what happens when the player uses an apple core on a passport, an apple core on a kitchen faucet, an apple core on a jar of fresh milk and an apple core on the door leading to the atomic power plant.

In the same way, having "push" and "pull" options means coding how you "push" an apple core, "pull" an apple core, "push" a rose bush, "pull" a rose bush, "push" a whiff of bad air, "pull" a whiff of bad air, and so on. Currently, I can't be assed to. But it's no dogma, I might change my mind when the right project idea comes along.

[find]

To return to the matter at hand:

The discussion started out when people (seemingly, _a lot_ of people) didn't even find the verbcoin: The act of holding down the mouse button was so counter-intuitive to them that it wasn't something they would even try out.

That's a matter of custom. If you construct a car where you have pull up the gas pedal in order to brake, this is going to lead to trouble. People just won't be expecting that - no matter how “logical” or “functional” it might be. You might document it in the user manual - but many drivers don't take the time to read user manuals before they turn the key.

The thing that makes this particularly diffcult is that several ”customs” have come up by now. For instance, when you switch from Windows to, say, Gnome, you end up tearing your hair because a lot of clicks and keystrokes that have become second nature to you just don't work the way you expect them to.

By now, operating systems have prescribed certain functionality with certain keystrokes or mouse clicks for decades. For instance, on a Windwos system, CTRL-C is prescribed to be "cut", CTRL-P is prescribed to be "print", a right-click is prescribed to call up a context menu and ALT is prescribed to call up the top-down menu. This has always made life hard for people that code software for several different operating systems such as Inkscape - or Emacs. (Emacs is a powerful public-domain text editor. In Emacs, CTRL-C is a sort of lead-in character combination and this is constantly very jarring to a Windows user.)

This is highly relevant here: We have clashes of tradition. Old gamers will expect mouse clicks to work “just as they do with LucasArts” or “just as in BASS” etc., but thes games predate the prescriptions that have come up with modern operating systems. Very new newcomers might have grown up with touch devices so much that they aren't even comfortable with a right mouse button. They will expect games to behave "the iPhone way" or "the Android way", where others will (still) expect "the Windows way".

How do we get the most people abord? How do we avoid alienating our target group? The answer will depend on that target group, so slim chances for an one-fits-all solution.

[more]

verb coins are significantly different from context menus (they typically take up far more screen space, for example, and usually cover up the thing you clicked on).

Have a look at the screenshot below. It's straight from Windows Word, I simply highlighted some words and right-clicked on them. It's obvious that it does take up a large chunk of screen space and that it does partially cover the thing you click on. It's just that we have become so used to these effects in years of Windows usage that we've stopped wondering about them. Since it is easy to make a context menu go away, we don't seem to mind the covered space.



Here's a verb coin of Netherworld, the game that started this discussion. I think that the covering aspect is comparable.



I might be wrong, but to me it seems that context menus have become even more prevalent lately than they used to be. For instance, call up a browser such as the Internet Explorer or Edge.  The standard way of "opening in another tab", "Save destination" and so on is the context menu.  There used to be top-down menus etc., too, but those seem to have fallen out of fashion.

I'm honoured! Let's call it a tie and let Hobo et al. decide on the theme of next month.

[As a quick workaround, can you get the inventory to pop up by hitting the "i" key?]

I can't continue the game, there is some kind of bug where the inventory icon simply disappears after reading the letter.

I'm having trouble reproducing the error, but you probably mean that the inventory closes and the "hamburger" menu (red button with white horizontal lines) doesn't pop up in its stead. You're right that this is a bug.

As a quick workaround, can you get the inventory to pop up by hitting the "i" key?


Edit: I think I have found a way to reproduce the bug: When Linkattus has the ransom letter,

• open the menu by clicking the "hamburger" button (thus, the inventory is open and the "hamburger" button is invisible);
• right-click on the ransom letter;
• whilst having the mouse over the inventory, hit the "i" key (thus, the inventory GUI closes)
• close the ransom letter by hitting the "X"

Result: The "hamburger" button AND the menu GUI is gone. This is a bug.

The following workaround should restore the interface to normal: Hit either "i" or TAB on the keyboard, this should open the inventory; close the inventory with the topmost red button of the inventory. Now you should be able to continue playing normally.

You should be able to toggle the inventory open/closed with the "i" key at any time (until you reach the end screens after leaving the kitchen).

Or change the verbcoin interaction:

Seen from a Windows perspective, a verbcoin is a context menu:  If you right-click into, say, Windows Word, you'd expect a menu to pop up with relevant options for interacting with the thing you clicked on. You'd expect to select a choice from that menu by fast-left-clicking it, or to close the context window by moving the mouse off it.

So the “Windows” way of a verbcoin would be: A (fast) right-click opens the verb coin, which stays visible until the player either left-clicks on an option or moves the mouse off the verb-coin.

If this is the handling that a Windows user ”expects”, then long-left-clicking instead of right-clicking and dragging the mouse to the option instead of fast-left-clicking the option is quite counter-intuitive.

People don't even understand a two-click interface any more.

Time for a no-click interface? After a pre-set time out, the pointer moves automatically to the correct spot, changes into the correct modes and triggers the correct option. Rinse and repeat!

If it's a stack in the classic sense, then you "push" something on top, and you "pop" something from the top. That means, at any point of time, the elements a[0], a[1] ... a[mx] for some mx are valid, the elements a[mx+1], a[mx+2] ... are invalid (free). So you don't need to keep track of "valid" for each element, but you manage an int mx as the fill level. It increments at each push and decrements at each pop.

The game uses a Verbcoin interface and I find it hard to believe that an adventure game reviewer couldn't figure that out.

On the other hand, it seems far-fetched that someone goes to the trouble of reviewing games, probably with a sense of conscientiousness and for the sake of quality control, who is then superficious and bad-minded about it.

So the more probable root problem must be that times have changed over the last decade and verbcoins have been buried in oblivion. Contemporary players simply don't expect anything other than fast-clicks for interface any longer, so they click around and “get nowhere” and don't know what to do.

But you're the owner of your page in the games repository. As a simple first remedy, you could add an explanation (something along the lines of “NOTE: Interact with hotspots by clicking AND HOLDING, and a menu with action options will pop up”).

Since attention is a scarce resource nowadays, such an explanation must be very conspicious and near the start in order not to be overlooked.

A better solution would be to prefix the game with an explanatory screen - if you can still find the sources.

However, that would mean recompiling the sources, which might become cumbersome on its own. It might mean having to  first install AGS 2.72, then load and save the game in that version, then switch over to AGS 3.4.1 and load/compile it there.

But the advantage would be that it would improve the game automatically, too: Current AGS provides superior installation options for windows mode. If you play the game as it is, the window is quite, quite, quite tiny. Contemporary AGS has zoom modes that are much better suited for large monitors.

Just my 2 pence