Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Hi Tobi, thanks for your feedback! :)

I'll add some Menu screen re-works to my list "Things to Fix" for the next build.

I'm currently working on building a monitor/screen selector workflow, so it shouldn't be too long before I have a solution nutted out.  I ideally want the user to be able to drag the avatar across all of their monitors, but at the very least I plan I letting the user choose which monitor to load the avatars into.

I'm not quite sure what you mean by "The click through/mouse transparency is also good, but it happens also when the settings menu is open and then it is just annoying."  If you can give me a little more info I'll see what I can do.

Thanks again.  Your feedback is most welcome :)

The whole application is mouse transparent, allowing to click on the windows behind it, good for the avatar, but bad for the settings, they also become transparent to the cursor when the window loses focus, either by a popup window, a notification or just by clicking outside of it. Then it is not possible to interact with the setting untill the tab in the application bar is clicked. Same for the hover menu, that should show up when moving the mouse to the bottom right corner. That feature only works when the window is focused. It's not intuitive. 

Ah yep now I understand what you mean, thanks for being so thorough :)

You are correct, the menus/buttons, etc are only clickable while the Desktop Buddy application is the active "window", so it will become passive/unclickable when you click on anything else, and then will only become clickable again when you activate it by clicking on it in the Taskbar or by alt-tabbing to it.

I'm working on a solution for this issue, as yes it is, as you said, not intuitive as it currently stands.  I'm just trying to find the right balance of maintaining interactivity with the Decker avatar while still allowing the user to go about their business and not be hindered or encumbered by Decker being on the desktop.  I accepted the current approach for now, as it gives the user full control of when Decker is intractable and when he isn't, as he is designed to be a background application first and foremost.  Being in view, but not "in the way" as much as possible.  You can see the dilemma here.

Thanks again for your feedback :)