> > > > > we’re putting s— >>> >>>> >>>>> — >>>>> >>>>> welcome to the time storm >>>>> >>>>> long ago traffick boss met a time storm surfer and tried to enslave >>>>> them. he had a giant business empire and thought he could enslave anybody. >>>>> >>>>> usually timestorms are small, localized events— >>>>> >>>> >>>> hey, that was a good one! >>>> >>>> — >>>> >>>> defeating the user at tictactoe >>>> >>>> still confuddled by my last chatgpt conversation regarding checkers and >>>> tictactoe, i tried playing tonight, and i am slightly remembering that it >>>> is indeed a draw game if O makes just the right moves. >>>> >>>> so to jump to the awesome chase, if we want to always win we’ll have to >>>> deceive or influence the user somehow — without violating the rules of the >>>> game — such that they make poor moves at crux moments and lose. ( >>>> >>> >>> in this manner, the game engine could play perhaps like an upset child >>> that refuses to lose in some manner or another. >>> >>> an initial idea, to find a quick and simple approach, might be to try to >>> make the board jump around such that playing certain win moves is not >>> reasonably possible within human reflexes, but have — >>> >>> what makes it fun is that it(‘s like having your devices hacked by >>> abuseware :D :D >>> >>> so we could make a tictactoe game that abuses the stupid player, never >>> letting them win :D :D maybe at the end it can hug them and be like “sorry >>> i abused you it’s all i understand” or something >>> >>>> maybe it could apologize every time it messes with the game, showing >> text on the aide that acknowledges abuse and expresses apology or >> condolences or tries to engage in restorative dialog somehow or something >> >> so! maybe a simple approach could be to measure the response time of the >> user making moves, and try to move the board suddenly such that if they >> press a winning move, they press a losing one instead. ((have experienced >> this a lot, but has a psychological component helping for me)) >> > > what kind of simple formulas and workarounds might be useful here? > > - distribution of player response times > we could stddev it and use if it’s tight. > > how about this: if the player has a tight std deviation of response times, > such that the likely width is below response times, then it jumps the board > to make them tap the wrong square > > but if they don’t have a tight response distribution, maybe it crashes the > game to get them more tense and reliable ((have experienced this a lot too)) >
(actually crashes seem used more to stimulate behavior change, in-app events might be better for building reliability. one approach is to make it easy to win for a bit, which is of interest ((because)) but breaks the goal of always winning, another approach could be to jump the board around harmlessly or something as a side game … but crashing could be a start. unsure what would be best to put there. see, another approach could be to fail to register an initial selection, but this seems like violating the game rules. ((similarly, much stronger when engaging rest of device )… interesting to think on some :s > both of these events are shocking and could build nascent dissociative > amnesia in a player if dialog and staging were kept up gaslighting the > causality and/or existence of the events . it could apologize for that too! > “sorry for abusing you here. sorry if you get DID. very sorry.” > how to abuse tictactoe player to always win. insight into human influence. users act with habits (that may change in response to things >
