[Wesnoth-wiki-changes] WesnothPhilosophy

[wiki]

UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; sv-se) AppleWebKit/125.5.5 
(KHTML, like Gecko) Safari/125.11
IP: 213.64.183.37
URI: http://wesnoth.slack.it/?WesnothPhilosophy
 - - - - -
Index: WesnothPhilosophy
===================================================================
RCS file: /home/wesnoth/cvsroot/wikiroot/WesnothPhilosophy,v
retrieving revision 1.13
diff -u -r1.13 WesnothPhilosophy
--- WesnothPhilosophy   27 Nov 2004 09:36:22 -0000      1.13
+++ WesnothPhilosophy   27 Nov 2004 09:43:13 -0000
@@ -1 +1,224 @@
-<spam removed - please restore to backup>
+Spam removed - Tried to restore from commit mail - but reverting to older 
version might be better option.
+
+The 18th of December will mark six months since the first version of Battle 
for Wesnoth, version 0.1, was released.
+
+At this time, I feel it is appropriate to respond to something Bazarov said in 
another thread:
+
+Bazarov wrote:
+
+ am having a little difficulty understanding the core values of the game in 
the eyes of the creators.
+ I think having an established, ordered list of these would help a lot in my 
attempts to help. A white
+ paper of sorts. I don't think this should be done by voting, either; a clear, 
concise vision would be
+ nice. Where does originality factor in? I, too, felt that the game's focus 
was on the units rather
+ than the strategy, that the building of my colourful army was more important 
than the logic of any
+ scenario.
+
+
+We talk about the 'KISS [1] principle' here alot, and I think that that is the 
most core design principle used in
+Wesnoth. It was the key principle that enabled Wesnoth to get off the ground, 
and it is the principle that has kept it
+alive since.
+
+First of all, the concept of 'KISS' is a software development principle. Not a 
game-design principle. The idea of game
+rules being simple is not necessarily a bad one, and can be linked to KISS in 
that game rules that are simple to
+implement are often ones that most players would consider 'simple'. However 
simple game rules are not directly related
+to KISS, as many people on the forum mistakenly seem to have thought.
+
+-When I was a teenager, I attempted to write games several times. Some of them 
were playable, even impressive -
+especially considering my resources and skill - but none of them were 
professional, and polished. When I showed them to
+people, they would be impressed, and say "this looks good", but I knew that 
none of them would actually want to take the
+game home and play it for themselves.
+
+My programming skills back then left alot of room for improvement. I had a 
basic, self-taught knowledge of C and C++.
+Then I went to college, and after that got a job programming, where my skills 
improved immensely.
+
+In some of my spare time, I decided to try writing a game again. What kind of 
game? Well, I was confident of my skills,
+so I would write a complex game, using all the latest programming tools.
+
+I wanted to write a Civilization-like game, but with some major rule changes, 
and a better AI. I had thought up
+sophisticated systems for everything. The result? It failed before it even got 
started, collapsing in a mountain of
+complexity.
+
+I gave up on writing a game for a long time after that. I was busy with other 
things anyhow. But then one day, I played
+a game that I had played when I was much younger, a Genesis game: Master of 
Monsters. It was fun, lots of fun, yet it
+was simple. Simple enough that I was confident I could program a game like it 
easily enough.
+
+I had analyzed that most Free games fall into one of two categories: they are 
either boringly trivial, or they are
+insanely complex, and never really get off the ground. I decided I would claim 
the middle ground: make it simple enough
+to write, but substantial enough to be lots of fun. It wouldn't be as 
ambitious as some things I wanted to write, but at
+least it would work.
+
+But, I don't see the point of writing a Free game which is simply a copy of a 
commercial game. My aim would be to write
+something new, something better, something which borrows the best ideas from a 
number of other games, and which adds new
+ideas of its own.
+
+
+The idea of KISS is that the feature must be easy enough to program that 
before the programmer starts working on it,
+they have a very clear and strong understanding of how they're going to make 
it work. Not a 'yes I can do this but it is
+kinda complicated'. Rather they should be thinking 'this is so stupid and 
simple that it's really really easy for me to
+do'. So I decided on a simple rule for the game: a feature would be added only 
if I knew immediately how to implement
+it. I wouldn't make vague promises to myself about features that would be 
later added, but which I had no idea how to
+do.
+
+I started with a few basic units, and two races: Orcs and Elves. Elves had 
horsemen, which could advance to knights,
+archers which could advance to rangers, and fighters which could advance to 
heroes.
+
+I considered different systems of advancement. Even considering something 
which keeps track of the activity the unit
+undergoes, and advances it in that area, but I rejected such a system for 
something simple, something similiar to Master
+of Monsters with the added choice of letting the player choose what their unit 
advances into at some points.
+
+The focus would be around building your own army, and watching it grow as its 
members became more experienced. You would
+only have basic control over the advancement of a particular member of the 
army, but you would decide what units go into
+the army.
+
+I also fleshed out a very basic interface. There would be only a few commands: 
to move a unit, and to attack with that
+unit, as well as to recruit and recall units. I added in unit skills, which 
was something Master of Monsters didn't
+have, but I made the skills occur implicitly -- healing would be dispensed to 
all units around a specific unit for
+instance.
+
+Obviously, Wesnoth is a fantasy game, so it contains some implication of 
spells/magic, however I have always disliked
+games that got deep into sophisticated systems of spells.
+
+In Wesnoth, wars would be decided with sword and bow. Mages would be involved 
too, of course, but warfare was to be
+about guiding troops around strategically, not about which spell to cast and 
where. So, from the beginning I decided
+that all spells would be implicit, or simply a type of attack.
+
+This was a big divergence from Master of Monsters where one spell could be 
cast every turn by each master at any place
+on the battlefield. That was, in my opinion, one of the game's worst features 
- if your enemy had advanced a unit on the
+other side of the map, you could try to kill him with a spell.
+
+I also made the combat very simple. An example of this is the way in which the 
chance to hit is calculated. I'm
+wondering how many people know how the chance to hit is calculated in Wesnoth? 
I thought it was alot more complex in
+Master of Monsters until I studied how they did it.
+
+What I suspect most people would immediately consider for a chance-to-hit 
system would be a formula that relies on the
+attacker's skill with the weapon, and the defender's defensiveness, as well as 
the terrain the defender is in.
+
+The way Wesnoth does it is in fact so insanely simple that I suspect many 
people who did not know how it is done will
+think 'what a naive, silly system!' when they read the following:
+
+Quote:
+ The chance to hit is taken entirely from the defender's defensive rating in 
the terrain it is in.
+
+
+So, Elves are always 30% chance to hit in forest, and 60% chance to hit in 
grassland. The attacker's skill doesn't come
+into the equation.
+
+I decided it would add interesting strategy, though, if just a very few 
weapons had a special attribute that would
+guarantee them a certain chance to hit. I decided that was an appropriate 
thing for magic, to differentiate it: so, I
+decided that magic attacks would always have 70% chance to hit.
+
+For all my efforts though, and for all the people who say that graphics are of 
little importance or unimportant, I don't
+think that Wesnoth would have gotten anywhere if fmunoz hadn't seen it, and 
drawn some very good graphics for it. The
+graphics I had drawn were pathetic, but he drew some nice ones, and added the 
undead and later humans to the game, as
+well as doing some scenarios, and adding some very good ideas to the game.
+
+I think it's important for us to remember the KISS principle as development 
continues. Remember: Wesnoth has not reached
+1.0 yet. It's not a finished work. It could still fail. Let's make it easy for 
it to succeed by keeping everything
+simple.
+
+Oh and how did I come up with the name 'Wesnoth'? It was late at night, and I 
wanted to release version 0.1. I muttered
+syllables to myself, until I came up with a pair that sounded halfway 
reasonable: 'Wesnoth'.
+
+David
+
+[1] Keep It Simple, Stupid
+
+||More on the KISS principle||
+
+The reason behind the KISS principle is fairly straightforward: often 
programmers will be confronted with someone -
+perhaps a user, perhaps a designer, perhaps themselves - who wants them to 
implement something to work in a certain way.
+Oftentimes the programmer can only just work their head around all the 
requirements, and when they start implementing
+the feature, they don't have a clear idea of how the entire feature is to be 
implemented, because it's so complicated.
+
+Such a situation inevitably leads to low-quality and very buggy software.
+
+KISS intentionally has the 'stupid' part, because often 'architecture 
astronauts' as they're known come up with 'super
+elegant generic designs' that to them are simple, and most importantly, 
elegant. Elegance is nice, but in a real-world
+situation, it doesn't defeat KISS. Without the 'stupid' part in there, some 
people would claim that elegance and
+simplicity are strongly related, and so their 'elegant' design should be 
implemented.
+
+But no, it doesn't matter how elegant it is. If the coder can't understand 
exactly how to do it, it's not KISS. A less
+elegant design, one that is simple and stupid, should be used instead.
+
+So that's it I guess: if the implementer finds it very very easy to do, then 
it's KISS. If they don't, it's not.
+
+This can be related back to game rules somewhat. One of the aims of Wesnoth 
was to make a game with a pretty good AI.
+One of the things I noticed about other games, was that they added in alot of 
game rules that their users wanted, which
+were very very difficult for the AIs of those games to use or understand.
+
+So, I decided I'd make a game where the rules were detailed enough to be fun, 
but structured in a way that the AI can
+work with them.
+
+I think that's the best definition of KISS for game rules that we will find: 
if it's very easy to implement, including
+making the AI use the rules effectively, then it's KISS.
+
+This makes most but not all of our current game rules KISS. In particular, 
special abilities involving auras
+(leadership, healing, illumination) are not currently used at all effectively 
by the AI. It might not be so complicated
+for the AI to be able to use them though.
+
+Things like skirmish are very KISS, since the AI immediately understands how 
to use it effectively.
+
+You'll note that originally, when Wesnoth consisted of no multiplayer, and no 
campaigns other than Heir to the Throne,
+it was structured so the AI would only control units that it can use 
effectively: it didn't have access to any aura
+effects, while it did have access to things like poison.
+
+This is the cornerstone of KISS: what is laughably easy for a programmer to do 
is going to result in high quality,
+bug-free software. What is 'simple' for users, or 'elegant' for designers, but 
not easy for a programmer is not going to
+result in high quality software.
+
+David
+
+
+||Wesnoth Philosophy II||
+
+||What's next?||
+
+I've been asked by Steelp (and others) to write something on where we plan to 
take Wesnoth next. So here is my opinion
+on where we should take Wesnoth next, as at version 0.8:
+
+I am now happy with Wesnoth's game rules. I think it is a good, fun, simple, 
and addictive game. A game that is fun to
+play, and challenging.
+
+I don't think we need any more game rules, or any game rule changes. The game 
has met and exceeded most of its original
+design goals.
+
+We have met many challenges during Wesnoth development, but we now have a new 
challenge: making Wesnoth a polished and
+high enough quality product to declare it 1.0, and show it to 'the world at 
large'.
+
+I think that we have a very real chance of failing. That we can continue 
adding features, debating changes, going
+sideways, and end up with a product that is too large, too bloated, too 
unstable to make it to 1.0. With a development
+team that is too burned out on adding features and debating insignificant 
changes to polish and debug the program
+enough.
+
+I think we have to accept that version 1.0 need not have every feature 
imaginable. That we will in fact have to leave
+out good ideas in order to deliver a finished product.
+
+I want to start moving aggressively toward a version 1.0. I think the longer 
we delay, the more developers and users
+will become frustrated at slow progress. My feeling is that the time is now to 
finish off all engine features, or decide
+that they will be left until after 1.0.
+
+IMO the engine is now feature-complete enough for a 1.0. It'd be nice to add a 
few more features, but it has enough
+features to ship a 1.0 already. gettext support would be especially nice, but 
I don't think it's absolutely necessary.
+
+I think that I would like to declare a feature freeze sometimes within the 
next few weeks. Features that are not added
+in this time will have to wait until after 1.0. I think we've been waiting 
long enough for this already, and I am
+unwilling to wait much longer. We have stayed in the very dangerous '90% done, 
10% to go' state for far too long now. It
+is time to move toward 1.0.
+
+To ensure that 1.0 is a stable program, we will take a number of measures. We 
will have a fairly long beta-testing
+period, in which time bugs will be hunted down and squashed. We will take a 
more rigorous approach to squashing every
+minor bug we can find than previously.
+
+During this time, campaigns will also be completed, as will graphics, sound 
and music. Translations will be finished,
+documentation written, and balancing done.
+
+I will discuss this further with developers, but IMO, campaigns that are not 
completed by 1.0 should be removed for the
+1.0 release. 1.0 should be an entirely finished product, with no 'loose ends' 
at all.
+
+After 1.0, I still don't think that we will have too many game rule changes. 
However, I would like to put some effort
+into making Wesnoth more flexible, to allow people who want to make forks to 
make their own projects.
+
+Personally, I am mostly committed to getting the project to 1.0 at the moment. 
After that, we can decide what will
+happen next.
+
+David