Working in a team question
-
Someone should be the architect and know the stuff well enough that he can write enough application skeleton so that every other developer can happily develop on his own little piece and integrate it seamlessly in the big picture. Other than that everyone can work on the little bit that he likes more...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
The more answers, the merrier! :)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Just get a good design chart started. Rather than worry about how to break up the team, just make sure it's modular (weather it's a functional chart, object design, etc) and then just work on it one piece at a time. Then anyone can pull from any part, and no one gets assigned a specific role.
So far it seems that a key pattern is, someone overlook the flow of information through the system and the others can add to it over time somewhat multi-responsibly. Big Grin | :-D Similar answer to what me and the team thought, but we are noobs - what do we know? xD
-
Someone should be the architect and know the stuff well enough that he can write enough application skeleton so that every other developer can happily develop on his own little piece and integrate it seamlessly in the big picture. Other than that everyone can work on the little bit that he likes more...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Its a good one, If only one person do the skeleton then the application will look like an application done by a team as one. It will be neat.
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
yes, and shout at them a lot. They will respect you for that. Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Our kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff The Snotgoblin for the Ipad -
yes, and shout at them a lot. They will respect you for that. Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Our kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff The Snotgoblin for the Ipadi found beer more effective!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
i found beer more effective!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Then Shouting them :beer: is the ultimate management tool. :thumbsup:
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
A five, Sir, for linguistic ingenuity!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
A five, Sir, for linguistic ingenuity!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
_Maxxx_ wrote:
A five, Sir, for linguistic ingenuity!
You are a gentleman.:thumbsup:
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
That's what you think :)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
That's what you think :)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
venomation wrote:
What roles could be subdivided logically in such a small team?
Height, weight, and age. Not necessarily in that order.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
-
venomation wrote:
What roles could be subdivided logically in such a small team?
Height, weight, and age. Not necessarily in that order.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
-
What I think does not really matter (Damned Banana Bender) now does it!?
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
Not one jot, sir, not one jot.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Thanks for a nice logical separation of responsibilities :-D
-
So far it seems that a key pattern is, someone overlook the flow of information through the system and the others can add to it over time somewhat multi-responsibly. Big Grin | :-D Similar answer to what me and the team thought, but we are noobs - what do we know? xD
More like one person should create the initial overview and structure that can be used for reference, and then step back and just be a normal team member, picking up coding tasks like everyone else. If re-thinks are needed, they can either be handled by discussion within the team, or by re-appointing one team member (not necessarily the same one) to the architectural role.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
I'm not sure you really should subdivide it into roles other than "let one guy make the calls in collaboration with the others". In game development this is commonly referred to as "lead programmer". Give this person responsibility to set up a time plan, discuss it with other people (designers, graphic artists, project leader ...) Once you have a timeplan you see what needs to be done, then just make sure that every programmer on the team has something to do every day and be sure to divide the tasks between you. Making sure that everyone gets something fun to do during the timespan that they can look forward to.
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
No roles, here's why: Let's keep it simple and say you have to build a web application. You have one html/css guy, one hosting guy and one usercontrol programmer guy. Now, suppose either one of them dies. What will happen to the project? It will be doomed! X| Better is to divide the project into small steps and make clear agreements who will/can finish which step at what given time. Have short meetings regularly to see if there are any unforeseen problems so you can change course or shift the schedule. The big advantage of a task-oriented approach is that it's concrete, everyone has equal control/responsibility over the project; so there's less nagging. :thumbsup:
Giraffes are not real.