Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

mouse click/hover area or position as input

A topic by puppetmaster created Apr 06, 2016 Views: 784 Replies: 12
Viewing posts 1 to 3
Submitted

Hello

I would ask if mouse click/hover area or mouse position as input are allowed?

thx

puppetmaster

I can't speak with authority (since only Daniel can), but I'd say mouse position as input is completely within the rules and spirit of the jam, but the mouse cursor isn't. After all, if you can see the mouse cursor, you've got a display of the position of an object in the game, so to be 100% compliant it'd have to be hidden.

(+2)

I don't see how the mouse cursor is a form of feedback. The game doesn't affect the the mouse cursor in any way, so it's not output from the game. And if just being able to see what your input is is feedback, does that mean I can't use keyboard keys as I can see if the key is pressed down or not by looking at it? The mouse cursor isn't a part of the game.

I still kinda think it is, though. Moreso than seeing a key being pressed down. After all, it's on the screen, made of several pixels, overlapping the single-color screen. It (probably) directly represents an object in the game, which although the display of it isn't a part of the games code still is a form of very clear visual feedback.

(+2)

All of those points are true, but you aren't getting that precise feedback from the game, you are getting that feedback from your computer. And seeing the mouse doesn't even give you precise feedback about the game. Sure you know exactly what you are inputting, but you don't know what that's doing. You don't know that moving your mouse is moving an in-game character around at a 1:1 ratio. You don't know if clicking is doing something in that particular part of the screen. Sure you can infer that info from what the pixel is doing and what the manual told you about the game, but the player inferring what's going on from their limited knowledge is exactly what this jam is all about.

I think you are confusing feedback as a whole and feedback from the game. The feeling of a key being pressed down is a form of feedback telling the player they pressed a key. Seeing the mouse cursor move around the screen is a form of feedback telling the player where they are moving the mouse. Seeing the one pixel turn on or off is a form of feedback telling the player what is happening in the game. The first is feedback from your real life keyboard, the second is feedback from your computer's operating system, the third is feedback from the game. If you start disallowing forms of feedback that aren't from the game then where do you draw the line? What if my game uses the current size of the game window as input, requiring them to resize the window to beat it. Do I need to somehow make them not able to see the window's current size?

Most likely the mouse position will directly correspond to an in-game location, though.

This view you're speaking about kind of opens up weird venues, though. If I write a program separate from the game, and I have it read the game's memory and draw dots over the game window where objects are, would that then be okay since it's not technically part of the game?

I think the mouse pointer deliberation is also affected by the fact that it is on the exact same output device as your bit. Not only that, but also often in a way where it's indistinguishable from the case where your bit area would actually have explicitly and directly output the pointer graphic.

(+1)

No, I think that that separate program would be cheating as it's taking information from the game, violating the "1 bit of output" rule. However if you made a program that read the bit and converted it from morse code to text that wouldn't violate the rule.

Really the point I'm trying to argue here is that the mouse is not a source of output. What the mouse does affects the game, but what the game does has no bearing on the mouse. Information is only travelling one way: into the game. You keep saying the mouse will correspond to a game location, but I don't see how that matters. The game isn't telling you it treated the mouse position as an in-game location, you only know that because you know how the game works.This doesn't violate any rules of output because this info isn't coming from inside the game.

No, the mouse isn't, but I'd still say the visible mouse pointer + corresponding to an overlapping in-game position is.

Submitted

My interpretation are:

  • mouse click [OK]
  • mouse hover [OK]
  • game move/freeze/block mouse [NOT OK]
  • mouse change look [NOT OK]

Daniel Linssen should please confirm

Mouse position with the mouse pointer visible over the screen influencing the bit counts into "look" for you, right? I'd say it's less about the factors you mentioned, and more about whether the visible mouse pointer represents an object in the game.

Submitted

No, mouse should only act as input device for game and should always have the same look.
Only when mouse change look it would influencing the bit counts.

  • click at specified position = screen flash
  • hover at specified position = screen flash

Idea:
find target (hover) and shoot at target (click)

Submitted

So I need to find a solution to hide my finger :-) (touchscreen)

Your finger is the input, though! That's a clever way to let the user be the feedback. The finger is more like the mouse than the mouse pointer. Cool!