Have you ever been told that you work too slow?

ned_poreyra

Is speed an issue in this industry? I mean 3D modeling/sculpting for games. I listened to a lot of interviews with pro artists and they all say "quality first", but on the other side I constantly hear how there is never enough time to complete a game, everyone is talking about that "crunch" thing... I don't know if I can work fast enough and I don't even know how to check that.

CrackRockSteady

As a very general answer, yes, speed is an issue.  For any project you work on there are going to be milestones and deadlines.  Those things get broken down further into specific tasks, and someone needs to know how much time it takes to do all the tasks so they can calculate how much can be completed for a given deadline.

For a more specific answer than that, well, it depends.  There are a million different variables that come into play that affect how much time a particular artist has to complete a particular task.

The quality level expected for a particular project, the experience of the artist, the priority of the asset, and a glut of other factors all come into play.  Some artists work faster or slower than others, that's always going to vary, and unless you're extremely slow to the point where it becomes a problem meeting deadlines, it's usually something teams just factor in when assigning work.  As long as the quality is there, speed isn't generally a major issue.  Speed also comes with experience, and junior artists are typically not expected to finish work at the same pace as a senior artist.

In general, I would worry about being able to produce high quality work.  Once you've got that down, just keep doing it.  Over, and over, and over.  You'll get faster, don't sweat it.


Edit:  I should note that my experience has been working in a studio, I would imagine things can be different for freelance artists (i.e., if you work on the slow side it may be more difficult for you to compete directly with other artists who are much faster).

Ultimately though, the solution is still the same: practice.

Neox

In the end, its always about Money. A Senior is more expensive and will be quicker to match the needed quality. So If you are a Junior, your rate will be lower, so you can Spend more time. If it is an important Asset the Budget will be Higher than for some simple prop that lies around somewhere.
Quality first, especially in the Beginning means you have to match the quality bar, in time you will Match that quality quicker, so you can ask for a better salary.

garcellano

Yeah, it's mainly just the deadline. I don't know if this falls in line with Producers, on how they'll budget the time, or if it's the Lead to handle it, depending on the task.
Crunch comes along with it, knowing that it might take more time to get something done.
Also, sometimes things change in the game or project, like the level design, characters, story, that might affect your department. It gets tough a bit, if the deadlines stay the same, while these change, making crunch become more of a factor.
Back on the topic, yes, speed does matter. I don't think I've every had a review where I was told I was being slow. As long as you hit your deadlines (or close to it, you should be ok). I think it can be an insult sometimes, to someone, to say that just to pressure them to work faster and stress out.
There are cases where having reviews or feedback on your task, as you're going through it, makes sense, because you're making sure it's going in the right direction. The worse case I can think of, is if someone does their task, does not talk to anyone for hours, comes back with a review, having to redo so much stuff. Putting it in chunks or phases makes sense.
That said, I do feel like I annoy my Lead or Senior Env for feedback, but at the same time, I prefer it that way, then to go all in until the task is done, not knowing if I'm missing something.

poopipe

OK,  so..
I am a lead - I've been one for some time and have at times been responsible for quite a lot of artists, I've also run outsource production so (you'd hope) I have a decent handle on production requirements and the impact of being late. 

The most important thing from a production perspective in an agile system is realistic time estimates. Scope can shift, dependencies can be worked around and producers can rejig stuff so things don't grind to a halt.  It doesn't actually matter that much if someone is slower than someone else(within reason) as long as the people scheduling the work aren't surprised by it.

Being fast is an advantage and it will be appreciated but the caveat is that you have to do the work properly - finishing something quickly is worse than useless if someone else can't pick it up and work from it. Simply put, If I cant come along late in the project, find the right files, rebake, make changes and export what I need to the game from your source data without having to talk to you then you have failed at your job. 


If your team aren't using agile management strategies then you're fucked whichever way you turn and regardless of how fast you are you're going to spend 50% of the project in crunch. I'd suggest worrying less about speed and more about getting a job somewhere else in that instance. 

CrackRockSteady

poopipe said:

...
The most important thing from a production perspective in an agile system is realistic time estimates. Scope can shift, dependencies can be worked around and producers can rejig stuff so things don't grind to a halt.  It doesn't actually matter that much if someone is slower than someone else(within reason) as long as the people scheduling the work aren't surprised by it...

Everything poopipe said, but this specifically x1000.  Being able to give an accurate estimate of the time you will need to do things is a skill in itself, and is more important than being the fastest.

Alex_J

poopipe said:

OK,  so..

so are you screening for this sort of thing when you do interviews? For art test are you asking for project files, and instructing the candidate to present there work as they would to a team? Or even given some specific instructions on how to organize and deliver?

And for the other side -- the job candidate -- what kind of questions might they ask to get a read on a place that might be a little less than professional?

Also, regarding "agile management strategies" and the anecdote of somebody else needing to get into your shit and working with it later, can you shed light on any common practices there? For instance, I am kind of self-developing this sort of thing in my personal work (i'm a hobbyist, no 3d work experience), and lately what I've been doing is organizing my projects by stages they go through, and then by file types. So I'll have a folder for fbx's called "working", and this is like, temporary throw away stuff; and then I'll have another folder called "baking fbx's" and this is further broken down into high and low, etc etc. But this is just me making this up as I go along, and of course most of it has been learned the hard way. It would be great if some tested and proven methods could be shared -- i realize it's highly dependent on the overall pipeline but still it could be useful.

poopipe

I won't comment regarding senior candidates as that will tend to be a longer process and is heavily dependent on context. 

Any screening is really just a matter of personality.  Usually there'll be a relatively informal chat on skype where (among other things)  I try to gauge the candidate's attitude to being part of a larger team - if they appear to place importance on the team's success rather than just their own I consider that to be highly positive. I'm not that bothered about how organised their folders are - if they're the sort of person who gets the team thing, they'll organise stuff the way they're asked to. 

You're not going to get a straight "do you like being in a team"  question - the right answer is obviously yes - your answers to other questions will reveal whether you're there to make a game or whether you're there to make "your stuff" 


The big thing to remember with working practices is this...   It is not your asset!  ..  Other people have to take your work and do other things with it before it makes it onto the shelves.  Poor (or missing) naming conventions, files referenced from your desktop, missing bits, etc. are the game art equivalent of shitting in a colleague's lunchbox.

At a studio, someone like me will tell you where you should put the stuff we need to export game data or feed into other bits of the pipeline, they'll also tell you what to name things. Your job is to follow that convention and to ensure that what you provide is complete (eg. your source meshes for baking need to be in source control, not on your desktop) and represents the same version of the asset that is in the game. 

Outside of a studio environment it's probably harder to work out what to do but  as an exercise, imagine yourself coming back to your work in 5 years - would you be able to carry on working without having to guess at which file to open or which object to select for export? 
fwiw your setup sounds sensible enough.


Agile vs non-Agile development is something I'm trained in and have opinions about but I'm definitely not the right person to explain it  - do a google for the basic jist of things. 

oglu

There are two kinds of slow/fast Artists.
Some Artists are slow to nail the concept and need several retakes to get the model signed.
Some Artist are slow modelers and nail the concept in the first go. 
Both get the model done in the same time.
Both need to learn/practive diffrent things to get faster.

Just something to think about.

onionhead_o

i think something missing is This discussion.

Artist that get it done quick, but terrible topology.

Artist that get it done in a reasonable time with good topology.

poopipe

There are certain basic skills you expect from a professional in any field. If you're producing bad meshes you shouldn't have a job to be slow at in the first place. 

oglu

A mesh with bad geo isnt finished. Try harder.