WesnothPhilosophy

The History of, and Philosophy behind Wesnoth (2003 original)

The 18th of December 2003 marked six months since the first version of Battle for Wesnoth, version 0.1, was released.

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, there is always 30% chance to hit Elves in forest, and 60% chance to hit them 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? (2008)

We had a section in here on where to take Wesnoth next, but it was written before 1.0 was released. That would make it rather out of date.

Eric Raymond has pressured me to update this section. Interestingly, much of the above was based on some of Eric Raymond's writings.

So, we are about to release Wesnoth 1.4. 1.4 will be a very solid, stable release, with an impressive list of features. Some people claimed that Wesnoth wasn't really ready for a 1.0 label back when we released 1.0. Any concerns that Wesnoth is not a stable, mature game should have been removed by 1.2 though, and certainly should be crushed by 1.4. The team has done an excellent job of building a very impressive product.

Where to now? Onward and upward, of course! We already have a great game, and around that great game has developed a great community. Using the resources we now have available, we can continue to improve the game to be better and better. To make it more fun, faster, run on more platforms, more reliable, and support a wider variety of game elements.

Of all suggestions to improve -- or perhaps I should say change -- Wesnoth, one of the most common, and certainly the most controversial, is to alter the gameplay in some way. To add a new gameplay feature, to add new unit special abilities, to alter unit stats, and so on and so forth. Are we planning to continue to make gameplay changes, and of what nature? Should we radically alter the game?

We have a great game, that people enjoy. We don't plan to radically alter the core game mechanics. We will continue to tweak things of course -- and our gameplay balance developers have done an excellent job of balancing things out, and will continue to do so. The core game mechanics will remain the same. What we might do, however, is add a wider variety of feature support to the engine, to support more different user made campaigns and scenarios.

A key part of Wesnoth's success is in keeping an open mind. No single developer, least of all me, has been able to consistently and accurately predict what is fun and what isn't. Instead, by developing a flexible platform that allows people to develop scenarios and campaigns on, users can make content which proves to be fun, or not. Our community has done an excellent job of creating fun content that I never imagined possible.

We want to continue doing this. We want to make our engine more and more flexible, little by little. We want to take 'fringe elements' -- dramatically different gameplay styles that were only supportable by bizarre and convoluted WML -- and make the engine support them better.

We have many plans for a variety of features to allow this. A better WML engine. A more flexible AI engine that will allow much greater customization.

However, the core Wesnoth team does not intend to migrate Wesnoth to a fundamentally different play style. But, that said, I think it would be a great idea for *someone* to. We have an excellent set of resources: great art, a good code base, and so forth. These resources could be re-used to make a 'civilization-style' hex game. Or a 'tactics' game (Wesnoth is already somewhat of a tactics game, but one could take this in different directions). Or more of a 'wargame'. For someone to do this would be excellent. If another great FLOSS game could be created with Wesnoth's resources, that would be great for the FLOSS gaming community. I, personally, would love to play such a game. :)

Something else we want to address going forward is Wesnoth's performance. Wesnoth was originally created using an approach that was easy to develop with, but placed performance, in terms of time and space, as a secondary concern. It is still easily runnable on most desktop machines, but it doesn't run well on smaller devices. We have several developers who are highly committed to making Wesnoth run well on small devices. We plan to work hard on this, and make this happen.

Finally, I think the best thing about Wesnoth is its community. I feel we should continue to foster and grow the community. We have recently had a "Wesnoth Conference" at FOSDEM, which ten Wesnoth developers and contributors attended. It would be excellent if we could organize such a thing again, perhaps on a larger scale.

That said, I personally feel that attempting to raise money to fund such a thing is entirely within the spirit of the FLOSS community. We could, for instance, consider using (unintrusive) ads on our website to raise money, and then organize a conference, funding it with the money (including paying subsidies to anyone wanting to come, to help pay for their expenses).

I must admit, that even after Wesnoth got 'off the ground', I was at times concerned about its chances of reaching a credible 1.0. Later I was concerned about its direction thereafter, especially with me becoming less involved with the project. I have been incredibly impressed by the development team and the community which has done an excellent job in developing Wesnoth. I am now very confident in Wesnoth's future.

See Also

• Frequently Proposed Ideas
• The History of, and Philosophy behind Wesnoth
• Wesnoth Philosophy II: Where Next? (2004)