A list of things that must, should or could be done by programmers.
Please, only programmers change this!
Ask Geoff the Medio if you'd like to help, or need help, with a programming task on this page.
- Keep an eye on bug reports and fix non-minor ones.
- Implement feature requests (typically requires design discussion on forums)
- Write up and maintain compilation User's Stories.
- Keep MSVC and XCode project files and CMake build files updated (if anyone adds or removes source files)
- Make the core / common library (mainly gamestate classes) be built as a shared / dynamic library instead of as a static library as it is now. This code should be the same for the server, human, and AI clients, so shouldn't need to be built into each of those binaries separately (Implemented for cmake build and Xcode project).
- Add a binary flag and related checkbox in the options screen to make the game use the default location for the resources directory, rather than using the version stored in config.xml. Currently, if more than one freeorion is installed on a system, and their resources directories contents are incompatible, it's necessary to delete the config.xml every time to make the game use the proper set of resources. With this switch, the game would automatically determine its own resources location (using the existing code that determines the default location of these files) and both versions could be run and would use their own, separate, automatic default locations for the resources dir without requiring the user to update it each time the version is changed.
- Stringtable entries can be formatted with <i>italics</i> or <rgba 0 255 0 255>colours</rgba>. It would be nicer if there were a few named colour tags available instead of requiring the clunky rgba as illustrated. <red>, <green>, <blue>, <white>, <black>, <defaultcolor>, etc. could be handy.
- Change victory conditions so that players can continue in the same galaxy after defeating all other empires PARTLY DONE IN SVN, should they be so inclined. Optionally, add multiple victory conditions and a way to choose between them during galaxy setup. Perhaps start or continue a forum discussion about what victory conditions there should be.
- Design and implement FreeOrion galaxy map saving and loading routines. It should be possible to load a map when starting a new game, instead of randomly generating one, and to save maps from the GUI or extract them from FreeOrion saved games. Maps should store stars, planets and planet specials. When loading, it should be possible to use only the stars (and randomly populate the systems), or use only stars and planets (and randomly add specials), or use all of the data.
- A way to do this might be to use a SVG image to store map data. Positions of stars would be indicated by circles in the image, and star colour would be indicated by the colour of the circle. Starlanes between systems could be indicated by lines between the system circles. Planets could be indicated by circles within the system circles, and planet type would be indicated by colour as well. Names of systems and planets could be text within their respective circles. Specials on objects could be indicated by boxes within the circle of a planet or system that contain the text that indicates the name of the special. Buildings on planets could be indicated by a different colour box that contains the name of the building. A zoomed-out (to see the whole universe) rendering of this SVG would resemble the in-game map, and zooming in would reveal details of the contents of systems and objects in systems or on planets in systems.
- Add additional moderator actions in moderator mode (a multiplayer game player type).
- Write code to get GG::Clr defined in a text file to determine the colours of meters in the GUI. The function GG::Clr MeterColor(MeterType meter_type) in InfoPanels.cpp should be updated to use this instead of hard-coded meter colours. Code to read colours already exists and is used for parsing tech category definitions in techs.txt, so doing the same for meters should be relatively simple.
- Bug of sorts: When building an Imperial Palace, the empire stockpile location is moved. When doing this, if the old and new stockpile locations aren't able to share resources, the new stockpile location shouldn't retain the old location's stockpile. Instead, the stored amounts of minerals and food should be set to 0.
- Modify the data transmission between the server and clients when sending turn updates and mid-turn updates, so that only data about changed Objects is sent. This should reduce the amount and duration of data sending, and should speed up unpacking / processing the results by clients.
Player order-giving improvements
- Make it possible to queue fleet orders (other than movement, which can already be queued), such as colonizing or invading a planet
- Add rally points for ships on the production queue
- Make it possible to give a production order a name, which will then be applied to all ships produced by that order. Multiple ships from the same order could have their object id appended to the name to disambiguate from other such ships.
- Add some player-helping AI scripts so the player can order a fleet to "explore"
- The ExecuteImpl functions of the various Order subclasses in Order.cpp should validate the orders they're about to execute, to ensure that invalid orders can't be sent by players using modified clients or improperly written AIs. For example, in FleetMoveOrder, a player could write a custom client that sends a FleetMoveOrder with a move route that doesn't follow the rules about where players can send ships. A bit of validity checking has been added to that function, but it should also check the route so that when the order is executed on the server, there's no way for an invalid order to be accepted. This validate should ensure that the series of systems in the order's route are all connected by starlanes known to the player that owns the fleet that issued the order. Other Order subclasses likely have similar checks that could be added as well.
- Add text commands for all the possible orders players can issue. The messages window has a basic order parsing system set up, which presently handles zooming to objects. Any of the Issue*Order functions in AIInterface.cpp could be make usable for human players as well using this text input method. Parsing the input text might be a bit tricky for orders that need one or more UniverseObject or content name, but should be doable in most cases. It should be possible to work things out for names that have spaces (thus making it harder to tell which parts of the input text are for which order function parameter) in most cases, without needing wrapping quotes or similar means to clarify, although those might be useful options to have anyway.
NOTE: It is strongly recommended that you discuss non-trivial GUI changes on the forums so additions and alterations match the desired stylistic direction, and to minimize revisions or wasted effort.
- Various feature requests on sourceforge are worth implementing.
- Investigate making dragging items on queues (production, research) determine where to drop something based on something other than the mouse cursor position. When dragging a box like a tech or production item panel around the queues, it's strange to have the apparent position of the box be different from the active position determined by the mouse cursor position. This means that if the box is dragged from the top, it will appear lower than it would if it was dragged from the top, for a given "active" position. (Where the "active" position is the mouse cursor position which is actually used to determine where in the queue the box it dropped). Ideally the centre point of the box would be used to determine where a box will be dropped, regardless of where on the box the cursor was when dragging started.
- Add "buildings of this type" list to building type entries in the encylopedia, similar to "ships of this design".
- The encyclopedia search function could be improved. Possibilities include more intelligent searching of article titles, searching of article contents, or showing a list of results instead of jumping to the first matching page.
- Improve 'Pedia navigation with a sidebar. See this thread
- Make the buildable items list sortable, with resizable columns
- When a building is selected in the buildable items list, get the building's effects groups and find all objects that would be targets of the building's effects if built at the selected location. Mark these objects in the UI somehow (discuss with graphics team).
- Add lines in the top-left production summary for the currently selected system. Now the total empire PP and wasted PP are shown, but it would be good to also show the available and wasted PP in the selected system.
- Make dragging a building from the buildable items list onto a planet attempt to order that building to be produced at the planet. Add the building to the end of the queue. Do the same for ships.
- Make dragging a building or ship onto the production queue enqueue that building or ship at the selected planet. If no valid build location for the dragged item is selected, then do nothing.
- Make dragging an item from the queue onto the empty space of the galaxy map, or onto the buildable items list, remove the item from the queue.
- Add a way to order a full fleet to be produced, consisting of multiple different types of ships in specific numbers. All the ships produced would be put into one fleet together. They'd either be added to this fleet as they're produced, or all be produced on the same turn whenever the total PP for the whole fleet has been allocated. Implementing this would likely require a new variant of ProductionOrder and server modifications.
- Make the tech list view resizable and sortable.
- The tech tree layout currently produces very unoptimal placement of dependency lines, where long pathes around techs are used for no apparent reason. This could be fixed.
- Make GUI layout changes persist between executions of the program. The user / player can rearrange and resize several windows on the tech screen, however these changes are lost when the user exits FreeOrion. The positions of the various windows could be stored in config.xml (similar to how galaxy setup selections are stored) and retreived the next time the program is run. Positions should probably be stored in a resolution-independent way, so that changing the resolution doesn't cause windows to disappear off screen, and/or sanity checks for size and position should be done when doing initial layout / retreiving from the options DB to ensure a reasonable layout. Entries in config.xml can be added by adding a function like void AddOptions(OptionsDB& db) in the anonymous namespace in ClientUI.cpp or MapWnd.cpp in files that don't already have one, or adding entries to an existing function of that sort in the file where a stored windows position needs to be retreived. The new options should store the x and y positions and height and width of the windows to have persistent locations between executions. The constructors for those windows could be passed (or modified to take) the positions and sizes as parameters, or the code that creates the new windows could reposition them, or an existing function to position windows could be altered to use them. Entries for these options aren't really needed in the Options screen.
- Fix up the top portion with the system resource summary, system droplist and star graphic
- Design and add a "shipyard in system" box to the system info section
- Show ships being built, similar to buildings being built on planet panels
- Make more aspects of planet appearance on the sidepanel vary depending on its in-game state:
- Industry meter level could change what texture is used for planets.
- There are currently hard-coded adjustments to rotation speed or axial tilt, but these would be better if implemented as effects.
- An effect to add a ring texture to planets could also be added. Ideally, rings should cast shadows on their planet.
Galaxy map screen
- Add tooltip to system icons on the map, indicating their colour. see this post for motivation. Additional info like # of planets or empires with colonies in the system might also be added to the tooltip.
- Add tooltip to the empire resource summaries at the top of the map screen. This should list, with text explanation, the stockpile, income, expenditures, and net change.
- If all the details sound like to much work, just indicating what the icons represent with a tooltip would be helpful.
- On empire resource summary, list all + and - contributions to the production and consumption of each resource. Something like " ObjectType ObjectName +/- ### " in a column.
- In MapWnd::RenderFleetMovementLines, move_line_animation_shift (a file-level static variable) is set each frame. It's then used in RenderMovementLine to determine where to position the first fleet move line dot after the start of the first segment of the move line. If several empires' fleets are all leaving the same system along the same starlane, these dots will overlap, and only one will be visisble. It would be better if there was an empire-id-dependent additional offset for the dot positions, so that multiple empires' dots can be seen moving along the same starlane.
- Figure out a good way to move up and down the partition between the top third of the panel that shows fleets and the bottom panel that shows ships within the selected fleet. Some way to drag a partition would be appropriate. This needs to work whether or not there is a new fleet drop target in between the two.
- If a fleets window is showing fleets not at a system, indicate that the fleets are "near SystemName" instead of just saying "Fleets".
- Add DesignWnd::MainPanel::CanPartBeAdded should be used to determine if parts can be added to the current design, and appropriately grey out / disable parts that can't be added to the current design.
- Make the parts list accept drag-drops of PartControls. If a PartControl is dragged from the parts list to itself, do nothing. If the PartControl is dragged from a SlotControl in the main design panel, then remove the part from the slot.
- SetRotationSpeed / SetAxialTilt - A few specials (Slow Rotation, Tidal Lock, High Axial Tilt, Gaia) should modify their planet's appearance. Currently the rotation and tilt specials are checked for during universe generation, and any planets with them have their rotation or tilt modified. It would be better if the specials could do this with an effect themselves, so that we can remove the hard-coded special names from the c++ code, and could add these specials later in the game and have their effects be visible.
- PlanetSlot - which slot a planet or other object is located in, in its system
- Speed - distance per turn an object is currently moving (and perhaps also max speed?). Most applicable to fleets and ships travelling between systems.
- ShipDesign details: designing empire, designed on turn / age of design
- Agressive / Passive - matches fleets that are set to be aggressive or passive.
- HaveFocusAvailable - matches planets that have a particular focus available for their player to select (even if not presently selected).
Referenceable Object Properties
For effects and condition definitions:
- PlanetSlot - which slot a planet or other object is located in, in its system
It would also be nice if it were possible to reference properties of an entire effects group when defining effects that (like all effects) act on a single object. This would allow the CreateSitRepMessage effect to say something like "The explosion destroyed 10 ships!" instead of showing 10 variations of "The explosion destroyed %ship%!".