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)

• Replace deprecated functions for file control operations from fcntl.h used in FileAppender.cpp from log4cpp with maintained logger.

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

• Modify the Process class implementation so that AI process / thread priroity is modified intelligently. Presently, as soon as the server sends out turn updates, all AI clients run a full priority and use up all the CPU (at least on a dual core system with > 8 or so AIs). This means that even though the client has received its turn update, it sits showing the player "Downloading new game state" until all the AIs have finished playing their turns. Then the AIs sit idle waiting for a new turn update until the player ends his/her turn. It would be better to have the server send messages to the AI clients to get them to modify their process priorities, or to directly modifiy those priorities if possible, in response to player actions. In particular:
  • While processing turn updates (all player orders received, executing them and updating gamestate, sending out new turn updates), the server process should be high priority, and the AIs low priority.
  • While the human player plays his/her turn, the AIs should stay low priority, only using a CPU when there is some extra to spare. This is so that the human client gets lots of CPU to process its turn update immediately after receiving it and let the player play their turn in a responsive UI.
  • When the human player ends his/her turn, if the AIs aren't finished their turns yet (the server hasn't received all AI turn orders), the server should set any AI processes that still have to send in their orders to high priority, and set each AI process to low priority again as soon as the server receives that AI's orders.
  • The client should always be high priority.

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

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

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

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

• Implement a "God Mode", similar to Observer players, but with the ability to create, remove, or edit objects from the universe, and edit Empires' properties including tech research progress, build queue progress, ship designs, etc. This could be useful as a map editor mode, and as an interactive storyteller mode for multiplayer games.

• 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

• There needs to be a way for players to set their fleets to "hostile" or "passive". This would determine whether they would initiate combat if an enemy fleet is in the same system, and whether they would block enemy fleets from passing through a system if already present. Stealthy fleets wouldn't reveal themselves if not set to hostile, but would reveal themselves to start battles or block ships if set to hostile. There needs to be UI support for this, so human players can control whether their fleets are hostile, and backend support so that the UI can issue orders to control this setting, and so that AIs can do the same.

• 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

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

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.

Research screen

• Add a sortable list of techs as an alternative to the tech tree view - Partly done, but list view should be put in a resizable window and made sortable
• Make techs on tree look a bit more like popup tooltips (discuss on forum first)
• 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).
• Add a button to automatically select a colony ship, on planet panels or on the sidepanel separate from the planet panels. This button should only appear when there are selectable colony ships in a system, and a planet is not colonized or being colonized.
  • Bonus: add the colony ship selection button only on planets that would be colonizable by a colony ship that is in the system. Make clicking the button select a colony ship that could colonize that planet.
• 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.
• Add code to render rings around planets. There are ring textures available in the art directory. Ideally, rings should cast shadows on their planet.

Galaxy map screen

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

• CreateSystem - similar to CreatePlanet and CreateBuilding, but for systems. Should not allow creating systems at the location of another system (or too close to another system?). Would be nice if creating a system at a location through which an existing starlane passes would cut the starlane, perhaps connecting the two new starlanes to the new system and the ends of the cut starlane.
• 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.

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.
• CanBeTerraformed - matches planets that are not the best environmental preference that is available for their species, and thus could be terraform to be improved. Might instead take a parameter to specify the species to check against.

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