Auto Secure LoginPut the player's real face in your game.
A player's face scan becomes a reusable 3D character your games can share, with consent recorded at every step.
Built for: A small game studio whose players keep asking to see themselves on screen, and who does not want to build head fitting, rigging, and review from scratch · A solo developer planning more than one title who wants one character standard that carries across a fighting game, a life sim, and whatever comes next · A studio lead who has to answer "where does the face data go, and can a player take it back?" before anyone will sign off on the feature · A technical artist who needs a written body and rig contract to author against, so a body made this month still works next year
The problem
FaceOff exists because of this.
Players have been asking for the same thing for twenty years: put me in the game. Not a slider-built approximation, not a cartoon avatar assembled from presets, but a face their friends recognize across a lobby. Every studio that has tried knows the shape of the work. You need a capture step a person can actually complete on their own phone without a lighting rig. You need to turn those images into a head that sits on a body without looking like a bobblehead or a mask. You need that head to blink and open its jaw without the identity falling apart. You need it all to run at frame rate on a phone that costs two hundred dollars. Then you need to do it again for the next player, and the one after that, ten thousand times, without a person babysitting each one. So most teams give up and ship a character creator, or they hand the whole problem to an outside service. The outside service is where it usually goes wrong. Player faces leave your building. You cannot say, with a straight face, where those images went, who has them now, how long they are kept, or what happens if a player asks for them back. Your legal reviewer asks a reasonable question and the honest answer is a shrug and a vendor's marketing page. Meanwhile the thing you actually bought is a black box: a face goes in, a model comes out, and when it comes out wrong you have no gate to catch it and no receipt showing who approved it. And there is a quieter failure that costs more. A face-in-game pipeline is not one problem, it is nine, and eight of them are approval problems. Did the head land at the right scale on this body. Does the neck seam show. Does the smile still look like the same person. Did the hair go through the shoulder. Does the impact land on the frame the reaction starts. Is the audio in sync. Did it crash on the third run. Teams build the geometry part, discover the review part is the real work, and end up approving things in a group chat. Six months later nobody can prove which build a named person actually signed off on, or that the character shipped is the character that was approved.
What changes
- In the current path player face data never leaves the studio's own machine, and FaceOff itself never keeps the source images: the character package it builds deliberately excludes the scan stills, the facial landmarks, and the player's account identity.
- The generic face and generic voice option is written into the platform's own working rules as something that cannot be removed, so declining to be scanned never costs a player the game.
- Forty-five named human checks across five review gates, each bound to the fingerprint of the exact file reviewed, so an approved character cannot be swapped for a different one downstream.
- Frame-level sign-off: the reviewer must see each of twelve specific frames before that frame's decision unlocks, and the clip is verified from its own bytes before it will play.
- Stand-in characters used for internal pipeline work are marked as such and are structurally refused by every production admission step; their diagnostic observations are even written to a different record shape that the production command will not accept.
- Character packages are game-neutral by rule: FaceOff is forbidden from importing or depending on any single game's code, so a second title does not mean a second pipeline.
- Each stage writes down what it has not proven, in the product's own records, rather than letting a passing mechanical check imply visual quality or device readiness.
What it does
How FaceOff works, start to finish.
FaceOff is the layer between a finished face scan and a character your game can load. It does not perform the capture itself. A separate ASL capture component runs the slow guided scan - front plus three angles in each direction, with checks for lighting, sharpness, framing, face count, angle, and hold-still stability - and hands FaceOff a finished, fingerprint-bound package. FaceOff's job starts there, and it starts by disbelieving what it was handed: it re-verifies the recorded approval decision and both candidate heads by fingerprint before anything is admitted, and it cannot be talked into disagreeing with a decision already on record. What FaceOff builds is a portable character package, and what that package leaves out matters as much as what it carries. It carries the derived head geometry, the body and skin and hair and clothing selections made against that identity, the consent receipt and agreement version, and the record of who reviewed it and what they approved. It deliberately excludes the source scan images, the facial landmarks, the player's account identity, and every source file location. The images that made the head do not travel with the character. The head is deliberately not welded to one body. FaceOff defines a body contract, and any body that satisfies it can accept any approved head. A body has to bring the full standard skeleton, a socket sitting directly under the head joint, and a removable stand-in head that comes off without taking the body mesh with it. Bodies are admitted once, with commercial rights approved and a named reviewer's visual sign-off attached, and then they are reusable. That is the whole point: one scan, many bodies, many games. A player who scans for your fighting game should be able to walk into your life sim next year as the same recognizable person, wearing something else. Animation works the same way. Instead of generating choreography per match, a sequence is authored once as a contract: exact timing, which frames each attack launches and lands on, where the camera holds, which reaction begins on which frame. FaceOff then drops each player's character into that sequence. The first sequence runs twenty seconds at thirty frames a second, six hundred frames, two characters, reciprocal attacks, a shot-reverse-shot camera that holds still through each impact. The design target is roughly fifty of these built once and reused for every pairing, rather than new animation per player. The same package is meant to feed simulation, sports, story, and social games, and FaceOff is forbidden by its own working rules from depending on any single game's code. The part that is unusual is the review discipline. Nothing in FaceOff advances because a script said it worked. Five named review gates stand between an admitted scan and a finished scene, carrying forty-five named checks between them. Ten checks on the head geometry alone: front likeness, both three-quarter angles, profile silhouette, face boundary, cranium proportion, head-to-neck proportion, neck transition, texture alignment, and no visible artifacts. Seven more once the head is on the body, covering identity, likeness, scale, neck seam, skin tone, hair and clothing interaction, and body coverage. Ten on the facial controls. Ten on the finished sequence, plus a separate yes or no on each of twelve individual frames the reviewer has to actually watch. Eight on the sound. Each approval is bound to the exact fingerprint of the exact file it approved, so an approved character cannot be quietly swapped for a different one downstream. Face data stays on the studio's own machine. The intake screen is reachable only from the machine it runs on, opens no route in from outside, and never returns a file location, a folder, or a face image to the browser; a person operating it cannot type in an arbitrary location to pull from. The generic face and generic voice path is a permanent requirement written into the platform's own working rules, not a fallback: a player who does not want to be scanned plays the whole game with a generic character, and the personalized path is entered only after an affirmative, electronically signed opt-in recorded before capture. Player-initiated deletion is a decision on record - it is meant to live in the player's own account rather than a support queue - but today it is a design commitment, not a built control.
Features
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
It admits a scan, it does not take one on faith
The guided capture happens in a separate ASL component: seven views, front plus three angles each way, with lighting, sharpness, framing, face-count, angle, and stability checks, and no continuous video kept. FaceOff's contribution is refusal. It re-verifies the recorded approval decision and both candidate heads by fingerprint, imports only the head that decision selected, and cannot overrule or quietly disagree with a decision already on record.
One head, many bodies, many games
The player's identity lives in its own package, separate from whatever body they are wearing. Bodies, skins, hair, clothing, and equipment are selections made against that identity rather than copies of it. The package is game-neutral, so a fighting game, a life sim, a sports title, or a story game can load the same character without rebuilding the scan. Several body versions can coexist, and the exact version a character was built against is frozen in, so an older character stays reproducible.
A body contract your artists can author against
A body is admitted only if it brings all nineteen required skeleton joints with the expected torso, arm, and leg ancestry, a head socket parented directly to the head joint, and a stand-in head that detaches without destroying the body mesh. A body whose head cannot be separated is rejected outright. Extra fingers, toes, eyes, jaw, and equipment bones are welcome and change nothing. Admission also checks the skinning, the artifact fingerprint, approved commercial rights, and a named reviewer's sign-off.
Nothing advances without a person saying yes
Five named review gates carry forty-five named checks between them, covering head geometry, the assembled character, the facial controls, the finished sequence, and the sound. A reviewer's identifier and the exact time go on every decision. There is no automatic promotion path around any of them, and a mechanical re-import passing is never treated as a person's approval. Each gate also writes down, in its own record, what it has explicitly not proven.
Frame-by-frame sign-off, not a thumbs up on a video
The sequence review requires ten judgments about the whole clip and a separate decision on each of twelve specific frames the reviewer has to see displayed first. The page verifies the clip's identity from its own bytes before it will play, and each frame's controls stay disabled until that exact frame is on screen. A reviewer cannot approve a frame they never looked at, which is exactly the failure this replaces.
Approvals are welded to the file they approved
Every character, body, sound file, and finished clip carries a cryptographic fingerprint, and every approval records the fingerprint of what was in front of the reviewer. Change one byte anywhere downstream and the chain refuses to continue. The frame list a reviewer must sign off on is re-derived from the controlled sequence at admission rather than retyped, so an approved character cannot be swapped for a slightly different one on the way to the build.
Face data stays on your machine
The intake screen answers only on the machine it runs on and opens no route in from outside. It never hands a file location, folder, or face image back to the browser, and an operator cannot type in an arbitrary location to read from. The character package it produces deliberately excludes the source scan images, the facial landmarks, and the player's account identity, so the pictures that made the head do not travel with the character.
The generic path is permanent, not a courtesy
A player who does not want to be scanned gets a generic face and a generic voice and the full game. This is written into the platform's own working rules as something that cannot be removed. The personalized path is entered only after an affirmative, electronically signed opt-in recorded before any capture happens, and a real voice is never silently required either.
Consent travels with the character
The signed agreement version and consent receipt are written into the character package itself, not filed away in a separate system that can drift, and they are carried through assembly rather than re-entered. Staging a two-character scene requires two different characters carrying two distinct consent receipts; the code refuses outright to stage a scene that reuses one. A consented identifiable voice additionally requires the exact consent-receipt fingerprint and a stated game-use scope.
Sequences authored once, reused per player
A sequence is a contract with exact timing: twenty seconds, thirty frames a second, six hundred frames, with each attack's launch and impact frame and each reaction's start and end frame written down. Reactions begin on impact, never before, and the checker refuses timeline drift, early reactions, effect routes that do not travel toward the opponent, and camera motion through an impact. Adding a sequence means adding a reviewed contract, not another branch in a script that quietly drifts from what was approved.
Facial controls that survive the export
Six named expression controls are built and measured: jaw open, each eye blink independently, each side of the smile, and inner brow raise. After export the file is re-imported and every control is verified to have survived with real, measured movement. A reviewer then has to exercise all six on the real face and confirm the person still looks like themselves at rest and in motion, with a stable neck and no mesh clipping.
Sound is its own gate - built, and switched off
Six sound cues lock to exact animation frames: each launch, each impact, and each reaction. Music is optional and never required. Listening review is eight named checks, including whether rights and voice consent are verified and whether the picture is unchanged, and approving the sound explicitly does not approve phone playback or release. Be clear about the state: this entire path is built and deliberately inactive. On a normal start the review screens are absent, and no real mix has been made or heard.
A phone budget you can hold a build to
Device acceptance is written as numbers, not vibes: at least five complete offline runs, zero crashes, at least 28.5 average frames per second, ninety-fifth percentile frame time no worse than 40 ms, worst frame no worse than 100 ms, dropped frames under two percent, peak memory under 768 MiB, and an explicit finding that the phone did not thermally throttle. Anything short of that is not admitted. The measuring is done by your build, not by FaceOff.
Proof
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
- Bodies and sounds are admitted only with commercial rights approved and a named reviewer attached, and the catalogs are shown empty rather than filled with placeholder options that do not exist.
Where it runs
Surfaces and status.
Status as of 2026-09-02. Verified on 2026-09-02 against the current source. Version 0.37.0; the most recent change is dated 2026-09-01 and the README's newest dated section carries the same date. 157 of 157 automated checks pass across 41 test files, alongside syntax checks over every module and deployment script. The pipeline is built end to end - scan admission, character package, body and sound catalogs, character assembly, facial controls, two-character sequence authoring, frame-bound sequence review, sound binding, device handoff, and a combined delivery candidate - and every stage is exercised by tests. What has not happened: no real person has been through the pipeline end to end; no production body asset is admitted, and the automated body tests run against generated stand-ins only; the head-scale review is sitting at the human-judgment step, recorded as AWAITING_HUMAN_PROPORTION_AND_LIKENESS_REVIEW; no on-device measurement run has been executed; the sound path and its review screens are off by default and no real mix has been made or heard; the likeness agreement is drafted and awaits legal review; and no player-initiated deletion control is implemented. Nothing is published to the internet, and no pricing exists anywhere in the source code.
Works with
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with FaceOff.
ASL Verifier
One-to-one face verification that fails closed, with no face search and no surveillance mode. If you need to confirm that the person scanning is the person who owns the account, that is a different job from likeness capture and should stay a different system.
Explore →ASL Timestamp Anchor
FaceOff's receipts prove what was approved and by whom. An independent time anchor proves when that record existed, to someone who has no reason to take your word for it.
Explore →ASL Files
For handing a review clip or a finished character to an outside animator or a publisher without email attachments - encrypted storage plus an expiring, password-protected send.
Explore →ASL Vault
A sealed store your build machines can write keys into without being able to read them back, so the machines producing artifacts are not the machines holding the secrets.
Explore →ASL Scan
Before you ship a game that touches player faces, get the app itself assessed against a signed scope so you know what you are actually shipping.
Explore →What is new
Recent progress.
This product ships often. The most recent verified changes, newest first.
it is at version 0.37.0, with the most recent change dated.
and 157 of 157 automated checks passing. The newest work is a separate review-only path for checking the scanned head at real body scale: it places a measured head at 0.24 m on a generic 1.80 m review figure - 7.5 head heights - and derives the neck's actual center from the geometry rather than assuming it, failing if the placed neck drifts by more than a hundredth of a millimetre. Three rounds were run and the first two were kept as rejections rather than quietly deleted: the first used a body too broad and rough to judge proportion against, and the second exposed a front-to-back neck-origin error that only showed in profile. The third corrected it and is the current candidate awaiting a person's proportion and likeness judgment; the next objective step after that is a fixed-orientation nine-view silhouette and facial-proportion comparison, which is a likeness diagnostic rather than an identity threshold. Also landed in the last few weeks: the local intake screen with rights-checked body and sound catalogs that show empty rather than fake, the character assembly and six-control facial rig steps, the first reusable two-character sequence as a fingerprint-bound contract, frame-level sequence review, the six-cue sound binding with its eight-check listening review, a crash-recoverable dispatch record, and the combined delivery candidate that proves the approved picture and the approved sound came from the same reviewed source.
Pricing
Pricing for FaceOff is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
Ask about pricingQuestions buyers ask
Straight answers.
What does it cost?
Pricing is not published yet, and we would rather say that plainly than invent a number. FaceOff is in development: the pipeline is built and tested, but no real person has been through it end to end and no phone measurement run has happened. If you want to be in the first group of studios using it, the conversation right now is about your engine, your device targets, and what a first integration would need, not about a price sheet.
We already have a character creator. Why would we add this?
A character creator gives players a face they assembled. FaceOff gives them the one they already have. Those are different products and they coexist well - the sliders stay for people who want to build someone else, and the scan is there for people who want to see themselves. If your players are already asking to be in the game, you know which one they are asking for.
We were going to use an outside photo-to-avatar service. What is different here?
Two things. First, in the current path the face data does not leave your machine: the intake screen answers only on the machine it runs on, opens no route in from outside, and never returns a file location or a face image to the browser. FaceOff does not even keep the source images - the character package it builds deliberately excludes the scan stills, the landmarks, and the player's account identity. Second, you get gates instead of a black box. Forty-five named human checks across five review points, each bound to the exact file that was reviewed, so when something ships you can show who approved it and what they were looking at.
What happens to a player's face data, and can they get it deleted?
Scanning is voluntary and requires an affirmative, signed opt-in recorded before capture. The scan keeps a small set of chosen stills rather than continuous video, and those stills stay in the capture step - they are deliberately excluded from the character package FaceOff builds. On deletion, here is the honest state: the decision is on record that a player can delete their face data and that the control belongs in their own account rather than a support queue, but nothing implements it today, and the account it would live in is your game's. There is also a boundary the agreement has to settle - deleting a source capture is not the same as unmaking what was already built and approved from it. That agreement is drafted and awaiting legal review before any launch.
What about players who do not want to be scanned?
They play the whole game. A generic face and a generic voice is a permanent product requirement written into the platform's own working rules, not a degraded mode and not something that can be quietly dropped in a later release. No feature gate hangs off handing over your face.
Is it ready to put in our game today?
No, and we will not pretend otherwise. Every stage is built and passes its automated checks, but a real person has not been through the pipeline, no production body is admitted, no on-device measurement run has happened, and the sound path is deliberately switched off. What is ready today is a serious conversation about integration and about being early enough to shape the body contract and the sequence format around what your game actually needs.
Does this lock us into your engine, your game, or your art style?
No. FaceOff is forbidden by its own working rules from importing or depending on any single game's code. What you get is a versioned character package and a body contract; your game loads the character and owns everything else - gameplay, controls, networking, progression, store builds. The body contract is a joint list and a head socket, so your artists can author bodies in whatever style your game needs.
How much work is the integration on our side?
Your side is loading a standard character file and playing a sequence. FaceOff hands over a package plus a device measurement plan telling your release harness exactly what to measure and hand back: five complete offline runs, zero crashes, the frame-time and memory numbers, and confirmation the phone did not throttle. What FaceOff does not do is build your project, your store build, or your playback harness - that stays in your codebase, which is also why it does not entangle your build with ours.
Will a two-character likeness scene actually hold up on a mid-range phone?
That is the right question and it is still an open gate. The budget is already written down and enforced: at least 28.5 average frames per second, ninety-fifth percentile frame time no worse than 40 ms, worst frame under 100 ms, dropped frames under two percent, peak memory under 768 MiB, and no observed thermal throttling, across five crash-free offline runs. Nothing gets admitted without hitting those. What has not happened yet is running it on a real phone.
Can we hear a scene, or is it silent?
Silent today. The sound path is fully built - six cues locked to exact animation frames, an optional music bed, eight named listening checks including rights and voice consent - and it is deliberately switched off. On a normal start the review screens are not even present. No real mix has been made and no listening review has been recorded, and we would rather tell you that than play you something that does not represent the state of the work.
What happens if we stop paying, or if you go away?
What you hold is a character package and a rendered scene in ordinary formats plus the body assets you had rights to, not entries in a system only we can read. The body contract is nineteen named joints and a head socket - it is written down and your artists can keep authoring against it. We would rather tell you that up front than have you discover it during a renewal conversation.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
- No real person has been through the whole pipeline yet. The review-only scaling pass dated 2026-09-01 showed that a scanned head can be presented at adult proportions rather than as a bobblehead; it did not prove likeness quality on a real face, and that judgment is still sitting with a human reviewer.
- FaceOff does not perform the face capture. It admits a completed, independently verified scan package and re-checks it; the guided capture and head reconstruction are a separate part of the pipeline, and their first physical scan and visual review are still outstanding.
- No production body asset is admitted today. The body and sound catalogs show empty lists on purpose rather than offering placeholder options that do not exist, and the automated body tests run against small generated stand-ins.
- The Android performance thresholds are written and enforced at admission, but no measurement run has been executed on a phone. Device acceptance is an open gate, not a claim, and there is no FaceOff phone application - your build does the measuring.
- The first sequence is deliberate blocking choreography for validating the pipeline, not finished, art-directed animation. It still needs effects work, sound work, and a director's eye. Only that one sequence exists today.
- The facial rig is a six-control minimum expression set. It does not replace a production facial artist, corrective shapes, lip sync, eye aim, or teeth and tongue geometry.
- The sound path is fully built and intentionally switched off. It has been exercised end to end against a stand-in, but no real sound has been mixed and no listening review has been recorded. On a normal start its review screens are absent entirely, and turning them on has its own open checklist.
- FaceOff does not create voice likeness itself. The character package can reference a voice and the sound contract accepts either a consented identifiable voice or a generic one, with generic always available; the voice itself comes from a separate ASL system.
- Player-initiated deletion of a face scan is a decision on record, not a built control. The intent is that it lives in the player's own account rather than a support queue; nothing implements it today, and the account surface it would live in belongs to the consuming game.
- The likeness and voice agreement is drafted and awaits legal review before any launch. Its scope is broader than the scan itself - it also covers retained source material and authorized face and voice engine training - and settling exactly what that means is part of what the legal review has to do. Nothing personal is captured without an affirmative, signed opt-in recorded before capture.
Put the player's real face in your game.
A player's face scan becomes a reusable 3D character your games can share, with consent recorded at every step.
Prefer email? contact@autosecurelogin.com