How would you version reference-based concept generation in a game-art pipeline?

Started by ethanjamescolez Friday at 4:08 PM 4 replies 100+ views

Original Post

Friday at 4:08 PM

I am looking at reference-based image generation as a pre-production step for game art, and the part I keep coming back to is versioning rather than prompting.

If a concept is built from several references, I think the generation request needs to behave more like an asset manifest:

- source IDs and a declared role for each reference, such as subject, composition, lighting/color, or secondary detail

- a short list of what may change and what must remain recognizable

- the selected model and current output settings captured with the request

- a rights/provenance note for every source

- an immutable request ID so a retry does not silently become a different experiment

The output would then enter a review state rather than going straight into the project. I would check silhouette and subject fidelity, anatomy and edges, perspective, lighting consistency, materials, embedded text or logos, and obvious artifacts. Only an accepted derivative would be exported, and even then it should stay labeled as generated concept material rather than captured reference or production-ready art.

For engine integration, I am unsure whether this metadata belongs beside the image as a JSON sidecar, inside an asset-management system, or in the importer database. A sidecar is portable, but an internal record is easier to query and can preserve review history when files move.

The goal is not to claim that generated output is automatically safe or shippable. Source permission, third-party rights, licensing, style consistency, and human art review still need separate decisions. Image to Image

Disclosure: I work on a related browser-based reference-image workflow. I intentionally omitted its name and URL because this question is about game-development pipeline design, not promotion. I also used AI assistance to organize this draft, reviewed and revised it, and take responsibility for the final wording.

How would you model this in a real game-art pipeline: portable sidecars, a central asset database, or engine importer metadata? And where would you place the accept/reject gate before an image can enter source control?

frob

Saturday at 5:36 AM

Simply: I wouldn't. There are version data that need tracking in games, but what you described is not part of it.

ethanjamescolez

Saturday at 5:49 AM

frob wrote:
Simply: I wouldn't. There are version data that need tracking in games, but what you described is not part of it.

Thanks for the perspective — I think a lot of teams are in that camp right now.

Part of why I asked is that I’m trying to understand where different studios draw the line between “disposable exploration” and “assets whose history we actually care about.”

For me, reference‑guided generation lands in that grey area. Once a generated concept is built from multiple references and starts influencing real designs, art direction and production sometimes need to know what went into it and how it changed. A bit of structured metadata (sources, settings, accept/reject) is just a way to keep that traceable, for teams that decide it matters.

stephen4

Saturday at 12:17 PM

I get your point, but I think keeping some basic version history could still help when generated concepts get revised or reused later.

bvanevery

Saturday at 4:12 PM

In all fairness I haven't worked in a commercial setting as an artist, let alone as part of a team with an Art Director. I've only worked on my own art and certainly understand creative processes. I'm also a programmer and game designer with plenty of source control experience. I comment my CHANGELOGS meticulously, intended as notes to others as to why I did things in such-and-such a way, and quite likely to my future self.

Your list of requirements sounds somewhat like an attempt at an Art Director to maintain some kind of dictatorship, rather than relying on the good judgment of the people hired to actually do the individual pieces of work. If you cannot trust who you hired, why did you hire them? Similarly if you can't trust the businesspeople you contract with to a large extent, why draw up a contract with them? A contract doesn't magically protect you from being ripped off, it just keeps people more honest and clarifies some expectations. People who work against you or try to rip you off, aren't people you should be in partnership with. So I see a lot of these issues as personnel and managerial style issues, not "it's in a document somewhere" issues.

I'd ask: what's the mental bandwidth you want to impose on a "line" artist, that's really an essential point you want at the front of their mind when working on something? Shouldn't it err on the side of being short, focused, and to the point?

If there's a reviewing process, I seriously doubt that any amount of notes is going to change the inevitabilities of review. Things can change a lot after a review, especially if the decisionmaker is a bit inconsistent or flippant. Who knows what external factors can come into play as well, if someone suddenly decides the project must go in a rather different direction. Tracking what was said at the review, sounds like it could be a lot more important, than your a priori list of concerns. The a priori list sounds like how you "might like" to see and construct the artistic world. Not the reality of what the artistic world is, under production constraints.

I would also note, if any of this is intended for tracking the milestones of a third party, they can deliver material in a very cynical manner to you. Some of them know you're a "stupid" manager who must object to things, to justify your prestige position and paycheck. So they may finish the actual project lickety split, then dole you out really bad versions over time, seeming to gradually improve at each iteration. They may already be coasting along sipping margaritas and doing other work, but they'll do a big dog and pony show for you as a client, a "narrative of progress" to keep you under control. I got told point blank by an ex-Pixar veteran, if the client isn't hitting the roof when you show them your stuff, you haven't done it awful enough.