Si bien el GameHacking se puede usar para bien, generalmente se usa como para el mal (o el caos, dependiendo de como lo veais). Generalmente, no os pasara nada, a no ser que busqueis ganar beneficios de esto. En cuyo caso: No me responsabilizo. Cada ano hay gente que va a la carcel por hacer esto. Es una infraccion clara del derecho de propiedad intelectual. Si lo haceis por profit (sin trabajar para la compania) podeis llevaros hasta 5 anos en prision y hasta 200,000$.
GameHacking es un subconjunto del Software Hacking. Sin embargo, Software Hacking se centra más en crear cracks, keygens, etc..., y GameHacking se centra en explotar tanto las mecánicas como las vulnerabilidades del juego.
Definamos, pues, el concepto de GameHacking como El área que se estudia el funcionamiento REAL del software (generalmente de los videojuegos), con la finalidad de romperlos, explotarlos, extenderlos, obtener ventajas, o hallar vulnerabilidades.
Vayamos por partes, en que consiste cada cosa:
Romperlos: Hacerle bullying al juego a lo hardcore. Extenderlos: Si no eres el desarrollador, a veces quieres añadirle cositas a los juegos. Tambien conocido como el modding. Obtener Ventajas: Cheats/Trampas. Malditos Hallar Vulnerabilidades: A veces los videojuegos tienen vulnerabilidades importantes, como el Source Engine que permitia a un jugador enviarte codigo malicioso al matarte, o un Server Crasher.
Los desarrolladores deben saber hacer esto para prevenir posibles vulnerabilidades. Y tambien deben saber como funciona el gamehacking para protegerse frente a Hackers. No te puedes proteger de aquello que no conoces.
Aunque tu juego este bien programado, y sea dificil de romper, hay que ser realistas. No todos los datos se pueden almacenar en el servidor constantemente, ya que enviar y recibir estos datos llevaria mucho tiempo (por las latencias/ping). Por ejemplo, los comunmente llamados Wallhacks (aunque el termino correcto seria Extra Sensor Perception o ESP). Todos los juegos permiten que el cliente (jugador) tenga acceso a las localizaciones de los jugadores enemigos a una cierta distancia, de manera que la diferencia de tiempo entre que un jugador vea a otro dependa de la memoria y no de la latencia de un jugador.
- Escribiréis código con la eficiencia en mente (cuando os falte memoria y/o potencia para hacer algo,, lo notaréis :D), y vuestra mente se habituará a buscar mejores soluciones.
- Codigo más legible: no es un area sencilla y si vuestro codigo no esta bien escrito y comentado, tendreis problemas para entenderlo.
- Todo esto hará que vuestro código esté mejor estructurado.
- Entendereis las desventajas de OOP. Los objetos tienen un overhead bastante gordo, y además, acumulable. Si usais demasiados, vuestro codigo no sera eficiente y lo notaréis. Muchas de estas se arregla con Data Oriented Design.
- Aprendereis las diferencias entre las distintas plataformas en profundidad; y mejorareis vuestros conocimientos sobre los lenguajes que useis.
- Pensareis Outside the Box.