2009-06-06 85 views
32

如果你正在寫遊戲,你應該考慮作弊者以及如何防止他們作弊。如何防止我們(多人)遊戲中的作弊行爲?

我不認爲只有MMO多人遊戲,但也單人或「家釀」p2p遊戲太。

當遊戲完全基於服務器 - 客戶端體系結構時,我認爲這項工作幾乎完成了,但也存在着黑客攻擊或其他問題。

我做了我自己的p2p遊戲,並在一段時間後出現了騙子。他們只是使用作弊引擎並嘗試加速和內存黑客的scriptkiddies。

大多數加速鉤子gettickcount。我通過下面這個簡單的技巧來整理出快速黑客。我只是跟蹤time()-GetTickCount()價值,如果差異發生變化,那就是作弊。

可以通過將散列副本保留在某處並將其始終移動並始終以隨機值對其進行重新散列來整理內存損壞。不匹配導致崩潰。

理清作弊引擎可言,只是檢查:

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0) 
{ 
    // Cheat Engine runs. 
} 

(一個朋友告訴我這個,我還沒有測試它。)

這些技巧整理出最騙子。但是當然有更多的作弊技巧。 我打開這個wiki,討論更多的另一個作弊技巧和避免它們的方法。

+1

如果您的遊戲使用存檔遊戲,您需要檢查存檔遊戲編輯和損壞 – Jim 2009-06-06 22:21:20

回答

54

我不認爲你應該做任何事來阻止單人遊戲的作弊行爲。您的用戶購買了遊戲,只要他們不與其他玩家對抗,他們應該可以作弊。

以下是我所做的一些事情。這些主要用於比賽遊戲中的反作弊系統,其中金錢受到威脅,並且對用戶系統的某些入侵級別被認爲是可以接受的。我會在休閒遊戲中做一些這樣的事情,因爲如果你的遊戲不穩定,可能會導致他們的系統出現問題。

1)如有可能,「永不相信客戶」是您最堅定的原則。在服務器上執行所有操作,只給客戶儘可能多的知識,以便在任何給定時間呈現他應該能夠在屏幕上看到的內容。即如果客戶不知道隱藏在牆後的玩家的位置,牆上的黑客就不會爲用戶帶來任何好處。對於高速動作遊戲來說,這可能非常困難 - 特別是現在實時陰影等都是常態,即使玩家的身體可見,用戶可能也需要能夠看到陰影 - 但它應該始終是在您的選項的頂部。在點對點遊戲中也非常困難,但是有限制同行間知識的方法。只有當它變得性能過高,或超出時間/金錢預算時,才應考慮以下幾項。

2)打開所有其他進程,並掛鉤它們的WriteProcessMemory函數,以便它們不能寫入遊戲進程中的內存。完成這一步將阻止90%的所有作弊和作弊引擎。

3)做同樣的事情,掛鉤各種鼠標和鍵盤仿真功能。這將防止很多的目標機器人和其他類型的自動化機器人。

4)掛鉤到遊戲自己的進程中的VirtualProtectEx/VirtualAllocEx/etc函數,並監視哪些模塊正在改變保護級別或分配新的內存塊。爲了防止遊戲執行大量分配時CPU密集度過高,您必須對此狡猾,但這可以完成。 5)掛鉤到LoadLibrary函數中,並監視動態加載的任何DLL,以防止DLL注入。

6)在遊戲連接上使用一些輕量級的多態編碼。

7)使用一些反調試技術來防止調試器附加到您的進程。谷歌反調試,你應該能夠找到很多東西。

8)使用自定義專有PE打包機來防止有用的反彙編你的遊戲。 9)掛鉤你的OpenGL或Direct3D函數和處理透明度和alpha混合的方法。

10)如果使用着色器,校驗和着色器和着色器常量值。

11)對玩家角色使用額外的遮擋剔除技巧,以防止他們在視線對他們的視線被其他幾何體阻擋時被渲染。它可能也可能不會幫助你的表現,但它會阻止很多wallhacks。

+10

+1以防止在單人遊戲模式下作弊。 – 2009-06-10 05:37:56

+2

P2P =點對點,即不是單人遊戲。儘管我同意不會浪費時間保護單人遊戲,只要作弊不能以任何方式干擾其他玩家(例如在線高分榜或類似遊戲)。 – 2009-06-10 23:20:29

+2

要了解要做的事情的完整列表,請+1。 – 2009-06-10 23:25:32

16

你可能會發現這篇文章在Cheat Proof Game Protocols有趣。它們都是同一個想法的變體:用哈希作爲承諾,然後在滿足其他玩家的行爲條件時揭示哈希承諾的含義。這很複雜,並且對性能有影響,但是其中一些想法可能是有用的,特別是對於點對點遊戲。

5

當遊戲完全基於服務器 - 客戶端架構時,我認爲這項工作已基本完成,但也存在着黑客攻擊或其他問題。

如果您不能移動大部分的邏輯的在服務器端運行,至少嘗試共享在每個遊戲階段的現實儘可能少的狀態,換句話說:使每個玩家的活動的遊戲模式進入帳戶,只分享當時實際相關的信息。

這樣不但可以減少作弊的可能性,還可以減少協議造成的流量,即提高效率。

這是一種技術,它本身早已爲遊戲/模擬行業所知並應用於提高渲染大型3D場景時的效率。

在那裏,「截錐體剔除」用於確定場景的哪些部分實際上是可見的,以便僅渲染相關部分。

類似地,可以使用相同的技術來限制多人遊戲客戶端僅在它們實際相關時才接收某些更新/信息,例如,如果其他客戶實際上在「相關範圍」內,則其他客戶端可以檢索相應的更新。

儘管如此,區分相關性和「可見度」:兩個被門隔開的玩家實際上可能不會「看到」另一個,但根據周圍環境,很可能會聽到彼此的聲音。因此,區分不同類型的「可見性」:傳播可聽狀態並不一定意味着將玩家的實際位置傳播到遊戲座標中。反之亦然:僅僅因爲你「看到」了一名球員,你不一定有權利聽取客戶的意見(例如想象一下步槍上的範圍)。

換句話說,嘗試鬆散地耦合您支持的更新數據包,以使它們彼此之間不存在相互依賴關係,並且還可以獨立傳播/訂閱。

只要運用適當的封裝和數據隱藏機制,就可以在很大程度上控制作弊行爲,這樣多人客戶端通常不會共享全局狀態,但共享狀態直接取決於玩家的活動上下文(位置,標題,方向,速度等等)。

相關問題