지속적인 브라우저 기반 게임 : 보안 문자 또는 보안 문자?


12

나는 꽤 오래된 학교 인 pbbg에서 일하고 있습니다. Carnage Blender를 사용해 본 적이 있다면 아이디어를 얻을 수 있습니다.

그렇지 않은 경우에는 많은 아이디어를 얻는 것이 좋습니다. 플레이어는 매일 특정 수의 "포인트"를 할당 받고 해당 포인트를 사용하여 다른 플레이어를 공격합니다. 포인트는 시간이 지남에 따라 특정 한도까지 누적됩니다.

포인트 시스템은 과잉 성취자가 캐주얼 플레이어를 완전히 앞지르지 않도록 설계되었습니다.

캐리지 블렌더의 경우, CAPTACHA 시스템은 사용자가 최소한의 노력으로 매일 모든 포인트를 사용하도록 설계된 봇 또는 스크립트로 시스템을 "게임"하는 것을 방지합니다. 가끔씩 임의의 보안 문자가 표시되며, 통과하지 않으면 사용자는 한 시간 동안 일시 중지됩니다.

내가 궁금한 점은 내 게임에서 더 사용자 친화적으로 만드는 방법입니다. 나는 이와 같은 나쁜 행동을 막아야한다는 것을 알고 있으며, 동일한 보안 문자 접근 방식을 쉽게 취할 수 있지만 더 사용자 친화적 인 대안이 있습니까?

초기 연구에서 Microsoft가 ASIRRA를 발견했지만 솜털 / 귀여운 분위기가 의도 한 게임 테마와 잘 맞지 않습니다.

업데이트
가장 관심있는 것은 표준 "이 단어 철자"보안 문자에 대한 대안입니다. 나는 좋은 선수들을 위해 가능한 한 방해받지 않고 게임 플레이를 유지하려고합니다.

내가 부르는 것을 본 적이 한 시간을 사용하여 사용자 요구와 같은 보안 문자를 "오 플러스 여섯 마이너스이 무엇을?" 그러나 이것은 악의적 인 사용자를 박살낼 수있는 충분한 양의 질문 데이터베이스를 컴파일하는 데 너무 많은 노력이 필요합니다. 특히 보안 문자는 자주 사용되기 때문입니다.

업데이트 # 2
Joe Wreschnig가 그의 답변에서 지적한 것처럼, 하루에 턴이 제한되면 봇 이 인간보다 게임을 더 빨리 플레이하지 못하도록 봇차 시스템을 갖추는 것은 약간 중복됩니다. 나는 나의 포인트 시스템을 편지로 설명하지 않았으며 그것은 내 잘못이었다. 실제로 10 분 또는 20 포인트가 몇 분마다 발생하고 200 점을 상회합니다. 따라서 경쟁이 치열한 플레이어는 몇 시간마다 돌아와서 포인트를 사용할 수 있습니다. 나는 내 게임을 좋아하는 사람들이 너무 자주 돌아 오도록 보상하고 싶습니다. 그들이 다음 날까지 점수를 얻지 못하도록 막는다면 웹 게임을 즐기는 선수들을 물리치게 될 것입니다. 이를 통해 플레이어는 지속적으로 포인트를 사용하지 않으면 서도 몇 분마다 포인트를 계속받습니다.

이것은 남용 될 수 있습니다.


1
다시 업데이트 # 2 : 포인트 시스템의 설명 된 목표는 다음과 같이 단순화되었습니다. "평균 하루에 최소 2.4 회 플레이하는 플레이어에게 보상하고 싶습니다." 왜? 그들이 하루에 한 번이 아닌 하루에 2.4 번을 돌보는 이유가 무엇입니까? 당신은 "내 게임을 좋아하는 선수들에게 보상하고 싶다"고 말하지만, 하루에 5 번 또는 단 한번만 로그인하든, 그것은 내가 당신의 게임을 얼마나 좋아하는지에 대한 척도가 아닙니다. 실제로 여기서하고있는 일과 하고 있는지 생각해보십시오 . 그런 다음 다른 방법을 찾아서 하루에 2.4 번 포인트 시스템을 만들지 않아도됩니다.
doppelgreener

1
최적의 플레이 위해 하루에 2.4 번 방문해야함으로써 많은 사람들이 그 약속을 할 수 없기 때문에 봇팅을 장려하고 있다는 사실을 정말로 깨닫기 바랍니다 . 그것은 심지어 필요하지 않습니다 : 당신은 그것으로 아무것도 달성하지 못하고 잠재적 인 플레이어의 봇과 소외! 하루 40 회 (물건으로 조절할 수 있음)를 줄 수있는 경이로운 게임 인 Kingdom of Loathing을 고려하십시오. 200의 모자를 사용하면 한 번에 최대 5 일을 기다릴 수 있습니다. 카오스 왕국은 비슷한 일을합니다. 빈번한 플레이에 대해서는 특별한 보상을 제공하지는 않지만 하루에 여러 번 로그인하는 플레이어가 있습니다.
doppelgreener

@Jonathan : 일반적으로 사람들이 평균적으로 하루에 x 번 로그인하면 관심있는 이유는 광고 속도에 따라 게임의 수익성을 높이기 위해서입니다. KoL의 수익 창출 전략은 게임 내 구매이므로 적용되지 않습니다.

1
@Joe : 그런 다음 다른 광고 / 수익 화 전략을 고려할 것입니다. 플레이어를 소외시키지 않으면 플레이어 수가 많아서 전체적으로 더 많은 광고를 표시 할 수 있다는 점을 염두에두고 싶습니다 . 내 게임이 성공적으로 설계된 경우, 사람이 그 것이다 하루에 여러 번 방문 어쨌든 할 것이다 - 때문에 게임을 좋아하고 게임 역학 투명 그렇게으로 그들을 압박하는 때문이에 선택 (참고 :이 방법 스티븐입니다 "나의 게임을 너무 좋아하는 사람들" , "내 압력 메카니즘이 작동 하는 사람들"에게 보답하지 않을 것 )
doppelgreener

답변:


8

"보다 사용자 친화적 인 대안이 있습니까?"

최종 사용자를위한보다 사용자 친화적 인 대안? 시스템에서 달성하도록 설계된 보안 문자 란 무엇입니까?

봇이 일반 플레이어보다 "빠르게"재생할 수 있다는 전제하에 봇이 봇을 방지하도록 설계된 것처럼 들립니다. 그러나 이미 사용자가 하루에 수행 할 수있는 작업 수를 제한하여 동일한 목표를 달성했습니다. 따라서 보안 문자는 중복 된 것으로 보입니다.

Loathing 의 대체 프론트 엔드 를 살펴 보시기 바랍니다 . 이 시스템은 비슷한 일일 턴제 시스템을 사용 하며 KoLmafia와 같이 널리 사용되는 대체 프론트 엔드가 여러 가지 있는데 , 이는 여러 가지면에서 게임 "보팅"과 구별 할 수 없습니다. 대부분의 플레이어는 캐주얼 플레이어라도 게임에서 빼앗기지 않고 추가한다고 생각합니다. 배치 작업을보다 쉽게하고, 느린 부분을 자동화하고, 게임 내 UI를위한 더 많은 옵션을 제공합니다.

AI가 단순히 인간보다 더 빨리 플레이 할 수 없는지 확인하기 위해 게임에 체크를하고 있다면 매일 체크 해야합니다. 디자인이 마치 게임을 자동화 하는 것을 권장 합니다. 균형을 잡으면 플레이어 경험 만 향상시킬 수 있습니다.


1
아주 좋은 통찰력! 하루에 한 번은 오해의 소지가 있으며 그것은 내 잘못이었습니다. 정교하게 질문을 업데이트하겠습니다.
Stephen

이것에 대해 더 많이 생각할수록 더 좋아합니다. 좀 더 생각하고 여기에 약간의 질문을하도록하겠습니다.
Stephen

1
예를 들어 KolMafia의 자동 전투 시스템은 실제로 전투 매크로 시스템을 실제 게임에 통합하기에 매우 유용했습니다.
coderanger

나는 RuneScape에서 Genie가 묻는 간단한 질문이 있다는 것을 기억합니다.
Jonathan Connell

3

나는 보안 문자를 요구하는 게임을 귀찮게하지 않을 것입니다 : 그들은 피해야 할 끔찍한 연습입니다.

어쨌든 게임은 어리석은 로봇보다 유리한 문제가있는 것 같습니다. 이상적으로는 어리석은 로봇에게는 이점이 없어야하기 때문에 어리석은 로봇을 처음 사용하는 것은 무의미합니다. 이를 달성 할 수없는 경우 실제 솔루션이없고 다소 유효한 해결 방법 만있는 디자인 문제입니다.

"멍청한 봇"이란 의미있는 결정을하지 않고 단지 "농장"(여기서 일어나는 일)을하는 봇을 의미합니다. 스마트 봇 (목표 로봇 또는 체스 게임 봇)은 완전히 다른 문제입니다.

그럼에도 불구하고, 디자인 결함 게임을 만드는 아이디어에 익숙하다고 가정하면 여전히 개선의 여지가 있습니다.

실제로 결정된 봇을 멈출 수 없으며 대신 봇을 사용하는 것이 쓸모 없게 만드는 유일한 일에 집중하십시오. 사람들이 봇을 사용할 이유가 없다면 ... 봇을 사용하지 않을 것입니다 (어쨌든 그들은 중요하지 않습니다).

가능한 해결책은 하루에 한 번이 아니라 매주 한 번의 로그인을 허용하는 것입니다. 사람들이 일주일 이상 로그인하는 것을 잊어 버린다면 어쨌든 게임에 관심이 없을 것이므로 봇을 사용하여 크레딧을 계속 얻지 못할 것입니다. 반면에 일주일에 한 번 기록한 다음 3 개월 후에 임의의 사람들을 공격하기 위해 돌아 오는 봇을 만드는 누군가가 망친다면, 당신은 어쨌든 당신을 깨뜨릴 것이라고 결정한 사람을 찾았습니다. 당신이 선택한 시스템 (물론 결함이없는 시스템을 선택하지 않았다면).

추신 : 해결 디자인 결함에 더 많은 노력을 기울이고 실제로 처음부터 해결하는 실수를하지 마십시오!


1
"이상적으로 멍청한 봇에게는 게임이 유리하지 않아야합니다."좋은 조언 +1
Stephen

좋은 조언이지만 인류가 달성 할 수 없는가?
Kzqai 2016 년

완전히 달성 가능하면 임의의 코드를 코딩하는 대신 실제 게임 디자인을 수행하면됩니다. 품질 비용.
o0 '.

2

나는 한 시간 동안 실패한 CAPTACHA를 금지하지 않을 것입니다. 가혹한 것처럼 보입니다. CAPTACHA를 성공적으로 완료하고 새로운 CAPTACHA 이미지가 표시 될 때까지 계속 진행하지 못하게합니다.

요청을 너무 빨리 보내는 경우에만 보안 문자를 표시하고 모든 요청에 ​​DateTime을 저장 한 다음 다음 요청과 비교합니다 .2-4 초 미만이면 CAPTACHA를 표시합니다. 그들은 간다. 게임, 서버 및 대역폭에 적합한 간격을 결정해야합니다.

작업을 수행 할 때마다 X 번씩 "강제"CAPTACHA를 수행 할 수 있습니다. 이렇게하면 자동화 된 스크립트도 pause내장되어있어 시간 제한 CAPTACHA를 트리거하지 않습니다.


권리. 이것들은 모두 보안 문자를 보다 사용자 친화적으로 만들기위한 유효한 아이디어 이며, 물론 보안 문자 경로를 방문하면 이와 같은 개념을 구현할 것입니다. 내가 찾고있는 것은 좋은 대안입니다.
Stephen

봇이 응용 프로그램을 원격 제어하기가 더 어려워 지도록 Flash 또는 Silverlight로 게임을 작성 하시겠습니까?
Nate

잘 모르겠지만 KingsOfChaos.com은 시스템이 어떻게 구현되는지 확인할 수있는 시스템 (매 순간마다 포인트 / 턴)과 매우 유사한 시스템을 가지고 있습니다.
Nate

2

플레이어가 다른 플레이어를 공격하기 위해 포인트를 소비하고 포인트가 제한되면 명백한 남용이 여러 계정을 만드는 것 같습니다.

사람들을 단일 계정으로 제한하는 데 성공하면 봇과 관련된 문제는 시스템에서 사람들이 잠들거나 직장에서 해고 할 수 있다는 것입니다.

따라서 제약 조건이 주어지면 (1) 봇에게는 이점이 없습니다. (2) 하루에 여러 번 로그인하면 사람들에게 보상합니다.

가장 이상적인 것은 하루 동안 사용할 수있는 행동 수를 합리적인 수로 제한하는 것입니다.

예를 들어, 누군가가 8 시간 동안 여러 번 합리적으로 로그인하고 시스템을 적절히 조정할 수 있다고 결정할 수 있습니다. 또는 누군가가 아침에 학교 나 직장에 가기 전에 확인하고, 집에 도착했을 때 확인하고, 저녁 식사 후에 다시 확인하고, 자기 전에 확인하십시오.

'이상적인'사용자의 행동을 파악한 다음 포인트 시스템으로 보상하십시오.


한 번에 많은 포인트를 사용하여 보상하는 시스템을 만들었습니다. 이렇게하려면 포인트에 가변 충전 속도가 있습니다. 포인트를 소비 할 때마다 다음 포인트를 얻는 데 걸리는 재충전 시간이 증가합니다. 따라서 봇이 포인트를 얻는 것만 큼 빨리 포인트를 소비하는 경우 다음 포인트를 얻는 데 시간이 더 오래 걸리지 만 사람이 모두 소비하면 아침에 집을 떠나기 전에 하룻밤 동안 축적 한 지점은 직장 / 학교에서 집으로 돌아갈 때까지 (8-12 시간 후) 다시 가져옵니다.


사용법에 따라 가변 충전율에 대해 생각한 적이 없습니다. 언뜻보기에 천재적인 소리. 나는 그것에 대해 생각해야 할 것이다. TBH, 그것은 캐주얼 플레이어에게 보상하고 하드 코어 / 다이 하드 플레이어를 처벌하므로 나는 몰라요.
Stephen

2

게임에서는 "captcha"를 "puzzle mini-game"으로 바꾸는 것이 좋습니다. 차이점은 관련된 재미의 수준입니다. 커스텀 미니 게임을 시도하지 않았고 여전히 봇팅되지 않는 한 게임에서 보안 문자를 사용할 이유가 거의 없습니다. 어떤 경우에는보다 지능적인 전술이 필요합니다.


1

Tchalvak에서 제안한 것처럼 '퍼즐 미니 게임'경로를 사용하지만 더 사용자 친화적으로 만들기 위해 몇 가지 포인트를 전달합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.