[Request] Mouse Support

[elwood...@gmail.com]

Stephen Plzzzzzzzzzzz.
I know it's been mentioned and talked about.
I know this project is like... only used by a select few frequently.
But it would add some fun stuff.

Don't get me wrong, I have a lot of features I would love to see, but this is like, definitely the biggest game changer.

I dunno if you need donations or if there's someway to sway you, but it would be so cooooooool.

Okay, enough ranting and troubling. Have a good day!

P.S. Plzzzzzzzz

[Stephen Lavelle]

What do you mean by mouse support? 

--
You received this message because you are subscribed to the Google Groups "PuzzleScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elwood...@gmail.com]

Heh, my apologies, I wasn't specific. It's just that I'm very hyped because I'm working on a VERY large-scale PuzzleScript game, the likes of which no one has even come close to yet. I'm hoping it will even all work out and run properly, but I digress...

I meant Mouse Commands for reading mouse inpu. So, basically, here are some mockup ideas:

Prelude options:
enable_mouse
(Would enable mouse input, possibly off by default)
disable_keys
(Would disable the standard keyboard inputs. This probably isn't necessary, but just a thought.)

How Mouse Works:

Objects are created at the mouse's X and Y tiles and update their location each tick.

These objects that are created exist on their own layers. Either above all existing layers or below them, I'm not certain it matters which.

(MX,MouseX,Mouse_X,MSX,CX,CursorX, etc.. Whatever naming convention you want*)
*Would be even better if you could rename or define it yourself like object grouping or the way the Player object is handled. I'm going to use MX & MY for brevity's sake.

Referenced as such.
[MX]
[MY]
(Not Sure if this should only be created on the exact tile the mouse_x, and mouse_y are on, or if an instance of [MX] should be created on each row in a single column where the mouse_x is. That way you can reference the exact mouse position with [MX MY] and use the current mouse column refferenced with just[MX]. For the simplest implementation, just having [MX MY] to reference the cursor location would be excellent. The column and row referencing is just wishful thinking and could be done with Vertical[Seer|...|MX], so probably irrevelant.)

EDIT:
[I'm going to leave the above jumble to show my thought process, but after saying it all, it occurred to me, you don't necessarily need two objects, one for mouse_x and mouse_y. You could just use one Mouse object that happens to be at the location of where mouse_x and mouse_y would be. This is definitely a cleaner solution and I believe offers exactly the same amount of functionality!]

[MCL]or[MLC]*
MouseClickLeft
[MCR]or[MRC]*
MouseClickRight
*Again, whatever preference with naming conventions.
These objects are created at [Mouse] whenever the corresponding click is made.

Just the left mouse click is really plenty. Having the right click as well is just wishful thinking. Plus, if you're only using one click you could stick with your existing conventions and just have a MouseAction or ActionMouse created at the location just like Action.

I think this is as simple and elegant of a solution to a mouse implementation as I could come up with, but I'm by no means a super good programmer or I'd try to add it myself. I wouldn't even know where to begin, honestly. I'm good at puzzlescript, not big-bad programming languages.

Thanks for taking the time to read all of this!

[elwood...@gmail.com]

Realizing what a headache that last post is here is a clearer design explanation for anyone who doesn't want to read that mess.

Mouse Input Suggest

Possible Preludes:
enable_mouse
(Enables the mouse input feature. Possibly off by default.)
disable_keys
(Disables default keyboard input. Just a suggested prelude option, not necessary.)

Mouse Implementation:
A [Mouse] object is created at the tile that contains the co-ordinates of the mouse's current position. This object is updated each tick to move and to check it's state. If the left mouse button is clicked [MouseAction(or ActionMouse)] is created at the [Mouse] location.*

*Possible to have MouseClick instead of MouseAction, which allows for MouseLeftClick and MouseRightClick, or possibly MLC and MRC. Whatever naming conventions you see fit.

[Hand-E-Food]

If this were to be implemented, I'd suggest:

1. Require the enable_mouse option so this compatible with older games that might already have a Mouse object.
2. Each turn, remove all existing Mouse objects and create a Mouse object under the cursor.
3. If the mouse button is clicked since the last turn, make it an action Mouse, just as pressing X makes an action Player.
4. Do not give movement (up, left, ...) to the Mouse object.  Let the script manage this with something like [Player|...|Mouse] -> [> Player|...|Mouse].  The mouse can move in inconsistent ways that make cardinal directions meaningless.
5. Turns are triggered no faster than key_repeat_rate or perhaps mouse_repeat_rate.  But does this mean that enable_mouse essentially infers realtime_interval?  enable_mouse and mouse_repeat_rate could be combined into a single option given they're required together.

[Stephen Lavelle]

Having thought about it (i've thought about it before, of course, but I try to read mails quickly), I'm not into this. It stretches the console specs too far (but the notion of having mousex and mousey "coordinate" objects is super cute).

Mouse games benefit a lot from mouseover things (some of which you could do I guess with what you have), and you might still want to allow drag/drop/click+drag, for instance. these things mightn't work so well on touch-screen either.  I feel also that it's generally not a great starting point for making games - I can't think of many game ideas that'd productively use it.

but, you know, it's all open source, so you can knock yourself out if you please and implement it in your own branch - I'd be interested to see what you made with it if you did!

best,

S

[elwood...@gmail.com]

@Hand-e-food

There's no need for messing with the movement, the mouse is on its own layer. It shouldn't be affect by anything like that.

Also, no need for real time mandatory. You only need to enable real_time on games you want to move some object's position with the mouse position. Such as having a visible mouse cursor or something. Othetwise, clicking would spawn an action which would trigger a game tick causing mouse position to update. Mouse position must always update at the start of game tick before any rules are checked/applied.

[elwood...@gmail.com]

@Stephen, I figured it would come down to that. Personally I can think of lots and lots of games that benefit from mouse input, specifically anything where the has been as sort of menu interface. Lots of existing games use the, move cursor and x to select mechanic. These are tedious is many games and unnecessarily time consuming. Having a mouse also makes bigger ventures in this sort of mechanic possible as well as just new sorts of games, like various puzzlers, point and click adventure, and fun tools applications.

But alas, I understand. I don't possess the knowledge to edit the source but maybe some other brave soul will see this and attempt.

[Stephen Lavelle]

". Lots of existing games use the, move cursor and x to select mechanic."

Lots? Name 3 :P

"Having a mouse also makes bigger ventures in this sort of mechanic possible as well as just new sorts of games, like various puzzlers, point and click adventure, and fun tools applications."

I kind of want to discourage people from making these games in puzzlescript, because it's not a good tool for them (even with mouse additions).  (When I started thinking of some mouse-based puzzlescript style thing, I ended up making http://www.flickgame.org ).

On Mon, Sep 11, 2017 at 7:45 AM, <elwood...@gmail.com> wrote:

@Stephen, I figured it would come down to that. Personally I can think of lots and lots of games that benefit from mouse input, specifically anything where the has been as sort of menu interface. Lots of existing games use the, move cursor and x to select mechanic. These are tedious is many games and unnecessarily time consuming. Having a mouse also makes bigger ventures in this sort of mechanic possible as well as just new sorts of games, like various puzzlers, point and click adventure, and fun tools applications.

But alas, I understand. I don't possess the knowledge to edit the source but maybe some other brave soul will see this and attempt.

[elwood...@gmail.com]

Like, this is just a quick scan of the featured games page but:
Symbolism
PrograMaze
Rose
JAM3 Game
Drop Swap

But there's definitely been other projects here and there that could have definitely used the feature.

I'm not trying to argue for it's use, you've stated your stance on it and expressed it's not the direction you wish to go. I just wanted to put it into the open and hopefully someone else with the vision will come along and do something with it. I just believes it opens a new door for many "panel" style games. Anything with a large array of panels you'd have to traverse and activate one or more of. Plus other small things here or there. I understand your saying Puzzlescript isn't intended for the creation of the games I mentioned before, but that doesn't stop it's charm and limitation from being big motivators and inspiration for developers like myself who enjoy not just the challenge of implementing these things, but the style of the language itself. I often view puzzlescript itself as the ultimate puzzle, thinking what it would take to piece together different styles of games within its confines. It's a very rich and rewarding puzzle experience that becomes deep and involved and you learn more and more each time you go back. Adding mouse input would just streamline some elements of that for different applications. It's the difference between old character name input screens and just typing the name on a keyboard.

Anyway, I've put out my thoughts and ideas about it. Thanks for your input and a view into your reasoning behind it, a lot more helpful than a flat no, or worse, no response at all! I think it's cool you still hang out in this group at all and chat with everyone and keep up with Puzzlescript game dev.

[elwood...@gmail.com]

Also, just a personal tick, but I can't say I'd ever do anything to "discourage people from creating" anything however they feel comfortable creating it. Creativity is the best thing we've got as humans, imo! :)

If you want to recreate the complete works of Aristotle gluing eyelashes to birchwood, GO FOR IT! Someone, somewhere will appreciate it and who knows what that might influence!

[Chris Pickel]

From the Puzzlescript Gallery, PrograMaze, Symbolism, and Bouncers all seem like they're in the category. Other non-Puzzlescript games like Lights Out or Rush Hour also fit.

I don't think it's a good idea to rush into mouse support without thinking about phones. “Under the cursor” isn't something that exists on touch devices. Good support for touch and drag might be a nice improvement, though: the virtual joystick that exists today works but I don't think it's great.

Implementation-wise: the way things work today, Puzzlescript translates keyboard events on the page into action/up/down/left/right on the Player object. The analogous way to do cursor input would be to translate cursor events on a cell into motion on Cursor{Clickable,Draggable,Movable} objects.

Since there are already games that use the cursor pattern, I think it's nice but not essential. I could get more excited about it as a way of improving phone support, though.

To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "PuzzleScript" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript...@googlegroups.com.

[elwood...@gmail.com]

I don't see anything changing for phones necessary for what I described. "Hovering and following the cursor" aren't really necessary. All that is really needed is a simple check for when a click or press is made, and an update to the [Mouse] object's location and click status before the execution of rules.

That being said, under cursor stuff works fine on phones it just translates to drag or hold. The way text selection and copy pasting works on most devices. But I don't really see much of a need for that sort of feature with the implementation I mentioned.

But I do agree with you that mobile virtual controls can be finicky at best.

[Hand-E-Food]

I can definitely see the benefit in the games you suggested, but they make a good point that this will be difficult for phones.

You spoke of having a Mouse object for its current location and another object for if you click the mouse button.  Phones will only report a tap as a click, and there's not really any other way to report the mouse location.  So every tap interaction is a mouse click.  You can't have the mouse location otherwise.  That might be fine.  That might make things easier if all it reports are mouse clicks and not mouse movement.  But if you have both mouse and keyboard enabled, you now have a problem that all taps of a phone are ambiguous between action and mouse click.

If PuzzleScript reacted to mouse movement, how often would it execute a turn?  Every time the mouse moved 1 pixel?  Every time the mouse moved to a new cell?

If I'm multitasking, I often need to click inside the PuzzleScript game for it to have focus and receive keyboard input.  How do it distinguish a focus mouse click from a game interaction mouse click?

I'm not trying to block the idea.  Idea's always seem simple until you start drilling down.  We just need to work out the requirements such that it's compatible with desktop, mobile, and existing games.

And ultimately, use the right tool for the job.  I know I abuse PuzzleScript to its limits and I really should learn some other game development platforms.  It's only my laziness that stops me from venturing out into something more versatile.

[elwood...@gmail.com]

You're really making this much more complicated than it is.

The short and long of trying to do mouse and keyboard on mobile is just silly. Normal phone applications dont even try to do this, why would puzzlescript.
You would just design your puzzle with mouse_enable and disable_keys as i mentioned in my earlier posts if you wanted it to extend to mobile and if you wanted control from both it would just be pc only.

Puzzlescript doesn't have to change the rate at which is executes turns at all, that stays the same. It isn't "reacting to mouse movement" it would only execute a new turn per click. Using the current location of the mouse during the click.

Having the exact passive location of the mouse, outside of clicks, is rather irrelevant for most things not to mention as you've pointed out, ridiculously intensive if you try to fire a tick everytime it moves even if only everytime it changes cells.

It wouldn't recognize the input click because it wouldn't have focus... When you give it focus, the click has already been made, it shouldn't have to register it twice.

[elwood...@gmail.com]

Also, while you're here Hand-E-Food, Flashpoint would LOVE a mouse cursor to simplify it's action selection. (Sorry for the multiple replies but there's no edit feature on these posts.) ):

[Skalmantas Šimėnas]

Honestly, I'd be completely fine with just having an Action on the tile clicked by the mouse and that's it, maybe with the option to throttle holding down the button.

I see a lot of potential in having any kind of mouse interaction because of how much less tedious having a cursor would be. Stephen said himself he's a fan of qrostar's games, which would be really tedious if controlled with an arrow-keys cursor like in Rose. Then there's the living example of Cosmic Express. The original puzzlescript version wasn't that tedious, you just chose where the tracks goes next since it's completely linear but it's so much nicer to be able to drag that track in a line and solve the whole level with one long nuanced mouse gesture. There are a lot of line-drawing puzzles that don't fit well into puzzlescript.

Yet, I don't feel excited about all this potential either. I only see puzzlescript as a really good prototyping engine and it's as limited as it should be. Having less of pain-in-the-butt to control the game definitely outweighs having a single time of some pain-in-the-butt to develop the simplest mouse interaction, yet, I don't know if I'd like to spend my time on implementing that and I respect anyone's decision not to implement it.

Speaking of that, puzzlescript engine's code is not a total huge mess and if you know how to make websites with javascript in them, you can totally understand the structure of it. In just a few minutes, I've found the function `onMouseDown()` in the source and it calls the `levelEditorClick()` and `levelEditorClick()` so there shouldn't be a big problem in extending that to modify the state of a running game, which is when `levelEditorOpened` is false. The main problem I have myself is that I have no idea how to get a local copy of puzzlescript to run on my machine and I have already tried to do that half a year ago without any progress in a whole hour and I don't really want to touch web development with javascript ever again because of how little time you actually spend solving problems and making code compared to how much you have to google your mose obscure problems.

Not really sure what a rant is but I've probably ranted just there but now it's over.

[Connorses]

Fwiw, I think Puzzlescript mouse input should be basic if it were implemented at all; I always saw Puzzlescript as a way to get inspiration by working within limitations. There are quite a few games where you put a cursor over a tile and press X to interact, which puts an 'action' flag on the player. My suggestion is that clicking a tile should make objects on the tile have the 'action' flag for that turn, since this doesn't stretch the existing rules too much. Requiring use_mouse in the prelude would make sure this doesn't break existing games.

[zaraw...@gmail.com]

This may be of interest to people on this thread:

https://groups.google.com/forum/#!topic/puzzlescript/FTqxzGcOD5Y