Messages

I ended up doing a dirty hack for the time being, but I hope to sit down and adapt it properly at some point.

Code: ags

function checkGUI() {
  if (GUI.GetAtScreenXY(mouse.x, mouse.y)) {
    hoverOver = GUI.GetAtScreenXY(mouse.x, mouse.y);
      if ((hoverOver == gExplorer)) {
        DragDrop.AutoTrackHookKey = true;
      }
      else if ((hoverOver == gDetails)) {
        DragDrop.AutoTrackHookKey = true;
      }
      else if ((hoverOver == gResume)) {
        DragDrop.AutoTrackHookKey = true;
      }
      else if ((hoverOver == gConfirmation)) {
       DragDrop.AutoTrackHookKey = true;
      }
      else if ((hoverOver == gDropdown)) {
       DragDrop.AutoTrackHookKey = false;
      }
      else if ((hoverOver == gMainMenu)) {
       DragDrop.AutoTrackHookKey = false;
      }
  }
  else {
    hoverOver = null;
    DragDrop.AutoTrackHookKey = false;
  }
}

Hacky, but it works for now.

This is an amazing module, but I'm absolutely confused by the examples and the reference. Please do not take my following comments as hostile or critical - I have nothing but praise for what you're doing. What's confusing for me is this: the module does a fabulous job when the automation is turned on...but I'm having a very hard time grasping how to do the behavior without automation.

In a nutshell, what I'm trying to do is make draggable GUIs to create a fake desktop. However, I only want to target a specific handful of game GUIs, not all of them. If I have DragDrop.AutoTrackHookKey set to true in my script, every game GUI is draggable in the way that I expect...except, this works with every GUI in the game, not just some of them.

I've tried to follow the examples and use a little scripting to get it to work, but I'm stuck. Here's what I've managed to do so far:

Global Script:

Code: ags

function dragWindow(GUI* Window) { // This is wrong
  if (DragDrop.HookKeyDown()){
    DragDrop.HookObject(1, mouse.x, mouse.y, Window.ID);
  }
  else if (DragDrop.HookKeyUp())
    DragDrop.Drop();{
  }
}


function checkGUI() // running under repeatedly_execute_always{
  if (GUI.GetAtScreenXY(mouse.x, mouse.y)) {
    hoverOver = GUI.GetAtScreenXY(mouse.x, mouse.y);
      if ((hoverOver == gConfirmation)) {
        dragWindow(hoverOver);
      }
  }
  else {
    hoverOver = null;
  }
}



function game_start()
{
  Mouse.Mode = eModePointer;
  DragDrop.Enabled = true;
  DragDropCommon.ModeEnabled[eDragDropGUI] = true;
  DragDropCommon.DragMove = eDDCmnMoveSelf;
  DragDrop.AutoTrackHookKey = false;
  DragDrop.DefaultHookKey = 0;
  DragDrop.DefaultHookMouseButton = eMouseLeft;
  DragDrop.DragMinDistance = 10;
  DragDrop.DragMinTime = 0;
}

I've tried a few different variations for my dragGUI function. If I include the DragDrop.Drop() call, dragging doesn't work at all. If I omit it, the window instead just sticks to my cursor the minute I hover over it.
I've tried going over your code examples and post a couple of times, but I'm feeling pretty lost. What's the proper order of operations for hooking a GUI, dragging it, and dropping it?


I guess what's also confusing involves figuring out how to register when the player is holding down the mouse button and dragging the mouse. Is HookKeyDown supposed to be called from within on_mouse_click / on_key_press and nowhere else?

How do you save player input as a variable?

In a nutshell, you first need to have a GUI with a TextBox in it.
Once you have that in the GUI, you'll need to click into the Events pane (the lightning bolt) to generate an _OnActivate event handler for that GUI element.
So, assuming your TextBox element is named TalkBox...

Code: ags

 if (IsKeyPressed(eKeyReturn)) { // Only submit text after player hits "Enter"
   String sentence = TalkBox.Text; // Save it as a local variable of the String type
   Parser.ParseText(sentence); // Parse the entire sentence
  }
}

That's a pretty basic starting point for text parsing - obviously, that doesn't do very much on its own, but you can use some of the documentation I pointed to earlier to extend it.

AGS does in fact have support for a Dictionary object. Maybe you could start by creating two: one for known words, and another for words to be learned? Maybe you could also somehow define a large list of synonyms for your known words?

It should also be possible to split up phrases word by word using something like Substring. Here's also some documentation for the Text Parser and some related functions.

Maybe you could do something like this:

1. Take player input from a text parser interface and save it as a variable.
2. Split up the sentence word by word, and check if any of them are in the Known Words dictionary, checking against known synonyms for each word.
3. Add Unknown Words not found in the dictionary to a Learned Words dictionary.

I'm not really sure how to progress beyond that point - AI Chatbots have progressed a lot in the past 20 years or so thanks to advancements in Sentiment Analysis and language models like GPT-3, but I think AGS is pretty limited in terms of what can be done here. You might be able to get away with creating a Markov Chain-style chatbot, which builds a table of seen responses to existing words and tries to create new responses to your prompts accordingly.

You could also borrow some ideas from AI Dungeon, which is open source and offers a seemingly comprehensive manual on how its GPT-2 based system works for generating realistic responses.

Oops! Sorry I didn't catch that. I'll definitely check this out for some of my projects!

Uhm, guys, you´re suppose to fill in the shape and not the outside as well.

According to the first post, part of the stated rules were:

Fill out the shape with your own idea and interpretation of the shape.
You may rotate the shape, you may color the outline and either the inside or the outside of the shape.

I get where you're coming from, but I also don't see a problem with radically reinterpreting the visual form, so long as the original shape can still somehow be seen within it

This is an amazing idea for a plugin! Quick question: is this plugin currently only available for Windows builds of AGS games, or will it also work with MacOS / Linux runtimes?

It's not the worst thing in the world if it's Windows-only at the moment, because Wine/Proton are pretty good for AGS games, but it'd be nice to support this kind of thing natively!

Aw, dad, did you have to get me an evil skull fortress again this year? 

[imgzoom]https://i.imgur.com/4GuhzUi.png[/imgzoom]

This is just my 2 cents, but...given that you want to have multiple things moving around in the background, would it maybe make sense to use characters instead of objects?

So, it's interesting that you bring this up! There are a couple of different ways to approach the construction of a dungeon - one fairly novel approach I've seen recently was that of a "virtual maze" variety, where a singular room had a bunch of hidden objects (walls, doors) that disappeared or reappeared based on where the player was on a virtual map - in other words, the room kept track of where the player was with some variables, and then used a Random Number Generator to decide when a monster should appear.

Note that this approach is largely for roguelikes. It's totally possible to construct a dungeon with different rooms, which might be useful if you're looking to create a much more controlled experience for the player.

There's a great breakdown of what SpaceQuestHistorian did for his joke game here: https://youtu.be/ANJQOPPcZKM?t=305

Thought about this for a few minutes. I don't know if it's possible to invoke speech playback without an actual say command.

Here's a really hacky idea, though: could you pipe the WrittenText to a secondary Say command that's referenced off-screen? It's a really dirty idea, but it might work.

So like...

Code: ags

    function TopBar60(this Character*, Int LineNum, String WrittenText)
    {
      Game.NormalFont = eFontSpeech;
      DisplayTopBar(60, this.SpeechColor, 16, this.Name, WrittenText);
      this.SayAt(999, 999, 0, "&%n %s", LineNum, WrittenText);
      Game.NormalFont = eFontNormal;
    }

It's hacky and gross, and probably slightly incorrect (been a while since I hacked around with this stuff), but with some tweaking it might be possible to get something out of it?

So, what I ended up doing is that I put each game into its own Git repository, for version control purposes. This ensures that I can easy download the last working version of my game and its source code if a major catastrophe happens with my computer.
Basically, I just use git functions from the command line, and create commits in a local directory before pushing them up to a remote branch.

In other words, I do this:

0. Save my work in the editor and close it.

1. Add any changes from my game's directory that might have been changed

Code: ags

git add .

2. Create a commit detailing what I did

Code: ags

git commit -m 'Add new scene in bar'

3. Push that code to a repo

Code: ags

git push origin master

For assets: one thing that I'm doing right now is that I keep all assets in a subdirectory of my game's working directory, meaning the assets go with the source code. This may or may not be preferable, and probably balloons up your repository's size - but, keeping your assets in git means that you can also keep track of the revisions as time goes on. One alternative I'm interested in trying is moving all of those assets into one big git repo of their own, keeping it all separate from source code. Then, when I'm working on a game, I can reference the shared asset directory for all of my games, in case I want to re-use some assets somewhere else.

Animated buttons would definitely work, if you plan on having limited amounts of dialog options for conversations. You could probably set it up so that whenever a conversation starts, some integer variable is set to capture the dialog ID number, and then you could use that value in your GUI logic. That way, when you click a button, the game knows to run a numbered dialog option in the active conversation.

[SO]

Having said that, I've recently been making some long overdue progress on a project, and it feels SO good!

Nice! I hear you there - I've recently caught a second wind in development by focusing on small parts that excite me. I built a method for traveling around the game that feels goofy and fun, and it's kind of motivating me to develop entirely new areas and stick them together. There's still not a whole lot for players to actually do, but connecting isolated scenes together feels like progress.

Did Covid really bring that many new people in?

I can't really point to any specific figures, but I will say, anecdotally of course, that there's greater demand from people buying gaming hardware...and one could guess by extension, games as well. There's also a bit of a silicon shortage, though, due to the pandemic.

I will say that I've been playing way more adventure games than ever before!

So! First off, I want to say that these look really great. Figuring out dithering is kind of hard, and not always obvious when starting out with pixel art. I personally tend to use it very sparingly.

For the first screenshot: You could actually benefit from more dithering in your general backgrounds. You have a great use of form and color, but the scene feels like it lacks texture.

For the second picture: this is a really good cutscene shot! It's almost perfect, but it feels like perhaps the shadows have dithering overkill, in addition to being too high in contrast. It might be worth reducing the opacity of those shadows so that they blend in more, and possibly not use dithering on the shadows directly. Something that I do in my pixel editor is that shadows are solid black at about 50% opacity, and the elements underneath the shadow (floorboards, brick, whatever) is what actually has dithering.

Third picture: overall, good, but there's too much dithering. The bit in the sky is a little bit unnecessary; the dithering in the clothing might need to be lower-contrast than, say, dithering in rocks. My opinion: you might benefit at showing different levels of dithering in different textures, to represent visually that they are made of different things. Rougher surfaces might need more dithering, smoother / soft surfaces might need less.

Fourth picture: this is just about perfect, but I think the jacket could actually do with more than three shades of brown. It's tricky to find that right balance and avoid the look of "pillow shading", but a tiny bit of pillow shading is actually useful in cloth textures, especially when representing wrinkles and folds.

Hopefully that helps! Best of luck with your project, it's already looking great!

I'm seriously considering doing characters in 3d in Blender, then using an art program to pixelate it.  Not sure yet.  The thing about Blender is you animate the character once, then just move the camera for different views.  I've done some modeling so that's not that big of a problem.

Honestly, this is a pretty neat workflow that I myself have considered. I believe Blender has a way to render animation frames at a low resolution? You might be able to render a very plain "basic" model to convey movement, and then paint over those frames in a pixel editor to make it look like regular pixel art. In a way, it's like rotoscoping, but using 3D models instead.

The question is, why wouldn't you do that? You're supposed to keep Windows up-to-date, like any other app or OS.
Just turn on automatic updates.

This. Unless one is working with a pay-per-megabit internet connection, I never understood why some people avoid software updates.

Part of the problem is laziness, but a larger part of the issue is...compatibility breaks. For example, in the macOS world, it's not entirely uncommon for entire applications to break because core APIs have seemingly suddenly changed. despite the effort of app developers to track changes from one beta release of an OS to the next.

Just jumping in here! I use Aseprite on Linux and absolutely love it. I use mine both for making sprites as well as background, and the tool has a built-in workflow for producing animations using onion-skinning.

It's got a great interface, and is really nifty for its support of layer groups and animation frames. The technique I've been developing involves painting layer upon layer upon layer, until the initial blobs I created look like shaded, clothed people.

Seriously, I can't recommend it enough. It's great with a Wacom tablet.

Hey, welcome to the community!

The advice about starting a basic test game is really good. Experiment with making a guy walk around, picking up an object, putting stuff in his inventory, and adding a score. In fact, these things are building blocks that can teach you how to make a basic puzzle, which is kind of a big part of developing adventure games!

I also really must recommend the AGS Manual. It's so, so, so helpful. I constantly look stuff up when I'm coding and trying to figure out ways to do something. As you get more used to the engine, you'll want to eventually explore deeper levels of customizing how the game engine works - you can make it do all sorts of crazy stuff with how a game handles clicks, and how the game interface is put together. The manual is extensive, and covers just about anything you'd want to know.

I'd also recommend asking plenty of questions, either here or on the AGS Discord (the technical support channel in particular has helped me a lot). If you have any background with programming, that will help you understand the more complex parts of the engine, but I originally started with AGS having almost no experience at all. One thing that really helped me in the beginning, too: play AGS games! There's so many to choose from, and they can show you all kinds of wonderful ideas about what's possible.

My biggest piece of advice is to not get discouraged, to not take your projects TOO seriously, and to have fun! This community is all about encouraging each other and finding advice and inspiration as we all try to make games.

Wow, this looks great! I love the visual style, and the interface design looks awesome. Seems like a fun premise.