Jump to content

  • Log In with Google      Sign In   
  • Create Account

When to Recruit

  • You cannot reply to this topic
12 replies to this topic

#1 SpiritBlade   Members   -  Reputation: 131

Like
3Likes
Like

Posted Yesterday, 09:54 AM

I have been working on a project lately and would like to get some help with some aspects I am not as familiar with in my skillset. I don't want to just randomly start recruiting anyone who will sign on and would like to put together a successful team and have a successful finished product so I am trying to make sure I prepare properly so my question is when is a good time to start recruiting? How much material should I have ready for review for potential members of the team? Also what is a good dos and don'ts on recruiting?


You have to believe that GOD is in Control, therefore there is NO need to be stressed out OR worried!


Sponsor:

#2 ThoriumLabs   Members   -  Reputation: 110

Like
1Likes
Like

Posted Yesterday, 10:14 AM

I'd like to know this as well! Any help here would be appreciated!



#3 slayemin   Members   -  Reputation: 2608

Like
6Likes
Like

Posted Yesterday, 01:31 PM

Depends on what you're recruiting for and what the work load is. You'll want to recruit different skill sets at different phases of the project.

 

Game design needs to be done from day 1.

Art and style guides needs to be done from day 1.

Programming can be done when 50% of the design has been figured out, though there's no harm in starting early.

Business planning needs to be done before the project even starts.

Marketing can be done when the project is about 90% complete (keep in mind, the last 10% takes the longest)

Writers can be brought in roughly around 50%-60% production phase (my guess).
Testing needs to be done when you've got something playable, but the testing work load ramps up as the project nears completion. You can probably get away with not having dedicated testers for the first half of a project. Keep in mind though, issues not found through testing snowball in the sheer amount of effort required to fix them. Finding and fixing problems early can save you TONS of time and money -- fixing hypothetical bug A at day of introduction + 2 costs a programmer 2 hours of work, which translates to $40 * 2 = $80. Fixing bug A at day of introduction + 200 costs a programmer 30 hours of work (due to refactoring all dependent systems), which translates to $40 * 30 = $1200.

When do you need to hire someone? When you have too much work built up for one person to handle or when you can't do the work yourself.

IF you have a lot of work, something someone can spend 40 hours/week doing, then you want to hire an employee.

IF you have a bit of piecemeal work, consider contracting it out instead.

Quick note on this: Contractors are generally more expensive per hour than employees, but will save you money if you don't have a lot of consistent work. You don't want to pay employees to sit around doing nothing. Employees on the other hand, give you consistency and continuity which you don't really get with contractors / freelancers. You generally don't want to contract out stuff which has a lot of stylistic variety, such as artwork.

IF you don't want to pay someone to work for you, be prepared to have them quit on you at any moment. Unpaid people have very little incentive other than their own morale / personal interests to stick around. If your making an unpaid person fill a vital role in your project, you're taking on a huge risk in terms of project management.

IF you want to build a geographically remote team of unpaid people, good luck. Not only may members drop off the project at any moment, you will also have huge communication challenges. You've got people all over the world with different time zones, languages, schedules, and cultural backgrounds. Project management and coordination of effort will be a nightmare. You're essentially operating a free open source project, where you should expect people to pop in and tinker a bit and disappear. Don't expect a lot of progress, or for the progress to go in the direction you want, to your level of satisfaction.


Eric Nevala

Indie Developer | Dev blog


#4 ThoriumLabs   Members   -  Reputation: 110

Like
0Likes
Like

Posted Yesterday, 02:08 PM

Depends on what you're recruiting for and what the work load is. You'll want to recruit different skill sets at different phases of the project.

 

Game design needs to be done from day 1.

Art and style guides needs to be done from day 1.

Programming can be done when 50% of the design has been figured out, though there's no harm in starting early.

Business planning needs to be done before the project even starts.

Marketing can be done when the project is about 90% complete (keep in mind, the last 10% takes the longest)

Writers can be brought in roughly around 50%-60% production phase (my guess).
Testing needs to be done when you've got something playable, but the testing work load ramps up as the project nears completion. You can probably get away with not having dedicated testers for the first half of a project. Keep in mind though, issues not found through testing snowball in the sheer amount of effort required to fix them. Finding and fixing problems early can save you TONS of time and money -- fixing hypothetical bug A at day of introduction + 2 costs a programmer 2 hours of work, which translates to $40 * 2 = $80. Fixing bug A at day of introduction + 200 costs a programmer 30 hours of work (due to refactoring all dependent systems), which translates to $40 * 30 = $1200.

When do you need to hire someone? When you have too much work built up for one person to handle or when you can't do the work yourself.

IF you have a lot of work, something someone can spend 40 hours/week doing, then you want to hire an employee.

IF you have a bit of piecemeal work, consider contracting it out instead.

Quick note on this: Contractors are generally more expensive per hour than employees, but will save you money if you don't have a lot of consistent work. You don't want to pay employees to sit around doing nothing. Employees on the other hand, give you consistency and continuity which you don't really get with contractors / freelancers. You generally don't want to contract out stuff which has a lot of stylistic variety, such as artwork.

IF you don't want to pay someone to work for you, be prepared to have them quit on you at any moment. Unpaid people have very little incentive other than their own morale / personal interests to stick around. If your making an unpaid person fill a vital role in your project, you're taking on a huge risk in terms of project management.

IF you want to build a geographically remote team of unpaid people, good luck. Not only may members drop off the project at any moment, you will also have huge communication challenges. You've got people all over the world with different time zones, languages, schedules, and cultural backgrounds. Project management and coordination of effort will be a nightmare. You're essentially operating a free open source project, where you should expect people to pop in and tinker a bit and disappear. Don't expect a lot of progress, or for the progress to go in the direction you want, to your level of satisfaction.

Thanks a bunch! This helped me quite a bit!



#5 SpiritBlade   Members   -  Reputation: 131

Like
2Likes
Like

Posted Yesterday, 03:14 PM

Depends on what you're recruiting for and what the work load is. You'll want to recruit different skill sets at different phases of the project.

 

Game design needs to be done from day 1.

Art and style guides needs to be done from day 1.

Programming can be done when 50% of the design has been figured out, though there's no harm in starting early.

Business planning needs to be done before the project even starts.

Marketing can be done when the project is about 90% complete (keep in mind, the last 10% takes the longest)

Writers can be brought in roughly around 50%-60% production phase (my guess).
Testing needs to be done when you've got something playable, but the testing work load ramps up as the project nears completion. You can probably get away with not having dedicated testers for the first half of a project. Keep in mind though, issues not found through testing snowball in the sheer amount of effort required to fix them. Finding and fixing problems early can save you TONS of time and money -- fixing hypothetical bug A at day of introduction + 2 costs a programmer 2 hours of work, which translates to $40 * 2 = $80. Fixing bug A at day of introduction + 200 costs a programmer 30 hours of work (due to refactoring all dependent systems), which translates to $40 * 30 = $1200.

When do you need to hire someone? When you have too much work built up for one person to handle or when you can't do the work yourself.

IF you have a lot of work, something someone can spend 40 hours/week doing, then you want to hire an employee.

IF you have a bit of piecemeal work, consider contracting it out instead.

Quick note on this: Contractors are generally more expensive per hour than employees, but will save you money if you don't have a lot of consistent work. You don't want to pay employees to sit around doing nothing. Employees on the other hand, give you consistency and continuity which you don't really get with contractors / freelancers. You generally don't want to contract out stuff which has a lot of stylistic variety, such as artwork.

IF you don't want to pay someone to work for you, be prepared to have them quit on you at any moment. Unpaid people have very little incentive other than their own morale / personal interests to stick around. If your making an unpaid person fill a vital role in your project, you're taking on a huge risk in terms of project management.

IF you want to build a geographically remote team of unpaid people, good luck. Not only may members drop off the project at any moment, you will also have huge communication challenges. You've got people all over the world with different time zones, languages, schedules, and cultural backgrounds. Project management and coordination of effort will be a nightmare. You're essentially operating a free open source project, where you should expect people to pop in and tinker a bit and disappear. Don't expect a lot of progress, or for the progress to go in the direction you want, to your level of satisfaction.

This helps me a TON on what needs to be done. Thank you!


You have to believe that GOD is in Control, therefore there is NO need to be stressed out OR worried!


#6 Orymus3   Crossbones+   -  Reputation: 9041

Like
1Likes
Like

Posted Yesterday, 08:15 PM


Writers can be brought in roughly around 50%-60% production phase (my guess).

 

Might be earlier, depending on whether you intend to localize in various languages, which can take some time depending on the amount of content...



#7 StarMire   Members   -  Reputation: 625

Like
1Likes
Like

Posted Today, 09:34 AM

If he's talking about getting people to work on the project for free, though, these things become much more complicated.

 

Game design needs to be done from day 1.

 

Only as little as possible to avoid severe creative differences.

 

Nobody wants to work for free on somebody else's game design.  It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.

 

You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members.  Such as:  one only likes JRPGs, the other only likes FPS - how do you resolve this?  You don't.  You only recruit one of them based on their having similar interests in line with the overall goal.

 

Narrow it down only just enough, but leave it open so contributors can feel like it's their game.  Achieving that balance in itself is something of an art.

 

 

Art and style guides needs to be done from day 1.

 

 

Where volunteer projects are concerned, that's almost impossible.  People will come and go from week to week, maybe only contribute a couple sketches, or one sprite.  Things are unfortunately very unlikely to match.  

 

And most artists who will work for free are both unwilling and unable to follow a strict style guide.  

 

The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.

For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets.  They are also more motivated by fandom.

However, this is also illegal.

 

For programming, it's a little easier for somebody to drop in and contribute a function or two.

 

In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.

 

If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment.  You'd basically just be finding an artist to work for to make his or her game idea.  And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.  

 

Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.


Edited by StarMire, Today, 09:37 AM.


#8 SpiritBlade   Members   -  Reputation: 131

Like
0Likes
Like

Posted Today, 12:13 PM

If he's talking about getting people to work on the project for free, though, these things become much more complicated.

 

Game design needs to be done from day 1.

 

Only as little as possible to avoid severe creative differences.

 

Nobody wants to work for free on somebody else's game design.  It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.

 

You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members.  Such as:  one only likes JRPGs, the other only likes FPS - how do you resolve this?  You don't.  You only recruit one of them based on their having similar interests in line with the overall goal.

 

Narrow it down only just enough, but leave it open so contributors can feel like it's their game.  Achieving that balance in itself is something of an art.

 

 

Art and style guides needs to be done from day 1.

 

 

Where volunteer projects are concerned, that's almost impossible.  People will come and go from week to week, maybe only contribute a couple sketches, or one sprite.  Things are unfortunately very unlikely to match.  

 

And most artists who will work for free are both unwilling and unable to follow a strict style guide.  

 

The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.

For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets.  They are also more motivated by fandom.

However, this is also illegal.

 

For programming, it's a little easier for somebody to drop in and contribute a function or two.

 

In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.

 

If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment.  You'd basically just be finding an artist to work for to make his or her game idea.  And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.  

 

Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.

Some very valid points thank you. I plan on doing a 50/50 deal where the project is concerned. What I would really like to do is get a small group together, maybe 2-5 members and form a permanent team for this project and future ones as well to share the revenue equally with and pay for services we need from freelance/professionals as the project calls for it. I realize this is a large goal to have but something I have been wanting to make happen for quite some time. I don't have any high expectations of his happening over night and I will be doing as much work individually as I can until I achieve success so I am making sure to set some guidelines to follow. I had a team I worked with before on a MMO project and it failed miserably due to A LOT of the circumstances you guys have listed and what you have posted is really going to help me with this so it is much appreciated. Thanks guys!


You have to believe that GOD is in Control, therefore there is NO need to be stressed out OR worried!


#9 StarMire   Members   -  Reputation: 625

Like
0Likes
Like

Posted Today, 12:43 PM

What I would really like to do is get a small group together, maybe 2-5 members and form a permanent team for this project and future ones as well to share the revenue equally with


Well, unless you've literally known these people for many years, and have experience working with them and get along well, there's not really such a thing as a permanent team like that. Revenue share just doesn't keep people with projects, since as soon as a seed of doubt it sewn, the distant "maybe" of money isn't a motivator.

Like slayemin said, you need to expect anybody or everybody to come and go. The only person you can be certain to rely on is yourself- and that is, only if you keep at it and don't let anything get you down (as they say, if you fall off the horse...).
 

and pay for services we need from freelance/professionals as the project calls for it.


The best thing you can do with limited resources for recruiting is probably to commission one really good piece of art (not too big), that represents the general concept and feeling you want to go for.

A picture says a thousand words- and when you own the art, that proves to people who see it that you mean business and you can get something done.

A website wouldn't hurt either.

From there, whether it's themed as some Eldritch horror, or about anime style kittens, you have a central concept piece you can use to recruit with, thus creating a central point of agreement for the team and goal piece (getting people who like whatever it is you've made so far).

Make sure not to be too specific in the piece. Just promo to get at the feeling you want to convey.

Whether the team agrees after that it should be an FPS, a JRPG, a Sidescroller... well, that's doesn't matter yet. Just work on some idea people can rally behind, and inspire the passion to get to the next step.

It's how fan games work, and if you want to motivate people to be involved for profit share (as hard as that is), you need them to be fans of something you've done/started with.


Edited by StarMire, Today, 12:45 PM.


#10 slayemin   Members   -  Reputation: 2608

Like
0Likes
Like

Posted Today, 12:46 PM

If he's talking about getting people to work on the project for free, though, these things become much more complicated.

Yes, I agree. Free labor is cheap, but you get what you pay for. I think volunteer projects are great for learning new things and getting experience, but it's excruciatingly difficult to seriously build a game which you want to release based on free labor. I personally would never attempt it or join a volunteer project. That's not to say it can't work though. I met a team of developers upstairs in our building who are all working together for free on an HTML5 MMO (top down shooter). Each of them are living off of personal savings from prior jobs and have been slaving away on this project for almost two years. One of them has until next summer until his bank account runs dry, so you can guess what kind of stress and pressure they're under. So, I suppose it's worth noting that "free" labor is never free for everyone -- bills and living expenses don't stop.

Game design needs to be done from day 1.

 
Only as little as possible to avoid severe creative differences.
 
Nobody wants to work for free on somebody else's game design.  It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.
 
You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members.  Such as:  one only likes JRPGs, the other only likes FPS - how do you resolve this?  You don't.  You only recruit one of them based on their having similar interests in line with the overall goal.
 
Narrow it down only just enough, but leave it open so contributors can feel like it's their game.  Achieving that balance in itself is something of an art.

I disagree and still stand by my original claim.

Imagine you're brought on as an artist onto a project and are told by someone, who doesn't really know what they want, to make the art for their game. You have no idea what they're trying to build and it could change at a moments notice. A detailed game design is something solid to stand on and something to work off of. It tells you exactly what needs to be built and how it should all work together with other parts of the game. Without it, it's like you're standing on a constantly shifting sand dune which changes form with the winds. When you have to build concrete assets, it's excellent to have as much requirements definition as possible. Naturally, the game designer can't detail out every single nuanced detail, so the *creative* part for an artist is in the actual creative production of the asset. The look, feel, character, style, etc.

If you think the artist is going to be annoyed by a lack of definition, just imagine how much more annoyed a programmer would be (speaking as a programmer myself). I WILL not write up a complete game system if I don't know exactly how it needs to work. There isn't any "figure it out as you go". I also happen to design my own game, but I haven't designed all software I've built. There is nothing more sexy to me as a programmer than an air tight design. There's no thinking required, just implement it to the spec! There is no confusion. You know what needs to be built. It's very refreshing to work on projects with clear definition.

One thing you do allude to, which is critical, is "stakeholder buy-in". You don't need to give everyone on the team creative control / input on the game design. Chances are actually really good that most people are actually not very good game designers. It's actually *really hard* to do correctly. A programmer is an expert at writing code. An artist is an expert at art. A producer is supposed to be an expert at project management. A writer is an expert at writing. Game designers are experts at building game systems. You wouldn't want your artist writing code, or your programmer creating art, so why would you have either of them doing game design? That's not their specialty, and not the only way they have creative input into the production of a game.

Art and style guides needs to be done from day 1.

Where volunteer projects are concerned, that's almost impossible.  People will come and go from week to week, maybe only contribute a couple sketches, or one sprite.  Things are unfortunately very unlikely to match.  
 
And most artists who will work for free are both unwilling and unable to follow a strict style guide.  
 
The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.
For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets.  They are also more motivated by fandom.
However, this is also illegal.
 
For programming, it's a little easier for somebody to drop in and contribute a function or two.
 
In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.
 
If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment.  You'd basically just be finding an artist to work for to make his or her game idea.  And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.  
 
Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.

Yes, this is bad. What you describe is exactly what you want to avoid in a serious project. Pick any well produced game and really look at the art style in it. It's consistent. The color palettes are intentionally chosen to create an intended feeling / atmosphere. Think of Skyrim, how they have a bit of a saturated color palette and pretty realistic character models and environments. Now, imagine what Skyrim would have looked like if they had 30+ artists come in, each with their very own unique interpretations on what the game should look like. Some would go for a my stylized approach, others go for hyper-realistic, some go for cartoonish, etc. In a vacuum, each art asset would look good, but when you put them all into the same universe together, you can't convince the player that the game world has consistency and you break the suspension of disbelief, which causes a loss of player immersion (which some mods break).

As for programming, it's equally problematic to have people pop in and write up a function or two and disappear. As a programmer, you *have* to be familiar with the code base / framework you're working within. That costs time for us to get familiar with it (ramp up time). If a programmer doesn't spend time getting familiar with what they're working with, they run a huge risk of breaking something or writing code which has already been done.

Anyways, I guess my whole point here is that people are super important to the success of a game project. In some jobs, people can be treated like interchangeable components -- not in game development! The ramp-up time for a person to really get into a project and become an expert is long, and you can't ever carelessly throw away your most valuable resource (staff) through people mismanagement. If you're going to be serious about building a game and releasing it commercially, you can't afford to screw up the building of your team. If you're just working on a school project or hobby project, recruit away!

Eric Nevala

Indie Developer | Dev blog


#11 slayemin   Members   -  Reputation: 2608

Like
0Likes
Like

Posted Today, 12:53 PM

A picture says a thousand words- and when you own the art, that proves to people who see it that you mean business and you can get something done.
A website wouldn't hurt either.

From there, whether it's themed as some Eldritch horror, or about anime style kittens, you have a central concept piece you can use to recruit with, thus creating a central point of agreement for the team and goal piece (getting people who like whatever it is you've made so far).

Make sure not to be too specific in the piece. Just promo to get at the feeling you want to convey.

Whether the team agrees after that it should be an FPS, a JRPG, a Sidescroller... well, that's doesn't matter yet. Just work on some idea people can rally behind, and inspire the passion to get to the next step.

It's how fan games work, and if you want to motivate people to be involved for profit share (as hard as that is), you need them to be fans of something you've done/started with.


One thing I'll add here is that you also have to think as a project manager.

How much time does it actually take to build an art asset with a set style? How does changing the style change the time it takes to build the asset?

If you aim for hyper-realistic art assets, it's going to take a LONG time. How many assets need to be created? How long can the project go before finances run out?

In my case, we *have* to aim for a bit more of a stylized art style because it's faster to create less detailed art and there's a LOT of art which needs to be created. It's odd, isn't it? That a project's constraints would actually have a big impact on the art style which gets used?

Eric Nevala

Indie Developer | Dev blog


#12 StarMire   Members   -  Reputation: 625

Like
0Likes
Like

Posted Today, 02:12 PM

Imagine you're brought on as an artist onto a project and are told by someone, who doesn't really know what they want, to make the art for their game.

 

I think you misunderstood.  I'm saying if you're not paying them, you have to give them a large influence over the design of the game.

 

If you're actually getting paid, naturally you want to know exactly what the client wants (because at that point they're a client) so you don't have to redo anything.

I think that goes for any contractor.

 

Let's say, for example, you're making a JRPG.

 

Turn your Volunteer artists loose making monster concepts, and also let them make up the story and some of the abilities of those monsters, where they show up, etc.

 

It's a juggling act to delicately balance and mitigate bad ideas which will inevitably come along with the good.

 

In a volunteer project, the project manager and often lead designer's work is very different, and runs more along the lines of disaster control, and trying to shoehorn all of the ridiculous nonsense people come up with into something that kind of works together.  

 

You have to make everybody feel like they're making big important contributions to the design of the game, and not just coming up with an art style (which, trust me, is not enough to keep your artists happy if you're not paying them: it's like telling programmers they can comment their code however they want, but to do this and that for free; people have certain passions, and you have to play to those to keep them motivated).

 

If you have money to pay, then by all means, that's always the best.

 

 

One thing you do allude to, which is critical, is "stakeholder buy-in". You don't need to give everyone on the team creative control / input on the game design.

 

Unfortunately, you usually do if you're not paying them.

 

Think of it this way:

 

Everybody thinks their own ideas are awesome and will make millions of dollars (no matter how much they actually suck).  People will only risk a revenue share later if they're under the delusion that their own grand ideas are the force that's going to push the project to financial success.

 

Whether those grand ideas are about talking swords that transform into dinosaurs, or a race of cat people who have three sets of ears.

 

It's a functional necessity in a volunteer team to humor whatever you get.

 

 

 

Chances are actually really good that most people are actually not very good game designers. It's actually *really hard* to do correctly. A programmer is an expert at writing code. An artist is an expert at art. A producer is supposed to be an expert at project management. A writer is an expert at writing. Game designers are experts at building game systems. You wouldn't want your artist writing code, or your programmer creating art, so why would you have either of them doing game design? That's not their specialty, and not the only way they have creative input into the production of a game.

 

Absolutely true.

 

You wouldn't necessarily want them to.  Unless you want them to actually get any work done at all without paying them. ;)

 

If you've run a volunteer team, or worked on one, before you start to understand the nearly impossible situation the project lead ends up in.

 

Like I said, if you have money to spend, it's better to just contract people, in which case you're right that they'll want clear direction.

Unless you meet a rare gem who has really good ideas.

 
 

Yes, this is bad. What you describe is exactly what you want to avoid in a serious project.

 

 

Absolutely, which is something that makes commercially viable free/volunteer projects nearly impossible.  Successful teams are rare and neigh mythical creatures, with a strong shared passion and usually years of friendship and working together in person.

 

Mismatched graphics and buggy execution is something I expect from hobby indie projects: it's not the end of the world to just get something done and get the experience you need from it.

 

Once things are just *done* you can always go back and clean things up, and invest in new art, etc.  The point is to get things done at that stage of the game.



#13 StarMire   Members   -  Reputation: 625

Like
0Likes
Like

Posted Today, 02:22 PM

One thing I'll add here is that you also have to think as a project manager.


How much time does it actually take to build an art asset with a set style? How does changing the style change the time it takes to build the asset?

If you aim for hyper-realistic art assets, it's going to take a LONG time. How many assets need to be created? How long can the project go before finances run out?

In my case, we *have* to aim for a bit more of a stylized art style because it's faster to create less detailed art and there's a LOT of art which needs to be created. It's odd, isn't it? That a project's constraints would actually have a big impact on the art style which gets used?

 

 

Oh, yes.  Sorry I didn't mention that.

 

You almost have to choose a style in which to stylize (at least a little).  

Realistic graphics are out of reach to all but the biggest studios, and even they are shying away from them now because from a business perspective they don't do much for you: They just cost more, and don't really help much with marketing (and will kill you if you fall short and hit the uncanny valley instead), since the consumer is very accepting of stylization.

That is, unless you're dealing with a particular IP or genre that traditionally requires realism for the AAA titles- usually sports and war simulation.

 

Before establishing your art style, do some tests to figure out if you can pull it off in your budget.

 

Tell us more about your game and what you want to achieve art-wise here:  http://www.gamedev.net/forum/18-visual-arts/

I'm sure we'll be able to give you some good suggestions for style when you're ready.

 

Your target image that you create for recruitment is your ideal, so you don't need to worry too much about functional game assets at that point, but do try to choose a non-realistic style that you like and that you think people will be able to get behind, and showcase that, since it will be a big part of your game.







PARTNERS