From FreeOrionWiki

A list of things that must, should or could be done by programmers.
Please, only programmers change this!

Contents 1 Help Needed 2 To Do 2.1 Misc 2.2 Stringtable Parsing 2.3 Player order-giving improvements 2.4 UI improvements 2.4.1 Production screen 2.4.2 Research screen 2.4.3 The SidePanel 2.4.4 Galaxy map screen 2.4.5 Fleets Windows 2.4.6 Design Window 2.5 New Effects 2.6 New Conditions 2.7 Referenceable Object Properties 3 Ongoing 4 Lower Priority

[edit] Help Needed

• Provide compiled binary downloads for OS's other than WinXP. Up-to-date MacOSX binaries would be particularly appreciated, as would Linux-flavour-specific packages.
• Ask Geoff the Medio if you need something to work on.

[edit] To Do

[edit] Misc

• Currently all keyboard bindings in-game are hard-coded. It would be much nicer to have a GUI or configuration file-based method to reassign keys.

• Change victory conditions so that players can continue in the same galaxy after defeating all other empires, 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.

• Add a command-line switch, similar to -f for fullscreen, which immediately starts a new game and accepts the default galaxy setup settings, taking the player directly to the map wnd of a new game without further input required.

• Implement full-fledged visibility system. On the galaxy map, what is/isn't visible is poorly designed at best. Visibility tests, done on the server, need to be implemented to determine which UniverseObjects each client should receive updates about. Previously-known states of UniverseObjects that a client can't see this turn should probably be retained as well, while accounting for objects that have been destroyed but which a particular client might not know are destroyed. Note how destroyed objects are currently tracked when a client does observe the destruction. Implementation should conform to the relevant section of the v0.4 design document with respect to visibility tests with stealth and and detection meters and distance dependence.

• Shaders, shaders, shaders. The ogre-integration branch needs love. Competent GLSL programmers are welcome to write swanky visuals and effects via shaders.

• Visual effects. If you have some interesting particle, shader-based, or GL fixed-functionality special effects, such as for explosions, or shield effects, or ray guns up your sleeve, please contact Tzlaine.

• A full-featured and easy-to-use GUI editor would be invaluable to designers, artists, and coders. A GUI editor would really speed up development for all three groups. GG has an attempt at one, but it's flaky.

• GG, our GUI library, is written by an ignorant American who only knows English. Our user base is all cosmopolitan jet-setters who speak six languages. As such, GG needs to have support for storage and output of Unicode characters. More importantly, it needs support added for the input of Unicode characters (in the end, this also means turning on experimental Unicode support in the Ogre-friendly input library we're using, OIS). Using UTF-8 may allow the internal storage (std::string currently) to remain unchanged, but there may also be arguments for using std::wstring.

• Write initial Python AI. Note that most or all of the high-level game design is in flux as we add features. The lower-level stuff (like how to move around and select targets in the combat system) may be possible to write once and for all right now.

• Improve and extend the functions and data exposed to Python for AI.

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

• Create a FreeOrion scenario and / or map editor. This can probably be done as a modification of the in-game GUI, so the standard MapWnd, SidePanel, etc. could be modified to add this functionality when the client is in editor mode. Should be possible to load maps and saved game, and save maps and saved games from in the GUI.

• Expose a Python scripting interface for server-side universe creation and game start setup. Top priority: once universe has planets and empires, allow custon script to create ships and shipdesigns, grant techs to empires, mark systems as explored by empires, etc. Should function by exposing effects that do these tasks, which would require adding CreateObject and other effects to expose. Also allow scripts to generate whole universes, with planets, systems, starlanes, etc.

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

[edit] Stringtable Parsing

• Currently, to put one stringtable entry into another, one generally has to manually type out the inserted string in the enclosing string. For example, to refer to a the "Psionics" tech by name in a building description, one has to type "Psionics". This means that if the name of Psionics tech is changed later, or if someone wants to translate the Psionics tech name string, all strings that refer to it will have to be updated separately. It would better if one could refer to another string by the code name. Syntax for this might be

REFERENCED_STRING
Referenced String

EXAMPLE_STRING
Example string includes the [[REFERENCED_STRING]] in it automatically.

Accessing UserString("EXAMPLE_STRING") would then return "Example string includes the Referenced String in it automatically."

Additionally, it should be possible for REFERENCED_STRING to contain another SECOND_ORDER_REFERENCED_STRING or REFERENCED_STRING itself recursively without crashing, or with an appropriate error message rather than an infinte loop.

[edit] Player order-giving improvements

• Make it possible to queue, edit, delete (etc.) fleet move orders
  • I think editing and deleting are of questionable utility. I think queueing and clearing are sufficient. -- Zach
  • An ideal interface for move order editing would be something like Google maps directions that allows one to drag waypoints from a long a route to another location. to have that location inserted into the route.
  • More important is appending destinations to the end of a move order sequence. Perhaps shift-clicking on a system would append that system to the end of the destination queue?
• Also allow other fleet actions to be queued, like colonizing a planet
• Make it possible to give multi-part orders, like colonizing a particular system or planet that a fleet is not located at, or making rally points for new ships away from where they are built
• Add some player-helping AI scripts so the player can order a fleet to "explore"

[edit] UI improvements

• Various feature requests on sourceforge are worth implementing.

[edit] Production screen

• 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).
• Replace BuildDesignatorWnd::BuildDetailPanel with EncyclopediaDetailPanel. The EncyclopediaDetailPanel::Reset function needs to be updated to properly handle display of buildings and ship designs.

[edit] Research screen

• Add a sortable list of techs as an alternative to the tech tree view
• Make techs on tree look a bit more like popup tooltips (discuss on forum first)
• Change how the tree panel layout is done.
  • It shouldn't be necessary to redo the graph layout when zooming. Recalculating this for each zoom makes zooming feel clunky and slow.
  • Get GraphViz to arrange the techs hoizontally according to some controllable logical positioning. The placement of tech panels presently seems to have no useful reasoning behind it.
• Replace TechTreeWnd::TechDetailPanel with EncyclopediaDetailPanel. The EncyclopediaDetailPanel::Reset function needs to be adjusted to display tech details in the same way as the current TechDetailPanel. Adding stringtable entries might be necessary for this.
• Make 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.

[edit] The SidePanel

• 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 it possible to change the width of the sidepanel
• Make it possible to toggle between opengl-rendered planets and static planet images (available in the art directory). There should be a toggle / setting in the UI options menu tab for this.

[edit] Galaxy map screen

• Improve the appearance of ship movement lines - put markers showing each turn's progress along a path
• Improve fleet icons (SF Feature Request)
  • Art instead of code-generated icon
    • Point in direction of travel
  • Make easier to click at all zoom levels
    • Expand clickable area
    • Make not resize when moused-over - do something else instead
• 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.
• Also on empire resource summary, list all + and - contributions to the production and consumption of each resource. Something like " ObjectType ObjectName +/- ### " in a column.
• Investigate making zooming in / out with the mouse scrollwheel do the zooming centred on the cursor position, rather than the centre of the screen.
• Make Nebulae graphics randomly rotate and/or flip, and make each graphic appear once per galaxy.

[edit] Fleets Windows

• Create a full-screen fleets summary view
  • List all fleets, friendly and enemy
  • Expandable to show ships in fleet
  • Show destination, location, other stats and info
  • Sortable
• Single-system fleets window
  • Make resizable and reconfigurable

[edit] Design Window

• DesignWnd::MainPanel::AddPart in DesignWnd.cpp needs to be implemented. This function should "intelligently" find a slot in which to place the passed part, moving around other parts within the design if necessary.

[edit] New Effects

• Generate SitRep messages
• Set research progress for a tech for an empire
• CreateSystem - similar to CreatePlanet and CreateBuilding, but for systems. Should not allow creating systems at the location of another system. Would be nice if creating a system at the location of a ship that's travelling on a starlane would cut the starlane, perhaps connecting two new starlanes between the new system and the ends of old starlane.
• AddStarlane / RemoveStarlane - Between the target object and objects matching a condition parameter (like the MoveTo effect's condition parameter)
• 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.
• SetTexture - Specials could set the texture used to render a planet, allowing specials to drastically change a planet's appearance. A likely use is to make Gaia planets look different. Could be later extended to other objects, as appropriate and as needed.

[edit] New Conditions

• Sorted - takes an object property, like Target.MaxFarming, and a number of objects, like 3, and matches that number of objects that have the largest or smallest value of the property
• Targetted - assuming there is some UI mechansim to target an object with another object, probably involving issuing an order to do this targetting, there should be a Targetted condition which matches objects targetted by the source object
• Age / CreationTurn - matches objects that are within the specified range of number of turns since they were created, or matches a range of creation turns
• 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.
• Moving / Stationary - whether a ship or fleet (or other object?) is moving at all (presumably under its own power) on a given turn. Unnecessary if a speed condition is available.
• ShipDesign id - similar to Building name, matches ships with a particular design. Ship designs are created in-game by players, while building names are defined in contenxt text files, so it will be necessary to be able to reference Source.DesignID or similar for this condition to be useful.
• Other ShipDesign details: designing empire, designed on turn / age of design, hull type or parts

[edit] Referenceable Object Properties

For effects and condition definitions:

• SourceTargetDistance - direct line distance between source and target being acted on
• SourceTargetJumps - number of starlane jumps between source and target being acted on, using starlanes known of by source's empire
• PlanetSlot - which slot a planet or other object is located in, in its system
• Speed - distance per turn an object is currently moving.
• Design and DesignID of a ship
  • Cost
  • Minimum build time
• BuildingType of a building
  • Cost
  • Minimum build time
  • Maintenance cost

[edit] Ongoing

• Keep an eye on SourceForge bug reports and fix non-minor ones.
• Implement SourceForge feature requests (typically requires design discussion on forums)
• Write up and maintain compilation User's Stories.
• Keep MSVC project files and SCons build files updated (if anyone adds or removes source files)

[edit] Lower Priority

• Add wormholes to universe generation
• Make planet appearance on the sidepanel vary depending on its in-game state, including presense of specials (including a Gaia special) or industry meter level. Planets should also have separate night-side textures (lights in dark), and be able to have ring systems surrounding them (mutually shadowing with planet), and battle damage (if not treated as a special). There are currently hard-coded adjustments to rotation speed or axial tilt, but these would be better treated as scriptable properties of the specials themselves. A future-proof / extendible format to specify this sort of change, or other appearance alterations of in-game objects due to specials (or other similar content types) would be useful. Note that this is probably not suitable for a first-time contributor, as it likely requires significant artist interaction and understanding of how FreeOrion planets, effects, techs, and other content work, both conceptually and in-code.
• Treat neutron stars and blackholes differently w.r.t. starlanes, planets, and wormholes (needs designer input; discuss on forums first)