เนื้อหาด้านล่างนี้ครอบคลุมแนวคิดและกลยุทธ์ต่าง ๆ เพื่อปรับปรุงความปลอดภัยและลดการโกงในประสบการณ์ Roblox ของคุณ แนะนำอย่างยิ่งให้พัฒนาอ่านผ่านสิ่งเหล่านี้เพื่อให้แน่ใจว่าประสบการณ์ของคุณมีความปลอดภัยและยุติธรรมสำหรับผู้ใช้ทุกคน ตรวจสอบแถบด้านข้างเพื่อหัวข้อเรื่องความปลอดภัยเพิ่มเติม
การตัดสินใจเกี่ยวกับการออกแบบพื้นฐานสามารถทำหน้าที่เป็นมาตรการความปลอดภัยขั้น "แรก" เพื่อขัดขวางการใช้ประโยชน์ แนวคิดหลักคือการออกแบบระบบที่การโกงนั้นเป็นไปไม่ได้หรือไม่ให้ข้อได้เปรียบที่มีความหมาย แทนที่จะพยายามตรวจจับและป้องกันการโกงหลังจากที่เกิดเหตุการณ์นั้นแล้ว
ลองพิจารณาเกมยิงปืนที่ผู้เล่นได้รับคะแนนสำหรับการฆ่า ผู้ใช้ประโยชน์อาจสร้างบอทที่โทรเลขไปยังตำแหน่งเดียวกันเพื่อถูกฆ่าซ้ำแล้วซ้ำอีกเพื่อคะแนนที่ง่ายดาย สถานการณ์นี้แสดงให้เห็นถึงความแตกต่างระหว่างแนวทางเชิงตอบสนองและเชิงป้องกัน:
| แนวทาง | ผลลัพธ์ที่คาดเดาได้ |
|---|---|
| ไล่ตามบอทโดยการเขียนโค้ดที่พยายามตรวจจับพวกมัน (แนวทางเชิงตอบสนอง) | ผู้ใช้ประโยชน์ที่ต้องการคะแนนอย่างรวดเร็วจะหาวิธีหลีกเลี่ยงโค้ดการตรวจจับที่ซับซ้อนของคุณและใช้บอทของพวกเขาในทางที่ต่างออกไป |
| ลดหรือเอาคะแนนสำหรับการฆ่าในผู้เล่นที่เกิดใหม่ (แนวทางเชิงป้องกัน) | เวลาพิเศษและความยุ่งยากจะต้องใช้สำหรับผู้ใช้ประโยชน์เพราะพวกเขาไม่ได้คะแนนสำหรับการฆ่าบอทของพวกเขาในทันที นอกจากนี้ "ผู้ตั้งแคมป์น้ำSpawn" จะถูกขัดขวางเพราะพวกเขาไม่ได้คะแนนสำหรับการฆ่าผู้เล่นที่เกิดใหม่ |
สถานการณ์การออกแบบเชิงป้องกันเพิ่มเติม:
| สถานการณ์การใช้ประโยชน์ที่อาจเกิดขึ้น | แนวทางเชิงตอบสนอง (มีประสิทธิภาพน้อยกว่า) | แนวทางเชิงป้องกัน (มีประสิทธิภาพมากกว่า) |
|---|---|---|
| (Obby) ผู้ใช้ประโยชน์โทรเลขไปยังจุดสิ้นสุดเพื่อรับรางวัล | ตรวจสอบเฉพาะตำแหน่งสุดท้ายของผู้เล่นและพยายามตรวจจับเวลาการทำเสร็จที่เป็นไปไม่ได้ | ออกแบบโดยมีจุดตรวจสอบที่จำเป็นและเรียงลำดับ เซิร์ฟเวอร์ตรวจสอบว่าจุดตรวจสอบแต่ละจุดถูกเปิดใช้งานตามลำดับก่อนที่จะมอบรางวัล คุณสามารถเพิ่มชั้นอีกหนึ่งโดยการติดธงผู้เล่นที่เสร็จสิ้นด่านได้เร็วกว่าเวลาที่เป็นไปได้สำหรับมนุษย์ การออกแบบประสบการณ์ (ต้องการจุดตรวจสอบ) คือสิ่งที่เปิดโอกาสให้การตรวจสอบจากเซิร์ฟเวอร์มีประสิทธิภาพ |
| (Combat) ลูกค้าแจ้งว่าทำความเสียหายที่เป็นไปไม่ได้ | พยายามตรวจจับและกรองค่าความเสียหายที่เป็นไปไม่ได้ | เซิร์ฟเวอร์คำนวณความเสียหายทั้งหมดจากสถิติอาวุธฝั่งเซิร์ฟเวอร์และตรวจสอบการตีผ่านการยิงจากเซิร์ฟเวอร์ |
| (Economy) ผู้ใช้ประโยชน์ทำรายการซ้ำผ่านการขออย่างรวดเร็ว | พยายามตรวจจับการขอซ้ำหรือลวดลายที่ไม่ปกติ | Implement server-side cooldowns and validate all transactions against current player inventory state |
เมื่อออกแบบฟีเจอร์ใหม่ ให้ถามตัวเองว่า: "ผู้ใช้ประโยชน์จะใช้ประโยชน์จากสิ่งนี้อย่างไร และฉันสามารถเปลี่ยนการออกแบบให้ทำให้การใช้ประโยชน์ดังกล่าวเป็นไปไม่ได้หรือไม่มีค่าได้หรือไม่?" แทนที่จะพยายามตรวจจับการโกงหลังจากเกิดขึ้น ให้ออกแบบประสบการณ์ของคุณให้อยู่ในวงที่การโกงไม่สามารถเกิดขึ้นได้หรือไม่ให้ข้อได้เปรียบที่มีความหมาย