This template uses a left-click interact right-click examine interface, similar to the interfaces used in BASS and Daedalic's games.
It comes with a number of features like:
- non-blocking walks (courtesy of Khris' GotThere module (http://www.adventuregamestudio.co.uk/forums/index.php?topic=36383.msg477380))
- exit cursors + double-clicking to teleport to exits (courtesy of Khris' double-click code (http://www.adventuregamestudio.co.uk/forums/index.php?topic=31759.msg408289))
- show-all-hotspots GUI
- inventory window that slides in and out (opens and closes without the need for any clicking)
- navigation map
- the full set of menus with more customisation options
- saves which include date/time and screenshot
Made for AGS 3.2.1, compatibility with other versions unknown
Changelog:
v1.1
- Expanded menu options (e.g. more volume and speed controls)
- Inventory is now properly translucent (32-bit)
- Panel GUI colours now easily customisable with dynamic sprites
v1.2
- GoThere module now makes sure player character faces the right way after walking
- GoThere functions better explained in dialogue tutorial
- Saves now include date/time and screenshot
v1.2.1
v1.3 14-07-2013
- Fixed major bug that gets rid of inventory window completely when Esc is pressed with it open
- General code optimisations and improvement of save function
v1.3.1 07-10-2013
- Fixed bug where game crashes in the absence of readme.txt
- Speaking cursor is now used when mouse hovers over characters
v1.4 19-10-2013
- Added alternative function to manually specify the direction that player character should face after reaching the walk-to point
The current limitation of the non-blocking walks / GoThere module is that the walk-to points have to be set in walkable areas, meaning that walk-to points have to be manually specified for objects and characters. If anyone can figure out a simple and reliable way to find the xy co-ords in a walkable area closest to any given co-ord (i.e. where the PC will stop after being told to walk to a point in an unwalkable area), we might be able to simply use the x and y properties of the object/character and mouse.x and y for hotspots whenever the walk-to points/properties are undefined, making things easier for developers as they would only have to define the points in special cases.
(http://rpgmaker.net/media/content/users/33416/locker/xalarcostscreenie.png)
Demo graphics courtesy of Reality-on-the-Norm
Download template here (demo game included) (http://rpgmaker.net/users/lemonheaded/locker/XALARCOST.agt)
Cool! :)
You should add "BASS" in the thread title, to optimize later researches.
Nice! It's always cool to see somebody actually use your stuff.
Maybe you should add a small demo game or a youtube video showing it in action though; people are suckers for stuff like that (I certainly am).
Monsieur OUXX: Done (:
Khris: Thanks for your code, it's really useful! The non-blocking walk module in particular is a godsend. I'm too lazy to do a youtube video, but the template includes a demo game and a basic tutorial through dialogue.
This is actually a really nice template. I can see it becoming quite popular - It should probably be bundled with AGS after some more testing if no bugs are found.
Good work.
Phemar: Thanks, glad you like it!
Looking forward to trying this out! :)
Nice work!
Could the double click be used as a general double click? -Like trigging interactions for example, not just for quick exits. Or would that cause conflicts and hiccups?
frenzykitty: Hope you like it!
StillInThe90s: Yes, it's possible. Note that the double-click code is only run when the cursor is the warp cursor (hovering on an exit), so take a look at the code under "if (mouse.Mode == eModeWarp) {" in the "function on_mouse_click(MouseButton button)" block and use it as a model for your general double-click code.
2 ways:
1) Execute single-clicks immediately (like to start a non-blocking walk) and let double-clicks override the first click without explicitly cancelling anything.
This is what happens in the template currently, so you don't have to do anything special.
2) Do not execute single-clicks until the maximum time interval between clicks (for it to count as a double-click) has run out, upon which the code for either single or double clicks will be run, which will result in a small delay for single-clicks.
This was what the original code (http://www.adventuregamestudio.co.uk/forums/index.php?topic=31759.msg408289) did, please take a look. More specific instructions below, but remember to take out the "if (mouse.Mode == eModeWarp) {" check.
Search the code for "// no return, will lead to ProcessClick later". At that place, insert a "return;" statement. The code for single-clicks will be called under repeatedly_execute instead of on_mouse_click.
Search the code for "__arrived = true; // makes sure player". Replace that line with a "single_click(false);" statement.
Search the code for "//single_click(true);" and uncomment out that line.
Add this function to the script:
function single_click(bool single) {
if (single) {
// single-click code
ProcessClick(mouse.x, mouse.y, mouse.Mode );
}
else {
// double-click code
Display("Double-click detected!");
}
}
Thanks lemonhead.
My own double click function works similar to your method 1, but is blocking 'SkipUntilCharacterStops' when mouse is over hotspots and objects.
I'm going to have a go at method 2 and see what to make of it.
I just wanted to ask your opinion, do you think this template is worth (useful and well-scripted) to be added to AGS Editor distribution for the future versions?
Also, sorry for not being able to check this thoroughly myself, - are all of the modules/features included are actually used by the template logic? I am asking, because Ghost included Tween module in the previous version of his "BASS Stub" template, which was not directly used anywhere in template scripts.
Crimson Wizard:
I think this template would be useful for those interested in implementing the features mentioned above. I wrote it because as a player I prefer it when adventure games have such features, and I wanted to make it easier for developers to include them.
Yes, the modules are actually used in the template logic. The GUIColours script is in use by default to make it easier for people to change the look of the buttons and sliders by using dynamic sprites, but it can easily be taken out for those who would prefer to import static images.
I tried the template, and want to mention few things.
1. When hovering the mouse over character, the icon displayed is "Interact". Maybe change it to "Speak" icon (unless this is a strict design rule)?
2. Perhaps the inventory "tab" could be made little larger? Since the inventory itself is rather wide, player might need to first move mouse to the very top-left corner of the screen, then move it back to select item in the rightmost part.
3. If there's no "Readme.txt" in the game folder, the game crashes with "null pointer" error:
File*output = File.Open("Readme.txt", eFileRead); // reads the file under the Compiled folder
String readmetxt = "";
String temp;
while (!output.EOF) { // make sure there's a "Readme.txt" in the Compiled folder
Thing is that if there's no file opened, the "output" pointer remains 'null'.
I also noticed that there are numerous commented out parts of the code. Are these left on purpose (so that developer could uncomment them to get an optional functionality), or this is an old version of the code that don't work anymore?
Crimson Wizard:
1. Done.
2. That's true, but I didn't want the tab to block too much of the screen. How wide do you think it should be in relation to the width of the whole inventory panel? Or would it be better to make the inventory tab hotspot wider without actually changing the size of the tab, so that it looks the same while responding to mouse hovers at the top part of the screen underneath the pull-down inventory panel?
3. Fixed.
Most of the commented-out code is left in to give developers more alternatives e.g. allowing them to use an imported sprite instead of a dynamically-drawn sprite as a hotspot marker. I've just gone through the code to remove the lines that are truly obsolete.
Just saw this:
QuoteGoThere module now makes sure character faces the right way after walking
Is there a bug in the module?
Khris:
Not in the original version of your module (: For the version implemented in this template, I took out the direction parameter of the walk-to point so that developers can have one less thing to specify, leaving it to be automatically calculated. I've also just added an option to manually override the direction when necessary.
I see, thanks for clarifying :)
Hiya.
I hate to necro this, but I was wondering if someone could help me out with this template. :(
This is perfect for what I need (that Wadjet-style UX) and could save me a lot of time.
I'm running it on AGS 3.5.0 and everything seems to work fine, except the dialogues are broken.
Specifically, I cannot seem to click any dialogue options in the demo game. Can someone help me out with this? :-\
Here is the bit of the Global script that deals with dialogue options rendering:
function dialog_options_get_dimensions(DialogOptionsRenderingInfo*info) {
info.Width = 320;
int i = 1, o = 0;
while (i <= info.DialogToRender.OptionCount) { // i is the total number of possible options
if (info.DialogToRender.GetOptionState(i) == eOptionOn) {
o++; // o counts number of options available right now
}
i++;
}
info.Height = (10*o); // assumes standard height of text? makes sure the window is only as tall as it needs to be
info.X = 0;
info.Y = (200-info.Height);
// Put the text parser at the bottom (if enabled)
info.ParserTextBoxX = 10;
info.ParserTextBoxY = 160;
info.ParserTextBoxWidth = 180;
}
function dialog_options_render(DialogOptionsRenderingInfo*info) {
// Clear the area black
info.Surface.Clear(0);
int i = 1, o = 1, ypos = 0;
String text;
// Render all the options that are enabled
while (i <= info.DialogToRender.OptionCount) {
if (info.DialogToRender.GetOptionState(i) == eOptionOn) {
if (info.ActiveOptionID == i) info.Surface.DrawingColor = 10; // green for hover
else if (i == info.DialogToRender.OptionCount) info.Surface.DrawingColor = 63488; // red for last option to quit dialog
else if (info.DialogToRender.HasOptionBeenChosen(i) == 1) info.Surface.DrawingColor = 27; // grey for option that has been chosen before
else info.Surface.DrawingColor = 15; // white for default text colour of option
text = String.Format("%d. ", o); // puts number before option so that players can select it with keypad instead of mouse click. this number is not the actual number of the option, but merely its position in the available options list
text = text.Append(info.DialogToRender.GetOptionText(i));
info.Surface.DrawStringWrapped(5, ypos, info.Width - 10, eFontNormal, eAlignLeft, text);
//ypos += GetTextHeight(info.DialogToRender.GetOptionText(i), eFontNormal, info.Width - 10);
ypos += 10; // assumes text height is 10
o += 1;
}
i++;
}
}
function dialog_options_get_active(DialogOptionsRenderingInfo*info) {
int i = 1, ypos = 0;
// Find the option that corresponds to where the player clicked
while (i <= info.DialogToRender.OptionCount) {
if (info.DialogToRender.GetOptionState(i) == eOptionOn) {
//ypos += GetTextHeight(info.DialogToRender.GetOptionText(i), eFontNormal, info.Width - 10);
ypos += 10;
if ((mouse.y - info.Y) < ypos) {
info.ActiveOptionID = i;
return;
}
}
i++;
}
}
function dialog_options_mouse_click(DialogOptionsRenderingInfo*info, MouseButton button) {
// do something here if you want!
}
Thanks in advance!
Quote from: biverix on Tue 11/04/2023 19:47:30I'm running it on AGS 3.5.0 and everything seems to work fine, except the dialogues are broken.
Hello. The dialog API had changed since AGS 3.4.0 (which probably was after this template release), you need to either update the script to the new rules, or enable Backwards compatible mode called "Use old-style custom dialog options API".
More information may be found in the manual:
https://adventuregamestudio.github.io/ags-manual/CustomDialogOptions.html
check out where it sais "COMPATIBILITY NOTE"
Thanks a lot! Must have missed that; turning backwards compatibility on seems to have worked just fine. I might just eventually get around to recoding that whole bit to work with the new-style dialogue API.