Red Flags in a Game Art Studio’s Portfolio: How to Verify What Was Actually Shipped

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Game art studio portfolio red flags include unclear origins, inconsistent scope claims and unsupported claims about work in released games. A buyer can check many of these before contacting a client, provided the review separates missing information from evidence of a false claim.

A portfolio mixes very different things under one layout. A released title, a studio’s own study, client work with restricted disclosure and a concept can sit side by side, and nothing in the image tells them apart. If you are shortlisting studios for an RFP, the method below tells you which claims to rely on and which to ask about. It is limited to checking individual pieces; it is not a full vendor selection process.

What does it mean to verify a studio’s portfolio? To verify an outsourcing studio’s portfolio is to check what it claims about each piece: its contribution, its basis for displaying the work and its public credit, if any. Separate the studio’s statements from independent corroboration, and record whether claimed deliverables can be traced to a released version.

What a Credit or a Showpiece Image Does Not Establish

A credit identifies a studio or contributor in the title’s acknowledgments. A portfolio image shows work the studio claims as its own. Neither, by itself, establishes the studio’s exact contribution or which deliverables appeared in the released game.

For a procurement lead, the exposure sits in the shortlist. A studio earns its place because a recognizable title appears in its portfolio, an RFP goes out, proposals are scored, and whether that title involved the asset category in the brief may only come up at the reference stage. By then the RFP cycle is spent, and a paid pilot or an MSA negotiation may already be under way with a vendor whose relevant experience was never confirmed.

For a producer, the same assumption becomes a capacity plan. A team is expected to deliver a scope because a credit seemed to cover it. If it does not, the first visible symptom is a milestone gate that slips while dependent activities wait. Checking the claim first moves that discovery from the first milestone to the shortlist.

The risk is not limited to dishonest studios. Templates, stale cards and unlabeled galleries produce the same confusion without any intent, which is why the method below starts with labeling rather than accusation.

Seven Common Situations Behind a Portfolio Item

The seven situations below help you describe what a portfolio item claims. They can overlap: work may be uncredited, restricted by an NDA and part of a released title at the same time. This is a practical checklist, not a ranking of work or an industry classification.

Studio studies, concept work and unreleased projects can all demonstrate relevant skills. The problem is a claim that misstates the work’s origin, the studio’s contribution or its release status.

[IMAGE: img-1] “Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Situation	What the studio can honestly say	Evidence that can exist	What to ask
1. Released title, scope documented	“We delivered these assets on this title”	A case-page scope statement, plus an acceptance record or client confirmation where disclosure is permitted	Which assets, in which version, and what did your team produce?
2. Released title, scope unclear	“We worked on this title”	A credit line or a logo, which can show a connection but not the deliverables	What exactly did you make, and which of it appeared in a released version?
3. Released title, no public credit	“We delivered work on this title, but have no public credit”	Delivery or acceptance records, where disclosure is permitted	What other evidence confirms the work, and what can you disclose?
4. Client work with restricted disclosure	“Client work; identifying details withheld where required”	An authorized description or sanitized breakdown, where disclosure is permitted	What can you disclose, and what remains unverified?
5. Studio study	“Our own study, rather than a client delivery”	A clear origin label and a breakdown of the studio’s contribution	Which parts did your team create, and were any third-party assets used?
6. Unreleased project: in development, paused or cancelled	“We delivered work for a project that has not been released”	Permitted delivery or acceptance records and a stated project status	What is the current status, and what display is authorized?
7. Concept or mockup	“We produced this concept or prototype”	A scoped brief or accepted deliverable, where disclosure is permitted	What was the agreed deliverable, and is any implementation being claimed?

A gallery image alone may not reveal these distinctions. Look for an explicit description, then check the claims that matter to your brief.

Credit, Display Permission and Scope Are Three Different Facts

A portfolio piece rests on three separate facts: whether the studio was credited, on what basis it may show the work, and what it actually produced.

Practitioners in a Polycount discussion describe credits as usually controlled by the end client and settled in the contract, and say that permission to show work usually follows public release, with stalled or cancelled projects excluded. They also stress that the two are separate: a studio can be credited without being allowed to show anything. These are individual practitioners’ accounts, not a standard, and contract terms vary.

A missing credit is a question, not a verdict. A credit can support a connection to the project, but its category and wording still need to be checked. It does not, by itself, establish which assets the studio produced or whether those assets were included in the released build. Our comparison of outsourcing companies makes a related point about scope: a credit does not, on its own, reveal the scope of a contribution.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Fact	What it answers	Where evidence comes from	What its absence means
Credit	Was the studio or a contributor named, and in which category and wording?	In-game credits or official release material. A store page does not necessarily list outsourcing vendors, and a third-party database entry needs its origin checked	Nothing definite: the client may control credits, and the reason for a missing credit may be unknown
Display permission	On what basis may the studio show this piece?	The applicable agreement, license or written authorization	If authorization is genuinely absent, a label does not make display permissible. If the buyer cannot verify authorization, record that limit without assuming a breach
Scope	What did the studio produce, and what is only claimed?	A case page describes the claimed scope; permitted acceptance records or client confirmation can corroborate it. A visual match in the game does not establish authorship on its own	The claim stays unverified until something outside the studio’s own wording supports it

Reading the Claim Language

Portfolio claims are made in verbs and counts, and both can be read like evidence.

Phrase	What it can mean	What to ask
“Worked on [title]”	Anything from one asset to full production	Which assets, and which of them are visible in the build?
“Contributed to” or “supported”	A role beside other vendors or an internal team	Who owned the deliverable and who reviewed it?
“Partnered with [client]”	A client relationship that may not cover the title shown	Which title and which work type?
A wall of client logos	A relationship, not a scope	Which logos map to a scoped case?
“[N] shipped titles” with no list	A count whose unit is undefined: title, project or contract	Can you list them and say what each one counts as?
“Production-ready”	A quality claim	What acceptance criteria applied, and what technical validation was relevant to this deliverable?
“Concept to final”	A capability statement	On which titles was the full cycle used?

Verbs that name a deliverable, such as “built the vehicle set” or “designed the shop screens”, are easier to check. Participation claims can be checked, but they need a follow-up question before they establish experience in your asset category.

Check whose experience is being claimed. Work an artist completed before joining the studio can demonstrate that person’s experience, but it should be labeled as prior individual work rather than a delivery by the current studio. For shared work, ask which parts the studio produced and which came from the client, another vendor or third-party assets.

Style labels are claims as well. A piece filed under stylized or realistic asserts a register, and our guide to stylized vendor selection explains why register match carries extra weight on a stylized brief.

Cross-Check the Studio’s Own Surfaces

A studio describes the same piece on several surfaces. Agreement between them is a consistency check, not independent corroboration.

Build a claim register for each piece you rely on. List every place the studio describes it, write down what each says about the title, the work type and the origin, and mark where they differ. A difference may be a stale card or a reused template; it is still a reason to ask.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Surface	What to record	What a gap can look like
Project card or list	Title, work type, client	A card that names more work types than the case page
Case page	Scope statement, period, release status	A scope statement that names no assets
Gallery caption or alt text	Title, origin label	A piece with no label at all
Proposal or deck	Titles used as references	A title cited for a category outside its scope
Third-party profile	Listed titles and services	A listing that cannot be traced to a primary source

A case page, a gallery and a studio-managed third-party profile may repeat the same claim, and repetition does not create independent evidence. Record who supplied each source and what it actually confirms.

For each claim, record:

• the exact claim as written;
• the URL or document name;
• the date you checked it;
• who controls the source;
• what it confirms;
• what remains unconfirmed.

Consider an invented example. A studio’s project card says “vehicles, weapons and characters” for a released shooter, its case page says “vehicles and weapons”, and a gallery shows character pieces with no label. The descriptions differ, and the gallery piece has no stated origin. Ask the studio to clarify its character contribution, then check what evidence supports that answer. The difference calls for follow-up; it does not, by itself, establish overclaiming.

The Squad case page states that our work for Offworld Industries covered concept art and unique skins alongside final assets for vehicles and weapons. The case page identifies our stated contribution. To check a particular deliverable against the released game, ask which asset or skin was included, in which version, and what part of it our team produced. Concept deliverables need a different check, such as a permitted scope or acceptance record.

The case page for Ready or Not states that our work for VOID Interactive focused on environment development.

Two tactical shooters, two different stated scopes. The case descriptions make those claims specific enough to ask targeted questions; a credit alone would not establish either scope.

Gallery pages can carry the same discipline. Our realistic weapons gallery names Squad for final production weapons and unique weapon skins and says that several other pieces, such as historic revolvers and an improvised melee set, are internal studies built to the same production standard. That is the kind of origin label to look for. It is still the studio’s own statement, so it needs the checks above.

Check Release Evidence for Claimed Assets

For a public title, an official released build or publisher-controlled material can help corroborate whether a claimed asset appeared in the game.

Pick one or two assets the studio specifically claims were included in a release. Ask for the platform, version or update and the asset’s name or location. Check the released build or official material, keeping trailers, promotional renders, mods and test builds separate from evidence of a commercial release.

Our realistic vehicle gallery lists the Kozak-2M1 and BTR-4 as production assets for Squad. Offworld’s Squad 10.0 release notes (November 2025) also identify these vehicles in the game. That supports their presence in the released product; the studio’s exact contribution still needs its own evidence.

A visual match supports the presence of an asset, not its authorship. It does not establish whether the studio modeled, textured, adapted or otherwise contributed to it.

Treat a missing match as a question. Assets may change between versions, appear only in specific modes or updates, or be omitted from trailers. Accepted concept work and other non-runtime deliverables may never appear as files in the build. An NDA may also limit what can be identified publicly.

Red Flags and Their Innocent Look-alikes

Missing labels and inconsistent claims can justify follow-up. A missing name, credit or public breakdown may reflect disclosure restrictions, so distinguish an evidence gap from a claim contradicted by evidence.

Pattern	Why it matters	Check	When it is not a flag
A piece with no origin label	A viewer cannot tell client work from a study	Look for a caption, an FAQ or a link to a case	Restricted-disclosure or studio work that is labeled as such
A studio study placed beside client titles	It may be read as client work on those titles	Compare with the case page and the gallery’s own explanation	The piece is labeled and the gallery says what is what
A title named without a work type	The credit stands in for scope	Ask which asset categories were delivered	A short mention that links to a scoped case page
General team or process text presented as project-specific	Roles or stages may be described that did not apply to this project	Ask which roles and stages actually applied to this project	The text is clearly identified as the studio’s general method or team structure
A count with no list	The unit and the evidence are undefined	Ask for the list and the counting rule	A count whose list is available on request
An unreleased project presented as released	The release status is misstated	Ask for the current status	It is shown with a clear status and authorized display
Concept or mockup presented as an implemented result	Implementation is implied but not shown	Ask what was delivered and what was implemented	The piece is accurately described as concept or prototype work
Prior individual or third-party work presented as a studio delivery	The studio’s contribution is overstated	Ask who produced which parts and under which engagement	The origin and the studio’s actual contribution are clearly stated
A claim with no label, no stated scope and no alternative evidence	The claim stays unverified	Ask in writing what can be disclosed	Disclosure restrictions apply and the studio states that limit

Technical signals sit on a different layer. Beauty renders with no in-engine view, missing modular thinking and inconsistent detail density are covered in our environment art outsourcing guide, and this guide leaves them there.

For interface work, the test of shipped screens versus mockups is set out in our UX/UI studio selection guide. The seven situations above apply to it unchanged.

What to Ask for in Writing

A written request turns a portfolio conversation into a record, and the specificity of the answer is itself information.

Ask only for information the studio is authorized to share. Do not require confidential contracts, source files or client contacts as routine portfolio evidence. An NDA between you and the studio does not automatically permit disclosure of another client’s confidential material. A permitted summary, redacted excerpt or client-approved reference may be sufficient.

Ask	What a verifiable answer contains	When a limited answer is still reasonable
Title, platform and release status	A named title, a platform and a public release status	A title withheld where disclosure is restricted, with the category and release status stated if permitted
Scope and asset list	Asset categories and named or described assets	Categories only, where asset names would reveal the client
Period	Start and end of the engagement	A range
Team, subcontracting and prior work	The studio’s actual contribution, the roles involved, and whether the example includes prior individual work, subcontracted work or third-party assets	Role titles without names
Display basis	The basis on which the studio displays the piece: client approval, an agreement clause or another written authorization	A statement identifying the permitted display basis without disclosing confidential terms
Who can confirm	A public reference, or a confirmation the client has approved	A statement that the client allows no contact, with other evidence offered

The studio’s display basis should be checked against the applicable agreement, license or written authorization. Public release does not by itself establish permission, and separate client approval may or may not be required by the agreed terms. Our guide to NDA, IP and contracts explains how an agreement can keep development materials confidential while permitting portfolio display after an agreed release or approval trigger.

Put the request into the RFP so every studio answers the same questions. Our RFP and SOW guide recommends asking for specific examples in the same asset category, visual style and technical tier as the project, not a link to a general portfolio.

Assess the specificity of the information the studio is permitted to share. If restrictions leave a claim unverified, record that limit and consider other evidence rather than treating nondisclosure as proof of overclaiming.

From Verification to a Decision

Verification settles one question: whether a claim can be trusted enough to carry into the next stage.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Outcome	What the record shows	Next step
Enough to shortlist	The pieces you rely on are labeled and scoped, the studio’s own pages agree, the claims that matter have support beyond those pages where that is possible, and at least one piece matches your asset category	Carry the record into the RFP and the later checks
Needs a reference or pilot	Scope matches only in part, rests on restricted-disclosure work, or the engagement is large or high-risk	Add a reference call or a paid pilot
Pause and ask	The studio’s pages disagree without explanation, or no scope or label can be obtained	Record the gap, ask in writing and log the risk

The reference-call and paid-pilot stages are covered in our vendor selection checklist. Verification decides which claims reach them.

When two surfaces disagree, start with the least accusatory explanation. A stale card or a reused template is a different finding from a statement that cannot be supported. Record both surfaces with dates, ask the studio to explain in writing and note the answer. If the gap affects a deliverable you depend on, enter it in the vendor risk register rather than carrying it as an impression.

Check the Records Before You Shortlist

Ten checks show where a portfolio review is still incomplete. Tick each one you can show on paper.

1. The origin of each piece is stated, including studio studies, concepts and unreleased projects.
2. The studio’s own contribution is named, not only the title of the game.
3. The permitted display basis is recorded, or the limit of what can be verified is written down.
4. The credit’s category is checked; if there is no credit, other available corroboration is recorded.
5. The project card, case page and captions agree, and the studio’s statements are kept apart from independent corroboration.
6. The unit behind any count of titles is clear, and the basis for the number is available.
7. For a claim of integration, the version or update is checked, or the evidence gap is recorded.
8. Studio work, prior individual experience and third-party contributions are kept separate.
9. Concept or prototype work, delivered or accepted work and released implementation are kept separate.
10. Each open evidence gap has a recorded next step and an owner.

An open item limits a specific conclusion; it does not make the studio a bad choice. The checklist exposes what you have not yet verified. It does not prove that a claim is false, and it does not require every item to be complete before you talk to the studio.

Start With the Piece Closest to Your Brief

Pick the portfolio piece that is closest to your brief and run it through this checklist. Identify the situations that apply, write down its credit, display basis and claimed scope, and compare the surfaces where the studio describes it. Then send the written request. One piece checked this way gives you a starting point. Verify the other examples your decision depends on rather than assuming they are documented equally well.

The aim is not to catch a studio out. It is to know what each piece can support before you build a shortlist, an RFP or a capacity plan on it.

Check our work the same way: each case page states what we delivered on that title, and several portfolio galleries explain which pieces are shipped titles, studio pieces or work shown under NDA. Ask us for anything a page does not cover at sales@nastyrodent.com, or use the request form on our portfolio page. We get back to you within 1–2 business days.