Watch: AI Creates Tomb Raider Super Jump Mod From Scratch
Creating game mods has never been easier! In this comprehensive guide and accompanying video tutorial, you'll learn how to recreate the legendary Super Jump mod for Tomb Raider Remastered I-III using nothing but AI assistance. No programming experience required - just describe what you want and watch Windsurf AI generate working code that transforms Lara Croft into a high-jumping legend.
What You'll Learn
This tutorial covers everything you need to know about AI-powered game modding for Tomb Raider:
- Zero-Code Modding: Use natural language to describe mod functionality to AI
- Real-Time Game Modification: Implement dynamic code injection with Frida
- Super Jump Implementation: Recreate the classic cheat that every Tomb Raider fan loves
- Professional Tools: Work with Node.js and Frida for serious game modification
Tools and Requirements
Before diving into the AI prompts, make sure you have:
- Windsurf AI (Your AI coding assistant)
- Node.js (JavaScript runtime environment)
- Tomb Raider Remastered I-III (Target game)
- Basic understanding of file navigation
The AI Prompting Strategy
The key to successful AI-generated mods lies in clear, specific prompts. Below are the exact prompts used in the video tutorial to generate a working Super Jump mod.
Complete AI Prompts for Tomb Raider Super Jump Mod
Setup manifest prompt
PROJECT DETAILS:
* Name: tomb-raider-super-lara-mod
* Version 1
* Entry script: index.js
* Add a start script for index.js
* Only dependency should be Frida, version 16.4.10
Author: [your name]
License: ISC
Format as a proper npm JSON file that we can use.
Setup entry script prompt
* Import the main function from src/super-lara-mods
* Call the main function to start the application
* include node js shebang line
This file should serve as the main executable entry point, for the npm start command.
memory-definitions.js file
// This file contains all the memory addresses we need to modify Lara's behavior
// 📍 Memory addresses for reading/writing game data
// Format: [address_offset, data_type, pointer_offset]
const memoryAddresses = {
// 🏛️ Main executable - Contains game state info
"tomb123.exe": {
scene_id: ["0x25FA74", "Int32"], // 🗺️ Current level number (1-17)
game_index: ["0xe0b68", "Int32"] // 🎮 Which game is active (0=TR1, 1=TR2, 2=TR3)
},
// 🏺 Tomb Raider 1
"tomb1.dll": {
lara: ["0x30ce50", "Int64", "0x0"], // 👩 Lara's main data pointer
height_speed: ["0x30ce50", "Int16", "0x24"], // ⬆️ Vertical movement speed
state: ["0x30CCAC", "Int16"], // 🎭 Lara's current state (on land, in water, etc)
},
// ⛏️ Tomb Raider 2
"tomb2.dll": {
lara: ["0x342fc0", "UInt64", "0x0"], // 👩 Lara's main data pointer
height_speed: ["0x342fc0", "Int16", "0x24"], // ⬆️ Vertical movement speed
state: ["0x30EAAC", "Int16"], // 🎭 Lara's current state (on land, in water, etc)
},
// 🌍 Tomb Raider 3
"tomb3.dll": {
lara: ["0x39de90", "UInt64", "0x0"], // 👩 Lara's main data pointer
height_speed: ["0x39de90", "Int16", "0x24"], // ⬆️ Vertical movement speed
state: ["0x39DCEC", "Int16"] // 🎭 Lara's current state (on land, in water, etc)
}
};
// 🎣 Hook addresses - Where we intercept game functions
const hookAddresses = {
"tomb1.dll": {
"LARA_IN_LEVEL": "0x2cac0" // 🚪 TR1 level entry hook
},
"tomb2.dll": {
"LARA_IN_LEVEL": "0x559b0" // 🚪 TR2 level entry hook
},
"tomb3.dll": {
"LARA_IN_LEVEL": "0x74cb0" // 🚪 TR3 level entry hook
}
};
// 📤 Export our address mappings for use in other files
module.exports = { memoryAddresses, hookAddresses };
Game script generator prompt
Your main export should be a function called createGameScript that takes two parameters: memoryAddresses and hookAddresses. This function needs to return a complete javascript string that Frida can inject into the running game. The format of the addresses and hooks are matching that of the memory-definitions.js file.
The generated code needs to work inside the game's memory space, so it should start by discovering the base addresses of all the game modules. Look for tomb123.exe, tomb1.dll, tomb2.dll and tomb3.dll using Process.getModuleByName(). Store these in an object and handle casdes where modules might not be loaded yet.
You'll need a helper function that can resolve the actual memory addresses from our offset definitions. This function should take a base address, an offset, an optional pointer offset, and an extra offset. Convert the hex strings to integers, add them together and if there's a pointer involved, follow it by reading the memory at that location and adding the pointer offset to the result.
The script should export several functions through rpc.exports that our main Node.js code can call. Create a getBaseAddresses function that returns all the module base addresses for debugging.
Build a readMemoryValue function that ca nread any type of data from game memory. It should accept an address name (like height_speed) which module to read from, any extra offset, and optionally override the data type. Support all the basic data types: signed and undigned 8bit, 16bit, 32bit and 64bit integers, plus floats and doubles. Use your address resolution function to canculate the final memory location, then read the appropriate data type using Frida's memory functions!
Also create a corrosponding writeMemoryValue function that works the same way but writes data instead. Return true if the write succeeds, false if it fails.
Add a getLaraPointer function that will specifically get the Lara main data pointer for a given game process. Read the pointer from the base address plus the Lara offset, and return null if the pointer is invalid.
Finally, create a hook function that sets up the function interception. Loop through all the hook addresses, calculate the actual memory locations, and use Interceptor.attach to monitor when these functions are called. Here's the important part: if the hook name is exactly 'LARA_IN_LEVEL' then send a message 'levelEntered' back to our main code. For any other hook names, just send the hook name in the message instead.
For ease of understanding, write emoji comments throughout the generated code to make it clear and engaging. Handle all potential errors gracefully, if something fails return null or false rather than crashing. Use console.error for any hook setup failures so we can debug.
The entire function should use a template literal to build and return this javascript code as a single string that frida can inject.
Super lara implementation prompt
Import frida for dynamic instrumentation, the createGameScript function from your game-script-generator file and the memoryAddresses/hookAddresses from your memory definitions file. The memory definitions file is the exact structure we need to use for these addresses.
You will need to track some variables:
* the frida session
* the injected script instance
* an exit flag boolean
* laras pointer
* current level number
*super jump is active boolean
* super jump is running boolean
* super fall is running boolean
For a game detection function, Create a function that reads the game_index value from tomb123.exe and returns the appropriate DLL name (tomb1.dll, tomb2.dll, tomb3.dll) based on whether the index is 0, 1 or 2.
For lara initialization:
Create a function to get the current game process ID, extract lara's base address from the memory definitions, get Laras pointer using the script's getLaraPointer function and read the current level from scene_id. Handle errors gracefully, by returning null.
For the super jump function, Create a asynchronous function named superJump with this exact structure:
1. Guard against multiple instances using the superJumpRunning boolean we created
2. Set the running flag to true
3. Define an inner function named loop that repeats every 5ms and starts immediately.
3a. Return early if exiting is true
3b. Reads state memory value and only proceeds if laraPointer exists and the state is 0 (she's on land)
3c. Wraps the main logic in a try catch block that logs any errors.
3d. Declare maxJumpSpeed as 175
3e. Read the current heigh speed value from memory
3f. Initialize a new speed variable to the current value.
3g. If the super jump is active, then: if the current speed is less than 0, we calculate the new speed using a Math.max of the max speed and the current speed - 25. Write it back to the memory address. Deactivate if the new speed is less than or equal to -maxJumpSpeed OR the current speed is less than 0 and new speed is more than or equal to 0!
If the super jump was not active, then we need to activate it only if the current speed is 0.
Use await/async pattern for this, for all memory operations with getGameProcessId. Structure must match exactly for variable state management.
For the SUPER FALL, no damage:
Create an async function that does a similar loop pattern. In this function loop we only need to repeat every 50ms. Check if exiting, read laras state (only continue if 0), read the current speed and if it is greater than 130 then write it at exactly 130.
For a level entry handler, to make sure we detect when lara enters the level,
Create a function that reinitializes laras data when entering a new level. Call the lara init function, and only enable mods for level 1-17. Start both super jump and fall protection functions.
For the main script part, display a startup banner with emojis for the mods showing a title and which mods are running. Create a loop that continuously tries to attach to tomb123.exe until successful, with 1second delays between attempts.
Once attached to the process, create and inject the script and set up a message listener for "levelEntered" events, load the script, set up hooks, initialize if already in a level, and keep the process alive!
We also need a cleanup function that sets the exit flag, stop all running loops, and unload the script if it exist and not destroyed. Detach from the game process. Include proper loging for each cleanup step.
Handle Node.js signals for exiting, SIGINT and SIGTERM along with an uncaughtException handler to log errors and call cleanup gracefully before exiting.
If the file is run directly, execute the main function with proper error handling. Export the main and cleanup functions for use by other modules.
Finally, CODING STYLE:
Use emoji comments throughout so that we can understand what is happening, for clarity. Include detailed explanations of the logic. Handle all errors gracefully with try catch blocks. Use professional structure with clear function separation.
Why This AI Approach Works
- Speed: Generate working mod code in minutes instead of hours of manual programming
- Accessibility: No need to learn complex reverse engineering or assembly language
- Iteration: Quickly modify and enhance your mods with simple text prompts
- Learning: Understand game modification concepts through AI-generated, well-commented code
- Experimentation: Try different mod ideas without fear of breaking anything
Watch the Full Tutorial
Ready to see this in action? Watch the complete video tutorial where we demonstrate every step of the process, from initial setup to testing the final Super Jump mod in-game.
