Tweet
First of all I must say that I am one of the very first members of this project and I have practically seen it rise from nothing to what it is now and I hope to see it continued as well.
As such I am deeply frustrated about the tensions on several aspects of upcoming mod, mostly discussion arisen about the goal to 'clone' SMAC.
I dont think such tensions are needed, in fact, they doo much harm to our Project as I've already seen a couple of potential participants being scared of after reading the discussions which sometimes seem too offensive and are also often misinterpreted by newcomers.
Here I must admit, after long reading of those discussions I myself am not sure whether I understand the Mission Goal, because one has been said in discussions prior and at the start of this forum (C4AC) and the other is being propagated now.
I also understand that there are different people gathering around this mod and their opinions on what should and what shouldn't be implemented differ.
That is only natural.
The challenge for organisatorial staff of the project is to develop a working scheme which would allow people come over their differences and reach some consensus over important matters instead of misunderstanding or even offending each other.
As a part of the Organisational team I come up with the following proposal on the Goal/Clone issue:
To start with:
1.Our differences tend to be small when we talk about the easily implementable things.
Example:
Sounds - we expect that once we have identified the sound files of SMAC versus the ones of cIV we will be able just to paste over some of the files with probably some file type conversion of sorts. I am not talking about legal issues here, but I hope everyone understands that the amount of work required to replace sounds of C4 with existing sounds of SMAC is not as hard as say programming Design Workshop or Crawlers in.
So, what happens when we discuss sounds - people generally agree that if we can (legal issue) keep the sounds of SMAC, let's keep em and add some in the same style where we don't have an existing protoype.
2.Our differences tend to be big when we talk about the hard to implement things.
Example:
Combat system - I as programmer am logically deducing, that the singular battle system of C4 ('strenght' concept instead of separate attack and defense) will be very problematic to transform into a dual battle system of SMAC. If you think about it a bit you will get the point easily. It is enough to mention three things:
1.Combat system is not likely to be a module-only piece of code. It is highly likely to have parts coded in .exe and parts residing in some other modules for best interaction between them.
2.Singular combat system has only one 'case' - value(strenght) of unit A against value(strenght) of unit B, both values modified by factor collections K1 and K2 representing the combat modifiers for units A and B.
Dual combat system (that of SMAC) first of all has one simple 'case' for the 'normal' combats where attack is used against defense plus one special 'case' where attack is used against attack (air combat and naval bombardment combat).
I expect this duality affect the complexity of combat algorithm so that it's levels higher than that of the singular one.
3.Unit. It has property 'strenght'. This property now figures in most aspects of the game, ranging from combat and ending to AI who uses this dumbed-down (sorry, but I see as another dumbing down example; let's not discuss it here) value to rate units and most probably uses the capabilities added by promotions to distinct better defenders from better attackers. The last part (AI) is probably the most problematic thing - it will be hard to teach them understand attack and defense if they're built upon 'strenght'.
So, what happens when we discuss implementing SMAC feature here - not only there is disagreement, there is major diferences between some very valuable-to-the-project and devout people. These differences range from keeping the C4 system but using it's own properties to make needed adjustions (and more on this later), to 'stamping' SMAC system in with no regard of it's global influence to game itself and no regard of how compatible with other original C4 constructs it is. There's even idea to take the SMAC system and 'upgrade' it by making a kind of rock-paper-scissors effect, proposed by Blake.
Thing is - we are not able to settle these differences for now and maybe will never be. At some point our modding paths may and most probably will split.
Therefore I offer to:
Split all features into 2 major cathegories:
1.Ones who are in C4 (they may look different, but basically they are there and work more or less similar to SMAC, terraforming is a good example)
2.Ones who aren't (by first look you don't see such a feature, not even something principally similar in C4, crawlers are good example)
The second cathegory would further split into 2 groups:
1.Features which can be implemented by 'adjusting' the existing mechanisms (basically, things which can be done almost as easy as the ones which are on the first cathegory, by using existing feature but changing it's properties)
2.Features need a good amount of additional coding, possibly a special module for them. For example crawlers would probably hard to implement using existing features, the 'convoy' weapon and appropriate orders should all be coded in anew.
This split would also dictate that on several occasions we will be implementing a feature of SMAC as a version of existing feature and only after we have advanced to the stage where we take on the hardest tasks, we implement the feature fully as in SMAC by rewriting needed parts.
Example:
Combat system - in early versions we can leave it as is, then we can try the 'modifier' approach (proposed by me some time ago) or any other approach which is implemented as adjustion of existing feature, not rewrite and finally when we come to the point we have implemented all the easy things, we can do the implementing of SMAC combat system.
And an 'operational stages' approach to work on our project.
1.Make a cathegorised list of things-to-implement. We can skip minor features which are very easy to do and it is believed everyone would want them in, like for example implementing monoliths (which would belong to 'terraforming items' group) or merge them into a 'group' of sorts.
2.Once ready at least in big lines, investigate to find out approximately how much effort it would take to implement (here we can make some sort of custom scale ranging say from 1-10, increasing difficulty as the value rises).
3.Starting with the easiest things, put each item of the list under Modgroup discussion.
This basically means that people from the Modgroup which is expected to do the implementation discuss the possible ways of implementation and choose the seemingly best (easiest and mst satisfying) of them and rates whether the 'easiness' of the task has been scaled adequately.
4.Starting with the easiest things, put each item of the list under public discussion.
Once some agreement threshold (to be defined in mission statement or some other important and public document) has been reached on that particular item, put it into to-do queue of the appropriate Modgroup (more on them later), so people there start to implement it, then test it, put it into the next release(version or update, call as you wish) and get the feedback.
If the feedback reaches a threshold (to be defined in mission statement or some other important and public document) of negativity where concerns about that feature as a whole arise, it goes back to point 3. then again to point 4.(public discussion and into queue), else it goes to 'implemented features' list and the task is marked 'done' or somesuch.
In case the proposed feature does not reach the threshold of agreement, it is delayed (by amount of time defined in mission statement or some other important and public document), then put again into point 3., then point 4. etc.
Please note that the 4 points are so far a proposal of 'operational stages' and some of them could be merged or split in case that turns out to be more rational.
---
In summary those two things (the cathegorising and the operational stages process) will lead to situation where the most agreed-upon and easiest changes will be implemented first and with the best discussed-over method (the discussion over methods can be skipped of course if there's only one reasonable way to do it) AND what is even more important - our project will be scalable to an extent that if a particular modder does not necessarily want to implement a particular feature in the way that our Mission Statement dictates (currently 'clone' doctrine) or evenmore, he has his own viewpoint on the issue, he can participate in the project up to the moment we implement that controversial feature. Then he can choose to go different path if he wishes so. Same works with simple users - if they don't like the latest feature implemented, they can use the last version and play that.
Ideally would be if we could code things into small pieces/modules which could then be disabled/swapped with another by users wish, but practically we wont be able to do it with all features (global ones as combat system being the first to come to my mind). We could even try to make support for some earlier feature-modules in later versions, so people who don't like some particular feature can play with all the other latest features without that particular feature alone. But that is a question of the current module structure and the ability of our programmers to write moduled code, thus should be decided upon later when we know more about the game.
---
This whole system was made up to allow people, whose viewpoints differ from the Mission Statement or the overall consensus in C4AC community in some advanced feature implementation issues, to participate in the project and give their own contribution to it, as well as allow them to later use our cooperative work as a basis shouldthey decide to go a different path.
It is also expected to stop all the current unneeded and destructive discussions about keeping C4 changes as this solution dicates that the changes will be adjusted/removed gradually starting with the easiest and most consensual ones and ending with the hardest and most controversial, thus eliminating any need to argue over that or other perticular change until it is time to implement it and any need to argue about keeping changes as a whole, global doctrine.
As it is we are only scaring people off with harsh attitude to 'heathens' who think differently. We need to be flexible and we can not afford even a single possible contributer to wander away. After all we will be attempting to do the work that usually is done by companies employing staff an order of magnitude higher both in numbers and skill.
---
Your opinion is welcome as this is only a proposal and could and probably even should be changed to best fit our needs.
As such I am deeply frustrated about the tensions on several aspects of upcoming mod, mostly discussion arisen about the goal to 'clone' SMAC.
I dont think such tensions are needed, in fact, they doo much harm to our Project as I've already seen a couple of potential participants being scared of after reading the discussions which sometimes seem too offensive and are also often misinterpreted by newcomers.
Here I must admit, after long reading of those discussions I myself am not sure whether I understand the Mission Goal, because one has been said in discussions prior and at the start of this forum (C4AC) and the other is being propagated now.
I also understand that there are different people gathering around this mod and their opinions on what should and what shouldn't be implemented differ.
That is only natural.
The challenge for organisatorial staff of the project is to develop a working scheme which would allow people come over their differences and reach some consensus over important matters instead of misunderstanding or even offending each other.
As a part of the Organisational team I come up with the following proposal on the Goal/Clone issue:
To start with:
1.Our differences tend to be small when we talk about the easily implementable things.
Example:
Sounds - we expect that once we have identified the sound files of SMAC versus the ones of cIV we will be able just to paste over some of the files with probably some file type conversion of sorts. I am not talking about legal issues here, but I hope everyone understands that the amount of work required to replace sounds of C4 with existing sounds of SMAC is not as hard as say programming Design Workshop or Crawlers in.
So, what happens when we discuss sounds - people generally agree that if we can (legal issue) keep the sounds of SMAC, let's keep em and add some in the same style where we don't have an existing protoype.
2.Our differences tend to be big when we talk about the hard to implement things.
Example:
Combat system - I as programmer am logically deducing, that the singular battle system of C4 ('strenght' concept instead of separate attack and defense) will be very problematic to transform into a dual battle system of SMAC. If you think about it a bit you will get the point easily. It is enough to mention three things:
1.Combat system is not likely to be a module-only piece of code. It is highly likely to have parts coded in .exe and parts residing in some other modules for best interaction between them.
2.Singular combat system has only one 'case' - value(strenght) of unit A against value(strenght) of unit B, both values modified by factor collections K1 and K2 representing the combat modifiers for units A and B.
Dual combat system (that of SMAC) first of all has one simple 'case' for the 'normal' combats where attack is used against defense plus one special 'case' where attack is used against attack (air combat and naval bombardment combat).
I expect this duality affect the complexity of combat algorithm so that it's levels higher than that of the singular one.
3.Unit. It has property 'strenght'. This property now figures in most aspects of the game, ranging from combat and ending to AI who uses this dumbed-down (sorry, but I see as another dumbing down example; let's not discuss it here) value to rate units and most probably uses the capabilities added by promotions to distinct better defenders from better attackers. The last part (AI) is probably the most problematic thing - it will be hard to teach them understand attack and defense if they're built upon 'strenght'.
So, what happens when we discuss implementing SMAC feature here - not only there is disagreement, there is major diferences between some very valuable-to-the-project and devout people. These differences range from keeping the C4 system but using it's own properties to make needed adjustions (and more on this later), to 'stamping' SMAC system in with no regard of it's global influence to game itself and no regard of how compatible with other original C4 constructs it is. There's even idea to take the SMAC system and 'upgrade' it by making a kind of rock-paper-scissors effect, proposed by Blake.
Thing is - we are not able to settle these differences for now and maybe will never be. At some point our modding paths may and most probably will split.
Therefore I offer to:
Split all features into 2 major cathegories:
1.Ones who are in C4 (they may look different, but basically they are there and work more or less similar to SMAC, terraforming is a good example)
2.Ones who aren't (by first look you don't see such a feature, not even something principally similar in C4, crawlers are good example)
The second cathegory would further split into 2 groups:
1.Features which can be implemented by 'adjusting' the existing mechanisms (basically, things which can be done almost as easy as the ones which are on the first cathegory, by using existing feature but changing it's properties)
2.Features need a good amount of additional coding, possibly a special module for them. For example crawlers would probably hard to implement using existing features, the 'convoy' weapon and appropriate orders should all be coded in anew.
This split would also dictate that on several occasions we will be implementing a feature of SMAC as a version of existing feature and only after we have advanced to the stage where we take on the hardest tasks, we implement the feature fully as in SMAC by rewriting needed parts.
Example:
Combat system - in early versions we can leave it as is, then we can try the 'modifier' approach (proposed by me some time ago) or any other approach which is implemented as adjustion of existing feature, not rewrite and finally when we come to the point we have implemented all the easy things, we can do the implementing of SMAC combat system.
And an 'operational stages' approach to work on our project.
1.Make a cathegorised list of things-to-implement. We can skip minor features which are very easy to do and it is believed everyone would want them in, like for example implementing monoliths (which would belong to 'terraforming items' group) or merge them into a 'group' of sorts.
2.Once ready at least in big lines, investigate to find out approximately how much effort it would take to implement (here we can make some sort of custom scale ranging say from 1-10, increasing difficulty as the value rises).
3.Starting with the easiest things, put each item of the list under Modgroup discussion.
This basically means that people from the Modgroup which is expected to do the implementation discuss the possible ways of implementation and choose the seemingly best (easiest and mst satisfying) of them and rates whether the 'easiness' of the task has been scaled adequately.
4.Starting with the easiest things, put each item of the list under public discussion.
Once some agreement threshold (to be defined in mission statement or some other important and public document) has been reached on that particular item, put it into to-do queue of the appropriate Modgroup (more on them later), so people there start to implement it, then test it, put it into the next release(version or update, call as you wish) and get the feedback.
If the feedback reaches a threshold (to be defined in mission statement or some other important and public document) of negativity where concerns about that feature as a whole arise, it goes back to point 3. then again to point 4.(public discussion and into queue), else it goes to 'implemented features' list and the task is marked 'done' or somesuch.
In case the proposed feature does not reach the threshold of agreement, it is delayed (by amount of time defined in mission statement or some other important and public document), then put again into point 3., then point 4. etc.
Please note that the 4 points are so far a proposal of 'operational stages' and some of them could be merged or split in case that turns out to be more rational.
---
In summary those two things (the cathegorising and the operational stages process) will lead to situation where the most agreed-upon and easiest changes will be implemented first and with the best discussed-over method (the discussion over methods can be skipped of course if there's only one reasonable way to do it) AND what is even more important - our project will be scalable to an extent that if a particular modder does not necessarily want to implement a particular feature in the way that our Mission Statement dictates (currently 'clone' doctrine) or evenmore, he has his own viewpoint on the issue, he can participate in the project up to the moment we implement that controversial feature. Then he can choose to go different path if he wishes so. Same works with simple users - if they don't like the latest feature implemented, they can use the last version and play that.
Ideally would be if we could code things into small pieces/modules which could then be disabled/swapped with another by users wish, but practically we wont be able to do it with all features (global ones as combat system being the first to come to my mind). We could even try to make support for some earlier feature-modules in later versions, so people who don't like some particular feature can play with all the other latest features without that particular feature alone. But that is a question of the current module structure and the ability of our programmers to write moduled code, thus should be decided upon later when we know more about the game.
---
This whole system was made up to allow people, whose viewpoints differ from the Mission Statement or the overall consensus in C4AC community in some advanced feature implementation issues, to participate in the project and give their own contribution to it, as well as allow them to later use our cooperative work as a basis shouldthey decide to go a different path.
It is also expected to stop all the current unneeded and destructive discussions about keeping C4 changes as this solution dicates that the changes will be adjusted/removed gradually starting with the easiest and most consensual ones and ending with the hardest and most controversial, thus eliminating any need to argue over that or other perticular change until it is time to implement it and any need to argue about keeping changes as a whole, global doctrine.
As it is we are only scaring people off with harsh attitude to 'heathens' who think differently. We need to be flexible and we can not afford even a single possible contributer to wander away. After all we will be attempting to do the work that usually is done by companies employing staff an order of magnitude higher both in numbers and skill.
---
Your opinion is welcome as this is only a proposal and could and probably even should be changed to best fit our needs.
Comment