How much time do I need per day?- about 1 - 2h is OK then I mean then you need to code not playing around and just being in Skype.- else if like 6 - 12h pew day would be awesome that's my time so having 3 more members with that time = OP!

6-12h! Wow. Congrats on finding ANYONE who wants to work for that long without earning anything.

I spent several years doing just that. Now I work 8-10h a day to earn approximately $10. Or occasionally the odd $100k.

I spent several years doing just that. Now I work 8-10h a day to earn approximately $10. Or occasionally the odd $100k.

Cas

Yes but the obvious difference here is that you were getting paid (and quite well too!). OP here wants us to devote a huge chunk of our day to a team that isn't going to make a profit. And yes, while money isn't everything, we all know that we need money to live. Programming 8 hours a day for your job is completely different than coding 8 hours a day for some random stranger who already has stated he isn't going to pay you a dime for all your hours you spend slaving over a game when you could be doing something else productive.

...and just an observation: why does everyone seem to want to form teams these days? You can accomplish vast amounts just on your own. Much more than you'll probably achieve with even two people. Every extra person you add to a team wastes a significant % of time to communications overhead. If there's anyone you really need to find, it's an artist.

Thats gotta be the most constructive thing said in this thread so far. Very true. I had never worked with an artist before until recently, and man, its so nice (assuming you like the artist, and the artist is any good).A game is so much more quickly done without f**king around with "placeholder" textures or trying to do both art and programming.

...and just an observation: why does everyone seem to want to form teams these days? You can accomplish vast amounts just on your own. Much more than you'll probably achieve with even two people. Every extra person you add to a team wastes a significant % of time to communications overhead. If there's anyone you really need to find, it's an artist.

Cas

Although I agree with most of this, team members mixed with bad communication usually ends in disaster and results in poor planning and structure.

However, 2 minds put together is far better than 1. In almost every single situation. The only situation this is not effective in, is when you try it with someone who is stubborn and close minded.

Try playing a puzzle game yourself, then try it with a friend watching as well. Goes the same for debugging, 2 people are going to spot the problem much quicker than 1.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

...and just an observation: why does everyone seem to want to form teams these days? You can accomplish vast amounts just on your own. Much more than you'll probably achieve with even two people. Every extra person you add to a team wastes a significant % of time to communications overhead.

As someone who is guilty of teaming up, I think that some coders feel like teams get more done, regardless of the person's people skills. Also, they may just want to be a part of a team. Doesn't it make you feel professional when you are working with others? Because of this, a lot of people just overestimate their people skills, and fall into the trap of forming a team without proper coding experience, or people skills, like VirtueeL here.

However, 2 minds put together is far better than 1. In almost every single situation. The only situation this is not effective in, is when you try it with someone who is stubborn and close minded.

Try playing a puzzle game yourself, then try it with a friend watching as well. Goes the same for debugging, 2 people are going to spot the problem much quicker than 1.

Errrrmmmmm.... I don't know about this one.

The huge misconception...

There is one huge factor that is being forgotten, the fact that you need to be able to understand. Two huge problems generate from this...

You have to be able to read another person's code to help with debugging

You have to understand a person motives for your project

In all cases, this makes your communication overhead go way way up. I'll tackle each problem below...

Debugging...

All programmers don't write in the same way, and even with rules, we have a hard time following conventions. Programming is pretty personal and having someone tell you how you can write code is annoying. Programmers code best when they are comfortable with what they are writing. In groups, this is why it is almost inevitable that Unit Tests became so popular, because it allows programmers to write in a way where they feel most comfortable. This enhances programmer productivity by a lot because a programmer just has to focus on making it work (the end result), not making it pretty.

If you want someone to read your code, you are going to have to make it understandable enough for both of you. The other thing you'll need to do is make sure you both are able to look at the code at the same time. Finally, you'll have to be able to explain where the bug is to your partner in order to fix it. The amount of time saved with both programmers working together to solve a syntax bug is lost by communicating about the bug in the first place. You can avoid this by writing issues, but it still means that the issue needs to be written and that also lessens productivity by a little.

Where I realize that this isn't true is when you are talking about brainstorming or algorithmic problems. In this case, planning with another person allows a much more tighter flow of ideas. Both benefit off each other's great ideas and can find possible pitfalls earlier. In any process where a plan has to be made, I realize that having a think tank is pretty beneficial because most pitfalls that you would have crashed into are avoided because of the varying perspectives.

In short, for planning collaboration is awesome, but for debugging it isn't as clear cut.

Productivity vs. Communication

When working with anyone else, organization is the most difficult aspect to nail. In group projects, lack of a proper way point leads to lessened productivity. People crave belonging and attention in varying forms, and when we work, it is a very lonesome task. So we end up communicating to another person, to fill in the void. This is bad, as work never gets done in this state. It is difficult for human beings to be 100% focused on a task when communicating, and some are better than others on masking that weakness.

How do you overcome this?

By being organized and setting proper way points. If you don't know the correct process to create a project, then doing this will be excessively difficult. The last thing you want is people talking about how best to lead, or how ineffective of a leader you are. A good leader either needs to know the way to solving an issue, or give off the perception that they do. Understanding your own motives for creating a project will actually make it easier to figure out if other people are right for your project. If you and your partners motives match, you will be able to see past problems a lot easier. Knowing that your partner is working toward the same goal you are gives an ease of mind when solving issues because you know they are not in it to hurt your project's progress. Then, all you need to focus on is dividing up the work...

Divide and Conquer...

The maximum productivity occurs when each member of your group can work in a singular environment.

In war, for example, you have a group of soldiers with swords and bows. Chances are if you are telling all of them to attack the front lines, you wouldn't want them all to attack melee range into the enemy. You'll collaborate at first telling the soldiers to attack melee while the bowmen attack from the rear. Now, when the war comes, the worst thing you want is the bowmen walking up to the footmen asking them were they should attack from every 2 minutes. Each should know their task completely and just focus on that task. Your chances for winning is intensified the less your soldiers have to collaborate.

In other words, by having an artist and a programmer, each person has a specific job to do that they can work on for maximum efficiency. Collaboration then is only used as a way of measuring progress, rather than a way to distract from productivity. There is a reason why all jobs work in this fashion. Productivity works best when people have specific tasks. The less you have to collaborate to get work done, the more productive your project will be.

Last Thoughts...

Productivity is always maximized when you are working alone. The key to getting a group project to work is making it so that each member of that group has a task in where they can work without having to collaborate on it. In order to achieve this the two things that you need is...

A leader that can create a good plan

The ability to split your project to attainable tasks

When collaboration is used as a measurement of progress rather than a measure of understanding, group projects can become effective. (Oh, and one more thing, that is only a small percentage of what is needed to actually being an effective leader in a group environment. ) Sorry for the slight derail, but there is a lot more to group projects than people think...

...and just an observation: why does everyone seem to want to form teams these days? You can accomplish vast amounts just on your own. Much more than you'll probably achieve with even two people. Every extra person you add to a team wastes a significant % of time to communications overhead. If there's anyone you really need to find, it's an artist.

Cas

Working alone is fine but if you do it for years it gets REALLY old. That would be a reason for me to go looking for other people.

A two-headed team, its perfection in my eyes. You don't need to juggle with responsibilities yet you're not alone.

My thoughts on this team building process is that when working in small teams, you should just never have more than 1 person doing the same job. Have *1* programmer, *1* artist, *1* music guy, *1* sound effect guy, etc. Reason being, is it's a lot easier to to have different pots that have to work together than a bunch of people working out of the same pot.

As the indie level, aside from maybe the sound effects (and music if your music guys ahve similar styles) you are going to hit a huge problem with coding and graphic style differences, it's just better to keep them all dedicated to one person.

Having said all that, I think teams on our level is a bad idea unless you have really good team members. (As some have proven, they do exist!) But do teams generally workout? Not really..

and sorry to break it to ya VIrtueeL; but you yourself currently lack the maturity and core skill sets to be in a team. Much less lead one. There's nothing wrong with that, but you're just not ready for it yet. I suggest trying to *join* small teams first where the product is pretty straightforward, and try to do your absolute best when you're in one. But currently, you lack the experience to run one yourself.

- Know when to do ctrl - z, we will use Saros as our multi coding plug-in! that's why!

Can you tell me more about saros? I've never heard of it before. What are the main advantages of saros over a more classic approach like svn or git? What has this to do with CTRL+Z? Don't you think that it will be quite a pain to work with multiple people in the same project like this? Just from my coding experience, except for pair programming sessions, I don't want any other developer working in my code base. How will you work if one developer works on(and breaks) the rendering code and another developer is working on let's say the enemy AI. As long as the rendering is broken, the other developer is doomed to wait until the problems are resolved.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org