Difference between revisions of "NotSoEasyCoding"

From The Battle for Wesnoth Wiki
(Game Engine)
(WML-related features: migrate [query_location] here from EasyCoding)
(44 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== Foreword ==
+
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. :-)
This page shows 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 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.
+
If you're not, you should post a feature request and discuss your idea on the forum or IRC or Discord. 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.
 
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 are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)
+
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....). We sometimes forget to update this page so it is recommended that, before you start to work on a task, that you ask in irc/Discord whether its still considered a good idea.
  
 +
If you are  part of the Wesnoth dev team you can also add new entries to the list, a new entry must contain at least
  
 +
1) A description of the problem.
 +
2) A motivation why or in which situations this is important.
 +
3) A link to a corresponding ticket on our bugtracker for discussion, if there is no ticket yet then  make one.
  
== Game Engine ==
+
__TOC__
=== add a mode to improve OOS detection in MP ===
 
We really need an optional 'pedantic mode' for MP which detects OOSes immediately, by comparing all game state information after each action and printing any mismatches. This mode will be optional because of the extra overhead it adds, and it would be very useful for debugging.
 
  
=== <s>Fix a longstanding bug concerning failure to initialize a side in networked mp</s> ===
+
== Game engine ==
  
(Actually we may have a fix for this now... will post reference)
+
=== [[OpenGL port]] ===
  
https://gna.org/bugs/index.php?21397
+
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.
  
The problem itself is quite simple -- when the server tells a client that their turn has begun, the client immediately broadcasts [init_side] to all the other players via the server, performing the initial upkeep, healing, and movement point reset actions. However, if this player disconnects / blocks the action by opening a dialog during the prior turn and never closing it, [init_side] is never broadcast. And if the game is then saved by one of the other clients, nothing in the current mechanism detects that this has been overlooked when the game is reloaded. The consequence is that in the reloaded game, that side's turn is *never* initialized -- they get no gold, their units don't heal, and they don't get full move points at the start of the turn.
+
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.)
  
Propose a mechanism to fix this -- perhaps games which have been loaded should be scanned to see if the current turn failed to initialize. Perhaps a flag in game_state could be used and saved. Perhaps a completely different approach. Check that your mechanism works whether the save is loaded from [snapshot] or [replay_start] and [replay].
+
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 whichever Wesnoth series that will see this project completed.
  
This bug has existed since at least Wesnoth 1.8
+
One of the many issues related to switching from software rendering to hardware rendering is Wesnoth's [[ImagePathFunctions]] mini-language. There is already a proof of concept [https://github.com/CelticMinstrel/wesnoth-ipf here] that converts most IPFs to OpenGL shader code, but quite a bit more work would need to be done to make something usable out of it. In particular, the ability to compile arbitrary [[Wesnoth Formula Language]] code into shaders would be needed, since some IPFs embed the language.
 
 
=== <s>Make a "replay actions since my last turn" button</s> ===
 
 
 
It would be very convenient if there an ability to replay everything your opponents just did at the
 
start of your turn, since sometimes things go out of vision or are confusing.  
 
 
 
The feature would be like a "replay since my last turn" menu option or button -- most likely, the best approach to implement it is to store a copy of the game_state object in playcontroller.cpp or even in resources, and to refactor the backlog object so that we can hold a "bookmark", i.e. a pointer, to the last position in the replay that we might look to jump back to. The replay process would work by swapping out for the old gamestate, then replaying through the actions since the bookmark until we get back up to speed. The difficult part would be making sure that scenarios with scripted WML events don't break when we do this. For debugging purposes, it might be good to check that at this point we have the same gamestate we did before we clicked the button. The bookmark should only be advanced when we end our turn, and there might be perhaps need to be multiple bookmarks, one for each side, to handle what happens when a side disconnects or is reassigned.
 
 
 
It would be especially helpful for MP play to have this, where special tactics with ambush units are quite common. Part of the design criteria of wesnoth is that it should be a high-level, thoughtful turn based strategy game, but you should be able to play asynchronously and not necessarily give attention to the game until your turn bell rings if you don't want to. Having ambush units and no ability to replay their movements during the opponents turn harms that goal.
 
 
 
For MP play, it will require special attention to make sure that events like "synchronize_choice" are handled correctly so as not to cause out of sync errors, and also that the timer is handled correctly.
 
 
 
Feature request: https://gna.org/bugs/?15334
 
 
 
Thanks to Zappaman for this. https://github.com/wesnoth/wesnoth/pull/270
 
  
 
=== Improve WML error reporting ===
 
=== Improve WML error reporting ===
Line 47: Line 33:
 
There are many programming bugs that give very unclear or cryptic error messages when using WML. Here are some examples:
 
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.
+
* <strike>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.</strike>
 
 
-- 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. It would be nice if we could catch this and report an error.
 
 
 
Many of the users of WML are students or beginners to programming, it is a big help to them to improve the error reporting of this nature -- not to mention that many veterans would appreciate 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.
 
 
 
=== Map label "groups" which can be selectively turned on and off by the user ===
 
 
 
It would be nice if the user could have more control over how map labels are displayed, for instance to be able to check on / off labels made by certain players, and for custom scenarios, to be able to make custom classes which the use can turn on or off. This might be helpful for custom scenarios esp. which might have some technical info they want to show, but which it might be messy to display all of the time. The hard part of this is that there should ideally be a gui to work with the map labels, although maybe this need could be worked around or simplified somehow.
 
 
 
=== Add a new damage stats calculation mode to support scenarios with extremely high stats ===
 
 
 
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.
+
* 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.
  
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.
+
* When doing scenario transitions in a campaign, if the side definitions don't match up 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...
  
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.
+
* 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 <i>before</i> resource starvation). It would be nice if we could catch this and report an error.
  
=== Better native support for random map generation ===
+
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.
  
Many UMC mods would like to be able to generate random maps for their gameplay. Right now it's quite difficult for them to do this, since if the built-in wesnoth random generator isn't flexible enough for them, then they probably have to start from scratch in lua.
 
  
One interesting project was the YAMG generator, which seeks to provide a highlevel map description language, i.e. with primitives like "there should be a forest region roughly here, between townships here and here, with a road between them" and the random generator fills in the details. Another way of going about things might be a generator that can take a map as a template, then it tweaks it randomly (a little or a lot) according to some rules.
+
=== Don't store all events in savefiles ===
  
The YAMG generator seems not to be developed anymore, but even if it is eventually finished there is certainly room for several general-purpose map generator projects.
+
Currently all events in a scenario are stored twice in each savefile (in [snapshot] and it [replay_start]), specially on wml-heavy umc content this can make savefiles quite big, The proposed solution is that events are not stored in savefiles when they are the same as in the scenario/era/modification file (e.g. not dynamically added with actionwml).
 +
In detail the savefile should for all events that have an id and are not generated dynamically ([event] actionwml), store dummy events like
 +
[event]
 +
  id=event_id
 +
  is_unchanged=yes
 +
[/event]
 +
in the savefiles (instead of full events), where the event is then read from the scenario/era/modification tag when the scenario is loaded. This should only apply to campaigns/modifications/mp maps/eras that require download (which is usually the case for campaigns but not for mp maps)
  
== MP Related ==
 
  
=== Automatically resolve add-on dependencies ===
+
See also https://github.com/wesnoth/wesnoth/issues/1512
  
In 1.11 add-ons may declare dependencies. A related easy coding task is to allow the user to force breaking dependencies.
+
== Multiplayer/replay features ==
 
 
A related goal which would be greatly beneficial would be that wesnoth can automatically resolve the dependencies by fetching the add-ons from the download server, when in the MP-lobby the user tries to join a game with a dependency they don't meet. A dialog would ideally be provided as well, or perhaps a preference.
 
 
 
https://gna.org/bugs/?21705
 
 
 
Even older: https://gna.org/bugs/?9683
 
  
 
=== Gold graph ===
 
=== Gold graph ===
  
Make a graph feature, presumably in a dialog, that helps depict the history of the game. For example it could display army value, army + bank value, number of villages tagged, luck swings... the purpose would be to assist spectators of a live game / spectators of a replay to understand the history of the game. It would be particularly helpful with AI development, by helping AI developers to identify key points where one of the AI is making a big mistake.  
+
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.
 
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.
Line 105: Line 71:
 
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 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 build dependency of wesnoth.
+
The extra code should be guarded with preprocessor flags so that ZeroConf does not become a mandatory build dependency of Wesnoth.
 +
 
 +
https://github.com/wesnoth/wesnoth/issues/1162
  
https://gna.org/bugs/?13703
+
=== 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.
  
=== Create a set of "common" mp messages which players can use when they don't share a language ===
+
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.
  
Most users speak english, however, wesnoth also has large Polish and Hungarian communities, and many Brazilian players, not all of whom 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 hard part is that if you don't already know about the gettext translation system, you will have to learn about it. The messages should be stored in a .cfg file in the data folder so that they can be easily modified and can be handled in the same way that other in-game text is translated -- they should perhaps go in their own gettext-domain however. Ideally there would be a gui dialog of some kind to select from them.
+
== GUI2 framework ==
  
== Improvements to AI ==
+
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).
=== Move and targeting phase ===
 
AI needs to move units which are not within range of the enemy. This is generally a sequence of moves (some interesting things like 'ambush!' or 'WML event' might happen as a result of those moves, which should interrupt this phase). The problem is that simply doing those moves 1-by-1 is very slow, for two reasons:
 
  
#movement maps are invalidated after each move, and are recalculated from the start. yet, if we are doing just a sequence of moves, we can just 'remove moved unit from moves' after each move and avoid expensive recalculation of the movement map.
+
=== Multi-line textbox, single-line textbox improvements ===
#* Note that WML could mess with the game state at any time, so at the very least, movement will need to be recalculated after a WML event blocks undo (that is, indicates that it changed game state). --[[User:Brilliand|Brilliand]] 01:30, 28 May 2012 (UTC)
 
#most tasks need devoting more than one unit to execute (i.e., it's meaningless to go for the enemy position with just 1 unit). So, making individual decisions just does some repeating calculations, which is slow.
 
  
A practical demonstration of these concerns are LoW 2 (dwarf ai is slow due to large avoid aspect) and NR:Showdown (orc AIs there are slow because of huge number of units)
+
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.
  
we need a fast and effective 'move and targeting stage' - both ideas and implementations are wanted.
+
=== Generic tab_container widget ===
Here's Sirp's idea (more in 2009-aug-15 irclog):
 
  
--
+
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.
  
=== Eval-based AI ===
+
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.
The AI system would be based around an 'eval' function -- a formula which is given a position, and returns a number saying how attractive that position is.
 
  
There would also be a 'candidate_moves' function -- a formula which is given a unit and returns a list of 'candidate moves' -- i.e. moves for that unit that the AI should consider making.
+
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.
  
The aim of the system is to come up with the combination of candidate moves that gives the best possible evaluation. By doing this, the AI will work in a team, since the 'eval' function can give bonuses for units being close together, protecting each other, etc.
+
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.
  
There are likely to be, of course, a very large combination of possible moves, and not every one can possibly be evaluated. Instead, we take a monte carlo approach.
+
=== GUI2 themable in-game UI ===
  
If an AI has N units that it can move, that is an N-dimension matrix of possible moves. We would choose some cells in this matrix at random and then evaluate them. Then, of these cells evaluated we would choose cells that evaluated well, and discard those that did not evaluate well. Then, we would begin with those cells that evaluated well, and choose a scattering of 'close by' cells -- i.e. cells where we only vary some of the dimensions, at random. We would continue to evaluate cells at random, starting with those cells that evaluated well, and evaluating cells nearby. After several iterations, we would hope to arrive at a cell that evaluates very well, and we would use this as our set of moves.
+
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).
  
Of course, this system will be made more complex by the uncertainty of attacks. There are a number of ways to handle attacks, probably the easiest being to consider attacks as types of moves, and then if a move combination involving an attack is chosen, perform the attack and then re-run the entire AI algorithm before moving again. (Something similar to what the current AI does).
+
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.
  
This is effectively an AI framework, not an AI in itself. How well it performs will correlate strongly with how good an eval() function one can write, and is also based on the notion that generally certain combinations of moves are 'similar' to other combinations.
+
'''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)
  
--
+
=== Rich Text Label Widget ===
  
=== Village grabbing ===
+
As of version 1.13.11, the one last dialog that hasn't yet been converted to GUI2 is the help dialog. In order to finish this conversion, a new type of widget is required. It needs to be able to support text with embedded images (both centered as a block and with text wrapped around them), clickable links that trigger a callback, and tab stops, on top of the regular Pango formatting stuff. This can probably all be done with Pango, but requires digging deeper into the API (particularly for the text wrap shapes). It would also need to parse markup, for example an extension of the standard Pango markup.
  
Improve AI village grabbing algorithm to assign villages that are farther than one turn from current unit location.
+
== Add-ons server and client ==
Idea how to do would be value villages so that it can filter out villages that belongs to enemies/allies sides.  Those villages are stored in memory and used in 2nd pass that determines how AI should dispatch units to get villages if it should at all in this turn. This should be close to optimal solution with currently available units but performance limits should be taken into account.
 
Good solution would be that village grabbing value could be calculated with attack ratings and if some village has high value it would make unit go for that village instead
 
  
This should help AI in begin of scenario. Currently AI might not grab all of villages that belong to its area which results quite large incoming loses.
+
=== Passphrase hashing ===
In later game enemy might have large number of units in one part of map so village grabbing should be avoided in that are. Single unit would be easy pray for enemy so moving there would result just to loses.
 
  
== Data Structures ==
+
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 [http://forums.wesnoth.org/viewtopic.php?f=62&t=42663 various implications].
=== Config Writer ===
 
  
The speed of saving Wesnoth games is dominated by the time to marshall all the config structures.  This involves deep copying them many times as each subsystem returns its config bundle; far better would be to have a "config_writer" class which is handed to each subsystem which iterates through its structures and does the writing (to file or network) directly to the config_writer instance.
+
Ideally, the server would store all passphrases in a hashed form.
  
Stop by #wesnoth-dev on freenode irc if you want to help with this, or post in the Coder's Corner.
+
=== Port redirection ===
  
=== Config memory optimisation ===
+
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.
  
Right now, most of the memory used by wesnoth when using '''low_memory''' configuration flag is used by the config object trees. It would be possible to drop unused "branches" of that trees by using boost smart pointers in the config structure
+
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.
  
come and discuss that change on #wesnoth-dev. Sirp is the one that knows the most about that...
+
== Multiplayer server and client ==
  
=== Improvements to Unit Map ===
+
=== Improve server WML processing ===
  
As described here: [http://www.wesnoth.org/forum/viewtopic.php?p=236063#236063] (cjhopman has submitted a patch on that already)
+
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 (https://github.com/wesnoth/wesnoth/issues/1420). Fixing this is not easy due to the aforementioned performance requirements.
  
== See Also ==
+
== WML-related features ==
 +
=== Game Information ===
  
=== Frequently Proposed Good Ideas ===
+
* [query_location] - queries a location from the user
 +
** variable
 +
** [filter_location]
 +
''Regarding [query_location]: probably a better name would be choose_location. This is used when a wml event is running and needs to get a target location hex from the user. For example, you right click on a catapult unit and choose the menu item "fire Catapult." Now a [message] says to click on any target within 5 hexes. Now [choose_location] is encountered and the mouse cursor changes to a target sign (possibly customizable). If the user's mouse drifts outside of the allowed locations it changes to a cancel icon. If the operation is cancelled then the variable is cleared and no location stored. --Sapient''
  
Check the [http://www.wesnoth.org/forum/viewtopic.php?f=12&t=9054&start=0&st=0&sk=t&sd=a B.W.H. list] in the Ideas Forum. Be aware that some entries there are old and have already been implemented, so you will need to investigate that before beginning work.
+
''This can be implemented in lua by using wesnoth.game_events.on_mouse_action and wesnoth.syncronize_choice''
  
[[Category:Development]]
+
https://github.com/wesnoth/wesnoth/issues/2325
[[Category:Future]]
 

Revision as of 08:54, 23 December 2022

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 or Discord. 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....). We sometimes forget to update this page so it is recommended that, before you start to work on a task, that you ask in irc/Discord whether its still considered a good idea.

If you are part of the Wesnoth dev team you can also add new entries to the list, a new entry must contain at least

1) A description of the problem. 2) A motivation why or in which situations this is important. 3) A link to a corresponding ticket on our bugtracker for discussion, if there is no ticket yet then make one.

Game engine

OpenGL port

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 whichever Wesnoth series that will see this project completed.

One of the many issues related to switching from software rendering to hardware rendering is Wesnoth's ImagePathFunctions mini-language. There is already a proof of concept here that converts most IPFs to OpenGL shader code, but quite a bit more work would need to be done to make something usable out of it. In particular, the ability to compile arbitrary Wesnoth Formula Language code into shaders would be needed, since some IPFs embed the language.

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 match up 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.


Don't store all events in savefiles

Currently all events in a scenario are stored twice in each savefile (in [snapshot] and it [replay_start]), specially on wml-heavy umc content this can make savefiles quite big, The proposed solution is that events are not stored in savefiles when they are the same as in the scenario/era/modification file (e.g. not dynamically added with actionwml). In detail the savefile should for all events that have an id and are not generated dynamically ([event] actionwml), store dummy events like

[event]
 id=event_id
 is_unchanged=yes
[/event]

in the savefiles (instead of full events), where the event is then read from the scenario/era/modification tag when the scenario is loaded. This should only apply to campaigns/modifications/mp maps/eras that require download (which is usually the case for campaigns but not for mp maps)


See also https://github.com/wesnoth/wesnoth/issues/1512

Multiplayer/replay features

Gold graph

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

Automatically link up to wesnothd server on a local network

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.

https://github.com/wesnoth/wesnoth/issues/1162

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.


GUI2 framework

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 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)

Rich Text Label Widget

As of version 1.13.11, the one last dialog that hasn't yet been converted to GUI2 is the help dialog. In order to finish this conversion, a new type of widget is required. It needs to be able to support text with embedded images (both centered as a block and with text wrapped around them), clickable links that trigger a callback, and tab stops, on top of the regular Pango formatting stuff. This can probably all be done with Pango, but requires digging deeper into the API (particularly for the text wrap shapes). It would also need to parse markup, for example an extension of the standard Pango markup.

Add-ons server and client

Passphrase hashing

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.

Port redirection

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.

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 (https://github.com/wesnoth/wesnoth/issues/1420). Fixing this is not easy due to the aforementioned performance requirements.

WML-related features

Game Information

  • [query_location] - queries a location from the user
    • variable
    • [filter_location]

Regarding [query_location]: probably a better name would be choose_location. This is used when a wml event is running and needs to get a target location hex from the user. For example, you right click on a catapult unit and choose the menu item "fire Catapult." Now a [message] says to click on any target within 5 hexes. Now [choose_location] is encountered and the mouse cursor changes to a target sign (possibly customizable). If the user's mouse drifts outside of the allowed locations it changes to a cancel icon. If the operation is cancelled then the variable is cleared and no location stored. --Sapient

This can be implemented in lua by using wesnoth.game_events.on_mouse_action and wesnoth.syncronize_choice

https://github.com/wesnoth/wesnoth/issues/2325