Introducing Lynci - How We’re Automating Game Porting

Game porting is still a surprisingly manual process.

Before a game can run properly on PlayStation, Xbox, Nintendo Switch, mobile, or another target platform, developers need to analyze the project, identify platform-specific problems, modify systems, integrate SDKs, adapt controls and UI, optimize performance, and prepare everything for certification.

A large part of this work follows patterns that we have seen again and again across the games we have ported over the years.

That is exactly why we are building Lynci.

Lynci is our internal game-porting technology that we are turning into a plugin for Unity and Unreal Engine. In the future, we also plan to support custom engines.

The long-term goal is simple:

Make it possible to port a game from A to Z significantly faster, with as much of the process automated as possible.

What is Lynci?

At its core, Lynci is not simply another coding assistant.

Underneath, it uses coding agents and large language models, but Lynci itself acts as a harness around them.

Instead of giving an AI model a single task and asking it to modify some code, Lynci creates and manages an entire porting workflow.

It understands what needs to happen, breaks the work into individual tasks, provides agents with the necessary context and rules, executes changes, verifies the results, and moves through the next steps of the port.

The goal is to automate the workflow, not just individual coding tasks.

It starts with understanding the game

The first part of Lynci is the project scanner.

Before anything is modified, Lynci analyzes the game project and identifies elements that may need to be changed for the target platform.

Depending on the project, this can include areas such as:

• platform-specific code
• unsupported APIs
• input and controller systems
• save systems
• achievements and platform features
• UI and UX
• graphics and performance
• SDK integrations
• build configuration
• certification requirements
• engine-version compatibility

The result is essentially a technical map of the port.

Instead of an engineer manually spending days going through an unfamiliar project and creating a list of potential problems, Lynci can build the initial picture automatically.

From scanning to fixing

Finding the problems is only the first part.

The next step is where Lynci becomes significantly more interesting.

Issues discovered by the scanner can be directly addressed inside the system using our automation layer and coding agents.

But the agents are not operating completely freely.

They work using a proprietary rules system developed from our experience porting games.

These rules describe how specific elements should be implemented, what approaches should be used, what platform requirements need to be respected, and what a correct implementation should look like.

This distinction is important.

LLMs are very good at generating code, but game porting requires much more than generating something that technically compiles.

The implementation needs to follow platform requirements, engine-specific patterns, performance constraints, certification requirements, and lessons learned from real production projects.

That knowledge is what we are gradually encoding into Lynci.

Turning our porting knowledge into software

Over the years, our team has accumulated a large amount of practical knowledge about what actually happens when bringing games to new platforms.

Which systems usually break.

Which architectures cause problems.

Which implementations fail certification.

Which shortcuts create issues later.

Which solutions consistently work.

Historically, this knowledge existed mainly inside the heads of experienced engineers and inside the processes used by our team.

With Lynci, we are trying to transform that knowledge into software.

The plugin itself provides the infrastructure and automation layer.

Our rules system provides the domain knowledge.

Coding agents provide the execution capability.

Together, these components allow us to automate increasingly large parts of the porting process.

Why not simply use a coding agent?

There is an important difference between using an AI coding tool and using a system designed specifically for game porting.

A coding agent can modify code.

But it does not automatically know:

• what needs to be modified across an entire game
• what order changes should happen in
• which platform requirements matter
• which changes introduce certification risks
• how different parts of the port depend on each other
• how our engineers would normally solve a specific problem
• how to verify that the resulting implementation is actually correct

Lynci is designed to provide that missing orchestration and domain context.

The LLM is only one component.

The real product is the system around it.

Built from a tool we use ourselves

Lynci is not being developed as a theoretical AI experiment.

We are building it because we want to use it ourselves.

Our team already works on ports, remakes, remasters, optimization, certification, and multi-platform development. That gives us an environment where the technology can constantly be tested against real projects.

Every new project exposes new edge cases.

Every difficult port teaches us something.

Every repeated task gives us another opportunity for automation.

That feedback gradually becomes part of Lynci.

This is also why we believe building the product internally first is important. Before asking other developers to rely on the technology, we want it to be something our own engineers are comfortable relying on during production.

Lynci will be free

The Lynci plugin itself will be available for free.

We are currently preparing it for wider release and plan to make it available through GitHub, as well as the Unity Asset Store and the Unreal Engine ecosystem.

We want developers to be able to explore the technology, understand how the workflow works, contribute to the project, and use its core functionality themselves.

There is one important distinction.

Our proprietary porting rules and knowledge base remain our own IP.

That part of the system contains the production knowledge we have accumulated through years of porting games and is available separately when working with us.

In some cases, access to those rules may also require an NDA.

The idea is therefore to keep the core technology open and accessible while protecting the specialized knowledge layer that makes our production workflow unique.

Where we want to take Lynci

Unity and Unreal Engine are only the beginning.

Eventually, we want Lynci to work with custom engines as well.

The direction we are working toward is a system where a developer can provide a game project, specify the target platforms, and let Lynci handle a significant part of the technical porting workflow automatically.

Scan the project.

Identify the required work.

Create the workflow.

Apply the changes.

Validate the implementation.

Prepare the game for the target platform.

There will always be difficult engineering problems that require human judgment, especially on complex projects.

We are not trying to pretend otherwise.

The objective is to automate everything that does not require that judgment, allowing engineers to spend their time on the problems that actually need engineering.

Sharing what we have learned

For us, Lynci is also a way to share something that historically stayed inside the company.

Over the years, we have learned a lot about bringing games to different platforms.

Instead of keeping all of that knowledge locked inside internal documentation and individual engineers, we want to turn as much of it as possible into a product that others can see, use, understand, and eventually contribute to.

We are building Lynci first and foremost because it makes our own work better.

Now we want to start opening that technology to the rest of the industry.

More details about Lynci, its architecture, supported workflows, and the first public release will follow soon.