How to license games to AI labs: value, rights and delivery

Ask what the lab needs to do

“Game data” can describe several very different deliverables. Before discussing price, ask the buyer to describe the operation it needs to perform and the result it will evaluate.

These distinctions have concrete research precedents. Google DeepMind's August 21, 2026 account of its games research describes SIMA observing the screen and using keyboard and mouse controls without needing an API or access to the game’s source. Microsoft Research's February 19, 2025 Muse article describes training on paired gameplay visuals and controller actions from Bleeding Edge. Those are research examples, not purchase orders for your catalog.

A playable build can therefore suit one request while editable project files matter to another. An instrumented environment may require a reliable reset, measurable objective or fast repeated runs. A screen-controlled task may not need a new API at all. Get that distinction into the scope before paying someone to build interfaces.

Read current demand at the level it supports

As of November 15, one game opportunity being qualified through Rightmark prioritizes Unreal Engine 5, following the buyer's November 9 reply. Its earlier questions covered studio-owned assets, maps, Blueprints, build data and employee versus contractor contributions. That tells an Unreal studio what to prepare for this conversation; it does not establish that Unity, mobile or older games have no value.

Keep three kinds of signal separate:

The public Wanted board has no individual request posted at this check. Private qualification conversations can still be active. For a current opportunity, ask for the written requirement, its date and the next selection decision. There is no reliable popularity ranking in these signals.

Write a one-title description

Record a neutral title ID, engine and version, project version, intended route, included material, source-control format, available build, supported operating system, required services and known gaps. State what you own and what must be excluded. “Complete Unreal project” should lead to a description of the maps, Blueprints, code and dependencies, not merely a ZIP size.

Consider an invented planning example: you hold two Unreal projects. One opens on a fresh workstation using permitted dependencies. The other opens only on its original developer's machine because a private plugin is missing. They may look equally substantial in a folder listing, but they require different preparation and cannot yet support the same runnable-package offer.

Keep the studio's business archive separate. Jira tickets, employee chat, customer support, player analytics and gameplay recordings have different contents and rights. Useful development context can be expressly included, but a request for game source should not silently become permission to export those systems. Our code datasets versus RL environments comparison expands the distinction between licensing inputs and supplying an executable environment.

Count distinct packages before counting potential licenses

Make one inventory row for each title and relevant version. Then identify ports, remasters, downloadable content, sequels and shared components. Twenty games using one core engine may contain valuable differences, but multiplying the same shared code by twenty overstates the unique material.

I would keep these fields together:

Rightmark's public game listings illustrate why these fields matter. One older catalog describes about 30 games, mostly Unity. Another describes around 17 game repositories sharing a studio's engine. A separate Unity project has dated private backups rather than Git history. Each needs its own assessment; the existence of several titles does not supply a common accepted unit or price.

Preserve the history you actually have. A dated backup can document a version without becoming a sequence of genuine commits. Record missing periods, migrations, public releases and known AI assistance accurately. A conversion may help the recipient work with a project, but it should retain a traceable relationship to the original system.

Connect every component to the permission it needs

The right to distribute a consumer game and the right to license its components for AI development need separate review. Give counsel and the technical owner a component-level schedule rather than asking them to approve “the game” as one indivisible object.

The current catalog explicitly excludes engine source and various third-party materials from game lots; some also exclude player data and player-made content. Those boundaries are useful preparation instructions, not an independent legal clearance of every file.

An exclusion has a technical consequence. If the missing plugin is essential to opening a map, ask whether the recipient can acquire the required license itself, whether a permitted replacement preserves the task, or whether a narrower deliverable remains useful. Do not send restricted material simply because it makes the project run. If none of those paths works, hold that title.

Choose a pilot that reveals useful difficulties

The following is an invented screening exercise. Every count is assumed to demonstrate the decisions, not a measured Rightmark conversion rate. The three catalogs are independent examples.

Rights-screened here means the hypothetical team has enough evidence to consider the specified pilot, not that all future uses are cleared. A route-fit decision likewise does not mean the buyer has accepted a delivery. Keep the reasons for exclusions and holds alongside the counts.

Choose an ordinary representative project and at least one relevant difficult case: an older engine, a shared dependency, a Blueprint-heavy title or an online feature requiring a controlled substitute. A pilot containing only your easiest projects will teach you little about the rest of the catalog.

Use the companion catalog inventory, rights-and-dependencies sheet and shared-component register to track this work. Ask the buyer whether the selection answers its decision. Expand only after the pilot establishes a useful route and the next group has its own scope. You can appraise the whole catalog while preparing a small, purposeful subset first.

Begin with a relevant reference, not a title multiplier

Start with these four game-related lots in Rightmark's public catalog, checked November 15. They show why a complete game, a studio monorepo and an unsized catalog need different quotes.

The dollar figures above are an ask or an indicative reference, not accepted buyer prices. The two on-request catalogs remain unpriced; averaging the four rows or multiplying the Unreal ask by a title count would conceal the missing scope. Each lot requires owner confirmation before samples and terms.

Indicative estimate, not an offer. Final offers depend on the systems you connect, data size and quality, access terms and due diligence.

The Rightmark Price Index, Q4 2026, published October 26, supplies another reference: $150 to $1,500 per qualifying private repository, per sale, at Medium confidence. That is a code-program benchmark, not a complete game quotation. The index also cites Epoch AI's January 2026 $200 to $2,000 per finished training task, at Medium confidence. Neither number is the studio's automatic payout.

The same Index also gives $10,000 to $100,000+ per premium or task-grade repository, at Low confidence. This is Rightmark's own estimate for repositories that build, pass tests and contain real bug-fix history; the Index says no buyer publishes a per-repository price for that category. CODE-CPP applies that same reference, so its listing is not a second independent market observation. Keep the Index's open-ended upper range separate from the listing's bounded $10,000 to $100,000 reference, then ask what the evaluated package and rights could support.

A finished task needs additional construction and evaluation. A game capable of supporting tasks has not already supplied an agreed number of accepted tasks. If a buyer prices through task yield, request its definition, assessment method and accepted quantity; do not invent a conversion from lines, hours or titles.

Find out why an offer is low

The first useful response to a disappointing quote is a reconciliation request. Which package, rights, quantity and preparation obligation did the buyer price?

Your development budget and store revenue explain the business you built. They do not, by themselves, price the AI rights a lab needs. The current game qualification described earlier also distinguishes game and general-code assessment rather than treating software resale value as the price basis.

There are two different negotiations here. You can challenge a low price for the same usable scope with better evidence. You can also reject a poor offer because it buys broad rights, requires unpaid work or delays payment beyond what the proceeds justify. The valuation guide makes the same practical point: compare scope, costs and payment conditions when considering an exclusive offer.

Work through 20-, 50- and 100-title economics

Here is an invented commercial planning exercise. All selected quantities and offer amounts are assumptions, not forecasts, transactions or multiples of the public Unreal listing. Assume the initial pilots lead to further agreed evaluation, after which 6, 12 or 18 selected titles qualify for the offered bundles. These are later selections, not the initial pilot counts above.

For each row, the exclusive and non-exclusive alternatives cover the same selected packages. Assume a 24-month exclusive term, an 80% owner share under both alternatives, buyer-funded preparation paid separately, no further owner deductions, and taxes excluded.

The formula is agreed consideration for the selected package, less the agreed owner deductions. The starting catalog size is not a price multiplier. In an actual offer, substitute the evaluated selection, actual commercial terms and preparation costs. The blank offer worksheet deliberately leaves those cells empty.

For the buyer, the cost is the full license amount plus separately payable preparation, access, compute or support charges. In the invented $150,000 exclusive example, the $30,000 intermediary share is already within that amount; adding it again would double-count it. The buyer's total is $150,000 plus the separately agreed costs, while the owner's assumed proceeds are $120,000 before taxes.

Put Rightmark's fee and work on the same sheet

Rightmark's current public offer distinguishes two models. On standard licenses, the buyer pays our fee on top and nothing is deducted from the owner's payout. On premium and bespoke deals, owners keep 75% to 85%, agreed in writing before sale. Buyers cover extraction, scrubbing and transfer, with nothing upfront for the owner.

The arithmetic remainder of the premium owner share is 15% to 25% on the agreed base. That does not establish an industry-wide broker rate or the numerical fee for a standard license. For a standard offer, write the buyer-paid fee as an actual quoted amount, B, rather than assuming a percentage: buyer total equals owner consideration plus B plus separately payable agreed costs.

Ask the intermediary to specify its included work: buyer qualification, rights coordination, scope negotiation, preparation management, sample feedback, delivery coordination and settlement reporting. Identify what an engineer, lawyer or specialist preparer will still do. Write down the fee base, payer, payment trigger, extras, repeat-license treatment and any post-termination introduction fee.

Direct licensing can be attractive if you already have the buyer and the staff to manage this work. An intermediary earns its place by resolving useful decisions and coordinating the agreed obligations. Compare that service with its actual price, using the broker-role guide where you need a fuller mandate checklist.

Define the reservation before negotiating its price

Exclusivity can make a valuable package worth more to a particular buyer. To maximize its value to your studio, ask what the buyer wants reserved and what you can keep available. A broad catalog restriction should not slip into a quote for a handful of selected games.

Rightmark's public Unreal early-access lot explicitly offers a copy while the studio keeps ownership and continues selling the game. That is a useful arrangement to discuss, but the eventual agreement must define the rights for your title. “We keep ownership” does not answer whether an affiliate can receive the source or whether the grant reaches future versions.

Ask counsel to examine model and output rights as well as raw-file redistribution. If preventing a competing use is central to the deal, specify the use you mean and ask whether the buyer can accept the restriction. Do not rely on deleting a source copy at term end to undo training already permitted by the agreement.

Compare the exclusive premium with realistic alternatives

Return to the invented 20-title scenario: six selected titles, a $150,000 exclusive offer or a $60,000 non-exclusive license, with an assumed 80% owner share and separately buyer-funded preparation.

The exclusive offer produces $120,000 for the owner before tax. One non-exclusive license produces $48,000. Two completed non-exclusive licenses would produce $96,000; three would produce $144,000, assuming the same terms each time. These are arithmetic scenarios, not a forecast that two or three buyers will appear.

Now consider the differences the simple calculation leaves out. Is the exclusive amount a fixed contractual commitment or conditional on further selection? When is it payable? Would another buyer plausibly want the same package during those 24 months? Does the exclusive scope reserve a valuable shared engine used by other games? Who pays for maintenance and adaptations?

A larger headline can be less attractive if most of it depends on uncertain future acceptance while the restriction starts immediately. Conversely, a strong fixed offer for a narrow, time-limited use can be more valuable than waiting for several speculative non-exclusive licenses.

I would negotiate in this order:

1. Limit the reserved package to the titles, versions and components the buyer needs.
2. Define the AI use and recipient group rather than reserving every conceivable use.
3. Align the start of the reservation with a meaningful commitment, not an indefinite discussion.
4. Price options, extensions, extra titles and substantial support separately.
5. Compare owner proceeds, cash dates and realistic foregone opportunities on that agreed scope.

A short paid evaluation option, a minimum commitment or staged title acceptance may help. These are negotiating choices, not standard Rightmark terms every lab accepts. Non-exclusive licensing can be the better fit when credible repeat buyers exist, future versions remain strategically important, or the proposed restriction is wider than the compensation supports.

Separate lab exclusivity from broker exclusivity

An exclusive license restricts rights in the game. An exclusive broker mandate can restrict who represents an opportunity. They need separate lines in your rights register.

Before approaching another intermediary or closing independently, check existing introductions, named protected buyers, term, termination and any fee tail. Record pre-existing relationships. A non-exclusive data grant does not automatically remove a fee due for an introduced buyer, and a brokerage appointment does not necessarily give the broker authority to grant a lab rights.

If you want to compare routes, describe one project in Rightmark's appraisal, including the catalog around it and the exclusive scope you are considering. The initial appraisal needs no files or system access.

Make each permission cover a concrete action

Start with a non-sensitive description. Move to an inventory or sample under the agreed confidentiality and evaluation arrangements. A bespoke game opportunity can use separate papers or a combined agreement; their wording determines what can happen next.

Code partner routes can differ. Rightmark's Trust page describes a combined confidentiality and license agreement before connection, with later non-exclusive lab licenses authorized by that initial signature. Do not assume every later sale on such a route comes back for another approval. Read the initial grant before using that process for game source.

For a separately scoped pilot, agree the materials, recipients and operations explicitly:

An NDA is not a substitute for checking these operations against the actual grant. Our agreement-permissions guide explains the distinction. Evaluation can be useful and narrow at the same time.

Give the pilot a budget and a decision

Use the pilot decision sheet to name the title and version, intended task, exact sample, exclusions, dependencies, permitted tests, pass/fail criteria, environment, work owner, funding, decision-maker and deadline. Add what happens after a pass, a bounded failure or a decision to stop.

The public Rightmark offer places extraction, scrubbing and transfer costs with buyers. For your game, turn that into a written work scope: who installs a permitted dependency, who repairs an export, who funds compute, what support is included and who approves additional work. A buyer changing the task after the first test creates a scope question, not an automatic obligation to keep rebuilding for free.

You might use an approved copy, an isolated workspace controlled by the owner, or scoped access to an agreed environment. Decide what may leave it and who reviews the output. An executable supplied by a buyer also needs scrutiny: determine what it reads, writes, runs and sends before allowing it near source or live services.

Check who contracts with you and who receives the material. Ask about the intermediary's authority, responsible contacts and any subcontractors. Where references matter, request permission-cleared examples or a reference the intermediary is authorized to provide. A research lab named in this guide is not presented as a Rightmark customer, and a technical demonstration is different from evidence of a completed paid license.

Do not attach the whole project to the first inquiry. A useful next step is agreement on one permitted test and the artifact needed to conduct it. If nobody can name the decision that test will enable, refine the scope before preparing more material.

Preserve the project as it actually developed

For a complete-project route, the deliverable must explain how its pieces fit together. Start with the selected native version, its real history and a dependency list. Preserve an untouched original privately and prepare a separate, identifiable copy.

Git, Perforce, SVN, Plastic or Unity Version Control, and dated backups require different export choices. Agree the format the recipient can use before converting history. If you convert, retain a private mapping to the original revisions and disclose gaps. Do not manufacture commits to make a backup collection appear more complete.

Blueprints, scenes, prefabs, maps and binary assets may carry behavior a text-line count misses. Make sure referenced large-file objects and permitted submodules are present where the delivery requires them. Describe which engine and plugin versions open the project. A current engine upgrade can change behavior and require new work; maintaining a permitted compatible environment may be the more faithful handoff.

Include a README with prerequisites, setup steps, launch or build command, expected result, known failures and what requires separate recipient licensing. Test the delivery copy in the intended environment. The original developer's machine may have cached files, credentials or dependencies that the recipient will never receive.

Decide what cleaning must remove and what it must preserve

Preparation involves several different jobs:

Review more than the latest source tree. Sensitive material can remain in history, comments, paths, author metadata, crash dumps, debug logs, configuration, screenshots or cached exports. Revoke an exposed secret before treating removal from the delivery as sufficient. Do not preserve real credentials inside a “before” example or send them as evidence of a successful cleanup.

Player chat, player-created content, analytics and voice recordings should remain outside the package unless separately scoped and authorized. The same applies to client-specific code and studio business records. The game may run against synthetic or approved test fixtures instead of a production database, provided the buyer agrees that setup serves its task.

Names and identifiers need deliberate treatment. A filename, asset GUID or Blueprint reference can be necessary to open the project. Blind replacement can break it. Keep any reversal map under the owner's separate control, apply consistent transformations where relationships matter, then reopen and retest the prepared project. De-identification reduces particular risks; it does not prove that nobody could recognize a game, a contributor or an event from the remaining context.

Use the current tools for the jobs they actually perform

Repo Check measures a supported Git repository locally. It does not run the project's builds, tests or installers. Its default check is offline; the optional --public-check makes disclosed requests to public archives and registries. Review that choice before enabling it.

Read share.json before sending it. Alongside counts and fixed labels, it carries a short owner-selected label and a repository identifier that someone with a matching copy can recognize. Keep the detailed reports and sensitive locations private. The report can inform qualification, but it is not a game build certificate, an ownership opinion or proof of anonymity. Non-Git histories and Blueprint-heavy projects still need their appropriate technical review.

The current Clean Room page, updated November 11, describes available code measurement through Repo Check and future code identity rewriting. For company archives, Archive Check provides the first measurement job in early access, while later jobs are a pilot build. The page separately offers specialist company-data de-identification inside owner systems. Confirm the actual game preparation service and environment in your scope; archive measurement does not clean a game project.

If the parties propose a clean room for evaluation, give the term an operational meaning. Specify its operator, isolation boundary, allowed software and services, access permissions, network rules, logs, output limits and owner approval. A multiplayer game needing online services may require a different permitted setup from an offline source inspection. Agree that exception explicitly rather than calling both environments identical.

Finish with evidence a recipient can reproduce

Return to the invented missing-plugin example. Suppose the excluded plugin provides an object used by a map. Deleting the plugin and renaming its references does not establish a working substitute. The team must lawfully supply the dependency, create an agreed replacement and retest, change the selected map or narrow the deliverable. Each option changes what the buyer evaluates.

Preparation tip: Ask a second engineer to follow only the intended delivery instructions in the approved environment. Every undocumented dependency they discover belongs in the handoff before the buyer repeats the exercise.

Record the prepared package ID and hashes, included components, exclusions, dependency versions, history coverage, rights-evidence references, scan date and tool version, environment, test results and unresolved limitations. Keep private identities, keys and rights documents outside the licensed dataset; share only the specifically authorized review evidence through its controlled channel.

The companion preparation checklist and manifest template make these items explicit. Complete them for the pilot first. A successful transformation of one project gives you an approach to test on the next group, not evidence that every title in a 100-game catalog has already been cleaned.

Choose a test that can answer the purchasing question

A demo proves only what it demonstrates. Decide which evidence the buyer needs for this route, then test the same version and environment the proposed delivery will use.

Do not require an API, headless mode or a deterministic reset simply because another route needs one. Ask what the task demands. For a stochastic game, document the relevant variability and seed behavior rather than promising identical output from every run. For an environment, distinguish an available score from the rubric that actually judges the buyer's intended behavior.

Describe the test inputs, expected results, commands or procedure, environment and responsible evaluator. Keep representative error logs without exposing credentials or private identifiers. A video may help explain a sequence, but it should identify the tested version and conditions; polished footage from a different build cannot substitute for reproducing the delivery.

Make the sample's limits visible

If three pilot titles pass, record those three results. A 100-title catalog may still contain other engines, missing histories, restricted assets and online dependencies. Group the next evaluation by those differences instead of declaring the catalog accepted.

The sample-evaluation guide explains why a buyer's freedom to test within a curated sample does not reveal what was excluded from it. Here, keep the selection rule beside the pilot: which engine groups, ages, rights conditions and technical difficulties it represents, and which it does not.

Watch for handpicked footage standing in for a reproducible build, a test report belonging to another revision, hidden production credentials, or an objective nobody agreed before the run. These are actionable gaps. Ask for the version, failed step and relevant evidence rather than accepting a vague “needs improvement.”

Suppose the map in our invented plugin example fails in the buyer's permitted environment. The next decision could be a lawful dependency installation, an agreed replacement and retest, another title, a narrower source package or a stop. The pilot sheet should assign the correction and its payer. A new task requested by the buyer should receive a revised scope.

Use five explicit outcomes: proceed on the defined scope; proceed subject to named conditions; correct and retest; evaluate a different sample; or decline. Save the evidence and version for each decision. A technical pass supports the commercial next step; it does not establish a signed license, acceptance of the full delivery or a payment.

Finish the agreement before relying on the timetable

The contract should identify the same selected titles, versions and components that the buyer evaluated. Reconcile changes between the pilot and final package. Add permitted use, recipients, exclusions, exclusivity, ongoing access, owner retained rights, fees, preparation and support obligations.

Counsel should review ownership warranties, liability, indemnities, limits and disputes against that scope. Ask whether a title with a different rights history needs separate treatment. A familiar-looking contract heading does not settle an unfamiliar grant over game assets or AI uses.

Then write an acceptance schedule the technical team can apply:

Rightmark's acceptance, remedy and payment arrangements remain deal-specific. Do not assume a universal refund right, unlimited corrections, standard preparation cap or a fixed owner payment trigger. Resolve them in the agreement governing this package.

For a catalog, consider whether each title or group remains useful independently. If it does, negotiate corresponding acceptance and invoice rights. If the buyer needs the whole connected package to perform the agreed task, whole-package acceptance may be appropriate. Merely sending separate ZIP files does not create separate payment rights. The acceptance-and-payment guide examines that distinction in more detail.

Deliver an identifiable licensed copy

Use the authorized export or scoped connection, with approved recipients and access controls. Rightmark's Trust page describes owner-approved, revocable access or exports and says Rightmark does not hold your passwords. Do not send master credentials, signing keys, production accounts or the private identity map with the delivery.

The manifest should connect the package ID and digest to the licensed scope: title/version IDs, included history, permitted assets and dependencies, README, exclusions, count basis, test evidence and changes since evaluation. The receiver first confirms integrity and expected contents, then performs the agreed checks on that version.

Keep these events distinct:

1. The package arrives and its files can be verified.
2. Technical checks produce a result.
3. The authorized party records contractual acceptance or rejection.
4. The agreed invoice trigger occurs and a conforming invoice is issued.
5. The buyer's funds clear.
6. The owner's funds arrive under the applicable settlement terms.

An advance or installment arrangement can change the order; record the actual agreement. An upload acknowledgment or portal status alone does not establish acceptance or money received.

If a correction changes the package, issue a new version and manifest, state the difference and rerun relevant checks. Do not attach an old passing report to the replacement. Closing access after a failed pilot and withdrawing an unlicensed candidate are different from revoking rights already granted under a completed license.

Put dates beside events, not beside vague stages

There is no established game-wide end-to-end timetable in the sources for this guide. The useful public code context has two different clocks:

The buyer page dates its guidance October 21; the Trust page shows October 18. Do not add those ranges together. Sample preparation sits within a wider process that may include owner decisions, lab selection and procurement. Neither figure establishes a game service-level commitment.

For your opportunity, use a clock register with a start event, prerequisites, responsible party, agreed deadline and evidence of completion:

An undefined start event can make a stated deadline useless. If “ten days after complete delivery” is proposed, define what complete delivery includes and how receipt is acknowledged. This is an example of wording to clarify, not a standard ten-day Rightmark review period.

You can move rights evidence, a stable version, dependency decisions and owner approvals forward. Lab selection and procurement are counterparty decisions. Ask which exact event is waiting and who can move it, rather than accepting “in progress” as a timetable.

Follow an invented game timetable through to owner receipt

Here is an invented ready-pilot timetable, not a typical game deal or a Rightmark service commitment. Assume one relevant buyer is available at the start, the owner already holds the required rights evidence, preparation is funded, the pilot passes without rework, and the final grant matches the tested scope. Every duration and payment term below is an assumption to make the sequence visible.

Day 0 is a Monday, when that buyer agrees to assess the candidate. Day numbers are elapsed calendar days, not inclusive date counts. A business day means Monday to Friday; this simplified example has no holidays. Each handoff happens immediately when its prerequisite finishes. The parties sign when evaluation and concurrent legal work finish, issue the invoice on acceptance, assume cleared buyer payment 30 calendar days later, then assume owner settlement 5 business days after that payment.

Under these assumptions, qualification to owner cash takes 93 calendar days, or 13 weeks and 2 days. The weekday conversion is 7 + 14 + 14 + 7 + 14 calendar days through acceptance, then 30 calendar days for buyer payment and 7 calendar days for settlement. The 28 calendar days of legal work run alongside preparation and evaluation and are counted only once. This arithmetic explains the dependencies; it does not estimate the probability that the pilot passes or a buyer signs.

The example starts with an available buyer. Finding one, waiting for selection, additional procurement approvals and a negotiation that remains open have no bounded duration here. Missing rights, a failed build, a corrected sample, holidays or a different payment clause change the schedule. If those are unresolved, add an explicit wait or correction before the next event rather than leaving day 93 on the plan. Replace the assumptions in the worked timetable and blank clock register with the dates and obligations the actual parties accept.

Reconcile the money when it arrives

Return to the offer worksheet. Match the contracted consideration, owner share or buyer-paid fee, authorized costs, invoice, currency, tax/withholding and transfer treatment to the actual receipts. Identify who collects each amount and who owes any onward payment. Do not assume every route sends funds through Rightmark.

In the invented $150,000 exclusive example, the expected $120,000 owner share before tax is a contractual calculation under assumed terms. If the bank receipt differs, obtain the settlement explanation and remaining balance. The headline license price cannot explain the difference on its own.

Keep verified bank and tax records in the agreed secure process, outside the dataset and public worksheets. Assign a person to follow the outstanding event through to a receipt or a documented dispute. The transaction is not finished merely because the files were delivered successfully.

A completed license changes what you can offer next. Maintain a rights register by title, version, shared component, recipient, use, term, exclusive scope, reserved rights and surviving obligations. Add the agreement reference, option dates, payment basis and person responsible for the next decision.

This matters particularly for a large catalog. An exclusive grant over one shared engine component may affect other titles. A grant covering specified historical releases may leave later versions available, but check its update and derivative-work language before offering them elsewhere. A renamed package is not automatically outside an existing commitment.

Record patches, ports, downloadable content and sequels as changes to assess. Do not promise ongoing updates or support unless their scope and compensation are agreed. Conversely, do not remove something the contract already includes merely because the commercial team thinks the first delivery ended the job.

One payment, recurring fees, revenue share and payment on each further license are different arrangements. Rightmark's code guidance describes payment again on further licenses, but another buyer must still select the material and the applicable rights must permit the transaction. There is no dependable number of repeat licenses to multiply into a revenue forecast.

Review expiring options, extension prices and any retained copies or use rights before renewal. Follow agreed deletion and access terms without promising that ending access erases previously trained models. Check protected introductions and broker tails before moving an opportunity to another representative.

Finally, bring the pilot's actual lessons into the next catalog group. Which dependency delayed the handoff? Which ownership document was hard to obtain? Which test exposed a scope mismatch? Those observations can improve the next selection without turning one successful pilot into a claim about every remaining title.

You do not need to rebuild 100 games before learning whether licensing is worth pursuing. Start with a description of one project, the catalog around it and the AI use it might support. Establish the rights and technical gaps, then obtain a scoped response before expanding the work.

The most useful exclusive offer pays for a reservation you understand: particular titles, components, uses and time. Compare its owner net and payment conditions with credible non-exclusive alternatives. Keep preparation, support and acceptance on that same sheet so a larger headline does not conceal a larger obligation.

Bring an engine/version description, available source and history, studio-owned assets, excluded dependencies and the parts you can demonstrate. The catalog inventory, offer worksheet, pilot sheet, preparation checklist and delivery tracker give your business and engineering owners a common record. Fill them privately; the first inquiry does not require project files.

• Worksheet instructions (Markdown)
• Catalog inventory (CSV)
• Clock and payment register (CSV)
• Delivery manifest (CSV)
• Offer worksheet (CSV)
• Ongoing rights register (CSV)
• Pilot decision sheet (CSV)
• Preparation checklist (CSV)
• Rights and dependencies (CSV)
• Shared component register (CSV)

• Worked game timeline (CSV)
• Worked game timeline (MD)

Appraise your game project with Rightmark. Describe one candidate, say whether you want exclusive and non-exclusive options, and request a discussion of the next useful test. That is a practical starting point for a license your studio can evaluate on both its technical scope and its economics.