This page lists projects which are considered a good idea by the developers but which have nobody working on them so far. If you think you've got the required skill for a task go on, implement it and you've got a high chance that it'll be accepted. The remaining barrier will only be that it's done well. :-)
If you are such a person, you should feel free to edit this page.
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you spend too long at working on a feature we'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)
- 1 Game engine
- 2 Multiplayer/replay features
- 3 GUI2 framework
- 4 Add-ons server and client
- 5 Multiplayer server and client
- 6 Data structures
Wesnoth currently depends on the unmaintained SDL 1.2.x code base and the 1.2.x-based versions of its companion libraries (SDL_image, SDL_mixer, SDL_net, SDL_ttf). This means Wesnoth can't benefit from features added in newer versions of SDL such as built-in support for Android and iOS, improved cross-platform Unicode support, built-in clipboard support, and any bug fixes made since SDL 1.2.15.
The problem with porting Wesnoth to SDL 2.0 as explained by lipkab (who attempted the task as part of GSoC 2014) is that SDL 2.0's software rendering API lacks some things Wesnoth needs such as a specific alpha blending mode (TODO: link to conversations here).
Furthermore, while software rendering is all good and nice, Wesnoth's approach does not scale well as display resolutions increase and the need for supporting high DPI configurations is factored in. One can easily see that our zoom functionality is clunky and inefficient. Having support for OpenGL and shaders would also enable us to implement fancier graphical gimmicks such as particle effects and atmospheric lighting. The downside of adding OpenGL to the mix is that we'd need people with a specific skillset to help us maintain the graphics engine in the long term, as hardware and driver-specific quirks are inevitable. Some users are also concerned about changing Wesnoth's hardware requirements so that they would be unable to play using old or unsupported hardware/OS configurations.
For hardware rendering to be effective, in particular, Wesnoth would necessitate a complete rewrite of the graphics rendering code (the display and game_display classes), the image cache manager (used to abstract the process of loading images from disk and applying image path functions), and potentially GUI2's canvas code. All three would have to limit the amount of textures they allocate to the absolute minimum, using larger textures instead. For example, the image cache could be reimplemented to load images from an internal spritesheet generated during the game loading process. (WML/Lua support for spritesheets would be nice would defining an API for it would only distract from the actual task at hand.)
The greatest difficulty in handling this task probably lies in writing a new optimized rendering engine and updating all code that relies on the old display/game_display API and semantics accordingly. The GUI2 framework code is presently unmaintained and it would take some time for somebody to study and change the current implementation. Finally, as we don't have a graphics engine maintainer at this time, this task involves an implicit long-term commitment to the project that extends beyond Wesnoth 1.14.x (or whichever series will see this project completed).
-- currently worked on by Aginor - 3 August 2015
Improve WML error reporting
There are many programming bugs that give very unclear or cryptic error messages when using WML. Here are some examples:
When calling a macro with the wrong number of arguments, Wesnoth tells the number it expected, and the number it got, and at which line number it was instantiated. However, it would be helpful if it would also tell the line number of the definition of the macro. This might be helpful if someone is redefining macros.
- For places where a standard unit filter is expected, if one is not found, the game should point out a problem. For places where such a filter is expected but [filter] child should not appear, if one does it should report an error and a line number. Many users have a hard time with this kind of thing.
- When doing scenario transitions in a campaign, if the side definitions don't matchup exactly the game tends to give unintelligible error messages. For instance, if one is transitioning and there is an AI side which does not have a leader (but it has a starting location in the map) it must have "no_leader = yes" in its [side] tag, or else when the team_builder objects enter stage two, the game will try to create a unit with an empty type, and the constructor of class unit will fail giving the error message "game::game_error tried to create unit with empty type". This really needs to be much better. For instance, giving a line number of a problem, or suggesting that no_leader should be used. (Note that, it is often possible to debug problems like this by turning on --log-debug=team_construction at commandline but I doubt that there are any users that know about this, you would only learn from reading the C++... without such debug info, fixing things like this can literally take hours.) For that matter it's some question why the team_builder doesn't just stop trying to build a unit when it sees it doesn't have enough info...
- Recursive macros break the game, and not by stack overflow but by exhausting the heap (which usually takes forever on modern OSes and results in memory thrashing before resource starvation). It would be nice if we could catch this and report an error.
Many WML users are students or beginners to programming, so any improvements to WML error reporting are a big help for their learning process -- many veterans would appreciate the extra help as well. In part we need fixits here and there, but more broadly we need a smarter system that can figure out what's really wrong when things go wrong, and give helpful suggestions.
Add a new damage stats calculation mode to support scenarios with extremely high stats
Done by Jyrki Vesterinen: https://github.com/wesnoth/wesnoth/pull/702
Most players use the damage calculation window constantly when they play so that they can see what to expect from various attacks. The way the game is currently set up, when a unit is selected, as soon as another unit is moused over the stats for an attack will be calculated, whether or not the user actually brings up the window.
The probabilities for the various outcomes are calculated by explicitly calculating the distribution of attacker and defender hp / slowed status after each swing by either party, one swing at a time. Thus at the end we get exact probabilities of the possible outcomes.
However, this comes at a cost -- the running time of the calculation can in the worst case be something like O( attacker_hp * defender_hp * total_number_of_strikes). In default era wesnoth (and in much of UMC) this is fine because units don't get extremely high hp values. However in some UMC units do get extremely high hp, and many will also have specials like drain and berzerk, and may have many different weapons as well. At some point these scenarios become unplayable even on a machine of moderate specs because mousing over any unit causes > 10 seconds of lag during which the game becomes unresponsive, trying to calculate attack outcomes.
In these cases, it would be better to give an "inexact" damage prediction, based on just simulating a few thousand attacks and plotting the results. Since it's a monte carlo algorithm rather than an exact algorithm, there will be some error, but if it makes the game playable then it's clearly an improvement, and anyways for "extreme stats" battles with high strikes and damage, the outcome is in a sense less random anyways because the outcomes with inordinate amounts of hits and misses are more and more rare (law of large numbers), so the error shouldn't actually be terribly significant.
If there were an advanced preference that caused the predictions to use such an algorithm instead of the current one, so that the user could turn it on if they start to get problems, it would eliminate a significant headache for some UMC.
Make a graph feature, presumably in a dialog, that helps depict the history of a Wesnoth match for the benefit of spectators of a live game or replay. For example it could display army value, army + bank value, number of villages tagged, luck swings... This would also be particularly helpful for AI tweaking development, by helping coders identify the AI's weaknesses and strengths in the context of a particular scenario.
A possible nice feature for this purpose would be to allow the user to click on the graph at key points which would trigger the "back to turn" mechanism to jump back in the replay, or automatically play the replay forwards from the beginning to that point... etc.
Related email on dev-talk: https://mail.gna.org/public/wesnoth-dev/2014-02/msg00089.html
The feature request was to use ZeroConf technology, if available, to publish info of a running wesnothd instance to other machines on a local network. Then when they are searching to connect to an unofficial server, they won't have to learn the IP address.
The extra code should be guarded with preprocessor flags so that ZeroConf does not become a mandatory build dependency of Wesnoth.
Stock MP chat messages for language-independent communication
Wesnoth has seen a large acceptance by international communities, and many players don't speak English. It would be nice we could have a set of messages that could be chatted, but which will be translated by our translators and displayed always in the current locale on each client, to make it easier to communicate in mp games / on the mp server.
The easy part is adding the messages. They would ideally be stored in a WML file in the core data dir so they can be easily modified and translated like all other mainline WML. The hard part is devising the interaction mechanism so that a player can easily make use of these stock messages in the MP lobby or in game.
As of 1.13.1+dev, GUI2's core and framework (including widgets and their APIs) are completely unmaintained. A prospective maintainer would have to be able to understand pretty advanced C++ making abundant use of template-based abstractions (most notably, the event handling code is almost completely implemented this way), multiple inheritance, and polymorphism. There is also some missing functionality (such as combo boxes and modeless dialogs) that the author did not get to implement, as well as work-in-progress functionality (new listbox and tooltip implementations, not enabled by default).
Multi-line textbox, single-line textbox improvements
GUI2 has a single-line textbox widget which works well for most purposes but falls short in a few niche cases. In particular, it's not possible to make it read-only without entirely disabling the user's ability to interact with the contents, which is inconvenient in places like the Game Paths dialog (or the About dialog in version 1.13.2 and later).
The widget also does not support multi-line contents. For this reason, GUI2 dialogs that present multi-line (read-only) text to the user make use of the scroll_label+clipboard button convention introduced by shadowm in 1.12.x (see the Chat Log, Gamestate Inspector, and WML load error dialogs for examples). This has the obvious limitations of not allowing the user to select specific portions of the contents, and not supporting editing.
Generic tab_container widget
After 1.13.1 was released, shadowm discovered a trick to implement tabbed dialogs in GUI2, involving a general widget bug fix to make children consider their parents' visibility when processing events, and an addition to the stacked_widget API enabling users to hide all but a single active layer.
The About dialog introduced in version 1.13.2 will use a horizontal listbox in combination with a stacked_widget, but ideally we should be able to reuse this pattern in more places without having to clutter up dialog implementations with the requisite code to synchronize the listbox and the stacked_widget's states. This hypothetical tab_container widget would combine the listbox and the stacked_widget to implement tabs in a cleaner fashion without having to expose the implementation details to individual dialog instances.
By all means, this should be an EasyCoding task, but GUI2's unusual code layout and API design conventions (compared to the rest of Wesnoth) may make it harder than it's supposed to be.
If you want to work on this, you should poke shadowm to make sure you don't duplicate efforts as he is working on a GUI2 port of the Preferences dialog and may take up this task after a while if no-one has done so first.
GUI2 most notably lacks a menu display (either for the game's menu bar or context menus). It is not known at this time how much work would have to be done in GUI2's core and framework to allow implementing this widget -- in particular considering how GUI2 widgets are never used without a parent dialog, which menus might not necessarily have, at least with the current gameplay UI implementation.
GUI2 menu FR: https://gna.org/bugs/?22820
GUI2 themable in-game UI
The "themable" in-game UI refers to the gameplay UI including the sidebar, menu/status bar, and map view. Most of it is not implemented using proper GUI1 widgets at all, except for the various interactive buttons, menus (which are floating GUI1 listboxes), and the command and chat input boxes (floating GUI1 textboxes).
Moving the theme UI to GUI2 would probably require finishing up theme support in GUI2 (which is largely incomplete), and may benefit from a rendering engine redesign as is also required for porting the game to SDL 2; in particular so that the GUI aspects are more clearly separated from the game board rendering aspect.
Note: This task is here solely for the sake of completeness, and only somebody very well versed in the intricacies of Wesnoth's game rendering code and GUI2 should ever try to take it up. (And even then, I would not want to be anywhere near that person when they inevitably break down and fling one or more tables around upon realizing the sheer complexity of the task. -- shadowm)
Add-ons server and client
The add-ons server (campaignd) uses a very dumb authentication scheme for uploading add-ons where an author sets a passphrase (or gets a random passphrase assigned by the game) the first time they upload to the server, and subsequent uploads of the same add-on are only allowed if the passphrase matches. The passphrase is stored in clear text form both client and server-side, which has various implications.
Ideally, the server would store all passphrases in a hashed form.
Wesnoth's MP server (wesnothd) uses a single port (15000) for servicing most requests and redirects clients to different ports according to the game client's version number. This allows the server administrators to reassign ports freely without having to modify the game client.
The add-ons server (campaignd) and client instead have a hardcoded default port number for a Wesnoth version series. For example, 1.12.x is hardcoded to default to 15006. This becomes a maintainability issue as add-on servers get decommissioned and their port numbers can't be reused for fear of misdirecting obsolete client versions to the wrong instance with incompatible add-ons.
Incremental upgrades and uploads
Right now, whenever a new add-on version is published, players must download (or conversely, upload) the whole contents, even if the differences between both versions amount to a single line change. This is not a problem with small add-ons, but there is a substantial number of large (> 10 MiB) add-ons on the server. Large downloads and uploads are inconvenient for players on slow or metered connections, and also increase the server's traffic requirements.
Ideally, for each add-on it attempts to upgrade or upload, the add-ons client should be able to send the server its local list of files with hashes, so that the server can identify which files need to be transmitted to/by the client, all archived on the fly like normal add-on downloads/uploads. The obvious downside is that the server would need to calculate an add-on's file hashes on demand, increasing CPU usage when servicing upgrades or uploads; this could be avoided by generating its file hashes when servicing uploads instead.
See also: https://gna.org/bugs/?19972 (for uploads only; there should be one for downloads too but I couldn't find it -- shadowm)
Porting the server to Asio
Although the client uses Boost.Asio for communications, the server continues to use SDL_net instead. This means, amongst other things, that we are limited to IPv4 and an unmaintained codebase full of hacks waiting to break apart in the future (Wesnoth's SDL_net code does, amongst other things, tamper with what are supposed to be opaque data structures maintained by SDL_net).
There was an attempt to build a new add-ons server (umcd) using Asio as part of GSoC, but it ultimately failed and the developers are no longer involved with the project. The umcd codebase status as of this writing is unknown.
Multiplayer server and client
Improve server WML processing
The server uses its own custom WML implementation separate from the main engine's to store and process WML objects for games -- see WesnothdDesign#simple_wml. This is intended to improve performance and reduce wesnothd's memory footprint with large numbers of games and complex scenarios. However, the simple_wml code sometimes messes up WML attribute translatability, resulting in MP scenarios/campaigns being untranslated for non-hosts in networked MP (http://gna.org/bugs/?22989). Fixing this is not easy due to the aforementioned performance requirements.
Make the Lua state persistent
Wesnoth is designed to make all data files as simple and human-readable as possible, including savefiles. WML is designed so that it is always very easy to write the entire WML state as plaintext and reload it correctly. There are many benefits of this, but especially
- It makes it easy for beginners / students to read the files and see what's going on
- It makes it easy for us to debug problems without needing special tools to read the savefiles
- It makes it easy to edit save files to work around any possible bugs. Users have even reported opening savefiles from version 1.10 in microsoft word (!) to correct minor bugs in mp and resaving them, as a policy for tournament games.
This was unfortunately somewhat lost when we added lua. If you use lua in your scenarios, things become more complicated because we can't save the lua state at all. If you rely on lua variables to save information, then when your scenario is saved and reloaded those variables will get wiped. The wesnoth engine provides places for lua to hook into "onsave" and "onload" so that the scenario developer can write their own serialization routines, but this is just punting the problem to scenario developers.
We also provide the "preload" event type specifically to work around the issue -- unlike all other events, preload is called exactly once for every time the scenario is loaded. The purpose is to give another way that lua users can initialize a table of lua functions used by their addon and guarantee that this happens before the functions are called. But to non-lua users this event is basically unsafe for normal use otherwise -- if there is a preload event which e.g. increments a WML variable, then the WML state now depends on how many times the scenario is saved or reloaded. In a normal scenario, save / reload events should be invisible, and normally if this isn't the case it indicates a bug similar to an OOS.
A nice solution to this would be if we properly serialized the lua state alongside the WML in a savefile. The most suitable solution is probably this library: https://github.com/fnuecke/eris It would require significant additional work as well to find a good way to serialize the C functions that we expose to lua, and the userdata like units held by lua.
More info here: http://lua-users.org/wiki/PlutoLibrary