You’ve come here either after reading our latest news post or because you saw this thread crop up in the forum index under the Developers’ Discussions section, which is now open for a limited time to posts from regular users.

So, you probably want to help develop Wesnoth but don’t know where to start. In that case, you have three options:

Search the bug tracker for a bug or feature request that you would like to see addressed

Once you know what you want to work on, you should get familiarized with Git and clone the Wesnoth source code repository, which contains all contents and history of mainline Wesnoth, including the game engine itself. Note that it’s a large download (approximately 2 GiB). If you require the ability to pause and resume your download, you should ask shadowm (either on IRC or via forum PM) for help with obtaining access to our downloadable Git snapshots.

Code Documentation

After obtaining a clone of the repository, you will most certainly want to refer to our existing code documentation for help:

Wesnoth’s source code documentation is most certainly incomplete, in large part due to an over-abundance of undocumented legacy code from retired developers which no-one has ever fully understood nor wanted to examine and document. Although the situation right now isn’t the best, we still have people able to help you with any questions you might have about a particular part of Wesnoth. The following information is also relevant for WML and Lua coders.

You will find all these people idling in our IRC channel, #wesnoth-dev @ irc.freenode.net at different times of day. Don’t have an IRC client? Here is a convenient webchat link you can use. The channel is logged at irclogs.wesnoth.org, so even if someone isn’t around you can still reach them by leaving your message prefixed with their nick like so: shadowm: Hi; in turn, you will also be expected to search the logs for any mentions of your nick made while offline. You may also use forum PMs for communication, but be aware that our primary discussion medium for mainline development has always been IRC and some of these people rarely (if ever) use the forums.

There is also a #development channel on Wesnoth's Discord, for those who prefer to communicate using that platform.

So, without further ado and in no particular order, here is our list of active developers, all ready to help you with your inquiries and pull requests:

shadowm:
For several years, he has been the sole maintainer of the add-ons client and server (campaignd). He’s also worked extensively with GUI2 in the past, converting and adding dialogs, and improving existing ones. He also understands our UI design practices best at the moment. Other than that, he does not really have a specific focus on any particular aspect of the game but he’s generally able to answer any question and point people in the right direction. Finally, although he works primarily on Debian GNU/Linux, he is also able to test Windows-oriented patches and has in fact contributed code for that platform on several occasions.

gfgtdf:
One of our most recent additions, he and iceiceice did a large amount of work on fixing various MP and replay mode bugs so that we could have version 1.12.x out before the end of 2014. His work continues in 1.13.x by fixing various bugs left from GSoC 2014, as well as implementing miscellaneous Lua and WML API features. His platform of choice is Windows and he, like aquileia below, can help you with any Visual C++-related problems.

aquileia:
Also a Windows-based developer, he maintains our Visual C++ project files and development kits.

vultraz:
He’s still learning C++, but he has a great deal of experience using WML and Lua, and generally has the right idea when it comes to critiquing UI design. He also uses Windows and builds Wesnoth with Code::Blocks and GCC.

zookeeper:
His “WML Wizard” title is not just for show. Among the current active developers, he has been around the longest and understands our WML/Lua API design best, and even maintains the majority of the mainline campaigns. He does not do C++, but if you intend to add new WML or Lua features or need help using the existing ones, you should definitely ask him for help and comments. His platform of choice is Windows.

Elvish_Hunter:
Like shadowm above, he does a bit of everything without a particular focus. His most recent work revolves around adding new image path functions and maintaining GUI.pyw, his GUI front-end for wmllint and wmlindent.

loonycyborg:
Although he is our Windows packager, he works primarily on Linux. Still, he is able to answer any kind of questions about our official Windows packaging process and also maintains our SCons build recipe.

mattsc:
Part of our Apple OS X packaging team, he is our resident AI expert and should be able to answer most of your AI-related questions, even if he doesn’t have much time at the moment.

ancestral:
Also part of our Apple OS X packaging team, he should be able to help you build Wesnoth if you are an OS X user.

Ivanovic:
Our internationalization manager and translation coordinator. Up until version 1.12.1 he also served as Wesnoth’s release manager. He uses Linux.

bumbadadabum:
For the past few years, he's been doing a variety of things, mostly focusing on campaign maintenance and lua code.

About the Code Base

Wesnoth’s code base comprises more than just the C++ game engine (wesnoth). A large amount of low level functionality, including the WML parser and preprocessor, is shared with the Wesnoth multiplayer server (wesnothd) and the add-ons server (campaignd). Mainline and user-made content maintenance also relies heavily on Python-based tools which are also part of the mainline code base: wmlindent, the WML indentation fixing script used to enforce a single indentation style across all mainline campaigns and MP scenarios; and wmllint, the WML code checker which is in charge of both updating existing WML whenever changes in syntax or semantics are added to a new version, and guarding against common code mistakes and typos in translatable strings.

Note that although the game engine itself is written in C++ (C++03, to be specific), most WML action tags as of 1.13.1 are implemented in Lua to varying extents. Going forward, we would like to delegate more and more tasks to Lua rather than hard-code them in order to enable content creators to do more with Wesnoth’s engine.

Wesnoth leverages functionality from the C++ standard library and Boost for its foundations, and uses SDL 1.2.x and its companion libraries (SDL_image, SDL_mixer) for implementing game functionality. Pango and Cairo are used for text rendering in GUI2 and a few other places, and SDL_ttf is used in legacy GUI code. The code base is cross-platform by design and it’s constantly tested on Linux, Microsoft Windows, and Apple OS X.

EDIT 2016-08-31: Moved from Developers’ Discussion to Coders’ Corner as part of restoring the group restrictions on the former. ― shadowm

Hi, I've read vultraz's thread and decided to volunteer as a WML coder to maintain a few mainline campaigns. I believe I'm familiar with WML enough to do the job and I had a little experience with Github, but my drawback is that I'm not a good enough player and not a native speaker of English, so I would frequently need help with lore and balance.
My most interested campaigns to maintain are Son of the Black Eye, South Guard and Heir to the Throne. Other campaigns are OK if you want me to take the job, but I am not enthusiastic with Wesmere MP. Because I playtested it with max_torch a few months ago. Aside from all the bugs, I don't feel the design being fun. I do hope sometime later a good shorter MP campaign can emerge and enter mainline in stead.

we proof-read the pull requests on GitHub before merging and will give you feedback either in the comment section or via IRC, so if you want to maintain one of the open mainline campaigns, welcome aboard! You'll probably want to discuss with zookeeper and vultraz on IRC which of the campaigns you listed you want to start with.

I'd be happy to help with language and lore as far as I can. You'll have to ask someone else to help play-testing, but I'm sure we'll find someone.

Hey, Xara. You're welcome to maintain those campaigns if you wish The best way to get started would be to clone our git repo and then browse through the relevant campaign's files and see if there are areas that need improvement, either code-wise or aesthetically (such as facings), and submit a PR for any changes you come up with.

As aquileia said, we do go over pull requests before merging them, and will be more than glad to give feedback and help.

Thanks for volunteering!

Creator of Shadows of Deception (for 1.12) and co-creator of the Era of Chaos (for 1.12/1.13).SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?

I played this game years ago and really enjoyed it. I've always thought this was a great project, and now that I can actually program, I'd like to help out.

I'm very strong with Python and could definitely provide help there. I've only been doing C++ for about 7 months, but I'm interested in improving and could provide some aid in that respect. Currently, my personal laptop is an OS X and I know a good amount about the OS. I cloned the repo today, so I'll start looking through the codebase in my free time.

I should also add that I love anything AI, although that doesn't seem to be a priority dev area in the project right now.

I have been teaching basic and intermediate programming (C/C++/C# mainly) for several years now, so I claim to have a pretty good grasp on algorithmics and at least some language features.
Also, thanks to my students, I have some, albeit limited, experience of working with Lua, Boost and SDL, but I'd certainly like to expand my knowledge of those.

I have been playing Wesnoth for two years. Recently, I have decided to create my own scenarios. I use Mac OS X. I feel I do well with tactics and not shabby with strategies. Perhaps, I may be useful play-testing until I become better at programming?

matthew619 wrote:I have been playing Wesnoth for two years. Recently, I have decided to create my own scenarios. I use Mac OS X. I feel I do well with tactics and not shabby with strategies. Perhaps, I may be useful play-testing until I become better at programming?

We can always use more playtesters, especially (but not exclusively) for development versions!

I Have read news on the website and want to help wesnoth developers. I have 2 years experiance as a python QA automation engineer, some experiance with WML (one addon at a server which need reimplementing it's features right way, and one campaign under developing not at the server yet). Some knowledge of C++ (beginning level, never used it for something big, so for the first time this is not area I can help with). Also also I had some experianse with formal grammars and parsing which I hope may be usefull for toolchains. Unfortunately my english is not good.

So I want to help with python toolchains and maybe authomation tests for wesnoth (I know nothing about about current wesnoth QA proсesses).
I found nothing about it in this forum thread. I guess at least tools may be outdated for new wml syntax. But I see no issues on github and hope somebody will tell what need to be done in this areas.

Hi, I wish to offer my help for python maintenance-tools. I have 4 years of experience developing python 2 . Already have cloned the git repo and have been looking a little at the main tools code. How can I help?

Hello, capgelka and jstitch. You should join the #wesnoth-dev IRC channel on freenode and discuss the areas you'd like to work on. There are already a few other people looking to help on the python toolchains, so you might be able to coordinate with them. The gist of it is that the tools are a mess and could likely use extensive refactoring or replacement.

Creator of Shadows of Deception (for 1.12) and co-creator of the Era of Chaos (for 1.12/1.13).SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?

Hi, everyone. I am interested in improving the display system of wesnoth. I already downloaded the git repo and looked at the source code. Looks like at some point developers abandoned hope for SDL2 and went for another library called SDL_gpu.

I think we can do it two ways. One is using SDL2 along with OpenGL, as discussed in the wiki. Another is migrating SDL1 surface blitting code to use SDL2's texture based 2D renderer. The last approach is going to be a lot more easy compared to the first one IMO. But as I read in the wiki page ( http://wiki.wesnoth.org/NotSoEasyCoding ... penGL_port ), others have commented that it is impossible due to SDL2 missing some alpha blending mode. It would be very helpful to see the full discussion regarding this topic.

My background:
I am a professional python programmer. I've worked with SDL1 in C on my pet project ( a tetris clone) and have very basic familiarity with c++. Looking forward to have fun tinkering with the code.

I can't link to the 'full discussion' of the topic, since it was mainly private IRC conversation and I don't have the logs anymore. I'll try to sum up the important facts here:

SDL2 doesn't have a decent software fall back mode. If the video driver fails for whatever reason, you're stuck with a software renderer that doesn't support some basic functionality that we need (for e.g. alpha blending). This is however a relatively minor concern.

SDL2 doesn't provide read access to textures or video frame buffers. Wesnoth's current (software) rendering solution involves a lot of optimizations that rely on read access and those would need to be dropped, so SDL2 wouldn't necessarily bring a boost to performance. Actually, I did have a working prototype of a rendering engine, and it turned out to be vastly inferior to the SDL1.2 renderer. Of course, a hardware accelerated engine should be able to outperform our current one, but that requires more substantial changes than simply replacing surfaces with textures.

The alpha blending/color modulation issue. Surprisingly, none of the alpha blending modes offered by SDL2 is for what you'd think is the most common use case: blitting semi-transparent surfaces on each other. They have all sorts of blending modes for crazy psychedelic effects, but you can't draw a ghost in front of a wall and have it look like a ghost in front of a wall. That, combined with the fact that you can't access the pixels you're drawing on top of is that what ultimately makes SDL2 a no-go for Wesnoth. There's a similar issue with color-modulation: none of the available modes is any similar to what we use for ToD coloring, which means that we can't just set modulation on a texture, we need to keep the appropriate surface around, recolor it via software when needed and then create a new texture.

Wesnoth uses hundreds of sprites at a given time, and currently these are all stored in their own surfaces (read textures for accelerated graphics). Since texture count is usually a bottleneck of graphics hardware, Wesnoth is generally unsuitable to run any kind of hardware acceleration (SDL2, SDL_gpu and OpenGL alike) until that is fixed.

I can't link to the 'full discussion' of the topic, since it was mainly private IRC conversation and I don't have the logs anymore. I'll try to sum up the important facts here:

SDL2 doesn't have a decent software fall back mode. If the video driver fails for whatever reason, you're stuck with a software renderer that doesn't support some basic functionality that we need (for e.g. alpha blending). This is however a relatively minor concern.

SDL2 doesn't provide read access to textures or video frame buffers. Wesnoth's current (software) rendering solution involves a lot of optimizations that rely on read access and those would need to be dropped, so SDL2 wouldn't necessarily bring a boost to performance. Actually, I did have a working prototype of a rendering engine, and it turned out to be vastly inferior to the SDL1.2 renderer. Of course, a hardware accelerated engine should be able to outperform our current one, but that requires more substantial changes than simply replacing surfaces with textures.

The alpha blending/color modulation issue. Surprisingly, none of the alpha blending modes offered by SDL2 is for what you'd think is the most common use case: blitting semi-transparent surfaces on each other. They have all sorts of blending modes for crazy psychedelic effects, but you can't draw a ghost in front of a wall and have it look like a ghost in front of a wall. That, combined with the fact that you can't access the pixels you're drawing on top of is that what ultimately makes SDL2 a no-go for Wesnoth. There's a similar issue with color-modulation: none of the available modes is any similar to what we use for ToD coloring, which means that we can't just set modulation on a texture, we need to keep the appropriate surface around, recolor it via software when needed and then create a new texture.

Wesnoth uses hundreds of sprites at a given time, and currently these are all stored in their own surfaces (read textures for accelerated graphics). Since texture count is usually a bottleneck of graphics hardware, Wesnoth is generally unsuitable to run any kind of hardware acceleration (SDL2, SDL_gpu and OpenGL alike) until that is fixed.

Hope that helped.

Thanks.That was informative. Agree with your point about Texture limitation of hardware. But it can be solved by automatically generating texture-atlas at loading time ( albeit not trivial ), as you suggested in the wiki. Because of the amount of surface redrawing Wesnoth does, surfaces and texture-atlas both need to be alive. Texture-atlases can be updated with render-to-texture feature of SDL2.

I am a bit lost in the blending issues though. Isn't blitting semi-transparent surfaces/textures is what SDL_BLEND_MODE_BLEND is for? ToD coloring uses the function 'light_surface' from 'sdl/utils.cpp'. If calculations of dr, dg, db variables are moved to lightmap generation function, SDL_BLEND_MODE_ADD (dstRGB = (srcRGB * srcA) + dstRGB | dstA = dstA) should be able to emulate the addition operation, given srcA is set to full opaque. For things like 'submerge_surface' function, it seems drawing on the surface is the only way to go.

I think I'm gonna start by porting sdl/utils.cpp to use textures (of type SDL_TEXTURE_ACCESS_TARGET) instead of surfaces ( as much as possible ). Whether it works or not is another matter.

I am a bit lost in the blending issues though. Isn't blitting semi-transparent surfaces/textures is what SDL_BLEND_MODE_BLEND is for?

Hm... I managed to dig up my post to the SDL forums about this topic. Since the only problem with alpha blending I mention there is its incompatibility with the software renderer, I assume that I started to misremember this problem later (it should be noted however that the SDL2 project was shut down soon after that post, so it definitely didn't happen due to this misinformation).

If calculations of dr, dg, db variables are moved to lightmap generation function, SDL_BLEND_MODE_ADD (dstRGB = (srcRGB * srcA) + dstRGB | dstA = dstA) should be able to emulate the addition operation, given srcA is set to full opaque.

I'm not sure what you have in mind here. I was talking about this when referring to color modulation. It's supposed to set a color overlay on a texture, but it doesn't really work how I'd like it to.

That post also reminded me about an issue I forgot about: scaling. Details there.

I think I'm gonna start by porting sdl/utils.cpp to use textures (of type SDL_TEXTURE_ACCESS_TARGET) instead of surfaces ( as much as possible ). Whether it works or not is another matter.

sdl/image.?pp could be easily adjusted to wrap an SDL_Texture object. It actually used to, before switching SDL_gpu, so you might be able to just restore it into an earlier state. There's also a fully working SDL2 window wrapper in that directory. Tons of SDL_GPU ifdefs splattered around in the code, these are very similar in logic to how a texture-based renderer should work.

I don't want to tell you what to or not to do, but personally I'd prefer if we could properly address these issues before jumping on SDL2 again. Also, I believe having the spritesheet (or as you call it: texture-atlas) feature implemented is a prerequisite for working on any kind of hardware acceleration.