Hello Gamedev.net! I have recently started an indie group and we are working on a game because our ambition is to have a product by the time we graduate in an attempt to gain entry to the Game Industry. The cruel part being the only way to get into the game industry is to have experience in the game industry.
A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything? Feedback would be very appreciated!
1
Indie Game Development
Started by Godoflaugh, Nov 05 2012 11:14 PM
11 replies to this topic
Ad:
#2 Members - Reputation: 4604
Posted 06 November 2012 - 12:09 AM
Well.. how large is your group that you need divisions .... from my experiences organisation structures hinders development more than it helps. You might look at agile development methods which help developing software in a team based fashion.I've attempted to recreate an actual company feel through creating divisions within the group,
Ashaman
My game: Gnoblins
Developer journal about Gnoblins
Small goodies: Simple alpha transparency in deferred shader
My game: Gnoblins
Developer journal about Gnoblins
Small goodies: Simple alpha transparency in deferred shader
#3 Moderators - Reputation: 4819
Posted 06 November 2012 - 12:24 AM
A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything?
This question is not about Game Design. Moving it to Producing/Managing.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com
Please do not PM me. My email address is easy to find, but note that I do not give private advice.
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com
Please do not PM me. My email address is easy to find, but note that I do not give private advice.
#5 Members - Reputation: 117
Posted 06 November 2012 - 03:53 AM
Well.. how large is your group that you need divisions .... from my experiences organisation structures hinders development more than it helps. You might look at agile development methods which help developing software in a team based fashion.
I have about ten people working together on the project, and we are all from different area's of study some computer science, art, music, business, marketing, and other fields. I felt by having each person work on their area of expertise and then have one or two people in the middle organize and manage the team would be very effective.
#6 Members - Reputation: 1714
Posted 07 November 2012 - 09:23 AM
It really depends.
Is the scope of the project and vision clear to everyone? Is it fixed, or do you expect to iterate?
Who are the stakeholders, who do you expect to potentially alter the scope of the end-product?
What are your expectations and what do you want to ship, and when?
Is the scope of the project and vision clear to everyone? Is it fixed, or do you expect to iterate?
Who are the stakeholders, who do you expect to potentially alter the scope of the end-product?
What are your expectations and what do you want to ship, and when?
#7 Members - Reputation: 117
Posted 08 November 2012 - 09:55 AM
Yes I have made it my goal as project lead to get everyone on the same page, and from the feedback that I am receiving from them at each weekly meeting is very positive. Currently the project is still a bit open and we are able to iterate new ideas and concepts, since it is still in the early stages of development.
Currently I have no stakeholders, and I'm unsure of changing the scope since the concept we are working with currently is still being fully developed.
My expectations for this game is to have a deliverable by the end of next year, and ship about 6 - 8 months after that, but that would be the most optimal timeline.
Currently I have no stakeholders, and I'm unsure of changing the scope since the concept we are working with currently is still being fully developed.
My expectations for this game is to have a deliverable by the end of next year, and ship about 6 - 8 months after that, but that would be the most optimal timeline.
#8 Members - Reputation: 1714
Posted 08 November 2012 - 10:27 AM
Note that I said "who" not "do you". If you don't have stakeholders, you still have people that will make the ground decisions. Are you the sole visionary of this project, or do you have any form of tech or creative input and direction from other members on the team? Who has a say, who has the responsibility, and who is accountable for these decisions precisely?who do you expect to potentially alter the scope of the end-product?
This is a critical information before you can determine whether you want to structure openly or not.
#9 Moderators - Reputation: 4819
Posted 08 November 2012 - 10:46 AM
Currently I have no stakeholders
That's not true. Everyone who's involved in the project has some kind of stake in it.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com
Please do not PM me. My email address is easy to find, but note that I do not give private advice.
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com
Please do not PM me. My email address is easy to find, but note that I do not give private advice.
#10 Members - Reputation: 117
Posted 08 November 2012 - 11:00 AM
That's not true. Everyone who's involved in the project has some kind of stake in it.
I was mistaken then, yes Tom you are correct everyone in my group then does have a stake in building this game.
In this design process, I am not the sole visionary everyone on the team is putting their input in and helping to develop the game. Because I believe having only one creative input has a tendencies to give a blandness, since my team is inter-disciplinary it gives a very wide range of design space to work with since everyone in the group has great ideas. However I am organizing everything, and have final say in the process, however I am very open to changes from my team. The person that is responsible for the group would be me, I am assuming responsibility/accountability for the group. I hope this answers your question, hopefully I'm not misinterpreting again.Note that I said "who" not "do you". If you don't have stakeholders, you still have people that will make the ground decisions. Are you the sole visionary of this project, or do you have any form of tech or creative input and direction from other members on the team? Who has a say, who has the responsibility, and who is accountable for these decisions precisely?
This is a critical information before you can determine whether you want to structure openly or not.
Edited by Godoflaugh, 08 November 2012 - 11:02 AM.
#11 Members - Reputation: 1714
Posted 08 November 2012 - 01:24 PM
Then:
What do you mean exactly. What is the average day like? What is your process? How do you get to review what's been done and what needs to be done from there on?
What everyone's average day looks like? Are they secluded focusing on their work, or do they interact with others in order to define how to shape things up?
I think you can't reasonably demand that every engineer on the team makes art, but its not impossible for an engineer to help out with art.
The general pro you can have by determining core roles is that you can ensure a core balance: if 50% of your members are engineers, you can expect about 50% of the team to deliver technical stuff. This doesn't mean none of them can make art, but common sense implies people will perform better if they do what they do best.
On the other hand, if you do have people proficient with more than one thing, then, what they do best is simply different.
I'd recommend to build your team around the people you have, identifying everyone's strengths and weaknesses.
Let me give you an example of what I mean:
On a recent project, I was given 3 programmers. What I was told by higher management is that one of them was kickass, another average, and the last, borderline ok. These were judgments based off a very restrictive grid analysis of their performance in terms of logic. Basically, it reflected whether they could make good code or not.
What they left out unintentionally, is what each of their strengths and weaknesses were.
The Good Programmer was kickass, but he needed very strict requirements. He could only work by making an analysis of a formal and detailed Technical Design Document (TDD). On a project where requirements are known, not subject to change, and the output quality is not "guessed", you'd want to clone this guy and use him wherever possible.
The average guy was more of a frontend programmer with a strong ascendant for art. His code was decent, but he's really more the kind of guy you'd want to make sure things make sense. He had a keen sense of figuring out design flaws that would make the game irrelevant. This guy actually helped me out identify design flaws back when they were still in design. As you might know, the later you figure out the flaw, the more it ends up costing. So he was a big help.
The borderline ok coder was actually the one I relied the most on. This guy was what I like to call a gameplay programmer: he's a gamer first, with some technical knowledge. Chances are the kickass coder will have to tell him his errors, help refactor his stuff, etc, but his input is invaluable, and he'll be the one with the patience to fine-tune feedbacks and timings to make the difference between a game "as designed" and a kickass product. It really added a lot that he was also part of the target audience of the project, so he made extra researches, etc. In the end, while his input as a programmer was "ok", his general contribution made him a necessary component of the project's success.
If you divide people formally by department, you might miss on this, then again, if you don't give a more or less formal line, you'll end up creating chaos.
Define roles, not professions. Make people owners of specific modules/features, not tasks. You'd be amazed at how many times I've shipped a title with prog-art just because someone felt involved in the project and decided he'd deliver his absolute best. Give the people some freedom, but keep the line straight. Everyone needs to understand the vision, and how to get there.
Then again, know your team. Some team-member's weakness is that they just don't work that way. They need to be told what they need to do, and they'll do it remarkably well. Not everyone is a visionary, and that's ok. Once you've identified who's a "soldier" and who's a "visionary", make them understand they are the same team. No one is bossing each other out. The temptation of a visionary to boss soldiers is a constant pressure that you need to diffuse. Make them work together, but insure you keep that fine balance. Understand that everyone's thrill and challenge doesn't necessarily lie at the same step. Some people are thrilled by creating the idea, others by developing it from A to Z, and others yet by polishing it to A+.
A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything? Feedback would be very appreciated!
What do you mean exactly. What is the average day like? What is your process? How do you get to review what's been done and what needs to be done from there on?
What everyone's average day looks like? Are they secluded focusing on their work, or do they interact with others in order to define how to shape things up?
I think you can't reasonably demand that every engineer on the team makes art, but its not impossible for an engineer to help out with art.
The general pro you can have by determining core roles is that you can ensure a core balance: if 50% of your members are engineers, you can expect about 50% of the team to deliver technical stuff. This doesn't mean none of them can make art, but common sense implies people will perform better if they do what they do best.
On the other hand, if you do have people proficient with more than one thing, then, what they do best is simply different.
I'd recommend to build your team around the people you have, identifying everyone's strengths and weaknesses.
Let me give you an example of what I mean:
On a recent project, I was given 3 programmers. What I was told by higher management is that one of them was kickass, another average, and the last, borderline ok. These were judgments based off a very restrictive grid analysis of their performance in terms of logic. Basically, it reflected whether they could make good code or not.
What they left out unintentionally, is what each of their strengths and weaknesses were.
The Good Programmer was kickass, but he needed very strict requirements. He could only work by making an analysis of a formal and detailed Technical Design Document (TDD). On a project where requirements are known, not subject to change, and the output quality is not "guessed", you'd want to clone this guy and use him wherever possible.
The average guy was more of a frontend programmer with a strong ascendant for art. His code was decent, but he's really more the kind of guy you'd want to make sure things make sense. He had a keen sense of figuring out design flaws that would make the game irrelevant. This guy actually helped me out identify design flaws back when they were still in design. As you might know, the later you figure out the flaw, the more it ends up costing. So he was a big help.
The borderline ok coder was actually the one I relied the most on. This guy was what I like to call a gameplay programmer: he's a gamer first, with some technical knowledge. Chances are the kickass coder will have to tell him his errors, help refactor his stuff, etc, but his input is invaluable, and he'll be the one with the patience to fine-tune feedbacks and timings to make the difference between a game "as designed" and a kickass product. It really added a lot that he was also part of the target audience of the project, so he made extra researches, etc. In the end, while his input as a programmer was "ok", his general contribution made him a necessary component of the project's success.
If you divide people formally by department, you might miss on this, then again, if you don't give a more or less formal line, you'll end up creating chaos.
Define roles, not professions. Make people owners of specific modules/features, not tasks. You'd be amazed at how many times I've shipped a title with prog-art just because someone felt involved in the project and decided he'd deliver his absolute best. Give the people some freedom, but keep the line straight. Everyone needs to understand the vision, and how to get there.
Then again, know your team. Some team-member's weakness is that they just don't work that way. They need to be told what they need to do, and they'll do it remarkably well. Not everyone is a visionary, and that's ok. Once you've identified who's a "soldier" and who's a "visionary", make them understand they are the same team. No one is bossing each other out. The temptation of a visionary to boss soldiers is a constant pressure that you need to diffuse. Make them work together, but insure you keep that fine balance. Understand that everyone's thrill and challenge doesn't necessarily lie at the same step. Some people are thrilled by creating the idea, others by developing it from A to Z, and others yet by polishing it to A+.
