Archiving graphics source files and game project files

Archiving game source files: why work disappears

A change of contractor or the loss of a key artist is the most common moment when it turns out that valuable work exists in only one place. Project files, graphics layers, animations, sound, and intermediate versions remain on someone else's drives and accounts.

Formally the work is paid for, but in reality the team loses what it created over months, and continuing the project has to start almost from scratch.

Graphics source files suffer the most — the very things from which scenes, characters, and interfaces are later assembled. They cannot be "reassembled": even a similar result would require new time and investment.

Storing work outside the common perimeter turns a routine rotation of contractors into a threat to the deadlines and budget of the entire direction.

The risk is compounded by the fact that the loss is discovered late. While the team works at its usual pace, no one checks where the working versions are and who has access to them.

When the contractor leaves, it turns out that some materials were not exported, some are in a format that no one can open, and some exist in a single copy without backups.

We close this vulnerability at the process level: we set up archiving of game source files so that the set of work remains with you, not with the contractor.

A clear folder structure, regular exports, backups, and a description of what is included in each archive make the project independent of who is currently working on it.

As a result, a change of contractor no longer means a restart, and the loss of source files does not turn into a loss of investment. The direction gets its work under control, and a new team enters the project using ready-made materials, not memories.

What the client gets from order in project files

A game project lives longer than it seems at the start: contractors change, funding pauses happen, the team switches to another product and returns to the previous idea months later.

It is the order in project files that determines what such a return will cost — a couple of days or months of digging. Here is what the client gets when graphics and code source files are arranged on shelves rather than dumped into one folder.

• Continuing development without reassembly. A new team or new contractor opens the project and immediately works, instead of spending the first week understanding someone else's structure.
• Preservation of graphics. Layers, layouts, animations, and materials are stored in an understandable form — they can be reused in an update, sequel, or port to other platforms without redrawing from scratch.
• Predictable development budget. It is clear what has already been done and what remains: estimating new functionality relies on facts, not guesses.
• Protection of investments. Everything you have already paid for does not have to be paid for a second time after a change of contractor or a forced pause.
• Fast return to the project. Even if development was stalled for a year, the working version is assembled in a matter of days, not restored from memory.
• Transparency for management and investors. It is clear what the product consists of and what state it is in — this is calmer for both planning and conversations with partners.

We establish such order taking into account how the project will develop further: the archive structure withstands changes of contractors, updates, and long pauses.

Checking the result is simple — ask any new specialist to open the project and name the timeline for the next revision.

Archiving formats: what suits you specifically

The choice of archiving format is not a debate about tastes, but a question of who and how will use the source files further.

Some need quick access to the graphics archive for edits, some need compact backup storage of the project for years, and some need neat transfer of source files to a contractor or new owner. Below are formats for typical client tasks.

If the project is alive and edits are ongoing, we bet on storage with version history — large studios use Perforce for this.

For handing over the game to a client or contractor, we assemble a separate set: a clear folder structure, a description of contents, and an integrity check so that the recipient can open the archive without our help.

Backup storage of the project always goes in at least two copies in different places — so a single failure does not turn into the loss of a year's work.

How work on the project proceeds: step by step

We guide the project through clear stages so that you have no unclear areas: you always know what is being done now and what will happen at the next step. Below is the path from the first conversation to the moment when the archive is with you and can already be used.

1. Brief and review of materials. We discuss what the game is, what work exists and in what state: graphics, sound, scenes, texts, project files. We immediately note what is critical to preserve and what does not need to be transferred.

2. Plan and approval. We show the structure of the future archive, the order of work, and timelines. You approve the plan before the start — edits at this stage are free for you in meaning, because it is cheaper to agree in advance than to redo.

Hmm — "free" — prohibited? It is prohibited to promise free work/consultation. Better to remove. Rewrite step 2: We show the structure of the future archive, the order of work, and timelines.

You approve the plan before the start, so the result matches expectations rather than being discovered at the end.

• Collection of work. We collect files from all sources: work machines, drives, correspondence with contractors, old builds. Nothing is lost along the way — we check each item against the list.

• Review and organization. We arrange materials according to the project's logic, remove duplicates, and give clear names. Both a new artist and a contractor a year later will understand the archive.

• Verification and handover of the archive. We run an integrity check so that files open and are not corrupted. We hand over the finished archive to you with a description of the structure and access.

• Support after handover. We stay in touch: we answer questions, help with access, and add new materials to the same structure. Many clients return with sequels and updates.

You do not need to understand the intricacies of storage — you receive an organized archive and a clear procedure for working with it.

What will be included in the delivery: a kit for your team

Graphics source files and project files are an asset that will survive both a change of contractor and a change of technology.

We assemble it so that a year later any of your employees or a new contractor can open the archive and immediately understand what is inside and how to use it. Below is what exactly you receive along with the project.

• Archive kit — graphics source files, models, animations, project scenes, and working files, arranged by projects and stages.
• File inventory — a table with the name, version, purpose, and modification date of each file: the needed item is found in minutes, without correspondence with the contractor.
• Archive documentation — a short guide: how to open, what tools are needed, what is connected to what, and in what order to look.
• Delivery contents — a list of archive sections with a note on what is included in the base kit and what is added at your request.
• Access to work — rules for granting rights: which of your employees and contractors, to which folders, and for what period receive access.
• Backups — the archive is stored in two independent places, so a failure of one medium does not turn into the loss of the project.
• Handover regulations — a step-by-step instruction on how to accept the archive, check completeness, and pass it on: to a new team or to your own storage.

As a result, you receive not a one-time export, but a working kit that can be used without us: update the project, connect new contractors, and calmly pass checks.

Case study: how a studio regained access to its work

The studio «Тёплый ветер» was running several game projects in parallel, and graphics source files were scattered: some on the work server, some on artists' personal drives, some in correspondence.

When the lead artist left the team, fresh versions of characters and animations could not be found, and the new project had to be assembled from old work. Production stalled, and the game's launch timeline slipped.

We sorted through everything that was preserved: we consolidated source files and project files by projects and stages, removed duplicates and corrupted copies, and marked which version of each scene is current.

Then we built a unified catalog with a clear structure and set up regular archiving so that the story would not repeat on future projects.

What the client received

• access to the work of four projects was restored in 6 working days instead of months of manual searches;
• questions like "where is the final version" within the team decreased almost threefold — artists returned to work, not to correspondence;
• an archiving procedure appeared: new materials are stored by the same rules, and loss of access no longer blocks the project;
• the timeline for the nearest launch shifted by days, not weeks.

The client's feedback was short: "Finally, we know what we have and where it is." Six months later, the studio returned to us for archiving two new projects — that is the main result of the work.

What if we have our own formats and strict requirements?

Own formats and strict internal rules are not an obstacle. This is usually exactly what the workflow of a studio with history looks like: its own catalog structure, its own extensions, its own access procedure.

We do not rework this to a "standard," but integrate into your logic — so the archive remains understandable to your team, not just to us.

Before starting, we discuss uncomfortable points: where the source files are, who owns the data, what to do with intermediate versions and working edits.

Separately, we check the result: we open a sample of files of different types and confirm that the source files are readable and that the connections between the project and graphics are not lost. The result is an organized archive that your team accepts, not a "black box."

Doubts before ordering: we answer directly

Before ordering source file archiving, a manager usually has two fears: "we hand over the materials — we lose control" and "what if the copy turns out to be unusable a year later." Both are closed not by promises, but by the design of the process: clear acceptance, recovery verification, and fixed responsibility of the contractor for the result.

We fix the composition of materials, storage conditions, and access procedure in the contract — you always know what is where. Below we briefly answer the doubts that come to us most often.

Who is responsible if materials leak?

Only assigned engineers have access, and work is carried out under a confidentiality agreement. Responsibility for preservation and non-disclosure is written into the contract — this is an obligation with consequences, not a verbal agreement.

What needs to be decided before the start?

Determine which projects and versions are critical, how often updates are needed, and who on the client side gets access. The rest is our job: we describe the storage scheme and agree it with you before the transfer begins.

Let's discuss your task and come back with a plan

Tell us about the project: what game it is, how many graphics source files and project files need to be preserved, who works with the materials, and what is critical for you — speed, order in versions, or access for the team.

We will ask clarifying questions and come back with a project estimate and a work plan. You can discuss the task at any stage — without pressure on timelines.

After contacting us, you will receive:

• Project estimate: the real scope of work for your archive, without hidden stages.
• Step-by-step work plan: from file inventory to handover of the finished archive.
• Storage scheme: how we will arrange graphics source files, models, sound, documents, and texts so that everything is found a year later.
• Access and version regulations: who sees what, how edits are recorded, and what happens during parallel work.
• Handover format: how you will receive the archive and how your employees will use it.
• Support after start: what we do in the first weeks of cooperation.

To leave a request, a short description is enough: what the project is, what volume of source files, and by what point order in the files is needed.

We will come back with clarifying questions, and then send an estimate and plan — you will only need to compare them with your priorities. If you want to adjust the plan, we will do so before the work starts.