Bartek Waresiak wrote:
-revolutionary: many changes, new units, new proposals, abilites etc..
changes (sometimes even drastic) to basic game rules. I bring this up,
because I noticed that some people would like to see some quite big
changes in a game. I see 2 dangers connected with this: first that we
will resign (even in only some parts od the project) from KISS
principle, and make game too complicated to be fun for average player,
second, that we will make Wesnoth, which won't be this 'our' Wesnoth
anymore.
-conservative: stick to 1.0 branch, do some bugfixing, add new things
only if they won't add anything complicated, do not try to change game
rules. But I think that this isn't trully what word 'develop' mean, so
it won't happen.
-careful reformist: take what wasn't so good in 1.0 and change it. Make
changes, but make them carefully, and not many at once. Add new things,
which will still 'fit' wesnoth and will be KISS. Make big change(s) _if_
needed, but consider all opinions, KISS principle and Wesnoth
Philosophy. I'm, honestly, in favour of this one. I belive that thanks
to it, we won't 'lose' that, what make wesnoth unique, and game won't
became too complex. Also developing process will still be ongoing.
I would also advocate "careful reformist". There are of course a lot of
radical changes that could turn out great, but I suspect it will be very
hard to keep the code stable and manageable this way.
as Dave said: "We will also continue to use evolutionary development
heavily We will not re-write large portions of code. Rather, we will add
a small amount at a time. Add one small feature at a time."
I think this is wise. Lets just have a look at trunk lately. It's
probably been broken more often than not. I believe it will become
harder to incorporate additional features, at least somewhat complex
one. Fx the new replay functionality had much wider implications than
first believed, and Yogi who is an accomplished coder to begin with has
had to fix a lot of problems that at first was not anticipated. New
features need to be carefully considered and integrated, instead of
ripping parts out and replace them with brand new code.
This will also ensure that Wesnoth stays Wesnoth and not end up as
something else.
--
mvh (o_
Hogne Håskjold //\
V_/_
