Programming tends to be considered a straightforward problem solvingactivity; a developer has a requirement and codes a solution. Beautyis often judged on the technical implementation's elegance oreffectiveness; this book is replete with excellent examples. Yetbeyond its immediate computing functions, code can have a profoundeffect on people's lives. It can inspire people to participate andcreate new content. Unfortunately, serious barriers exist that preventindividuals from participating in a project.

  1. The Battle for Wesnoth is a free software online game that can be learnt efficiently offline. The game is graphical and role based. There are two versions (at the time of writing) that you may download. The first is stable, version 1.02 and the second is somewhat less stable, but has a few more features that are being put through a test phase.
  2. The Battle for Wesnoth is an open source, turn-based strategy game with a high fantasy theme. It features both singleplayer and online/hotseat multiplayer combat. Explore the world of Wesnoth and take part in its many adventures! Embark on a desperate quest to reclaim your rightful throne. Flee the Lich Lords to a new home across the sea.

Most programming languages require significant technical expertise toutilize, which is out of reach for many. In addition, enhancing theaccessibility of code is technically difficult and is not necessaryfor many programs. It rarely translates into neat coding scripts orclever programming solutions. Achieving accessibility requiresconsiderable forethought in project and program design, which oftenruns counter-intuitive to normal programming standards. Moreover mostprojects rely upon an established staff of skilled professionals thatare expected to operate at a reasonably high level. They do notrequire additional programming resources. Thus, code accessibilitybecomes an afterthought, if considered at all.

Our project, the Battle for Wesnoth, attempted to address this issuefrom its origins. The program is a turn-based fantasy strategy game,produced in an open source model based on a GPL2 license. It has beena moderate success, with over four million downloads at the time ofthis writing. While this is an impressive metric, we believe the realbeauty of our project is the development model that allowed a band ofvolunteers from widely different skill levels to interact in aproductive way.

Enhancing accessibility was not a vague objective set by developers,it was viewed as essential for the project's survival. Wesnoth's opensource approach meant that the project could not immediately expectlarge numbers of highly skilled developers. Making the projectaccessible to a wide a number of contributors, with varying skilllevels, would ensure its long-term viability.

Battle for Wesnoth is a critically acclaimed strategy game, currently we will bring wesnoth universe into Mount & Blade Series. 7/10 (13 votes) - Download Battle for Wesnoth Free. Battle for Wesnoth will take you to a fantasy world with elves, wizards, dwarves, orcs and warriors. Download Battle for Wesnoth for free and be victorious. Sometimes a simple idea can become a great project thanks to imagination and hope. The Battle for Wesnoth is a turn-based strategy game with a fantasy theme. Build up a great army, gradually turning raw recruits into hardened veterans. In later games, recall your toughest.

Our developers attempted to lay the foundations for broadeningaccessibility right from its earliest iteration. This would haveundeniable consequences for all aspect of the programmingarchitecture. Major decisions were made largely with this objective inmind. This chapter will provide an in-depth examination of our programwith a focus on the efforts to increase accessibility.

The first part of this chapter offers a general overview of theproject's programming, covering its language, dependencies andarchitecture. The second part will focus on Wesnoth's unique datastorage language, known as Wesnoth Markup Language (WML). It willexplain the specific functions of WML, with a particular emphasis onits effects on in-game units. The next section covers multiplayerimplementation and external programs. The chapter will end with someconcluding observations on our structure and the challenges ofbroadening participation.

25.1. Project Overview

Wesnoth's core engine is written in C++, totalling around 200,000 linesat the time of this publication. This represents the core game engine,approximately half of the code base without any content. The programalso allows in game content to be defined in a unique data languageknown as Wesnoth Markup Language (WML). The game ships with another250,000 lines of WML code. The proportion has shifted over theproject's existence. As the program matured, game content that washardcoded in C++ has increasingly been rewritten so that WML canbe used to define its operation. Figure 25.1 gives arough picture of the program's architecture; green areas aremaintained by Wesnoth developers, while white areas are externaldependencies.

Overall, the project attempts to minimize dependencies in most casesso as to maximize the portability of the application. This has theadded benefit of reducing the program's complexity, and decreases theneed for developers to learn the nuances of a large number of thirdparty APIs. At the same time, the prudent use of some dependenciescan actually achieve the same effect. For example, Wesnoth uses theSimple Directmedia Layer (SDL) for video, I/O and event handling. Itwas chosen because it is easy to use and provides a common I/Ointerface across many platforms. This allows it to be portable to awide array of platforms, rather than the alternative of coding tospecific APIs on different platforms. This comes at a price however;it is harder to take advantage of some platform specific features. SDLalso has an accompanying family of libraries that are used by Wesnothfor various purposes:

  • SDL_Mixer for audio and sound
  • SDL_Image for loading PNG and other image formats
  • SDL_Net for network I/O

Additionally, Wesnoth uses several other libraries:

  • Boost for a variety of advanced C++ features
  • Pango with Cairo for internationalized fonts
  • zlib for compression
  • Python and Lua for scripting support
  • GNU gettext for internationalization

Throughout Wesnoth's engine, the use of WML objects—that is, stringdictionaries with child nodes—is fairly ubiquitous. Many objectscan be constructed from a WML node, and also serialize themselves to aWML node. Some parts of the engine keep data in this WML dictionarybased format, interpreting it directly rather than parsing it into aC++ data structure.

Wesnoth utilizes several important subsystems, most of which are asself-contained as possible. This segmented structure has advantagesfor accessibility. An interested party can easily work a code in aspecific area and introduce changes without damaging the rest of theprogram. The major subdivisions include:

  • A WML parser with preprocessor
  • Basic I/O modules that abstract underlying libraries and system calls—a video module, a sound module, a network module
  • A GUI module containing widget implementations for buttons, lists, menus, etc.
  • A display module for rendering the game board, units, animations, and so forth
  • An AI module
  • A pathfinding module that includes many utility functions for dealing with a hexagonal gaming board
  • A map generation module for generating different kinds of random maps

There are also different modules for controlling different parts ofthe game flow:

  • The titlescreen module, for controlling display of the title screen.
  • The storyline module, for showing cut-scene sequences.
  • The lobby module, for displaying and allowing setup of games on the multiplayer server.
  • The 'play game' module that controls the main gameplay.

The 'play game' module and the main display module are the largestwithin Wesnoth. Their purpose is the least well defined, as theirfunction is ever-changing and thus difficult to have a clearspecification for. Consequently, the modules has often been in dangerof suffering from the Blob anti-pattern over the program'shistory—i.e., becoming huge dominant segments without well-definedbehaviors. The code in the display and play game modules areregularly reviewed to see if any of it can be separated into a moduleof its own.

There are also ancillary features that are part of the overallproject, but are separate from the main program. This includes amultiplayer server that facilitates multiplayer network games, as wellas a content server that allows users to upload their content to acommon server and share it with others. Both are written in C++.

25.2. Wesnoth Markup Language

As an extensible game engine, Wesnoth uses a simple data language tostore and load all game data. Although XML was considered initially,we decided that we wanted something a little more friendly to non-technicalusers, and a little more relaxed with regard to use of visual data.We therefore developed our own data language,called Wesnoth Markup Language (WML). It was designed with the leasttechnical of users in mind: the hope was that even users who findPython or HTML intimidating would be able to make sense of a WMLfile. All Wesnoth game data is stored in WML, including unitdefinitions, campaigns, scenarios, GUI definitions, and other gamelogic configuration.

Battle For Wesnoth Mods

WML shares the same basic attributes as XML: elements and attributes,though it doesn't support text within elements. WML attributes arerepresented simply as a dictionary mapping strings to strings, withthe program logic responsible for interpretation of attributes. Asimple example of WML is a trimmed definition for the Elvish Fighterunit within the game:

Since internationalization is important in Wesnoth, WML does havedirect support for it: attribute values which have an underscoreprefix are translatable. Any translatable string is converted usingGNU gettext to the translated version of the string when theWML is parsed.

Rather than have many different WML documents, Wesnoth opts for theapproach of all main game data being presented to the game engine injust a single document. This allows for a single global variable tohold the document, and when the game is loaded all unit definitions,for instance, are loaded by looking for elements with the nameunit_type within a units element.

Though all data is stored in a single conceptual WMLdocument, it would be unwieldy to have it all in a single file.Wesnoth therefore supports a preprocessor that is run over all WMLbefore parsing. This preprocessor allows one file to include thecontents of another file, or an entire directory. For instance:

will include all the .cfg files within gui/default/window/.

Since WML can become very verbose, the preprocessor also allowsmacros to be defined to condense things. For instance, the{LESS_NIMBLE_ELF} invocation in the definition of theElvish Fighter is a call to a macro that makes certain elf units lessnimble under certain conditions, such as when they are stationed in aforest:

This design has the advantage of making the engine agnostic to how theWML document is broken up into files. It is the responsibility of WMLauthors to decide how to structure and divide all game data intodifferent files and directories.

When the game engine loads the WML document, it also defines somepreprocessor symbols according to various game settings. Forinstance, a Wesnoth campaign can define different difficulty settings,with each difficulty setting resulting in a different preprocessorsymbol being defined. As an example, a common way to vary difficultyis by varying the amount of resources given to an opponent(represented by gold). To facilitate this, there is a WML macrodefined like this:

This macro can be invoked using, for instance, {GOLD 50 100200} within the definition of an opponent to define how much goldthe opponent has based on the difficulty level.

Since the WML is processed conditionally, if any of thesymbols provided to the WML document change during execution of theWesnoth engine, the entire WML document must be re-loaded andprocessed. For instance, when the user starts the game, the WMLdocument is loaded and available campaigns among other things areloaded. But then, if the user chooses to start a campaign and choosesa certain difficulty level—easy for instance—then the entiredocument will have to be re-loaded with EASY defined.

Battle for wesnoth cheats

This design is convenient in that a single document contains all gamedata, and that symbols can allow easy configuration of the WMLdocument. However, as a successful project, more and more content isavailable for Wesnoth, including much downloadable content—all ofwhich ends up inserted into the core document tree—which means theWML document is many megabytes in size. This has become a performanceissue for Wesnoth: Loading the document may take up to a minute onsome computers, causing delays in-game any time the document needs tobe reloaded. Additionally, it uses a substantial amount ofmemory. Some measures are used to counter this: when a campaign isloaded, it has a symbol unique to that campaign defined in thepreprocessor. This means that any content specific to that campaigncan be #ifdefed to only be used when that campaign is needed.

Additionally, Wesnoth uses a caching system to cache the fullypreprocessed version of the WML document for a given set of keydefinitions. Naturally this caching system must inspect the timestampof all WML files so that if any have changed, the cached document isregenerated.

25.3. Units in Wesnoth

The protagonists of Wesnoth are its units. An Elvish Fighter and anElvish Shaman might battle against a Troll Warrior and an OrcishGrunt. All units share the same basic behavior, but many have specialabilities that alter the normal flow of gameplay. For example, a trollregenerates some of its health every turn, an Elvish shaman slows itsopponents with an entangling root, and a Wose is invisible in aforest.

What is the best way to represent this in an engine? It istempting to make a base unit class in C++, with different typesof units derived from it. For instance, a wose_unit class couldderive from unit, and unit could have a virtualfunction, bool is_invisible() const, which returns false, whichthe wose_unit overrides, returning true if the unit happens tobe in forest.

Such an approach would work reasonably well for a game with a limitedset of rules. Unfortunately Wesnoth is quite a large game and such anapproach is not easily extendable. If a person wanted to add a newtype of unit under this approach, it would require the addition of anew C++ class to the game. Additionally, it does not allow differentcharacteristics to be combined well: what if you had a unit thatregenerated, could slow enemies with a net, and was invisible in aforest? You would have to write an entirely new class that duplicatescode in the other classes.

Wesnoth's unit system doesn't use inheritance at all to accomplishthis task. Instead, it uses a unit class to represent instancesof units, and a unit_type class, which represents theimmutable characteristics that all units of a certain type share. Theunit class has a reference to the type of object that it is.All the possible unit_type objects are stored in a globallyheld dictionary that is loaded when the main WML document is loaded.

A unit type has a list of all the abilities that that unit has. Forinstance, a Troll has the 'regeneration' ability that makes it heallife every turn. A Saurian Skirmisher has the 'skirmisher' abilitythat allows it to move through enemy lines. Recognition of theseabilities is built into the engine—for instance, the pathfindingalgorithms will check if a unit has the 'skirmisher' flag set to seeif it can move freely past enemy lines. This approach allows anindividual to add new units, which have any combination of abilitiesmade by the engine, by only editing WML. Of course, it doesn't allowadding completely new abilities and unit behavior without modifyingthe engine.

Additionally, each unit in Wesnoth may have any number of ways toattack. For instance, an Elvish Archer has a long-range bow attackand also a short-range sword attack. Each deals different damageamounts and characteristics. To represent an attack, there is anattack_type class, with every unit_type instancehaving a list of possible attack_types.

Battle For Wesnoth Mac

To give each unit more character, Wesnoth has a feature known astraits. Upon recruitment, most units are assigned two traits at randomfrom a predefined list. For instance, a strong unit does more damagewith its melee attacks, while an intelligent unit needs lessexperience before it 'levels up.' Also, it is possible for units toacquire equipment during the game that make them more powerful. Forinstance, there might be a sword a unit can pick up that makes theirattacks do more damage. To implement traits and equipment Wesnothallows modifications on units, which are WML-defined alterations to aunit's statistics. The modification can even be applied to certaintypes of attacks. For instance, the strong trait gives strong unitsmore damage when attacking in melee, but not when using a rangedstrike.

Allowing completely configurable unit behavior with WML would be anadmirable goal, so it is instructional to consider why Wesnoth hasnever achieved such a goal. WML would need to be much more flexiblethan it is if it were to allow arbitrary unit behavior. Rather thanbeing as Multiplayer Implementation

The Wesnoth multiplayer implementation uses a simple-as-possibleapproach to implementing multiplayer in Wesnoth. It attempts tomitigate the possibility of malicious attacks on the server, butdoesn't make a serious attempt to prevent cheating. Any movement thatis made in a Wesnoth game—moving of a unit, attacking an enemy,recruiting a unit, and so forth—can be saved as a WML node. Forinstance, a command to move a unit might be saved into WML like this:

This shows the path that a unit follows as a result of a player'scommands. The game then has a facility to execute any such WML commandgiven to it. This is very useful because it means that a completereplay can be saved, by storing the initial state of the game and thenall subsequent commands. Being able to replay games is useful both forplayers to observe each other playing, as well as to help in certainkinds of bug reports.

We decided that the community would try to focus on friendly, casualgames for the network multiplayer implementation of Wesnoth. Ratherthan fight a technical battle against anti-social crackers trying tocompromise cheat prevention systems, the project would simply not tryhard to prevent cheating. An analysis of other multiplayer gamesindicated that competitive ranking systems were a key source ofanti-social behavior. Deliberately preventing such functions on theserver greatly reduced the motivation for individuals to cheat.Moreover the moderators try to encourage a positive gaming communitywhere individuals develop personal rapport with other players and playwith them. This placed a greater emphasis on relationships rather thancompetition. The outcome of these efforts has been deemed successful,as thus far efforts to maliciously hack the game have been largelyisolated.

Wesnoth's multiplayer implementation consists of a typicalclient-server infrastructure. A server, known as wesnothd, acceptsconnections from the Wesnoth client, and sends the client a summary ofavailable games. Wesnoth will display a 'lobby' to the player who canchoose to join a game or create a new game for others to join. Onceplayers are in a game and the game starts, each instance of Wesnothwill generate WML commands describing the actions the playermakes. These commands are sent to the server, and then the serverrelays them on to all the other clients in the game. The server willthus act as a very thin, simple relay. The replay system is used onthe other clients to execute the WML commands. Since Wesnoth is aturn-based game, TCP/IP is used for all network communication.

This system also allows observers to easily watch a game. An observercan join a game in-progress, in which case the server will send theWML representing the initial state of the game, followed by a historyof all commands that have been carried out since the start of thegame. This allows new observers to get up to speed on the state ofthe game. They can see a history of the game, although it does taketime for the observer to get to the game's current position—thehistory of commands can be fast forwarded but it still takestime. The alternative would be to have one of the clients generate asnapshot of the game's current state as WML and send it to the newobserver; however this approach would burden clients with overheadbased on observers, and could facilitate denial-of-service attacks byhaving many observers join a game.

Of course, since Wesnoth clients do not share any kind of game statewith each other, only sending commands, it is important that theyagree on the rules of the game. The server is segmented by version,with only players using the same version of the game able tointeract. Players are immediately alerted if their client's gamebecomes out of sync with others. This also is a useful system toprevent cheating. Although it is rather easy for a player to cheat bymodifying their client, any difference between versions willimmediately be identified to players where it can be dealt with.

25.5. Conclusion

We believe that the beauty of the Battle for Wesnoth as a program ishow it made coding accessible to a wide variety of individuals. Toachieve this aim, the project often made compromises that do not lookelegant whatsoever in the code. It should be noted that many of theproject's more talented programmers frown upon WML for its inefficientsyntax. Yet this compromise enabled one of the project's greatestsuccesses. Today Wesnoth can boast of hundreds of user-made campaignsand eras, created mostly by users with little or no programmingexperience. Furthermore it has inspired a number of people to take upprogramming as a profession, using the project as a learningtool. Those are tangible accomplishments that few programs can equal.

One of the key lessons a reader should take away from Wesnoth'sefforts is to consider the challenges faced by lesser skilledprogrammers. It requires an awareness of what blocks contributors fromactually performing coding and developing their skills. For example anindividual might want to contribute to the program but does notpossess any programming skills. Dedicated technological editors likeemacs or vim possess a significant learning curve thatmight prove daunting for such an individual. Thus WML was designed toallow a simple text editor to open up its files, giving anybody thetools to contribute.

However, increasing a code base's accessibility is not a simpleobjective to achieve. There are no hard and fast rules for increasingcode's accessibility. Rather it requires a balance between differentconsiderations, which can have negative consequences that thecommunity must be aware of. This is apparent in how the program dealtwith dependencies. In some cases, dependencies can actually increasebarriers to participation, while in others they can allow people tocontribute more easily. Every issue must be considered on acase-by-case basis.

We should also be careful not to overstate some of Wesnoth'ssuccesses. The project enjoyed some advantages that are not easilyreplicated by other programs. Making code accessible to a wider publicis partly a result of the program's setting. As an open sourceprogram, Wesnoth had several advantages in this regard. Legally theGNU license allows someone to open up an existing file, understand howit works and makes changes. Individuals are encouraged to experiment,learn and share within this culture, which might not be appropriatefor other programs. Nevertheless we hope that there are certainelements that might prove useful for all developers and help them intheir effort to find beauty in coding.

Coments are closed

Recent News

  • Maple 2018.1 Update
  • IconJar
  • PixPlant
  • CollageIt

Scroll to top