5 ms·
The best way to do it that I've found is to arrange a folder hierarchy of "where" rather than "what." So there's no one place with all the game's rock models, b
by jtolmar 11y ago
The best way to do it that I've found is to arrange a folder hierarchy of "where" rather than "what." So there's no one place with all the game's rock models, but rather firelands/towerofeternalflame/courtyard/rock01.3ds and so forth. "Where" doesn't have to mean a literal location; it could be playerbases/horde/rock.3ds or something. Though for most games, everything not tied to the player really can just be its literal location. It's crucial that these directories have a mix of models, textures, and whatever else you need, instead of a mass of parallel structures.
If there are automated tools, they should run on the entire asset directory and dump to a new directory in whatever hierarchy makes sense to the tool. When that turns out to be slow, check "file modified" timestamps in the tool instead of dumping required knowledge on the artist.
Getting artists to actually use source code control instead of having personal folders full of things like rock01_retouched_new_final_final.3ds is a bit of a pipedream, but you can at least put the asset directory under source control and make that the only way to see things in the engine.
- solipsism 11y agoGetting artists to actually use source code control instead of having personal folders full of things like rock01_retouched_new_final_final.3ds is a bit of a pipedream BS. Just hire better artists. It sounds like hand-waving, but I've worked with both kinds of artists. You're building games, so if you focus on only hiring artists based on their portfolio you might end up with a bunch of stubborn artists who need to be hand-held and worked around constantly. If instead you focus on hiring artists who are good at art AND who can demonstrate a propensity or desire to learn new workflows and and to be flexible, then you'll end up with a bunch of team players. This is a common complaint about artists, but it has more to do with culture and expectations than anything else.
- blablablame 11y agoAgreed. While a few artist keep a few _01 _02 files around, mostly as backup/undo files, my last few years in the industry, they all used some kind of version control (maybe not git, but perforce and svn with their visual tools)
- dev360 11y agoSounds like perforce is common when there are lots of binary files - is this mostly due to storage concerns?
- vvanders 11y agoBunch of factors: - Really good binary performance(light years ahead of git). - Proper locking for files that can't be merged(basically everything in the art dir). - Proxy support for co-located teams. Game repos can easily approach multiple TB just for the art assets. In that area Perforce is once of the few VCS that scales appropriately.
- malkia 11y ago+1. Also easy graphical interface - P4Win/P4V, and easy to understand the system of changelists. It also helps that older changelists mean things submitted in the past, newer in the future - e.g. in contrast with digest/fingerprint schemes like other systems use.
- vvanders 11y agoYup forgot about that but a good point as well.
- sytse 11y agoYes, perforce is really good with large binary files. Only recently Git LFS allowed for git repositories to store large binaries as well.
- ido 11y agoWe use git with lfs for our game. It has on occasion been a bit of a pain, however perforce is too...unfortunately there isn't a really great solution atm, just a bunch of more or less flawed ones.