Tweet
Well, we're now up to the stage were we have several coders working in parallel on different areas. 
Now that we're there, and hopefully growing bigger shortly, we need a serious amount more of organization in the coding area. I am frankly completely out of my realm of competence here. 
for this reason, I am just going to post my first take on that what I think we should do in terms of coding organization, and let the discussion go on from there. We need to reach some sort of consensus on the topic fairly soon, perhaps by the end of August. Otherwise, chaos will reign.
I think we need an organizational structure that is as flexible as possible for this project. Due to Real Life glitches that are sometimes unpredictable, even committed individuals will essentially drop out for periods of up to a month or so, and the project needs to be able to make progress despite those problems. A flexible team approach seems to be the best way to handle this.
I guess what I suggest initially is to break down game areas (e.g. military or main map) by types of competence in programming, for instance graphics, interfaces, model "guts", Internet capabilities, AI, etc. As an example, I think I can do a good job with model guts and AI, but get increasingly less competent, and less interested, as we move into the other areas.
IMO there should be a programmer in charge of coding the guts for each major functional/model area. For most functional areas of the game we already have dukes to handle them (or hopefully will soon). My view is that combining the dukes in charge of the various areas, with the model guts coders, and with people doing other functional things (interfaces, graphics or tools) gives us fair coverage of what needs to be done.
For each area, the person doing the guts of the particular model would have to go first, providing javadoc or better documentation of what classes and variables they plan to use. As the organizational structure for the code is built up, there will be very tight communication between the duke and the coder for that area. Once the guts coder has the area outlined, even if they are sidelined for awhile, someone else can pick it up if needed.
The best level of documentation for each model or implementation area should show private variables and methods also, so that people doing the interface for it, etc. can see what's going on. Then there should be a lower level of documentation that just shows the classes, and methods, that interface with other modules. After that, the interface, graphics, and tools people can start in on their detailed specs.
What this would mean, is that our people that, for instance, are good at interfaces, could move from area to area starting with whatever is ready first, and not have their unique talents wasted by coding up the "guts" of any particular model. People working in the "flex" areas like interfaces or graphics, should sign up in whatever area they're interested in. When an area's team has enough people with the right skills to do its job, then new participants will have to sign up for some other area. When an area is at the point where it can't proceed much further since it is being held back due to progress and other areas of the game, those team members that can should move on to another area of interest.
I, and hopefully some others, will try to function as "flex programmers" to move along the areas that are progressing slowly for any of a number of reasons.
Will my proposal work? I have no idea. But anyway, we can start the discussion, and hopefully have some sort of agreement by the end of August. Clearly we need to plan this out in somewhat more detail. I haven't even begun to discuss low-level things like who has a lock on which part of the code etc.
Please let the group know what you think. I would especially like to hear from those of you who have done planned coding professionally. I'd like to hear your opinions on how to use your knowledge of how it works in a corporate environment, and how those planning tools might work in an amateur project like ours.
Mark
Now that we're there, and hopefully growing bigger shortly, we need a serious amount more of organization in the coding area. I am frankly completely out of my realm of competence here. for this reason, I am just going to post my first take on that what I think we should do in terms of coding organization, and let the discussion go on from there. We need to reach some sort of consensus on the topic fairly soon, perhaps by the end of August. Otherwise, chaos will reign.I think we need an organizational structure that is as flexible as possible for this project. Due to Real Life glitches that are sometimes unpredictable, even committed individuals will essentially drop out for periods of up to a month or so, and the project needs to be able to make progress despite those problems. A flexible team approach seems to be the best way to handle this.
I guess what I suggest initially is to break down game areas (e.g. military or main map) by types of competence in programming, for instance graphics, interfaces, model "guts", Internet capabilities, AI, etc. As an example, I think I can do a good job with model guts and AI, but get increasingly less competent, and less interested, as we move into the other areas.
IMO there should be a programmer in charge of coding the guts for each major functional/model area. For most functional areas of the game we already have dukes to handle them (or hopefully will soon). My view is that combining the dukes in charge of the various areas, with the model guts coders, and with people doing other functional things (interfaces, graphics or tools) gives us fair coverage of what needs to be done.
For each area, the person doing the guts of the particular model would have to go first, providing javadoc or better documentation of what classes and variables they plan to use. As the organizational structure for the code is built up, there will be very tight communication between the duke and the coder for that area. Once the guts coder has the area outlined, even if they are sidelined for awhile, someone else can pick it up if needed.
The best level of documentation for each model or implementation area should show private variables and methods also, so that people doing the interface for it, etc. can see what's going on. Then there should be a lower level of documentation that just shows the classes, and methods, that interface with other modules. After that, the interface, graphics, and tools people can start in on their detailed specs.
What this would mean, is that our people that, for instance, are good at interfaces, could move from area to area starting with whatever is ready first, and not have their unique talents wasted by coding up the "guts" of any particular model. People working in the "flex" areas like interfaces or graphics, should sign up in whatever area they're interested in. When an area's team has enough people with the right skills to do its job, then new participants will have to sign up for some other area. When an area is at the point where it can't proceed much further since it is being held back due to progress and other areas of the game, those team members that can should move on to another area of interest.
I, and hopefully some others, will try to function as "flex programmers" to move along the areas that are progressing slowly for any of a number of reasons.
Will my proposal work? I have no idea. But anyway, we can start the discussion, and hopefully have some sort of agreement by the end of August. Clearly we need to plan this out in somewhat more detail. I haven't even begun to discuss low-level things like who has a lock on which part of the code etc.
Please let the group know what you think. I would especially like to hear from those of you who have done planned coding professionally. I'd like to hear your opinions on how to use your knowledge of how it works in a corporate environment, and how those planning tools might work in an amateur project like ours.
Mark
c.
Comment