Touhou captcha

[Chiiruno]

Win against a (short) boss and you get to post if you are marked for captcha. I don't really expect this to ever be implemented, since it's difficult, but it ought to be. One benefit is that no bot on Earth will be able to post on meguca after it gets marked. Also bots that use TOR won't be able to post once I get around to #746

[Chiiruno]

Ah, a downside would be that noscript wouldn't work, unless you default to the character captcha for noscript.

[bakape]

Do it and put it behind a server configuration.

On Mon, 9 Jul 2018, 21:05 チルノ, notifications@github.com wrote:

Ah, a downside would be that noscript wouldn't work, unless you default to the character captcha for noscript.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/778#issuecomment-403568823, or mute the thread https://github.com/notifications/unsubscribe-auth/AHfPsOBWm36Dfgj8yCSaowMTLriNNJZNks5uE5tWgaJpZM4VIJYA .

[Chiiruno]

Ideas:

• Interchangable characters behind client options
• Ability to mute sound behind client options
• Use Meister from EOSD for (at least the initial) captcha spell card
• Not have the card be too hard, use one of Mokou's cards, easy/normal version of Kaguya's or Eirin's last spells in IN, toned down version of resurrection butterfly

[Chiiruno]

This will require duplicating the player position, health, and boss position, health in the server to avoid fake wins. Perhaps have the server send the boss position/health to the client?

[bakape]

What you do to prevent client exploits is check all the data submitted by the client for validity. With danmaku you would likely need to replay the game on the server to validate. If the game mechanics are deterministic, you could have the server replay all of the player's moves and assert they won. Something like this:

1) Player gets random seed and captcha ID from server. 2) Player plays the game. Timing of every keystroke is logged. a) Seed deterministically changes some parameters of the game. 3) After winning player sends the ID, keystroke log and seed to server. 4) Server replays the game (i.e., submits all the move timings to the engine) and asserts player won. 5) Player can now shitpost.

Why am discussing game anti-cheat practices on meguca?

P.S.: This should be a library and/or separate captcha authentication server so we can spread this madness for all to hate. I can help with the server side once you have the engine somewhat playable.

[bakape]

Configurable boss health and game speed is a must for adoption.

[Chiiruno]

Yeah, I'll make this into a Go library with a typescript/js frontend. All that sounds about right, this'll be interesting whenever it gets done.

[Chiiruno]

Ah, mainly for easy compatibility with meguca, I don't feel like making bindings.

[bakape]

Don't be too hasty on language choice. Since you will need the engine implemented on both the client server, you will either need to implement them twice or use a language that supports both... and Go WASM support landed recently. Hmm. I'd honestly write the engine in C++, but Go could work. I don't know how stable it is and the Go JS bundle size will be huge.

[Chiiruno]

Yeah, I know. In reality I'm going to write it in Rust, because fuck C++. I guess it'll be a good project for learning Rust anyway, I got the basics down some time ago, but still. I hate making bindings.

[Chiiruno]

Now that I think about it, I could do mainly WASM for the client part too, since it won't be manipulating the DOM very much.

[bakape]

Entirely in Rust or just the engine?

[Chiiruno]

Might as well do it entirely, write some bindings to Go for the server portion, maybe I can find a generator for the bindings. Rust and WASM go along well, so why not.

[bakape]

Writing the non-engine client parts in Rust is pointless and extra complexity, since you would just be drawing to the canvas (or WebGL2).

[Chiiruno]

Okay, I can just do the non-engine in Typescript then. Thanks for the heads-up.

[bakape]

And there won't be much in terms of bindings, I think. Just need to input the keystrokes and optionally output a bitmap each frame interval.

[bakape]

Tell me once you have the repo. I can help with the engine too.

[Chiiruno]

Yeah, probably a 512x1024 bitmap where each bit is either empty, player, boss, or danmaku. Could probably only use the top half for the boss if we keep it to certain spell cards, and have two maps instead, top one being somewhat smaller memory footprint.

Okay, thanks, I'll get to this probably after my PRs are merged and a few more issues are fixed.

[Chiiruno]

Might need to differentiate between danmaku and player attack, maybe I can use one of the other variables somehow.

[Chiiruno]

Oh, if I did the two map thing, I could have both the player and the boss use the same value, probably call it control or something.

[bakape]

Let each point in the 2D array contain multiple an array of entities.

[Chiiruno]

No need, since we can tell if a danmaku hits the control by current vector, and if the next tick it hits the control, apply damage and erase the danmaku. May be different in practice, I want to keep the memory footprint as small and efficient as possible.

[bakape]

Let each point in the 2D array contain an array of entities. Place boss, player, player projectile and boss projectile in an enum. The array stores instances of these. For a strat you can have only one type for each of these, but can later make the enum contain trait pointers for different projectile types.

[Chiiruno]

Alright, that will work I think.

[bakape]

Make the repo, so I can track progress and help.

[Chiiruno]

Alright, give me a moment.

[Chiiruno]

https://github.com/Chiiruno/touhou-captcha

[bakape]

Add me as a collaborator.

[bakape]

You don't an organization for that. Just Click the repos settings,

[Chiiruno]

Uh, I thought I had to make an organization for some reason, feel free to deny the organization invite. Sent a collaborator invite.

[Chiiruno]

Since we're sending almost everything but user input to the client, I'll start with the server library. Easier to work with a 2D array anyway. For the client... I'll have to look to see if there aren't any good WASM game engine libs. Although, if they're too heavy, I might just roll my own.

[bakape]

The game engine has to have a headless sped up replay mode. I doubt many have that.

On 8 September 2018 at 23:07, チルノ notifications@github.com wrote:

Since we're sending almost everything but user input to the client, I'll start with the server library. Easier to work with a 2D array anyway. For the client... I'll have to look to see if there aren't any good WASM game engine libs. Although, if they're too heavy, I might just roll my own.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/778#issuecomment-419669519, or mute the thread https://github.com/notifications/unsubscribe-auth/AHfPsFSOTdHV4e6EG-zZ4F71oeMR8f93ks5uZCNqgaJpZM4VIJYA .

[Chiiruno]

So probably roll my own, then. Well, that's fine. Touhou is fairly simple anyway. Since it's 2D in nature and vertical scrolling, I can use palettes I think.

[Chiiruno]

No, for a while now it's been 3D. I'll have to emulate the levels a bit closer.

[Chiiruno]

The game engine has to have a headless sped up replay mode. I doubt many have that.

Wait, do we need that for a simple touhou captcha? Wouldn't that be server-only? Could you elaborate?

[bakape]

If you go 3D, you will have to write WebGL. 2D can be done on a canvas.

[Chiiruno]

I have some limited experience with building 3D engines, so that shouldn't be a problem. I guess the question is this: Does the background being 3D matter so much in this case?

[bakape]

Basically, all player input has to be serializable and then you need something that can determine, if that input actually wins the game. My idea is do that by feeding input into a headless engine.

[bakape]

Does the background being 3D matter so much in this case Does 3D matter

Not at all. Just make it some static image.

[Chiiruno]

Well, I would have both the client and server use a 2D array, and just put that into an array every X frames, which would be sent to the server for verification. Probably have pin point accuracy (more frames) for damage, lose, and win conditions. That way we could just replay on the server in an instant and verify. Maybe we could even skip a lot of the frames and only focus around those for optimization.

Not at all. Just make it some static image.

Alright, that simplifies things.

[bakape]

Why send the 2D array? Just send the seed and all user inputs. The 2D array is deterministic with that information known and is not required for headless play.

[Chiiruno]

Oh, duh. Good point. Okay, that simplifies that. We would have the server send the seed probably, so just have the client send the user inputs and the seed back for identification. Okay, this will work.

[Chiiruno]

Since that is the case, I can probably share the engine part for both the client and server.

[bakape]

Please reread the thread. I said that a few hours ago.

On 8 September 2018 at 23:39, チルノ notifications@github.com wrote:

Since that is the case, I can probably share the engine part for both the client and server.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/778#issuecomment-419671363, or mute the thread https://github.com/notifications/unsubscribe-auth/AHfPsKl1hINUjas-MTO8vpBOXOKieguVks5uZCsYgaJpZM4VIJYA .

[Chiiruno]

Okay.

[bakape]

@Chiiruno This still alive?

[Chiiruno]

It seems kind of redundant now that you made your own, so at least as far as meguca is concerned, no, for now.

[MagmaDivide]

ARE U FUCKING STUPID ANIME KIDS? JUST MAKE A SIMPLE TEXT CAPTCHA

[RMiko]

You sound upset. Is everything alright, little guy?

[Chiiruno]