hey all, first post here.

I have a project where I'm trying to educate people that have never played any game in their life to the problem of cheating in PvP competitive FPS. Problem is, I'm pretty ignorant of almost anything related to game programming, but still want this proof of concept.

Basically I need a very basic first person shooter with multiplayer PVP support. I'm hoping that this is something i can do myself quickly using tutorials.

Then I need to develop a basic ESP/wallhack for this basic game, to showcase the problem.

How would yo ugo about it? thanks

beret7a said:

How would yo ugo about it?

I would stick with screenshots and illustrations. We don't just whip up multiplayer FPS games from scratch overnight, and if we did it would have a specific netcode, which might have some exploits and not others.

Stick with illustrations and screenshots; that'll also allow you to comment on cheating across a variety of games, instead of just issues in FPS games as a whole.

LorenzoGatti said:
a demonstration

I agree with this - I wanted to extend the suggestion of screenshots by adding video recordings, but some interactive elements are nice and typically less boring than still slides.
I also agree about UML; in short you want to simplify as much as possible to ease in your blank audience. After that, perhaps you can ramp up the detail a bit while explaining how various exploits work, building onto their knowledge from the crash-course class.

Thanks for both comments, are you aware of existing documentation for FPS ?

Definitely interested what was suggested: agents / components of network protocols for your typical FPS game, temporal succession of both network messages and internal events such as rendering frames and acquiring inputs

LorenzoGatti said:

SuperVGA said:
Stick with illustrations and screenshots; that'll also allow you to comment on cheating across a variety of games, instead of just issues in FPS games as a whole.

General theory about what the problem is would be much more effective, efficient and educative than the narrow exercise of teaching your class how to write a wallhack or the like. Regarding specific content types:

• Screenshots of hacking tools (or maybe a demonstration of mature ones for an established game) are needed to explain what you are talking about, particularly for “people that have never played any game in their life”.
  You have the opportunity, within the course of an introductory lesson, to show them a relatively novice-friendly game genre and then (as soon as they have fun shooting each other) spoil it with hacks in the most infuriating way.
• UML sequence diagrams or something similar should be useful and versatile for your topic, as they can represent clearly the different agents and components involved in network protocols, what they are busy with, and the temporal succession of both network messages and internal events such as rendering frames and acquiring inputs.

beret7a said:

Thanks for both comments, are you aware of existing documentation for FPS ?

I'm not completely sure what sort of documentation you're referring to, but there are often resources to be found online, examining various in-game actions, inspecting packets sent or trying to explain the netcode.

An early type of netcode used for our FPS back in the DOS days is lockstep, which is described here.
Quake 3 has a well-known and more sophisticated netcode, described here.

Now the exploits might not relate directly to netcode; Counter-strike wallhack IIRC was just forcing a different set of vertex attributes to the graphics card - please correct me if I'm wrong. You could also deem rocket-jumping an exploit, and once you could move sqrt(2.0) instead of 1.0 per tick, by moving forward/backwards at the same time as sideways. I'm not sure what that was called, but in official documentation or source code, you'd have to really drill into it to uncover stuff like that.

But there is potentially a lot of ground to cover. Finding good resources that have already reverse-engineered the games you want to cover might be a good idea. I doubt you'd appreciate reading official documentation or source to get information on exploits, network-related or otherwise.