Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / DNG - Project Manager Guidelines

Author
Message
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 7th Aug 2010 05:48 Edited at: 3rd Nov 2010 19:40
Hello, this thread is for experienced coders who want to run a project for Dark Noob Games. If you have any advice on how to run a team please post, I'd especially like to hear from people who have run DNG projects in the past.


Do oranges know what colour they are?
BN2 Productions
20
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 7th Aug 2010 09:28
One thing I learned way back in the days of Furious Pickaxe was break up the tasks early, often and into many parts. Frequently, progress is made in a "I'll do a little now and someone will finish later" which made it very hard to keep track of for larger assignments.

By breaking it up, it is easier to get them complete much faster, thus preventing "sorry I was gone for 2 weeks" hangups in the progress.

Another issue we faced was when a newer member completely reworked the game loop. While he made some improvements (which relied heavily on his changes and were difficult to isolate on their own), it made it VERY difficult come time for the final build, as I was unaware of all of the flag variables used.

Key point here: as the manager, YOU compile the code. You are in charge of the structure, skeleton, subroutine names, etc. Ideally you should be able to quickly draft the skeleton, assign subroutines to members, and fill it out that way, instead of trying to have everyone work together (it doesn't work too well that way).

Other misc tidbits. I frequently found myself constantly asking for updated code, just to see progress. Perhaps requiring either a daily update or weekly update on progress. If you are 2 days late or so, you are assumed to have dropped the project and its assigned to someone else (more than a couple times someone was just afk for weeks and there was no way to figure out what was happening). This prevents lulls in progress from stopping all development when a really key integral part is in the air.

Communication is key in all of it. Make sure everyone knows where you are going, why and how it will work. Perhaps even if you just request a weekly update, post the next day or so one large Progress update to inform everyone where everything is, kinda a State of the Union address type thing (dunno what the equivalent of that is if you aren't in the states, its when the leader gets up and talks about where everything is at on all fronts and where its going)

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Aug 2010 14:12
@Obese87
What is the point of grading? Why spend time on a ranking? The goal is to teach new coders, right? So assign tasks that you would think beginners could handle and hold their hand along the way.

A huge maker or breaker is being decisive and staying goal oriented. Have an initial brainstorming session and collect any and all ideas that are valid and useful to the project. After that, set in stone what is to be done and do not deviate from that. A show stopper is when additional or new ideas start being added, weighed, and voted on. If it is an actual improvement that is along the goals that have already been set, then it may be worth considering. If it's a brand new thing that would be nice and open up the game to something new, note it, and set it aside until the original goals are met.

Leave optimizations to the end when everything is done. If you try and optimize as you go, you'll never get anything done. Again, if a good idea for some kind of optimization comes up, note it, write it down, add it as a remark, but move on.

Be aware and be ready to accept that people are going to leave and flake on their responsibilities. If you decide to be a leader in a project, then commit to finishing it. If you don't, no one will.

Enjoy your day.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 9th Aug 2010 00:37
Thanks for posting, lots of good advice there.
I did the grading so I know what kind of jobs I can give people and also monitor their progress. You are right that I shouldn't stall the project while grading people so I've started it going, grading can wait.

Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 11th Aug 2010 03:33
Nesting errors could be presentational as well. 9/10 times nesting errors won't happen if you keep your code formatted and indented properly.


With so many different people working on a single project, this is where I think having a flowchart or some kind of UML diagram early on is a necessity. It will make breaking up and assigning tasks much easier to follow.


"Any sufficiently advanced technology is indistinguishable from magic" ~ Arthur C. Clarke
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 21st Aug 2010 18:39
I now realise you need to make placeholder graphics before anything else, otherwise no one can see what they're doing.

@Phaelax
I'm experiencing a great need for flowcharts right now!

old_School
14
Years of Service
User Offline
Joined: 29th Aug 2009
Location:
Posted: 5th Oct 2010 03:21
Probly the best thing for any project is good communication between members. Best way Ive seen is through voice chat systems. I currently use Team Speak for all my projects.

Next part would be a good outline. In any project you need a guideline to follow. So writting everythign thing before even starting the projects are a must.

Next Setting goals. May seem like common sense but people get off track easly. So set goals for things to get done. But when making goals make sure they are realistic and completed on time. Getting off track leads to project failures.

Next would be get orgnanized. If you have a good outline your half way there. Assign a project manager. Manager should be the go to guy to a degree. Not th tech support for the entire project but whom you consult for advice an direction. Consulting for tech help should be done with the Sr. members or in this case a Sr. programmer.

Next break up the tasks. Assasign people best skilled to be Sr. members and those with a interest in that area should be assasigned to those Sr. members. Kinda like mentors.

Finaly. Hold meetings regularly to share information. Always keep everyone up to date. But avoid having meetings that will be pointless. If no progress is made then no point in meeting.

Hope it helps.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 3rd Nov 2010 19:43
I have deleted the grading system; Latch was right it just wastes valuable time.
If anyone has any more tips about project management please post; I will sort them out and put them in the first post when I get around to it. This will become a well of information to help people run projects


Do oranges know what colour they are?

Login to post a reply

Server time is: 2024-04-25 11:36:03
Your offset time is: 2024-04-25 11:36:03