WesnothPhilosophy
Contents
The History of, and Philosophy behind Wesnoth
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:
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 a lot, 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:
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: Where 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 sometime 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