Hi everyone,

As title,i'd like a few adivice on how a team for making a simple 2D JRPG should be like.
I've already been into a game project (not jrpg) but it gone after 3 weeks because 2 concept artists,1 modeller and the former (modeller) were basically always inactive.One of them even reaplyed me to a mail after an half year when the project was totally abandoned...
The only active one was the good guy story writer.

Anyway,(oh,i'm a programmer) i'm going to complete the engine (Map Editor,Scripted dialogue,GUI system,Script system,game entities and so on..) to have less work on the programming side when the project starts.So as soon it's complete,i'd like to use it for a small game.

I really want to start and finish a project because i want something done in my portfolio.
How a team for this kind of game should be formed? (I mean,how many people and in which role)
And how can i avoid to have all those inactive people like the last time?

Thanks in advance.

Interview people beforehand. If somebody does not put in their dues, they are given a warning and then dropped from the project to find someone new.

I learned this first putting together rock bands, and now working with groups doing games.

Interview people beforehand. If somebody does not put in their dues, they are given a warning and then dropped from the project to find someone new.

I learned this first putting together rock bands, and now working with groups doing games.

how do you calculate what their dues are?
how much work must they have done per day or week etc?
what counts as work?

[quote name='dakota.potts' timestamp='1353645478' post='5003375']
Interview people beforehand. If somebody does not put in their dues, they are given a warning and then dropped from the project to find someone new.

I learned this first putting together rock bands, and now working with groups doing games.

how do you calculate what their dues are?
how much work must they have done per day or week etc?
what counts as work?
[/quote]

All of these are dependent on the group and should be discussed during the interview. OP has had people drop off and not e-mail him until 6 months later. That is obviously not paying any dues or contributing any work. As far as the specifics (The whens, hows, whys, and wheres), that is up to both parties to decide.

[quote name='glhf' timestamp='1353646828' post='5003378']
[quote name='dakota.potts' timestamp='1353645478' post='5003375']
Interview people beforehand. If somebody does not put in their dues, they are given a warning and then dropped from the project to find someone new.

I learned this first putting together rock bands, and now working with groups doing games.

how do you calculate what their dues are?
how much work must they have done per day or week etc?
what counts as work?
[/quote]

All of these are dependent on the group and should be discussed during the interview. OP has had people drop off and not e-mail him until 6 months later. That is obviously not paying any dues or contributing any work. As far as the specifics (The whens, hows, whys, and wheres), that is up to both parties to decide.
[/quote]

i think you must be very precise when making such a contract im pretty sure you could get sued bigtime if you kick someone off a team when they wasnt breaking the contract.
what would an example of contract be?

an amount of hours put into work?
for example coding?

then you must also somehow have it written in contract how much work he should be able to do in one hour.

because if you kick him off team because he did so little work even though he did sit infront of computer working the least amount of hours required then i think he could sue you.

how do you do all this stuff?

also you could ofcourse kick him anyityme you want but then he must be your employee not a partner.
and most indys are all partners in their teams because they usually work for shared revenue.

[quote name='dakota.potts' timestamp='1353647997' post='5003380']
[quote name='glhf' timestamp='1353646828' post='5003378']
[quote name='dakota.potts' timestamp='1353645478' post='5003375']
Interview people beforehand. If somebody does not put in their dues, they are given a warning and then dropped from the project to find someone new.

I learned this first putting together rock bands, and now working with groups doing games.

how do you calculate what their dues are?
how much work must they have done per day or week etc?
what counts as work?
[/quote]

All of these are dependent on the group and should be discussed during the interview. OP has had people drop off and not e-mail him until 6 months later. That is obviously not paying any dues or contributing any work. As far as the specifics (The whens, hows, whys, and wheres), that is up to both parties to decide.
[/quote]

i think you must be very precise when making such a contract im pretty sure you could get sued bigtime if you kick someone off a team when they wasnt breaking the contract.
what would an example of contract be?

an amount of hours put into work?
for example coding?

then you must also somehow have it written in contract how much work he should be able to do in one hour.

because if you kick him off team because he did so little work even though he did sit infront of computer working the least amount of hours required then i think he could sue you.

how do you do all this stuff?

also you could ofcourse kick him anyityme you want but then he must be your employee not a partner.
and most indys are all partners in their teams because they usually work for shared revenue.
[/quote]

From what I understand, OP doesn't have the resources to be entered into any kind of a legal contract. He's building a portfolio. It's not a business endeavor. It's a hobby or an art form. OP is perfectly free to work with whomever they want and break partnership with whoever they want same as a band, acting troupe, or a couple of artists who paint together.

For signing a contract, I'm going to expect a lot more than that. But I'm also at HipK's level and would be willing to put time in on the project if I didn't have a couple of my own.

Now, kicking the person and then using their IP can land you in big trouble. The way I look at it, my IP is mine until I receive payment for signing it away and I won't sign it away without that.

Hello HipK, are you doing this in parallel with your college or education? I think this is very good intention but seeing the replies from other OPs, I think you'd be better to state this clearly. If that's the case, I'm afraid I can share some experience.

I've already been into a game project (not jrpg) but it gone after 3 weeks because 2 concept artists,1 modeller and the former (modeller) were basically always inactive.One of them even reaplyed me to a mail after an half year when the project was totally abandoned...

I've been there and I can tell you this is very likely to be the case in... 4 cases out of 5 (because I've given up at the fifth).
What I found is that the persons who didn't give up were the ones I trusted since start. Rather than interviewing them, I've talked to them for weeks. You can explicitly ask them something but mostly you run the checks yourself. Question such as

1. Do this (wo)man show consistent attitude and hobbies? This is an indication of how much they are really interested in those activities.
   
2. Are they party addicts? There's no problem in having fun. But if the fun must go on starting Thursday night, you can bet productivity is not going to be all that great.
   
3. How often they explicitly show support/opposition to someone else idea? This is an indication of their teamwork quality. Under NO circumstance take someone who argues on bike shed discussions. They must be able to focus on the goal.
   
4. Now that FB is around: look at their profile. You'll find out for example that... I'd rather not talk about that.
   

Anyway,(oh,i'm a programmer) i'm going to complete the engine (Map Editor,Scripted dialogue,GUI system,Script system,game entities and so on..)

That's an hell of work for a single dude. With at least another team mate, you'll end up in extreme pressure. I can tell you because I was there (except I had a programming team mate).
On the pro side, many years ago a member actually manged to do a JRPG. But you'll have to keep it simple. You really want a proof of your skills rather than a "commercial" product.

I really want to start and finish a project because i want something done in my portfolio.

Way to go! I wish you success! Remember: this is your target, not something commercial quality. In the end I had to give the middle finger to everyone and focus on something I can do myself.

1. How often they explicitly show support/opposition to someone else idea? This is an indication of their teamwork quality. Under NO circumstance take someone who argues on bike shed discussions. They must be able to focus on the goal.
   

Just a question about this.. If the team member is arguing against your idea.. you think he is a bad team member?
Maybe it's other way around because you don't want to argue (reasoning about if it's really such a good idea).
Maybe his arguments are right and thats the reason you don't want to argue because you can't argue against whats right.
If you are the designer then it's true that the designer should have most of the time final say on anything that is designers job but designer should still be open minded to feedback.
But you did say that you were programmer.
arguing is a good thing it's just uncomfortable to argue with most people because it can feel like fighting but it's really just reasoning.
Good arguing is when it's done with intelligence, logic and sense and calmness.

But you are right about one thing..
You should only work with people you "trust".
If you feel after talking with them that you are on the same channel and agree about most if not everything when just chit chatting about games in general.

You can't work together if you are interested in different types of games.. unless you are doing it for business just.
Then you should be able to work on a game even if you wouldn't enjoy playing it as long as market research shows the game will have a lot of players.

And if you are programming for a game you yourself wouldn't enjoy playing then you will for sure not argue about any design.

First of all thanks for the replies.
Yes,the project will surely be a not payed one,so the main reason
for someone to join in is the opportunity to have somenthing for a portfolo.
Making experience is useful to everyone,hardly someone will
offer you a paid project without it.

@dakota The problem whith officially kicking out people is that
they could get angry,even after a while and deny you the right
to use their works.
I was thinking more to a "leave them inactive and just replace them"
thing.
What do you think of it?

@Krohm The idea to keep costant contact with them (without beibg ossessive )
is a nice one.At least i'll have a stable feedback.
Yes,i'm frequenting university,but I always put at least 3-4 hours
into the project every evening.
For the engine:I know it's a bit of work but I prefer to have all
te programming part on me to avoid delays from others.

Anyway,just to have an idea,how many people should I look
for in the beginning to make sprites etc.?


Thanks again.

Ps:sorry for not quoting and for mistakes but i'm writing
from a mobile.

You can't just drop people and use their work. They still hold copyrights unless you have a contract saying they forfeit their copyright if they are inactive for X time.

My suggestion here would be to create a game that doesn't require fancy art. From experience, artists will rarely work for free. Pixel artists even less. This might also have the benefit of scoping down the project and allowing you to actually finish it.

About arguing with team member, it's usually a good thing up to a point. Sometimes, you run head first into a wall and the only thing that can save you is someone hitting you with a baseball before you reach the wall. However, it must not be taken personal. If someone starts saying "use MY idea or I quit!!!1", then you should definitively not use their idea and find someone else. The better ideas will be created when you try to bridge different concepts in a simple and efficient way.