Skip to main content

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

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.