Reply to Re: Recondite Twenty-Eight: The Sixth Day
If you don't have an account, just leave the password field blank.
@LeprochaUn & liquid141:
(First, please accept thanks to both of you for your thoughts on the matter of how a "Community D-Mod Jam" would work).
If DmodDevA works on a version and DmodDevB works on a version at the same time then you get conflict errors because now you have differences in the files. In this case only DmodDevA's or DmodDevB's work can be kept(or you could spend a while resolving script issues).
Yes, there would be no conflict in the actual scripts. That is, since DmodDevA and DmodDevB each worked in different scripts (shopcsrn.c and shopkeep.c respectively), the version control system (assuming that we use one) would not detect the conflicts over two different conversations. Initially both shopcsrn.c and shopkeep.c would be "kept." And yes, in this simplified example, you could certainly "spend a while resolving script issues" once they were detected. Ideally, that resolution would require a dialogue between DmodDevA and DmodDevB. If we collect a few of these in the course of development, I'd say that it would make the "Community D-Mod Jam" process a bit tedious.
IF we go through with this "Community D-Mod Jam" idea, I agree that it makes sense to develop the "rough sketch" of a "solid story" first. As a next step different parts could be divided up into little teams. For Example, Team#1 could consist of DevModA fleshing out the story while Dink is in the town of SplatBang. If DmodDevB and DmodDevC agree with the storyline, then DmodDevB could do the mapping for the town. Finally DmodDevC could do the coding for various places in town. Then Team#2 could start on the DungeonOfDoom section of the story, mapping and coding, followed by Team#3 working on the same things for the ElysianFields section of the map.
One other factor here is something we have to be realistic about. Dmod development is (for most people) not the first and most important part of their lives, and there are dozens of unfinished dmods that testify the to reality that it takes time and commitment to develop a dmod, especially at this time in the history of Dinkdom. Many give up on the effort and therefore do not even end up uploading an incomplete dmod to be downloaded by Dink fans around the globe. Putting together a long list (well, it will seem like a long list for this small group of gaming fanatics) of people to work on a dmod practically guarantees (IMHO) that someone will stop producing or not produce fast enough to sustain the interest of all others involved.
(First, please accept thanks to both of you for your thoughts on the matter of how a "Community D-Mod Jam" would work).
If DmodDevA works on a version and DmodDevB works on a version at the same time then you get conflict errors because now you have differences in the files. In this case only DmodDevA's or DmodDevB's work can be kept(or you could spend a while resolving script issues).
Yes, there would be no conflict in the actual scripts. That is, since DmodDevA and DmodDevB each worked in different scripts (shopcsrn.c and shopkeep.c respectively), the version control system (assuming that we use one) would not detect the conflicts over two different conversations. Initially both shopcsrn.c and shopkeep.c would be "kept." And yes, in this simplified example, you could certainly "spend a while resolving script issues" once they were detected. Ideally, that resolution would require a dialogue between DmodDevA and DmodDevB. If we collect a few of these in the course of development, I'd say that it would make the "Community D-Mod Jam" process a bit tedious.
IF we go through with this "Community D-Mod Jam" idea, I agree that it makes sense to develop the "rough sketch" of a "solid story" first. As a next step different parts could be divided up into little teams. For Example, Team#1 could consist of DevModA fleshing out the story while Dink is in the town of SplatBang. If DmodDevB and DmodDevC agree with the storyline, then DmodDevB could do the mapping for the town. Finally DmodDevC could do the coding for various places in town. Then Team#2 could start on the DungeonOfDoom section of the story, mapping and coding, followed by Team#3 working on the same things for the ElysianFields section of the map.
One other factor here is something we have to be realistic about. Dmod development is (for most people) not the first and most important part of their lives, and there are dozens of unfinished dmods that testify the to reality that it takes time and commitment to develop a dmod, especially at this time in the history of Dinkdom. Many give up on the effort and therefore do not even end up uploading an incomplete dmod to be downloaded by Dink fans around the globe. Putting together a long list (well, it will seem like a long list for this small group of gaming fanatics) of people to work on a dmod practically guarantees (IMHO) that someone will stop producing or not produce fast enough to sustain the interest of all others involved.
