Welcom to The Civ4 Community Core Project

Impaler[WrG]

Civ4:Col UI programmer
Joined
Dec 5, 2005
Messages
1,750
Location
Vallejo, California
Greating Intrepid moders, hackers and Civ-adicts the Civ4 Core Community.

NEWS
Many of you have never seen this forum until now as it has been Private and the project has languished for some time partly because of it. To stimulate and support a new burst of development I've done several things, first Thunderfall has at TGA's consent made me group moderator, second I've had Thunderfall make the forum public and thirdly I'm now admining the projects SourceForge repository along with mexico.

WHY ITS OPEN
By opening this forum I'm hoping to generate more interest in the project both by other mod makers and the community at large. Were going to take requests from anyone who has them but please make sure that your requests are appropriate for the nature of the Project (see requests section). I'm also looking to recruit as many developers and testers as possible. Sign-up today.

WHAT MAKES CCCP SPECIAL
The CCCP is very different from all the other mod projects with sub-forums. It realy isn't a mod, its a mod platform, a set of code and tools and features beyond the standard Firaxis SDK that can be used to make a "real" mod such as Ket's mod which was built ontop of it. The target audience is the mod making community itself, the goal to make the project so desirable that everyone wishes to use it as a Basis for their mods. I even expect most of the team members will have dual membership in the popular mod packs. To maintain interoperability as much as possible the CCCP is devoid of any actual game play content any request which is "content" like "add the Dutch civ to the game" or "make the Axman weaker" would be rejected automatically. The CCCP wont even contain the files these things are stored on. The appropriate requests are for adding new features to the game engine such as a new XML tag, rule changes in the SDK and improvements to the User Interface.

REQUESTS
Their are two types of valid requests each of which has its own separate Request thread (use them). Their are requests for new never before seen features and requests for an existing mod to be merged into the project. The first step of the former is for someone to develop this new thing in the first place, if a project member like the idea and decides to in fact do that then great it kills two birds with one stone (creation and integration) but that doesn't have to be the only way. Their are lots of mod makers who whip up mods on request or because they like an idea they heard about. If some outside our project will do or has already done the development then the request is of the second much easier type. And of course if the mod author themselves wants to do the integration work all the better.

PRIORITY
Prioritizing tasks is of course going to be necessary in any project. But priority in a volunteer project is really quite loose when it comes down to it, every team member really sets their own priorities, the "official" priority list is really a guideline. I'll consult with the team and fans of CCCP seek to prioritize tasks in the following order. Critical Bug fixes (the game is crashing) are of course the #1 priority and all members should try to atleast examine a major bug thats found on the chance they might instantly be-able to solve it and spare someone else a bunch of :wallbash: Second priority is getting non-functional (but not game crashing) things to function properly. Third is including existing or new stuff thats important for one of the mods thats actively built upon top of the Project. Forth is including existing stuff for a mod that wants to migrate to being built on the CCCP. Fifth is incorporating existing and new mods of high desirability by the general fan-base. Lastly the development of brand new functionality thats desired by fans (but not wanted for any existing mods).

ELIGABILITY
Their are some rules that we need to follow to keep the spirit of the project, all mods need to pass eligibility to be allowed in. Eligibility is completely technical in nature theirs no judgment on how "fun" something would be. We can do this because the #1 eligibility rule is "All new functionality must be by default latent" This means that the new feature will be dormant and inactive until explicitly activated by some switch in the games Assets, typically a GlobalDefine or using a new XML tag. Other alternative activation methods might include the inclusion of a special Python file or something I've never even heard of before so long as its optional and can be configured to be latent. The Second test is stability, components don't need to be absolutely rock solid but should atleast be mature. Third is performance, if it causes a major slow down in game speed or consume huge amounts of memory then it would be ineligible.

JOINING
To join the project just post in the Join thread, list your skills what mods your developing or working with and what you plan to contribute. I'll then add you to the group. If you dont have a SourceForge account get one and then I'll add you as a developer their as well. If your not familiar with version control software read up on it, the repository is SVN based. Also place a post in the Current Task thread and edit it as your current project changes so we can see at a glance what everyones currently doing.
 
*GASP*

A post in the ccp forum. First time in about two months. I do wish you luck with this project, but unfortunately I am being my old sceptic self, and see no reason why it should do better than last time. Sorry for being so pessimistic, but it is what I truely think.
 
*GASP*

A post in the ccp forum. First time in about two months. I do wish you luck with this project, but unfortunately I am being my old sceptic self, and see no reason why it should do better than last time. Sorry for being so pessimistic, but it is what I truely think.

In my opinion, software projects fail when they take on too much. This seems to be a classic example. I believe the trick is to FOCUS.

I propose you drop everything except:

  1. New python functions exposed to make modding easier and new kinds of Python mods possible.
  2. New XML tags exposed to make modding easier and new kinds of XML mods possible.
  3. Merging the SDK parts of mods making LIMITED changes to the SDK in order to make possible the rest of their features.
  4. Merging mods designed to make modding easier, such as XML modular loading. These should be the ONLY mods making any sort of large changes to the SDK included.
  5. Smallish bug fixes.

In other words, a mod to make modding easier!

Things you should not be doing:

  1. AI Modding. Leave this to guys like Blake.
  2. UI Modding. Leave this to unaltered gameplay modders like me. (Except for SDK components to make UI modding easier like Action Buttons which would fall in #4 above).
  3. "Big" SDK mods that change the whole nature of the game. Definitely no total conversions.
  4. Avoid mods which are just written in C++ because the author decided to, or it was "easier", not because he had to. I have already rewritten two of TheLopez's mod components in python.
  5. Mods to improve performance.
  6. Pure python mods of any sort.
  7. Pure XML mods of any sort.
  8. Pure Graphics mods of any sort
  9. Scenarios
  10. Any mod that does not alter the SDK.

Furthermore, do not include any mods for which you do not get explicit support from the mod maker. That particularly includes mods for which you would have to write any enabling/disabling code.

If you follow these ideas, you have a decent chance of producing something in a reasonable timeframe, which is reasonably stable, and might be actually usable in time for any mod integrator to use before the next patch or expansion pack.

Of course, it also begs the question of what I am needed here for. :)

P.S. Also, if you want an interface modder like me to even consider using your dll, stay far, far away from code that could make savegames incompatible. It really turns me away. I know that would be difficult, but as I said before, a CCCP subset which is savegame compatible could be possible. And by savegame compatible I mean both ways. Ruff_Hi refuses to consider any DLL at all for his SG audience primarily for this reason.
 
I think you are right Gaurav. Focus should be on adding features that have a broad need across multiple mods, but dont change anything unless the modmaker enables them.
 
Top Bottom