Difference between revisions of "NotSoEasyCoding"

Revision as of 21:10, 26 August 2009

Foreword

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

Game Engine

Multiplayer and RNG Cheating

As described here: [1]

A more generalised teleporting ability

see [2]

A change to allied healing

As proposed here: [3]

Improvements to AI

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

we need a fast and effective 'move and targeting stage' - both ideas and implementations are wanted.

Village grabbing

Improve AI village grabbing algorithm to assign villages that are farther than one turn from current unit location. 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. 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

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.

Stop by #wesnoth-dev on freenode irc if you want to help with this, or post in the Coder's Corner.

Config memory optimisation

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

come and discuss that change on #wesnoth-dev. Sirp is the one that knows the most about that...

Improvements to Unit Map

As described here: [4] (cjhopman has submitted a patch on that already)

@@ Line 31: / Line 31: @@
 #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.
-#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)
+#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)
 we need a fast and effective 'move and targeting stage' - both ideas and implementations are wanted.
 === Village grabbing ===