Im all for fun. I suspect that the amount of realism from a mod will be a personal preference. Is it realistic that a group of settlers would be killed by a Lion? Isn't it more realistic that this group of settlers would be killed off by Maleria? But watching your people killed by mosquito's isn't nearly as much fun as seeing them attacked by lions, despite the realism (personally I consider animal attacks to be a generalization for all natural threats).[...]
I am very glad that you have pointed out the things above.
Of course, it is not realistical to have a group of settlers, capable of founding a complete new city, being killed by lions. And I agree, this is just the symbolization of the early dangers lurking in the woods and fields.
Therefore, it is acceptable to have this limited realistical approach for the benefit of an easy and quick to understand gameplay.
So I agree with you, I just would prioritize realism to highly. Fun trumps everything. In fact the only true advanatge of realism in games is that it makes the game intuitive. We don't need to explain why a tank has a higher strength than a spearman, our players can tell just by looking at the unit picture that their spearman is in trouble. As such we have made the game easier to play by compling with realism. In the worse case where we create non-intuitive systems players will be frustrated with mixed messages and annoyed that they have to remember facts about the game that are contrary to what they would expect.
Here I think, we have to be very careful about making use of the term "realism".
Is it realistical to have units living for millenia? No, obviously not.
Would it be fun to have to replace them every turn? No, obviously not.
So, in this area "realism" spoils the fun immediately. Therefore, you have to be "unrealistic" for the sake of the playability.
But what about the siege weapons?
Is it realistical to have catapults attacking units in the field with trumpets and waving flags, in fact being some kind of ancient field artillery? No, obviously not.
In fact, it is completely contradictional to everything somebody would expect. A catapult is a machine standing somewhere and throwing stones at almost immobile targets. That is, what the player knows from "real life experience" (in this case, from history) and that is, how he would think it should work.
Therefore, the complete design of the siege weapons manifests a misconception in the core game.
And therefore, this would be a candidate for modification. Unfortunately, as I have pointed out in the previous post, the engine does not allow for many changes to the better, unless you are willing and capable of making use of the SDK.
One other thing is about the movement of naval units. For millenia, sailing was the fastest way of moving from A to B. That is the very reason why the whole mediterranean area was full of early powers, starting with Egypt, Greece, Persia, Carthage, Phoenicia and so on.
Once again, in the game this historical experience is not portrayed. Your galley is not quicker then your warrior, if both move at the same coast. Therefore, many people immediately lose the interest in building a navy, as there is almost no visible benefit to do so.
And even the developers lost this interest, as the weak implementation of the whole naval thing proves.
In this area, at least slight improvements seem to be possible by making use of rather easy XML modifications. New features may be added by some Python coding as well, still a comparably easy task.
So, as far as I see it, this is another candidate for modding.
These shall be only two of the almost countless examples in which areas one could improve - or alter - the game.
What I want to say by this: to create a playable modification, have a look at the weaker parts of your starting base, the core game.
Think about why these weaker parts are weak. Is it just because of some misbalanced values? Is it because of a flawed concept? Is it because of a unit which has been forgotten to be put into the game?
And what can you do to improve this, as far as your personal likings are concerned?
After you have identified these issues, start with the easy improvements to keep the momentum. For most modders, this will be the tweaking of XML files and there is nothing to be said against it.
By this, you can issue a first version quickly and see, how people respond to it.
The more difficult tasks, the creation of new game behaviours by Python or SKD modifications could be (and should be, as far as I see it) left for later stages of your "project" (because, a modification in fact is nothing less than a project).
But, and I think, this is important as well, try to anticipate what might happen or what you are willing to do in the future as well. That means, if an "easy" XML tweaking would result in something which will be contradictional what you want to do in the future, you should avoid to do so. At least, as your modification "A" is concerned.
Players who like "A" in the early stages might get confused and frustrated, if "A" later on becomes completely different.
Therefore, if your increased skills, experience, maybe the forming of a development team would lead to changed behaviour later on, it might be a wise idea to create a second, third, .... ninth modification basesd on what you have learned in the past.
That way, you avoid to make people become familiar with your early settings and then, just switch to different reactions and behaviours of the game.
In general, I think we are sharing similar ideas in many cases. Thinking about what you really want to do and what you want to achieve is a crucial part. Preparing the individual steps to achieve your goals might be even more important.
And finally, as long as you are not intending to keep your modification just for your own, give the community a chance to offer their feedback.
This should be done between 4 and 5 in your stage outline I guess.
