GTA VI, AI, and the future of games: who will create, modify, and preserve what we play?

Editorial note: research completed on October 21, 2026. Information about products and projects reflects the sources consulted on that date. The architectural examples and development situations presented throughout the article are analysis and illustrative scenarios.

When I see the anticipation surrounding GTA VI, I think about two things at once: wanting to explore that world as a player, and the work needed to make it all function as a developer. The street, the car, the lighting, and the people appear on the screen. The thousands of decisions that support the experience remain hidden behind it.

That hidden side is exactly what connects most closely with my work. I develop systems, work with integrations and automation, and also create games with Unity. I was already developing a skateboarding game back in 2017; today, with a small team and AI tools, I can consider possibilities that would once have been very difficult to sustain on my own.

That makes me more curious, but it also changes the questions I ask. How much of this work does AI actually help us do? What happens when it gains tools to investigate programs that have already been compiled? Can we bring more console games to the PC? And who will make sure they remain playable when today's hardware, stores, and servers no longer exist?

This conversation brings together GTA VI, PS5 jailbreaking, REA, recompilation projects, characters that hold conversations, and worlds generated by models. They are related subjects, with important differences between them. Understanding those differences helps us see where the opportunities lie for players and developers alike.

My expectation is that more people will be able to create, investigate, and adapt games. The outcome will depend heavily on how those people define quality, organize their work, and verify what they have produced. AI can greatly increase our capacity to make things. Choosing which things deserve to exist remains a very human part of the project.

1. GTA VI as the starting point for a bigger conversation

When consulted for this article, the official GTA VI page announces a November 19, 2026 release for PlayStation 5 and Xbox Series X|S. PC does not appear among the platforms listed on that page. That is the confirmed information I use as a reference.

There is also a relevant statement about AI. According to a GamesIndustry.biz post about its interview with Strauss Zelnick, the executive said generative AI plays no part in what Rockstar is building in GTA VI. The scenarios discussed here therefore concern the industry's future.

A large open world is an excellent place to start this discussion because it brings together problems from almost every area of development. There are visuals, physics, character movement, the interface, audio, missions, and progress storage. Everything needs to work together while the player does things someone probably hoped they would never try.

Imagine a hypothetical mission in which you have to meet someone at a restaurant. The player decides to arrive in a truck, park sideways across the entrance, and run off in the opposite direction. The project needs to decide what happens to the meeting, the traffic, the people nearby, and the objective. The freedom offered to the player becomes an enormous range of situations for the developer to consider.

That is why I am cautious about the idea that generating more content means producing a better game. A tool can create a hundred different building facades while leaving unanswered why the player should visit that street. It can invent fifty conversations without building a single interesting relationship. It can design a gigantic map whose main activity is rushing across it.

Quantity is easy to show in a presentation. The quality of the experience becomes apparent when someone plays, fails, keeps trying, discovers a possibility, and wants to continue. To me, that is a much more useful criterion for evaluating how AI is helping a project.

There is also a curious effect when we compare ourselves with enormous productions. An independent developer might conclude that they need to build an entire city to take part in this evolution. I prefer to look at problems within a small team's reach. An interesting combat system, a well-developed building mechanic, or a short experience with personality already requires enough decisions to keep plenty of people busy.

A smaller game can also explore ideas that might struggle to find room in a production of a different scale. It can have an unusual rule, local humor, an unconventional visual direction, or a length designed for a single evening. Making elements easier to produce only becomes an advantage when it serves a recognizable vision.

GTA VI, then, serves as a window into this discussion. It focuses attention on what we expect from a game and on the distance between the visible experience and the engineering that supports it. From there, we can ask how new tools change the work of people building very different experiences.

And we can do that without turning the wait for release into a list of imaginary features. A useful exercise in thinking about the future begins by distinguishing what has been announced, what has already been demonstrated in another context, and what we are proposing as a possibility.

2. A game is a system of promises to the player

Working with software, I find one question particularly useful: what does the system promise to do when someone takes an action? In a game, that question comes up constantly. When players press a button, they expect a response. When they store an item, they expect to find it later. When they learn a rule, they expect to be able to rely on it next time.

That trust can be built with very simple rules. Think of a hypothetical tower defense game: enemies follow a path, towers attack, and the player manages resources. Before adding a complex story or a city full of characters, we already need to decide when an attack lands, how damage is calculated, which target takes priority, and what happens when multiple effects overlap.

An ice tower reduces speed. Another applies poison. An enemy resists ice but continues taking poison damage. It seems like a small situation until someone asks whether two slowing effects stack, whether resistance applies before or after a bonus, and whether damage continues during a disappearing animation.

Players may never see those questions written down. Even so, they feel the answers. When two seemingly identical situations produce inconsistent results, they begin to distrust the rule. When they can understand the logic and try combinations, they start making better decisions. Consistency becomes part of the fun.

In business systems, we have similar concerns about records, inventory, prices, and the state of an operation. A screen reporting success needs to correspond to something that actually happened. An integration that accepts an order must account for retries, failures along the way, and delayed responses. In a game, we also need to know which changes have happened and which are still pending.

Imagine that a game saves the inventory and then closes before recording the level state. When it opens again, the player might have an item from a mission the game considers unfinished. Now imagine that an update changes the inventory structure and older saves stop loading. These are invented examples, but they help reveal how much work happens far from the visual side.

This is where integration experience connects so well with game development. We need to define contracts between components. The combat system reports an outcome; the interface displays it; audio responds; the save system records what should persist. When each part assumes something different, the defect shows up across the whole experience.

A thoughtful architecture helps assign those responsibilities. If the interface also decides damage, if animation controls the balance of resources, and if conversation text creates items directly, any change risks affecting distant parts of the game. The project starts depending on the memory of whoever wrote everything and a good deal of luck.

AI can speed up the implementation of each component. To benefit from that gain, I want to be able to explain how they connect. I want to know which part decides the actual state of the game, which merely displays that state, and which depends on an external service. I also want to be able to replace a piece without rebuilding the entire game.

That applies to a new project and to an attempt to recover an old one. Making a level appear on screen is a real achievement. The evaluation continues when the character changes areas, receives two events at the same instant, loses the connection, loads a save, and closes the application. Quality lives in those transitions too.

That is why I like to think of a game as a collection of promises. Some are explicit, such as saving progress. Others are felt, such as the sense that a control always responds in a similar way. Any tool involved in development needs to help fulfill those promises.

3. The different kinds of artificial intelligence in the same conversation

The phrase “AI in games” can describe very different kinds of work. Sometimes we mean an enemy's behavior. At other times, a tool that assists the programmer. We might also mean image generation, voice, testing, or a model that tries to simulate an interactive environment.

Putting everything into a single category makes evaluation harder. An improvement in texture production does not demonstrate that characters have learned to converse. A good dialogue does not prove that the system knows how to complete a mission. And a tool capable of explaining a compiled function still needs to demonstrate what it can reconstruct from it.

A practical distinction helps:

Use	What it can do	The question I would ask
Game behavior	Choose paths, targets, and reactions within rules	Can the player understand and respond to this behavior?
Development assistance	Help write, explain, and review parts of the project	Has the result been integrated and verified in its real context?
Content production	Propose images, text, sounds, and variations	Is it artistically coherent, useful, and properly licensed for use?
Agents with tools	Examine files, run analyses, and track tasks	What evidence supports the conclusion, and which actions are permitted?
Generative characters	Converse and propose actions in context	Does the response respect the game's state and limits?
World models	Generate interactive sequences of an environment	What consistency exists beyond the seconds shown?

This table is a conceptual framework for the discussion. The categories can overlap, and each project chooses a different combination. There is no obligation to put all of them into the same game for it to feel modern.

Traditional character behavior remains valuable. A state machine can organize actions such as patrolling, pursuing, and retreating. Pathfinding can calculate where a character can go. These solutions make it possible to build precise, predictable challenges for the person designing the experience.

A boss, for example, can become more interesting when its moves follow patterns the player learns to recognize. If every attack changed because of a decision that was difficult to anticipate, the battle might feel unfair. The choice of technique needs to serve the kind of enjoyment the game is meant to offer.

Procedural generation also deserves its own place. Rules and combinations can produce maps, place objects, and vary encounters without a language model. A deterministic system, when configured that way, also offers the advantage of reproducing a generation from the same seed and parameters.

A programming assistant, meanwhile, operates mainly in the creation process. It can help investigate a bug or propose an editing tool. That does not imply that the released game will need to communicate with an AI to function. It is possible to use extensive assistance during development and deliver an entirely local experience.

That difference changes cost, maintenance, and preservation. If AI helps create a file that later becomes part of the game, that file may function independently of the service used to create it. If an essential gameplay decision requires a remote request every time, the service's availability becomes part of the experience.

I like this distinction because it brings the conversation back to concrete decisions. We can ask where the tool saves work, where it introduces a dependency, and where it needs review. That makes it easier to choose a useful application and explain to players what they are getting.

With these differences in mind, we can move into one of the areas attracting the most attention right now: using agents to investigate existing software, including games whose original code is not publicly available.

4. Reverse engineering: looking inside a game

When we play, we see the result of thousands of decisions: the character responds to the controller, the door opens, the music changes, and the enemy notices us. Someone investigating the program from the inside needs to follow the path in reverse. They start with those effects and try to discover which rules, structures, and dependencies produced them. It is a process of observation, hypothesis, and comparison, often with incomplete information.

That matters to game developers, but also to anyone maintaining an old system. Imagine receiving a program that an organization depends on, with inadequate documentation and behavior nobody can fully explain. Before replacing anything, it would be prudent to discover what that thing actually does. In games, the challenge adds physics, animation, audio, and a community capable of noticing that a jump feels subtly different.

A few terms help us follow this conversation without turning the article into an assembly lesson:

Term	What it seeks to do
Reverse engineering	Investigate how a system works through what can be observed and analyzed.
Disassembly	Represent machine instructions in a low-level language readable by specialists.
Decompilation	Reconstruct a higher-level representation from compiled code.
Static recompilation	Translate code ahead of time so it can be compiled for another environment.
Emulation	Reproduce the platform behaviors required to run the program.
Port	Adapt a product to a target platform, including its dependencies.

These words describe activities that can overlap. A project might analyze the binary, reconstruct some functions, translate others, and reproduce services the console provided. The final product can use several of these techniques without fitting neatly under a single label. That is why discussing only whether a particular effort “is emulation” often obscures the more useful question: which parts were adapted, and how was the result verified?

Ghidra, maintained by the NSA, brings together disassembly, decompilation, graphing, and scripting tools to analyze compiled programs. That infrastructure helps examine evidence; interpretation still depends on context.

A fundamental difficulty appears when we confuse decompilation with recovering the original project. During compilation, much information can disappear: names chosen by the programmer, comments, file boundaries, and structures the compiler reorganized. Two different pieces of code can produce equivalent instructions. Finding a plausible reconstruction therefore does not mean discovering exactly what was open on the developer's computer.

Consider a hypothetical racing example. The car slows near a bend, and a function appears to adjust its speed. The first interpretation might be “this controls braking.” But that same function could receive values from a steering assist, a collision, or a cinematic sequence. Changing its behavior without investigating those relationships might improve one corner and break three other situations.

There is also a difference between understanding a rule and deciding to change it. If a particular jump depends on a calculation quirk, preserving it might be necessary to maintain the original feel. Fixing it might be desirable in a modernized edition. Both decisions can make sense, provided they are deliberate and match the project's goal.

That is why reverse engineering has an almost archaeological dimension. The researcher encounters elegant solutions, limitations of the time, and improvised fixes that acquired a purpose over the years. The work requires respecting what exists before concluding that you could do better. For anyone planning to use AI in that investigation, this attitude is especially important: a convincing explanation must remain open to the possibility that it is wrong.

5. Recompiling for PC is already a reality—and it does not always involve AI

Seeing a game associated with a console running well on a computer creates the feeling that someone has opened a secret passage. Behind it, though, are contracts that still need to be fulfilled. The program expects certain data formats, services, hardware responses, and timing behavior. Translating instructions solves part of that conversation; adapting the rest requires its own work.

N64Recomp transforms Nintendo 64 binaries into C code, using symbols and metadata to guide the translation. Its output depends on a runtime that provides the functionality required for execution.

Here, runtime can be understood as the infrastructure that handles requests from the translated code. Imagine moving a team to another building: changing everyone's address does not guarantee that the phones, files, and internal processes will work. In software, this work includes discovering which expectations remain valid and which need a compatible implementation. The translation becomes useful when the environment can support it.

Zelda64Recomp applies this approach to Majora's Mask, uses RT64, and requires the original game without distributing its assets. The team expressly states that it does not use generative AI and rejects contributions that use it.

That position deserves to be stated plainly. Identifying the techniques used gives proper credit to the community's work and avoids confusing automation with generative AI. Automation, compilers, and analysis tools have histories of their own. A serious discussion of the future needs to acknowledge those foundations and credit the people who built them.

For Xbox 360, XenonRecomp converts executables into C++ but warns that it does not provide a runtime: making the game function remains the responsibility of the project using it. That limitation prevents treating the tool as a ready-made universal converter.

UnleashedRecomp makes the process tangible: it is an unofficial Windows and Linux port of the Xbox 360 version of Sonic Unleashed. It uses XenonRecomp for PowerPC code and XenosRecomp for shaders, converted to HLSL. Game files must come from the user's legally acquired copy.

It is worth paying attention to that separation between CPU code and graphics work. A game can make decisions correctly while still drawing incorrect shadows, displaying broken materials, or synchronizing its animations poorly. It can also produce a perfect image and fail to load a save. Compatibility needs to be considered as a collection of behaviors, with separate criteria for each part.

Another approach appears in OpenGOAL, which reconstructs the GOAL language environment and provides native x86-64 ports of games in the Jak and Daxter series. The project began in 2020 and, when consulted for this article, considered the first three games playable.

What makes this example interesting is the breadth of the problem. Sometimes preserving a product means recovering the conditions needed to continue working on it: language, tools, formats, and possibilities for modification. A community becomes able to correct behavior and experiment with new ideas. Preservation becomes more valuable when the knowledge remains understandable to the next person who arrives.

That also explains why “it ran on my computer” is an initial milestone, not a certificate of completion. In a hypothetical scenario, a port works for an hour but fails when loading an earlier chapter or switching controllers. Another maintains sixty frames per second while changing the speed of an important animation. The player encounters these problems in the most costly way: after trusting the product.

AI can help investigate and fix situations like these. The size of its contribution depends on the project, the available tools, and the quality of validation. Successful recompilers demonstrate that concrete technical paths exist; turning each new release into a reliable port still requires an individual assessment.

6. REA: when the agent gains tools to investigate

An interesting change occurs when AI stops depending solely on a description someone typed. An agent equipped with tools can look for evidence, form a hypothesis, run a check, and return to the investigation. That brings the conversation closer to a working process. Quality depends as much on the questions as on the ability to check the answers.

REA, short for Reverse Engineer Anything, connects agents to tools for analyzing binaries, applications, and behavior. It can integrate Ghidra, Hopper, or IDA capabilities. It is an investigation interface with MCP and a CLI; it does not automatically turn any game into a finished port.

For someone who works with integrations, that proposition is familiar. Connecting systems allows an existing capability to become part of a workflow that previously required manual intervention. But the connection needs to carry enough context for the response to be interpreted correctly. Receiving a value without understanding its unit, origin, or conditions of validity is an excellent way to automate the wrong conclusion.

As a hypothetical example, imagine investigating why an enemy gives up a chase. The agent finds a comparison involving a distance and suggests that it has identified the vision limit. Renaming the function, changing the number, and celebrating would be tempting. First, it would be better to discover what calls it, which states it runs in, and whether that distance represents vision, navigation, or separation between map regions.

A productive investigation would keep those possibilities open until it had enough evidence. It could compare similar situations, look for references to the same data, and check the hypothesis against observable results. If a contradiction appeared, the next step would be to revise the interpretation. The record of discoveries should make clear what was observed, what was inferred, and what still needs confirmation.

In the official DX-Ball case study, REA presents the reconstruction of a sound-panning function: 3,205 cases compared against the original x86 and a match for all 63 compiled bytes. The October 7, 2026 checkpoint still described the full game as work in progress.

That kind of focus allows us to ask useful questions. Which function was reconstructed? Which inputs were compared? What fell outside the test? The demonstration's modest scope helps us evaluate its merit by distinguishing a verifiable achievement from a conclusion about the entire program. Finding one correct piece can be important progress without requiring anyone to announce that the puzzle is finished.

Tools like these also change how effort is divided. The human can focus more attention on selecting problems, defining criteria, and reviewing discoveries that affect the whole project. The agent can explore relationships and prepare hypotheses that would take time to assemble manually. This distribution works best when every advance has a justification another person can examine.

There is also a practical question of memory. A long analysis produces a lot of intermediate knowledge, and not all of it should remain in one enormous conversation. Recording decisions with evidence, keeping uncertainties explicit, and organizing discoveries by subject helps work continue. That benefits a human team, a team with agents, or any combination of the two.

A good note might say, for example, that a particular hypothesis was observed in one specific version, in two situations, and has not yet been examined in the others. That sounds like bureaucracy until someone spends an afternoon trying to reproduce a result in a different file. Useful documentation makes the reasoning repeatable. It preserves the path to the conclusion, including the questions that remained open.

The name “Reverse Engineer Anything” is an ambitious introduction. Evaluating a project requires getting down to specifics: supported formats, connected tools, known limitations, and demonstrated results. For a developer, that is exactly where the opportunity lies. A good integration can remove enough friction to make an investigation viable when it would otherwise remain on a list of ideas.

7. The test that separates a reconstruction from an imitation

There is a dangerous moment in any software project: when the demonstration starts looking good before the behavior becomes reliable. The character walks, the camera follows, and the menu responds. Everyone relaxes a little. But those signs can still conceal errors under conditions the presentation did not cover.

In an account published on October 9, 2026, Maurice Heumann described three months of decompiling an FPS with agents. After encountering semantically incorrect code, he reported 99% of functions reconstructed and 83% matching byte for byte. These are the author's reported results; no independent audit was presented.

The case prompts a reflection that goes far beyond games. Readability helps maintain a program, but organized code can still implement the wrong rule. Detailed comments can explain a mistaken decision perfectly. A review needs to compare the implementation with expected behavior, avoiding the assumption that confidence in the writing proves accuracy.

In binary-matching decompilation projects, one form of verification is to recompile the reconstruction and compare the result against the original under controlled conditions. That can provide a very strong reference for the parts being compared. However, interpretation requires care with the compiler, options, references between functions, and other comparison conditions. An isolated percentage does not describe all those details.

Imagine a hypothetical project with a thousand functions, nine hundred of which have passed verification. The number looks excellent, but it does not tell us whether the remaining hundred handle secondary elements or loading saved games. Nor does it reveal whether interactions between already approved functions were exercised. A coverage indicator helps organize the work; to evaluate the player experience, we need to understand the significance of behaviors that remain uncertain. The count can advance considerably while the project remains blocked at precisely the step that allows players to finish the campaign.

We also need to choose what “preserving” means. If fidelity is the goal, a strange behavior in the original may need to remain. If the goal includes fixing that behavior, the change needs to be identified and tested as a decision made by the new project. Mixing reconstruction and modernization without recording the boundary makes it harder to discover where a difference came from.

We can imagine validation in layers. First, small functions receive known inputs and have their outputs compared. Then whole systems are exercised: inventory, combat, physics, interface, and saves. Finally, full sessions look for problems that only appear when those parts are combined. Each layer answers different questions, and none automatically replaces the others.

Consider a hypothetical inventory example. One test confirms that the character can store an item. Others need to check maximum capacity, discarding, transfers between characters, persistence after restarting, and behavior when an operation fails. If the game supports networked play, synchronization and authority become concerns too. The seemingly simple function participates in a much larger set of commitments.

In business systems, the concern is similar: an apparently completed operation can leave inventory, payment, or records in incompatible states. In games, the equivalent might appear as an impossible-to-finish mission, a duplicated object, or lost progress. A beautiful interface does not necessarily reveal those states. Trust comes from investigating the conditions a user may encounter outside the ideal path.

There is room for AI in many of these tasks, including proposing test cases and investigating differences. It is wise, however, to preserve the independence of acceptance criteria. If the tool producing a solution can also freely relax what counts as success, distinguishing a fix from a change to the rules will be difficult. The result must remain verifiable through a mechanism or review that does not merely accept the producer's justification.

That care does not diminish the value of automation. It makes progress cumulative: an approved change can support the next ones, and a regression can be located. For a small team, that predictability is enormously valuable. The opportunity lies in producing, understanding, and maintaining more work without losing the ability to explain why it is correct.

8. The PS5 has been jailbroken. What does that statement actually tell us?

When news appears that a console has been jailbroken, it can feel as though a door has opened and everything now works on the other side. Install any application, modify any game, run any version. The statement is short enough to spread quickly, but it hides questions that make a considerable difference to anyone trying to understand the technical achievement.

The first is the extent of the access obtained. A system has components with different responsibilities and permissions. Being able to run a program in a limited context does not mean controlling every component, just as entering one room in a building does not give you the keys to the other floors. Even elevated privileges do not automatically provide the knowledge needed to interpret everything there.

There is concrete research in this area. The Relapse repository documents a PS5 access chain with version-dependent support and records stability limitations. That does not demonstrate universal game compatibility or automatic transfer to other platforms.

Another part of this landscape is etaHEN, whose documentation presents homebrew, plugin, and debugging features. Homebrew is the term for community-created software for a particular device. An environment that allows such software to run expands the possibilities for experimentation, but each application still needs to work correctly within it.

Consider a simple example. Someone manages to open their own application that draws a square on the screen and receives controller input. That may already represent an important advance for that environment. A complex game, however, will require much more: continuous resource loading, synchronized audio, storage, communication between components, and handling several situations at once.

There is also a difference between demonstrating a possibility and delivering a repeatable experience. One successful run shows that a path worked on that occasion. To turn the experience into something reliable, we would need to understand why another attempt failed, how the system recovers, and which conditions change the outcome. Software developers recognize this work: the first successful run usually opens a new list of tasks.

The environment's version remains part of the equation. Sony's official documentation says some applications or content may require a system software update. The existence of a research environment compatible with a particular version therefore does not establish that it will meet every future requirement.

To me, that is where the most interesting connection with integration work lies. Imagine that a connection to a service has finally returned a response. We still need to verify whether the response is complete, whether the data matches expectations, and whether the process can continue when a step fails. That initial response is a milestone; reliable operation depends on the entire path that follows.

This distinction also improves the conversation about security. A project may have serious documentation, but a file distributed by someone else may not correspond to that project. The name on a page and a professional appearance do not establish the executable's origin. Anyone evaluating research needs to examine what its authors have published and recognize the limitations they themselves present.

There is a legitimate discussion about how much control owners should have over their equipment. At the same time, platforms need to address service integrity, account protection, and the behavior of unknown software. We can examine that conflict without pretending that every objective is the same. Homebrew, research, preservation, game modifications, and content distribution raise different questions.

In the context of GTA VI, that care prevents an enormous leap in reasoning. News about access to the PS5 does not demonstrate that the game could be transferred to PC through that route. Evaluating that hypothesis would require specific evidence about the game itself, its requirements, and a working implementation. Enthusiasm becomes much more interesting when we know exactly which problem has been solved.

9. Why a console game does not become a PC game with one click

It is understandable to look at a modern console and think of it as a computer in another shape. It has a processor, memory, storage, and graphics components. Sony itself describes the PS5 as having an AMD x86-64 CPU. Similarities between components, however, tell us only part of what a program needs to find in order to function.

A game constantly communicates with the environment for which it was developed. It requests memory, reads files, sends work to the graphics card, receives input, and manages sound. Those conversations follow specific conventions. Having a processor capable of understanding a particular instruction does not guarantee that the services the program calls exist, accept the same parameters, or return equivalent results.

Think of two companies that work in Portuguese. One identifies customers by their CPF, while the other uses an internal code; one considers an order complete when it is paid, the other when it is delivered. The shared language helps, but it does not solve the integration. Someone needs to understand the meaning of each piece of information and establish how one process corresponds to the other.

In games, the difficulty also lies in meanings and expectations. A save operation can depend on a specific structure, permissions, and confirmation received in a particular order. Replacing a function's name does not guarantee the same behavior. If the new implementation confirms before finishing the write, the error may appear only when the player closes the program during that interval.

Graphics work adds another layer. A game organizes resources, prepares effects, distributes tasks, and expects them to finish under certain conditions. Reconstructing that communication requires understanding what is being requested and how to reproduce the result in the target environment. A texture appearing correctly does not prove that lighting, transparency, shadows, and memory management have also been resolved.

Then there is time. Imagine a hypothetical game that updates a movement rule according to the number of frames produced instead of correctly accounting for elapsed time. Increasing the frame rate could change the character's behavior. An adaptation would need to identify that relationship and decide how to preserve the experience without simply retaining every limitation of the previous implementation.

This example helps show why measuring speed alone can mislead. A fast execution can produce incorrect results. A working menu can hide problems halfway through the campaign. A visually faithful segment can fail when loading a saved game or moving to another map region. Compatibility needs to be evaluated through behavior as well as the opening image.

There are also dependencies that do not reside entirely on the device. Suppose the client contacts a service to validate inventory, receive missions, or calculate part of a match. Having the local files does not necessarily reveal all the logic running on that server. An AI can suggest hypotheses about that logic, but a hypothesis and a verified reconstruction remain different things.

In practice, the investigation requires organizing evidence. Comparing inputs and results, recording differences, and creating situations that help isolate a problem. If a collision works in one scenario and fails in another, we need to understand what changed between them. Analysis and automation tools can help considerably with this work, provided conclusions are checked against observed behavior.

An AI can speed up the reading of difficult passages, suggest names for structures, or propose adaptations. It can also produce a convincing explanation for something it has misinterpreted. That is why I would evaluate its contribution by the verified work it helps complete. The criterion would be reducing uncertainty and resolving observable differences, rather than simply generating an impressive amount of code.

For someone creating their own game, this discussion offers an immediate opportunity. Isolating platform-specific features, documenting dependencies, and testing target versions during development can reduce later difficulties. These decisions require some early effort, but they offer something valuable: less knowledge trapped in assumptions nobody remembers making.

That is why adaptation and recompilation projects deserve attention for the problems they manage to solve. They show concrete paths with defined scopes. The possibility of extending those paths with AI is interesting, but it needs to be demonstrated case by case. Between understanding instructions and delivering an entire, comfortable, reliable play session, there is a great deal of engineering that the game's launch button does not reveal.

10. An NPC that talks also needs to respect the rules

Imagine an RPG in which you enter a shop and try to persuade the merchant to sell you a sword for half the price. He answers with personality, remembers a previous quest, and even complains about the cost of iron. The conversation seems excellent. Now imagine that after this performance, your money disappears and the sword never reaches your inventory. The character gained charisma; the shop gained a customer service problem.

In this hypothetical example, I would divide the interaction into clear responsibilities. First, one layer interprets the sentence and identifies what the player intends to do. Then it turns that intention into a proposal the game can evaluate: buying a particular item at a particular price, using a particular currency. Language can be flexible; the operation needs a precise meaning.

The next step would be checking the rules. Does the merchant have the sword? Does the player have money, inventory space, and access to that offer? Does negotiation allow a discount, or does the quest require a fixed price? Those answers should come from the systems that control the world, using current information, even when the character's explanation is highly convincing.

Only then would the purchase take place. In the architecture I propose, deducting the money and delivering the item would form a coordinated operation capable of recognizing a repeated attempt. If the connection dropped during confirmation, clicking again should not charge the player twice. That precaution sounds bureaucratic until it happens to your legendary sword, bought with three nights of dedication.

After the operation, the character would receive the result and produce a response consistent with it. If the purchase failed because there was no space, he would explain that; if it succeeded, he could comment on the acquisition. His personality would remain free to vary the way he speaks. The outcome recorded by the game would be the reference for what he can claim happened.

In an online experience, I would keep inventory decisions with the authority responsible for the game session. The client would send the intention, and that authority would validate and record the change. A response generated on the player's computer would not gain the power to create items on its own. The same principle applies to rewards, quest completion, and currency transfers.

This separation also helps us imagine less dramatic errors. The merchant could mention a quest the player does not yet know, reveal another character's information, or promise a discount that does not exist. I would limit the context he receives to what his role allows him to know. Each action would have explicit possibilities, instead of blanket permission to change the world.

Real tools are exploring parts of this approach. NVIDIA describes ACE as a suite for character speech, intelligence, and animation, with local and cloud components. That offers concrete examples of integration. The existence of those pieces still leaves room for architectural decisions of our own.

In June 2026, the company introduced an agent SDK and Unreal Engine plugins, focused on local execution. These are documented references for that ecosystem. They should not be presented as ready-made Unity plugins.

In my view, the choice between local processing and an external service begins with the kind of experience we want. A reflective conversation can tolerate a pause that would disrupt an order given during combat. I would define how long each interaction can wait and what happens when that limit is exceeded. That decision would guide the design before a model is chosen.

I would also account for the full cost. For local execution, I would reserve a processing and memory budget alongside the other systems; for external services, I would estimate traffic, calls, and operational work. I would compare both on the hardware and under the network conditions of the intended audience. A solution that suits the developer's computer still needs to demonstrate that it fits the experience offered to the player.

Behavior without the service deserves an equally clear decision. For this hypothetical merchant, I would preserve a traditional buying and selling interface, accompanied by prepared dialogue. Free-form conversation could become temporarily unavailable without blocking progression. It would be a deliberate product choice: keeping the shop open even when its most sophisticated feature needs a rest.

Finally, I would test situations that contradict the ideal demonstration: an ambiguous request, an out-of-stock item, a repeated purchase, and an interrupted connection. I would observe whether the rules remain consistent and the explanation follows the outcome. An interesting character can surprise us through personality. To feel convincing as part of that world, he also needs to respect the commitments the experience makes to the player.

11. AI-generated worlds: what the demonstrations already show

Demonstrations of AI-generated worlds provoke an understandable reaction: if we can already describe a place and walk through it, how far are we from requesting an entire game? I think that is an excellent question, provided another accompanies it: which parts of that game are we considering finished? Exploring a street, completing a mission, and recovering a saved campaign demand different commitments from an interactive experience.

In February 2025, Microsoft introduced Muse, developed with Ninja Theory. The model was trained on Bleeding Edge gameplay. The research explores generating images and controller actions to support ideation.

In October 2026, looking only at that announcement would be insufficient. The current WHAM project page also presents WHAM-RT, designed for real-time interaction. A September note records the team's and technology's transfer to the Microsoft.AI group.

That evolution deserves attention, but I would distinguish the demonstrated advance from the task I want to solve. For experimenting with a scene's atmosphere, a tool can be very useful without controlling an entire campaign. For building competitive combat, my criteria would differ. I would need to verify whether equivalent actions produce consequences consistent with the rules and with participants' expectation of fairness.

The original WHAM version's model card documents its specialization in Bleeding Edge, potentially incorrect outputs, and Microsoft Research License. Those limitations belong to the version described. Access to the weights also requires observing the terms of use.

In the Genie 3 announcement, Google showed navigable environments generated from text. The company acknowledged challenges involving duration, control, and interactions between agents. Those parameters describe that presentation, without establishing a permanent limit for future models.

Project Genie, introduced in January 2026, brought world exploration to an experimental web prototype. In May, Google announced a global expansion for eligible subscribers and Street View integration. The company continued to characterize it as experimental research.

A useful way to evaluate any demonstration of this kind is to imagine a small, concrete task. I would request a room with two doors, a key, and one rule: the blue door only opens after picking up the key. Then I would try returning to the room, dropping the object, picking it up again, and repeating the route. The question would be whether the consequences remain recognizable after my interventions.

That hypothetical test would still be far from evaluating a complete game. I would add session interruption, progress recovery, a configuration change, and repetition of an important event. I would also observe whether players can understand why they won or lost. My interest would lie as much in the freedom to experiment as in the stability of the commitments the experience makes.

That opens an interesting discussion about authorship. If I generate ten possible streets and choose one, I still need to decide what that street does for the game. Does it guide the player, hide a shortcut, support a chase, or simply fill space? I would use the speed of exploration to compare design decisions, avoiding the temptation to turn visual abundance into an obligation to keep everything produced.

For preservation, I would make an even more careful distinction. Imagine two hypothetical versions of an old racing game: both resemble the original setting, but one subtly changes the car's response in a particular corner. Someone reliving a memory may not notice. For someone studying that version's behavior or comparing times, the difference changes the object of analysis.

That is why I would present a reconstructed experience with a description of the method and its uncertainties. Visual reproduction, artistic reinterpretation, and preserved execution can serve different interests. Before evaluating the result, I would ask what the project intends to preserve: appearance, feel, rules, data, or a verifiable combination of those elements. Naming the objective allows us to value each effort for what it actually offers.

I would also keep examples that allow results to be compared as work progresses. A known route, a sequence of actions, and expected behavior would help explain what changed. In a hypothetical preservation project, those records would form part of the deliverable. Anyone arriving later would have material for investigating differences, including those the first team overlooked.

The future that interests me most allows these approaches to be combined deliberately. One team could explore environments with generative tools and turn the best ideas into a project with explicit rules, directed characters, and verifiable behavior. Another could create experimental experiences in which instability itself is part of the concept. In both cases, the public presentation should match what the experience can sustain.

12. What changes for a small team working with Unity

For a small team, I would begin this conversation far from a gigantic map. I would choose a short experience capable of showing what makes the project interesting. In a hypothetical tower defense game, that might mean an arena, two towers, a few enemies, and a short sequence of waves. The goal would be to play, observe decisions, and identify what deserves development before multiplying content.

I would call this first deliverable a complete sample of the game. It would include starting a session, building, facing the challenge, winning or losing, and restarting without intervention from the programmer. The appearance could be simple, but the central actions would need to work together. That scope would help uncover problems a collection of isolated demonstrations might leave hidden.

In this hypothetical tower defense game, one tower could hit several targets and another deal more damage to a single enemy. One wave would let us observe the choice between those options. If both were equally suitable in every situation, there would be a design decision to investigate. That discovery would guide the next task more clearly than simply producing another ten towers.

At this stage, I would choose one question at a time to guide the AI. Perhaps we need to organize wave configuration, investigate unexpected behavior, or create an editing tool. The request would include the observed problem, the system's intended behavior, and a way to evaluate the change. I would avoid mixing a visual revision, a new mechanic, and a structural reorganization in the same attempt.

The most interesting opportunities may be tools only the team uses. Imagine a panel that lets us compare enemy resistance and tower damage without searching for values in multiple places. Or a routine that finds missing references before a testing session. These are hypothetical examples of small automations whose results can be checked and whose benefits grow as the work repeats.

I would also use assistance to formulate diagnostic hypotheses. If a wave suffers a performance drop, I would ask for possible explanations and ways to distinguish between them. Then I would measure behavior under representative conditions, including outside the editor. The model's suggestion would become a line of investigation; the decision to change the project would depend on what observation revealed.

When planning tests, I would ask for cases that challenge the rules. What happens when two enemies receive their final hit at the same time? When a tower is removed while a projectile is in flight? In a hypothetical project, these questions could reveal ambiguities before the team produced dozens of variants built upon them. The effort would focus on relevant behaviors, with expected results defined by whoever is designing the experience.

File organization deserves the same attention. Unity explains that .meta files store identifiers and information related to assets. References between files depend on that structure. An automated reorganization needs to respect those relationships.

I would keep changes small, recorded, and easy to review. Before accepting a broad change to scenes or assets, I would compare the result and open the affected parts in the project. I would also record the editor version, packages used, and setup procedure. The goal would be to let another person reproduce the environment without depending on the memory of whoever configured it originally.

For localization, assistance could prepare translation proposals, but I would reserve review for context and the interface. An ability with a short Portuguese name might need a different solution in English or Spanish. I would test the text inside the button, description, and situation where it appears. The criterion would be helping the player understand a decision while preserving the game's personality.

I would also separate generating alternatives from editorial choice. If the tool offers twenty names for a tower, someone needs to decide which fits the world, the other towers, and the audience. If it generates an interesting image, there is still a decision about its purpose and visual coherence. That space for judgment deserves its own time in the plan, even when the first proposal arrives quickly.

For me, a good cycle would always end with a playable version. The team would choose an improvement, implement the necessary scope, verify its effects, and decide the next step with the game open. AI could participate in several stages of that process. The project would advance through the quality of decisions incorporated into the experience, at a size the team can understand and continue maintaining.

13. Preserving a game means preserving the ability to play it

Imagine finding a game that shaped your childhood twenty years from now. Its cover is available, there are gameplay videos, and many people still remember it. You can watch what others did, but you can no longer make your own decisions in that world. Part of the memory was saved. The experience that depended on your participation has become inaccessible.

That difference makes game preservation distinctive. A recording can show the path someone chose, but it does not let you try another strategy, fail somewhere else, or discover a detail that went unnoticed. The object of study includes rules, possibilities, and responses. When interaction disappears, the record remains valuable, but it offers a different experience.

A Video Game History Foundation study published in 2023 estimated from a sample that 87% of games released in the United States before 2010 were out of print, using data through April 2023. The finding concerns commercial availability; it does not mean 87% were lost.

That difference deserves care because a copy can exist without being easily accessible. It can also be stored but depend on equipment that is difficult to maintain or services that no longer operate. Keeping files is an important step. Understanding how to run them, documenting their dependencies, and enabling appropriate forms of access adds further tasks.

Consider a hypothetical game that runs locally but requires a response from a server before reaching the menu. When that server disappears, the barrier may be a small check relative to the rest of the program. In another project, almost the entire simulation might happen remotely. Both stop opening, but the difficulty of recovering the experience is quite different.

This distinction helps avoid easy promises about AI. A model can help examine the client and organize clues, but it cannot turn nonexistent information into reliable documentation. If part of the experience was never present in the available files, we will need to find other records or acknowledge the gaps. Inventing plausible behavior can produce an interesting recreation, but it needs to be described as a reconstruction choice.

Less conspicuous details also carry a game's identity. A save format, controller response, animation rhythm, and input timing can change how playing feels. A visually similar version is not automatically equivalent for every purpose. For historical research, some differences can matter as much as appearance.

At the same time, preserving does not have to mean preventing improvements. We can imagine an edition with accessibility options, modern resolutions, and reference tools, accompanied by clear documentation of the changes made. The point is to let people understand what they are experiencing. An improvement becomes more valuable when its relationship with the previous version can be examined.

In its June 16, 2026 response to Stop Destroying Videogames, the European Commission did not then propose a legal obligation to keep games playable. It announced dialogue through the end of 2026 toward a shutdown code of conduct. The initiative therefore did not become a universal legal guarantee.

As a developer, I think it is productive to bring the question to the beginning of a project. If the connection drops, what keeps working? If an API is discontinued, which features are affected? If the team needs to stop operating, is there a way to preserve the essential part of the experience? These are architectural questions with cultural consequences too.

An offline mode can be viable for some projects and unsuitable for others. Even when preserving everything is impossible, separating dependencies can prevent a secondary service from interrupting functionality that does not need it. Documentation, organized copies of production materials, and knowledge of licenses also help. None of these measures resolves every obstacle, but each reduces a dependency that would otherwise need to be rediscovered later.

This care connects directly to systems and integrations. The greater the dependence on a vendor, the more important it becomes to understand what happens when that vendor changes its operating terms. In games, the consequences can extend beyond a company's operations and affect an experience thousands of people would like to revisit. Thinking about that future while we still have access to the code and the team seems a very reasonable responsibility.

14. Technology advances; rights remain part of the project

A tool capable of analyzing a game does not, by itself, grant permission to publish everything it can produce from it. Access, transformation, and distribution raise different questions. Buying a copy resolves a purchase relationship; it does not automatically answer the others. That distinction needs to accompany technical enthusiasm from the planning stage onward.

In Brazil, Software Law No. 9,609/1998 provides limited exceptions in Article 6, including backup and certain integration for exclusive use. These should not be summarized as general permission to distribute adaptations. Assessment depends on what was done, the materials involved, and the specific purpose.

A game also contains content beyond its program. Law No. 9,610/1998 addresses copyright and makes various uses of works subject to authorization, with relevant statutory exceptions considered. Releasing a tool under an open license does not automatically make the music, images, and other works it processes open too.

Platform contracts also exist. The Brazilian PS5 system software license restricts reverse engineering, decompilation, and circumventing security mechanisms. This establishes the terms Sony presents. A contractual clause alone does not justify turning any situation into a blanket conclusion about criminal conduct.

For a specific project, it is worth separating the components before making decisions. Which part did the team create? Which part depends on third-party material? Does the result include protected files or only a tool that operates on files supplied by the user? Those distinctions help formulate the right questions, although they do not produce automatic authorization.

The care can begin with simple records: where materials came from, licenses used, permissions received, and changes made. If a project based on third-party works is intended for distribution or commercial use, legal review should consider that particular case. This is a step in defining the product, just like understanding technical requirements and service dependencies.

This subject allows us to advocate preservation and recognize the work of the game's creators at the same time. It also allows discussion of changes to the rules when they hinder culturally relevant uses. The aim is to build sustainable paths for research, development, and sharing. AI's contribution within those paths can be enormous, but the tool's speed does not replace decisions that remain ours.

15. Where I see room for people who develop systems and integrations

Looking at all of this, I can see opportunities that fit my work very well. Some lie in the game the public will buy. Others lie in the tools that help a team produce, test, distribute, and maintain that game. That second group deserves considerable attention.

Think of a team receiving models, textures, audio, and animations from several people. Every file has an origin, version, license, configuration, and some relationship with the others. A tool that organizes that information and finds inconsistencies before publication could save a great deal of manual investigation. AI could help classify materials and explain problems, while objective checks handle formats, references, and limits defined by the project.

I also imagine a diagnostic assistant that receives logs from a testing session and organizes errors by situation. Instead of presenting a huge list of repeated messages, it could suggest groups of causes and indicate which evidence needs examination. To work well, it would have to preserve the original records and let the team check each hypothesis.

Another avenue is localization. Translating an interface involves screen space, context, proper names, plurals, controls, and text that appears at specific moments. A useful tool could connect every sentence with the place it appears, show differences between versions, and collect questions for human review. A translated file becomes much more valuable when accompanied by the context needed for approval.

Then there is organizing delivery. A release can contain the right code and the wrong files. It can be sent to the wrong platform, use a test configuration, or include outdated text. Anyone already working with automation recognizes this kind of problem: many small steps, dependencies between them, and opportunities for error when everything relies on someone remembering the sequence.

I would treat these possibilities as product hypotheses. Before building a large service, I would talk to teams, observe a real routine, and look for a frequent task with a verifiable result. Then I would make a small version that solves that problem from beginning to end. The benefit would need to show up in the work of the person using the tool.

The same logic can extend to education and training. An interactive simulation can help someone understand a process, try decisions, and observe consequences. AI could adapt explanations; the system would remain responsible for the rules and content quality. For local uses, I would also consider operation with limited connectivity and interfaces that do not require familiarity with games.

What attracts me to these possibilities is the combination of fields. Game development brings interaction, immediate response, and experience. Systems bring organization, consistency, and maintenance. Integrations connect components that began separately. AI can help us move through those stages, provided the work it needs to do is clearly defined.

For a small team, choosing a problem of this size can be more productive than starting by promising a platform capable of making any game. Learning becomes concrete. We can watch someone use the result, observe where they still get lost, and decide the next adjustment based on something that happened.

I also like the possibility of creating tools that remain useful after the excitement around a particular model fades. If their value depends on organizing work well and integrating capabilities, we can replace part of the technology without abandoning the product. That autonomy is an architectural choice I would want to preserve.

16. The future I would like to help build

I can imagine at least three paths for the coming years. They can happen simultaneously, in different proportions, and do not need to be treated as predictions with fixed dates.

In the first, tools improve and teams can devote more attention to polish. AI helps investigate problems, prepare variations, and reduce repetitive tasks. The game reaches the public with a clearer vision, fewer unnecessary obstacles, and a team that understands what it is maintaining. That is the scenario I would try to build in my own work.

In the second, production speed grows faster than the capacity for review. Many similar projects appear, along with rushed updates and systems that work only under the conditions of the demonstration. The problem emerges when the player makes an unexpected choice, uses another controller, or tries to continue an old save. The team gains volume and accumulates a debt of understanding.

In the third, new forms of creation broaden the range of possibilities. People can prototype ideas that previously went no further than conversation. Communities document old games more thoroughly. Specialized tools bring together fields that used to work separately. Variety increases because technology serves different intentions, with room for styles, scales, and audiences that do not fit a single formula.

The direction of each project depends on the choices we make during production. How much work can we review? What should function without depending on an outside company? Which parts can be replaced? How will we explain the experience's limits to the player? Who can continue development if the person who knows everything leaves the team?

Those questions seem less eye-catching than a video of an entire world appearing on screen. Even so, they help determine whether that world will still exist when someone wants to return.

When GTA VI arrives, I want to enjoy the experience as a player. As a developer, I will also keep paying attention to the small decisions that make a world convincing: the response to an input, the clarity of a rule, an interaction that works despite an unlikely choice.

And when I think about what comes next, I see room for many people to take part. Those creating a game, those making a tool, those studying an old system, and those organizing the knowledge someone else needs to continue the work.

That future interests me because it combines curiosity with responsibility. I want tools that expand what we can imagine and a development practice that supports what we promise. After all the conversation about the next breakthrough, someone will open the game, press Continue, and expect to find their own save waiting there.