How Artificial Intelligence Is Transforming Reverse Engineering and Game Development
CHAPTER 1 — THE IMPOSSIBLE IS BECOMING POSSIBLE
For decades, video games have been built on technologies that define what is possible within their worlds.
Every game has its own systems, limitations, and architecture.
A mechanic developed for one game engine cannot simply be transferred into another.
At least, not without a considerable amount of engineering.
But something has started to change.
Today, independent developers are reconstructing systems from commercial video games, translating technology into modern programming languages, and creating combinations that would have seemed unlikely just a few years ago.
Imagine bringing the mechanics of Skate 3 into GTA San Andreas.
Or using combat systems from Call of Duty: Modern Warfare 2 inside a Minecraft world.
Imagine reconstructing the functionality of an old video game and adapting it to run natively on modern computers, without relying entirely on traditional emulation.
Now imagine going even further.
Instead of transferring systems from other games, developers can create their own physics, algorithms, and architectures, using artificial intelligence as an engineering tool.
All of this inside a game released more than twenty years ago.
These possibilities are already being explored by independent development communities.
But there is an important question behind these advancements.
Are we witnessing a revolution caused by artificial intelligence, or an evolution in the human ability to develop software with its assistance?
To answer that, we need to understand how modding reached this point.
---
CHAPTER 2 — WHEN MODDING BECAME MORE THAN REPLACING FILES
For many years, modifying a video game primarily meant replacing textures, models, sounds, vehicles, and characters.
A car could be replaced with another vehicle. A map could receive new buildings. A mission could be modified.
And these possibilities alone transformed the way countless games survived over time.
But some communities decided to investigate something much deeper.
The internal functionality of the games themselves.
That is how reverse engineering became a fundamental part of advanced modding.
By analyzing executables, memory structures, binary files, and compiled functions, developers began understanding technologies that had never been publicly documented.
In GTA San Andreas, for example, the community spent years identifying functions, structures, and components related to RenderWare and Rockstar's proprietary game systems.
Tools such as plugin-sdk helped make this knowledge accessible to other programmers.
Over time, it became possible to modify internal behaviors, introduce entirely new mechanics, and extend functionality without relying exclusively on the game's original development tools.
But there was a problem.
Investigating an unknown system could take weeks, months, or even years.
Understanding the code was only one part of the process.
Developers still needed to create implementations, compile them, run tests, identify failures, and correct incompatibilities.
And this is where artificial intelligence began taking on a new role.
Not simply as a tool that answers questions.
But as a technology capable of participating directly in software development.
---
CHAPTER 3 — THE ROLE OF ARTIFICIAL INTELLIGENCE AND THE OPERATOR
There is a popular belief that artificial intelligence is making technical knowledge unnecessary.
That all someone needs to do is write an instruction and wait for the system to create everything automatically.
But complex development projects reveal a much more interesting reality.
Artificial intelligence can generate code, analyze functions, suggest algorithms, explain unfamiliar structures, and help identify errors.
Modern models can also work with large collections of files and carry out multi-step programming tasks, depending on the tools and permissions available.
However, there is a fundamental difference between generating code and engineering a complete system.
Imagine two operators using exactly the same artificial intelligence model.
The first operator writes:
"Create a skateboard physics system for GTA San Andreas."
The AI might produce a basic implementation involving acceleration, jumping, and some collision conditions.
Perhaps the result works in a simple demonstration.
Now imagine a second operator.
This person understands GTA San Andreas's architecture, collision systems, vectors, transformations, three-dimensional movement, and physics update cycles.
Instead of making a generic request, this operator establishes detailed technical requirements.
They define how the skateboard should detect the ground.
How its orientation should follow inclined surfaces.
How velocity should be preserved during transitions.
How collision information should be retrieved.
How the character's state should change between riding, jumping, grinding, and landing.
How the implementation should interact with the game's internal structures.
And which situations must be tested before a feature can be considered complete.
Both operators have access to the same artificial intelligence.
But they provide completely different levels of context.
The first provides an objective.
The second provides an architecture, constraints, and validation criteria.
That difference can dramatically affect the quality of the result.
And it reveals one of the most important aspects of modern AI development tools.
The effective capabilities of artificial intelligence are not determined exclusively by the model itself. They also depend on the information provided, the tools available, and how the problem is approached.
This does not mean experienced operators cannot make mistakes, or that an AI cannot independently suggest impressive solutions.
It means human experience remains especially valuable when multiple complex systems must work together.
An experienced operator can recognize an apparently correct solution that actually introduces stability problems.
They may identify when a particular architecture will compromise performance.
Or when a mathematically valid algorithm fails to produce the desired physical behavior.
Artificial intelligence can accelerate the execution of tasks.
But the operator can still determine what should be built, why it should work in a particular way, and how the result should be verified.
To understand this process through a real project, we need to examine one of the most interesting examples of modern game reconstruction.
Skate 3.
---
CHAPTER 4 — SKATE 3 AND THE RECONSTRUCTION OF COMPLEX SYSTEMS IN RUST
Released in 2010, Skate 3 became a reference point for skateboarding video games.
Its gameplay involves complex systems for movement, animation, collision detection, balance, and trick execution.
Recreating these characteristics outside the original game requires understanding far more than how its movements look.
Developers need to investigate how the underlying components interact.
The project known as Skate 3 Rust Engine emerged from this type of research.
Before the Rust reconstruction, a developer known as dumbad spent more than two years investigating Skate 3.
This work included analyzing file formats, interaction systems, maps, collisions, animations, and developing modding tools.
Later, another developer known as Chasm worked on recompilation and rendering experiments before progressing toward an implementation using Rust and Bevy.
An important distinction must be made here.
Rust is a programming language.
Bevy is a game engine developed in Rust.
Therefore, this project is not simply a case of automatically converting Skate 3's original engine source code into Rust.
It is a reconstruction based on knowledge obtained through reverse engineering.
And this is where artificial intelligence enters the picture.
The developers publicly acknowledge using AI tools to assist with programming.
But they also emphasize something fundamental.
Without the years of previous investigation, much of the knowledge required to guide the implementation would not have been available.
In other words, artificial intelligence did not independently discover every internal mechanism of Skate 3.
It helped transform existing knowledge into a new implementation.
And that represents an important change.
Research that might previously have required an even longer development process can now be translated into working code more quickly.
However, producing the code does not complete the engineering process.
The Skate 3 Rust Engine still has differences compared to the original game.
That is because visually reproducing a feature does not necessarily mean reproducing the internal behavior responsible for it.
An animation may appear correct while its underlying physics produces inconsistent results.
A grind might work on one surface and fail on another.
A landing system may behave differently depending on the angle, velocity, and collision conditions.
Reconstruction still requires investigation, implementation, and testing.
But something even more impressive becomes possible.
Once these systems operate as reusable components, they can potentially be integrated into other games.
And that is exactly what started happening.
---
CHAPTER 5 — WHEN SKATE 3, CALL OF DUTY, AND MINECRAFT COME TOGETHER
One of the most unusual examples of this trend is the 2010 Rust Rewrite Mashup.
The project combines technologies associated with three very different games.
Call of Duty: Modern Warfare 2.
Skate 3.
And Minecraft.
Its foundation is IW4L, a Rust reconstruction of Modern Warfare 2.
On top of that architecture, the project integrates skateboarding systems and components related to Minecraft-style worlds.
This makes it possible to experiment with skateboarding mechanics inside Modern Warfare 2 environments and combat mechanics within Minecraft-inspired worlds.
However, this does not mean three original game engines were copied and automatically merged.
The result depends on reconstructed implementations and adaptations between systems.
Each component must understand the information provided by the others.
A skateboarding physics system needs collision data from the environment in which it operates.
An animation system must correctly represent physical movement.
Controls need to be adapted.
And different mathematical representations must be made compatible.
All of this requires engineering.
But when these integrations work, they demonstrate an extraordinary possibility.
Technology originally associated with one game can be reconstructed as a component capable of functioning in another environment.
And this idea eventually reached one of the most well-known modding communities in the world.
The GTA San Andreas community.
---
CHAPTER 6 — GTA SAN ANSKATEAS: BRINGING A RECONSTRUCTED SYSTEM INTO ANOTHER GAME
GTA San AnSkateas, developed by RyGlizzy, demonstrates how these technologies can be adapted to GTA San Andreas.
The project takes advantage of a skateboarding implementation used in the 2010 Rust Rewrite Mashup.
To achieve this integration, it uses an architecture involving multiple components.
An ASI plugin written in C++ communicates with GTA San Andreas through plugin-sdk.
A 32-bit Rust library provides an interface to the skateboarding systems.
The skateboarding implementation itself uses components derived from the reconstruction discussed earlier.
In this architecture, GTA San Andreas provides the environment in which the player moves, while external systems participate in the skateboarding experience.
But this integration presents challenges.
Collision formats need to be interpreted.
Movement must remain synchronized.
Animations must accurately represent the physical state.
And communication between components must avoid inconsistencies.
An architecture like this allows developers to build upon work already completed by others.
It also demonstrates how independent research can create new possibilities for different gaming communities.
However, there is another approach.
Instead of adapting a reconstructed system, a developer can study the desired mechanics and create their own algorithms.
That second approach brings us to Reprise Eagle Skateboard.
And this is where our discussion about artificial intelligence, engineering, and the importance of the operator becomes even more interesting.
---
CHAPTER 7 — REPRISE EAGLE SKATEBOARD: DEVELOPING AN ORIGINAL SYSTEM
Reprise Eagle Skateboard is a project developed by Frikmano for Project Eagle, an initiative focused on expanding and modifying GTA San Andreas.
Its objective is to introduce a skateboarding system combining movement, tricks, environmental interaction, and player progression.
The project draws inspiration from games such as Skate 3, Bully, and Tony Hawk's Pro Skater 3.
But there is an important distinction between Reprise Eagle Skateboard and GTA San AnSkateas.
While RyGlizzy's project integrates an external skateboarding implementation, Reprise Eagle Skateboard was developed with its own systems, designed specifically to operate within the GTA San Andreas environment.
This does not automatically make one approach superior to the other.
They represent different engineering strategies.
In Reprise Eagle Skateboard, one of the central challenges is representing skateboard behavior using the structures of a game that was never originally designed for this purpose.
GTA San Andreas already includes systems for vehicles, characters, animations, and collisions.
But those systems do not natively reproduce the full complexity of a dedicated skateboarding game.
A skateboard needs to respond to the terrain.
Maintain velocity through certain transitions.
Lose momentum while traveling uphill.
Gain speed while moving downhill.
Execute jumps.
Detect environmental edges suitable for grinds.
And determine whether the character is properly positioned to land.
Simply making a character slide across the ground is not enough.
A consistent relationship must be established between movement, physics, animation, and the surrounding environment.
In Reprise Eagle Skateboard, movement has been designed around factors such as acceleration, momentum, terrain inclination, and ramp transitions.
Its available mechanics include ollies, flips, spins, grabs, manuals, handplants, and grinds.
The project also features skill systems, experience, level progression, and customizable controls.
These features require much more than a collection of animations.
They need to exchange information.
For example, during a jump, the system must track the character's state, velocity, and trajectory.
Executing a trick may affect the conditions required for a successful landing.
A grind must recognize a compatible surface and determine how movement should continue when the skateboard leaves it.
Meanwhile, the progression system modifies certain player capabilities according to their unlocked skills.
All these components must work together.
And the more systems a developer adds, the more important the underlying architecture becomes.
This is where the experience of the person developing the project can directly influence the result.
---
CHAPTER 8 — THE OPERATOR AS THE ARCHITECT OF ARTIFICIAL INTELLIGENCE
The development of a project like Reprise Eagle Skateboard helps illustrate a transformation taking place throughout software engineering.
A developer's role is no longer limited to manually writing instructions line by line.
Developers must also design systems.
Establish rules.
Determine how different modules communicate.
Investigate problems.
And decide which solutions are appropriate for the intended outcome.
Artificial intelligence can assist with several stages of this process.
Imagine a developer working on skateboard behavior during the transition between flat ground and a ramp.
A generic instruction might ask the AI to make the skateboard travel up ramps.
But an operator with knowledge of physics and programming could approach the problem differently.
First, they would identify how to obtain the surface normal.
Then they would investigate how to orient the skateboard relative to the terrain.
They would define how the appropriate component of velocity should be preserved.
They would analyze how to perform the transition without producing sudden or unnatural movements.
And they would establish tests involving different angles and velocities.
With that context, artificial intelligence could help implement the calculations, organize the code, and investigate potential errors.
Notice the difference.
Creativity is not limited to imagining that a character should ride up a ramp.
It also involves understanding the problems that must be solved to produce that behavior.
Another example involves grinds.
It is possible to ask an AI to make a skateboard slide along edges.
But identifying usable edges in a three-dimensional world requires much more.
The system must investigate geometry.
Identify potential contact segments.
Distinguish suitable surfaces from incompatible obstacles.
Evaluate alignment and velocity.
Determine entry and exit conditions.
And prevent minor irregularities from incorrectly launching the skateboard away from the surface.
An experienced operator can divide this problem into smaller systems.
They can propose grind classifications.
Introduce continuity checks.
Establish balance conditions.
And guide the implementation of tests.
Artificial intelligence, in turn, can accelerate the development of those solutions.
But there is no guarantee that the first implementation will be correct.
Perhaps the algorithm works perfectly on a curb but fails when used on a handrail.
Perhaps edge detection consumes excessive processing resources.
Or perhaps a calculation produces different results depending on the game's update frequency.
At that point, the developer must identify the problem and determine how to correct it.
That is why the quality of an AI-assisted project cannot be evaluated solely by the amount of code produced.
Thousands of lines of code do not necessarily represent thousands of lines of properly engineered software.
Engineering lies in organization, consistency, decision-making, and validation.
That is the difference between using AI to generate isolated features and using it as part of a structured development process.
It also explains why two programmers using the same model can achieve dramatically different results.
---
CHAPTER 9 — THE EVOLUTION OF REPRISE EAGLE SKATEBOARD AND ITS POTENTIAL
There is another important characteristic of the Reprise Eagle Skateboard concept.
Its potential does not have to end once the player learns to perform a few tricks.
The system can evolve into a much larger experience.
The project has already been designed with progression elements, unlockable skills, customizable controls, and different movement mechanics.
But there is also a proposed expansion involving skateboarding becoming part of the world of Project Eagle itself.
Imagine traveling through Los Santos and encountering non-player characters riding skateboards.
Skate crews gathering in specific neighborhoods.
Skateparks with activities taking place independently of the player's presence.
Score challenges.
Competitions.
Rival characters.
And a dedicated storyline centered around skateboarding culture.
These features should be understood as development proposals rather than a collection of systems that are already complete.
But they demonstrate something important about system planning.
An isolated mechanic can eventually become part of a much larger virtual world.
And in this case, integration with tools such as Reprise Eagle Mission Studio Tools could enable missions, objectives, dialogue, and events related to skateboarding.
That expansion would require connecting different architectures.
The skateboarding system would need to report states and events.
The mission editor would need to recognize those events.
Non-player characters would require compatible behaviors.
And progression systems would need to track the player's development.
Here, we are discussing artificial intelligence in two different contexts.
The artificial intelligence used to assist with programming.
And the artificial intelligence controlling characters within the game.
These technologies serve different purposes.
One assists with software development.
The other participates in simulating a virtual world.
This distinction matters because generative AI does not necessarily need to control NPCs directly to contribute to their development.
It can help developers design algorithms, organize behaviors, and implement rules that the game later executes using traditional programming techniques.
This is an example of how modern tools can expand the possibilities of an independent project.
The challenge then becomes connecting those possibilities without compromising stability and performance.
---
CHAPTER 10 — REUSING EXISTING SYSTEMS OR DEVELOPING ORIGINAL TECHNOLOGY?
The comparison between GTA San AnSkateas and Reprise Eagle Skateboard presents an important discussion for the development community.
Is it better to reuse an existing implementation or develop an original system?
The answer depends on the project's objectives.
Reusing a library can save time and take advantage of research that has already been completed.
It can also provide faster access to complex functionality.
However, external components introduce dependencies.
They may require extensive adaptations.
They may contain structures that are incompatible with the host game's architecture.
And they may impose specific licensing conditions.
Developing an original implementation, on the other hand, gives the developer greater freedom to define rules, interfaces, and behaviors.
The physics can be organized specifically for the environment in which it will operate.
The developer can choose which calculations will be performed.
Which information will be stored.
And which components should receive priority.
However, building original systems requires time, research, and testing.
Implementing original physics does not automatically guarantee superior performance.
And reusing an existing implementation does not necessarily mean the final result will be heavier or less stable.
Rust and C++ are both capable of producing high-performance software.
The result depends primarily on how systems are constructed and integrated.
This brings us to another point.
A version of GTA San Andreas equipped with complex physics and collision systems can require significantly more processing power than the original game.
Depending on the implementation, certain features may consume more CPU or GPU resources than equivalent functionality in modern games.
This does not mean every advanced mod will necessarily be more demanding than GTA V, for example.
But it demonstrates that a game's age does not determine the computational cost of new technology added to it.
Performance needs to be measured.
Operations need to be analyzed.
And implementations must be optimized according to their actual bottlenecks.
This concern applies both to the integration of external technologies and to the development of original systems.
The difference lies in the freedom and responsibilities each architecture provides.
And neither approach eliminates the importance of a developer who understands what is happening internally.
---
CHAPTER 11 — OTHER GAMES, OTHER APPROACHES
This evolution is not limited to GTA San Andreas.
Several projects demonstrate how communities are discovering new ways to reconstruct and preserve video games.
OpenGOAL, for example, works with games from the Jak and Daxter series.
Through research and specialized tools, the project aims to reconstruct and adapt the software for modern computers.
Another example is Zelda 64: Recompiled.
In this case, static recompilation techniques are used to run Majora's Mask natively on modern computers, introducing improvements and additional modding possibilities.
However, there is an important difference.
The developers behind Zelda 64: Recompiled explicitly state that they do not use generative artificial intelligence in their development process.
This demonstrates that reverse engineering, recompilation, and game reconstruction are fields that exist independently of modern AI models.
Artificial intelligence can assist with these processes, but it is not a universal requirement.
OpenMW represents another approach.
It develops an open-source engine capable of running The Elder Scrolls III: Morrowind.
And related initiatives, such as OpenMW-Web, demonstrate how that technology can be adapted to run in web browsers using WebAssembly.
In this case, we are not talking about automatically converting an engine into Rust.
OpenMW is developed primarily in C++, and its browser adaptation involves its own compilation, rendering, and compatibility challenges.
What connects all these examples is not a particular programming language.
It is the ability to study existing technologies and create new ways to execute them.
Sometimes through recompilation.
Other times through independent reconstruction.
Or by integrating components into a different architecture.
And increasingly, some developers are using artificial intelligence to accelerate parts of this work.
---
CHAPTER 12 — THE CONCERNS SURROUNDING THIS NEW GENERATION OF MODDING
But this transformation also introduces risks.
One of the first concerns involves copyright and licensing.
Reconstructing the behavior of software does not automatically provide ownership rights over all its components.
Source code, models, animations, textures, and other resources may be subject to different legal protections and conditions.
Additionally, open-source projects have licenses that must be respected.
Another concern involves the quality of AI-generated code.
Just because an AI can generate an implementation does not mean that implementation is correct.
Memory management problems, synchronization errors, collision inconsistencies, and performance issues can remain hidden during superficial testing.
There is also an additional concern.
The loss of recognition for human contributions.
When a project is presented simply as an engine reconstructed by artificial intelligence, there is a risk of overlooking the years of research performed by developers who investigated the original software.
In the case of the Skate 3 Rust Engine, its creators acknowledge this issue.
Previously accumulated knowledge was essential in guiding the reconstruction.
On the other hand, it would also be incorrect to dismiss the genuine contributions of AI tools when they are used.
These systems can significantly accelerate certain programming tasks.
The discussion does not need to be about choosing between human work and artificial intelligence.
It can instead focus on understanding how these two capabilities are being combined.
And how to ensure that the resulting software is reliable, maintainable, and properly attributed to its contributors.
Because developing something quickly is not the same as developing it correctly.
And a project does not automatically become technically advanced simply because it was created with the assistance of an AI model.
Its quality must be demonstrated through functionality, architecture, and results.
---
CHAPTER 13 — THE CHANGING ROLE OF THE DEVELOPER
Perhaps the most important transformation of this new era is not the replacement of programmers.
It is the expansion of what developers can do.
Traditionally, a significant portion of programming time was spent writing repetitive structures, implementing routines, and manually searching for errors.
Artificial intelligence tools can reduce some of that work.
This allows certain developers to dedicate more attention to system planning.
Architecture.
Behavioral investigation.
And result analysis.
But this possibility depends on how the technology is used.
An operator can automatically accept everything an AI produces.
Or they can treat its responses as hypotheses that need to be verified.
They can request isolated features.
Or they can build a complete architecture, directing each component and establishing quality criteria.
The difference is important.
Because complex systems do not depend solely on knowing how to write individual instructions.
They depend on understanding the relationships between those instructions.
That is why projects such as Reprise Eagle Skateboard are relevant to this discussion.
The complexity is not limited to creating a usable skateboard inside GTA San Andreas.
It involves establishing a structure in which movement, collision, animation, progression, and other systems can work together.
Artificial intelligence can assist with implementing different parts of this process.
But the conception of the project, its objectives, and its architectural decisions remain central elements of engineering.
This does not mean future artificial intelligence systems will be unable to assume greater responsibilities.
More advanced agents are already capable of executing sequences of tasks and making technical decisions within defined boundaries.
Over time, that autonomy may increase.
Perhaps future systems will be capable of planning, implementing, and validating complex projects with much lower levels of supervision.
But the ability to execute a task does not automatically eliminate the need to determine which tasks are worth executing.
Or which technical, creative, and practical compromises are acceptable.
In game development, this is especially important.
Because creating an experience is not merely about solving mathematical problems.
It also involves making creative decisions.
Determining how something should look.
How it should respond to player input.
What level of difficulty it should provide.
And what sensations the player should experience.
Artificial intelligence can participate in these decisions.
But creative direction and responsibility for the final result remain fundamental considerations.
---
CHAPTER 14 — THE FUTURE OF MODDING AND GAME ENGINES
For decades, the limitations of a game engine determined much of what developers could produce.
But the history of modding demonstrates that these limitations are not necessarily permanent.
A community can investigate a technology.
Document its functionality.
Reconstruct its components.
And develop new applications.
Projects such as the Skate 3 Rust Engine demonstrate the value of years of reverse engineering combined with modern programming tools.
GTA San AnSkateas demonstrates how a reconstructed implementation can be adapted to another game.
Reprise Eagle Skateboard represents the strategy of creating original systems to expand the capabilities of an existing architecture.
And projects such as OpenGOAL, Zelda 64: Recompiled, and OpenMW show that there are different approaches to preserving, adapting, and reconstructing older technologies.
Each has its own challenges.
But together, they reveal a trend.
The modding community is expanding its role.
From modifying content to developing tools, systems, and execution technologies.
Artificial intelligence may accelerate this transformation.
But it will not be solely responsible for every discovery.
Some developers will continue working without AI.
Others will use it as an assistant.
And some may build highly automated development processes.
The decisive factor will not simply be which tool was used.
It will be what each project actually managed to build.
---
CONCLUSION — ARTIFICIAL INTELLIGENCE IS NOT THE END OF HUMAN CREATIVITY
There is a growing belief that, in the future, anyone will be able to create virtually any software simply by describing what they want.
Perhaps development tools really are moving toward increasingly advanced levels of automation.
But the projects we have examined demonstrate that there is a difference between imagining a feature and understanding what is required to build it.
The reverse engineering of Skate 3 did not begin with artificial intelligence.
It began with developers investigating a complex piece of software.
GTA San AnSkateas demonstrates what can happen when that accumulated knowledge becomes reusable technology.
And Reprise Eagle Skateboard demonstrates another path: using existing games as references to develop original systems adapted to a completely different architecture.
Three stories connected by the same principle.
The ability to transform knowledge into technology.
Artificial intelligence is changing the speed at which parts of this work can be completed.
But speed does not automatically mean quality.
And automation does not mean the absence of engineering.
A skilled operator is not simply someone who knows how to write elaborate prompts.
It is someone who can understand a problem, establish an objective, evaluate alternatives, and recognize when a solution genuinely works.
That ability can be amplified by artificial intelligence.
And perhaps that is where one of the greatest revolutions in modern development truly lies.
Not simply making programming faster.
But allowing independent developers to explore projects that previously would have required significantly greater resources.
The future of modding may involve reconstructed engines, shared systems, intelligent tools, and classic games transformed by modern technology.
But behind every project, there will still be a fundamental question.
What do we want to build?
Because artificial intelligence can help discover ways to execute an idea.
But the ability to identify possibilities, challenge limitations, and imagine new experiences remains one of the driving forces behind the modding community.
And as long as developers are willing to understand how games work, there will always be people trying to discover how to push those games even further.
The future of modding will not be defined solely by the power of its tools.
It will also be defined by what their creators are capable of achieving with them.
END.