Programming Work

From FreeOrionWiki

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.

Contents 1 Misc 2 Player order-giving improvements 3 UI improvements 3.1 Production screen 3.2 Research screen 3.3 The SidePanel 3.4 Galaxy map screen 3.5 Fleets Windows 3.6 Design Window 4 New Effects 5 New Conditions 6 Referenceable Object Properties

Misc

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

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

• 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. Likely key bindings could be stored in config.xml the same way other information is stored in it. 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. There should be a new option for each action a keypress can take, and the stored value would be some representation of the keypress or keypress and modifier key (eg. shift, ctrl, etc.). MapWnd::ConnectKeyboardAcceleratorSignals and MapWnd::SetAccelerators need to be modified to get the keys to bind to various commands from the options DB using the standard GetOptionsDB().Get<TYPE>("option-name-text") lookup. It might be possible to make the option TYPE std::pair<GG::Key, GG::Flags<GG::ModKey> > to store the key + modifier combination, but I don't know if this will automatically convert to text, and if so, if the conversion is easily editable. If not, a bit of custom code to convert to and from a string representation would be needed.

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

• Shaders, shaders, shaders. Competent GLSL programmers are welcome to write swanky visuals and effects via shaders, for use in the combat demo or on the galaxy map or related screens.

• 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. It would be good if the AI could be updated to build ships and buildings and research techs.

• Improve and extend the functions and data exposed to Python for AI.
  • Add a "__str__" function to the Universe class and the UniverseObject class, which uses the existing Dump functions of UniverseObject and ObjectMap to output a text representation of an object. Note that similar code exposing such a function already exists in the set wrapping header.

• Implement Lua integreation for AI scripting, universe generation, or human client helper scripts. Lua seems quite popular for game scripting these days, and FreeOrion could be modified to use Lua scripts, much like Python is currently used for AI scripting. Googling for Lua C++ integration or similar searches give a variety of tutorials, so there should be lots of help for this task.

• 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 a "seed" field to the galaxy setup dialog. Defaults to 0 for consistency, can be set to whatever to generate different galaxy. Could have a "reseed" or "randomize" button to generate a new seed based on the clock. Would need to send the seed to the server with the galaxy setup data.

• Add additional moderator actions in moderator mode (a multiplayer game player type).

• Expose a Python scripting interface for server-side universe creation and game start setup scripts. The starting unlocked items, ship designs and starting fleets are currently defined in content files in the default directory, but the addition of a shipyard and palace and the homeworld special to the homeworld are hard-coded in C++ during empire generation. It would be better if they were scripted and adjustable. There is also currently no way to significantly alter the game start conditions... Useful things might be to mark other systems as explored, give different types or numbers of planets to empires. Even more significantly, the placement of systems and planets and starlanes should be fully scriptable. The existing C++ universe generation functions can be exposed to and called from python to provide a way to replicate the existing functionality, but it should be possible to implement new generation routines in Python that just call an exposed C++ function to add a system, planet, starlane, special or building. Placement of empires and their homeworlds should also be scriptable in the same way.

• 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 move orders
  • A possible 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- or ctrl-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"

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

• Create a GiveToEmpireOrder which takes an object id and empire id, and gives the object to the empire. Creating a new icon similar to invasion and scrapping to indicate this in the GUI. Optionally, only allow gifts of objects in systems containing a ship or planet of the other empire. Only planets, ships, and possibly fleets, should be giftable. The UI for giving units would probably be a right-click popup, perhaps with a submenu under "Give To Empire" that lists all viable recipients for the clicked object.

UI improvements

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.
• It would be nice to be able to copy and paste text to and from the system clipboard using CTRL-C, CTRL-X, and CTRL-V in edit controls. This would likely require OS-specific code on Windows, OSX, and Linux to access the clipboard (or equivalent).
• 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.
• Improve ground combat sitreps. Indicate how many troops were involved by which empire(s), and how many troops are left owned by which empire.
• Add a way to lock and unlock the positions of movable windows like the empire summary & turn button, the sidepanel, sitrep, encyclopedia, or fleets windows. A good way might be a right-click popup, or a button similar to the X to close on some windows which makes it not move around when dragged.
• Add "buildings of this type" list to building type entries in the encylopedia, similar to "ships of this design".
• Write a whole new saved game browser, which allows nice things like sorting by file modified date, rather than alphabetically as is the case now. Also showing some basic info about the game, like the name of the human player, current turn, and similar in a preview panel for the selected save would also be nice.
• Improve the encyclopedia interface, as suggested here.
• An encyclopedia search function would be useful. There is space left of the back/up/next buttons where a text field and search button could be added. Entering text here would scan the (user-text readable) titles and contents of encyclopedia pages and compile a set of links to those pages where the entered text appears.
• Improve 'Pedia navigation with a sidebar. See this thread
• (in progress) Enable right clicks on certain icons to jump to the 'Pedia entry. For instance right clicking on species, special or building icons in the side panel.
• Sitrep messages about techs, buildings, ship parts, or hulls being unlocked.

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

Research screen

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

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 toggle between opengl-rendered planets and static planet images (available in the art directory).
• 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.
• In FleetButton::Init there are calls to FleetHeadIcon to get the icon to use for the fleet on the map. In cases where multiple fleets are represented by a single icon (if (m_fleets.size() != 1)) a default generic icon is always used. It would be better if the function checked whether all the icons for the fleets being represented were the same, and in that case, used that icon instead of the generic one. This is particularly noticable for cases like two space monster fleets being in the same system being represented by a generic icon instead of the distinctive monster icon.

Fleets Windows

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

• Presently, the "active" FleetWnd is the one representing the last-clicked fleetbutton, or the one last clicked on by the player, or in which a fleet was clicked. This is only relevant when there are multiple fleet wnds on screen, which can be enabled in the options menu. The active fleet wnd can be determined by seeing which fleet button has white (for selected fleet) move line dots coming out of it on thoe map. It should be possible to set the selected fleetwnd by clicking on just about anything in it. This should include changing ship selection in fleet info section of the fleetwnd (at the bottom). Making this happen would require getting some signals of selection changes or clicks on the relevant list box, and propegating these as is done for the fleets list box at the top of the fleetwnd. This shouldn't be too complicated to figure out.
  • It might also be nice to indicate somehow which FleetWnd is selected.

• 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
  • This could be part of a list to show *everything* in the universe... sorted by owner, type (fleet, ships, planets, systems), or other properties.

• If a fleets window is showing fleets not at a system, indicate that the fleets are "near SystemName" instead of just saying "Fleets".

Design Window

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

New Effects

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

New Conditions

• 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
• OwnerControls - takes a special, building, ship hull or ship part name (which appropriate type indicator in the parameter) and a minimum and maximum number. Matches any object owned by an empire than also owns the a number of the indicated item that falls into the indicated range. This will be useful for, for example, limiting an empire to only owning one of a particular building or ship hull. For specials, the empire needs to own planets (or anything else that can have specials on it) with the indicated special attached to them.
• 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).
• SpeciesCanColonize, SpeciesCanProduceShips - matches objects when the specified species can colonize or produce ships, respecively.

Referenceable Object Properties

For effects and condition definitions:

• DistanceToTarget - just like DistanceToSource, but relative to an effect's target object, rather than the source object.
• 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 (as opposed to the BattleSpeed and StarlaneSpeed properties that indicate the movement speed if moving, which is different if the object isn't moving at the present time).

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%!".