============
THINGS TO DO
============

Freeciv is quite mature, and we think its already a great game,
but there are always things to add or improve.  This file lists
some new features which are being worked on, or are planned, or
desired.  (See also the file BUGS, for some known deficiencies.)

TODO:
=====

- Sound support.

- Server-side player scripting.

- Diplomacy:
  * Senate
  * AI handle diplomacy

- Better graphics for city styles.

- Better internationalization (fix some problems, modify those
  English sentences which can not be translated into most other
  languages, better gui handling for different-length words,
  mixed language client-server, more complete translations,
  more languages).

- Make the rulesets for City Improvements and Wonders more flexible.

- Extend governments ruleset to allow Fundamentalism, and fix up AI
  handling of variant governments.

- Ports to Win32 and Mac are being worked on.

- Make the code view-agnostic: remove assumptions about which tiles are
  valid. Fx the assumption that the map wraps in the x direction. This
  can be done by making the code use macros like whole_map_iterate and
  square_iterate. The functions map_adjust_x() and map_adjust_y() should
  be removed and code that use them made to use normalize_map_pos(),
  is_real_tile() or a macro.
  It would also be nice to remove the assumption that the x values go
  [0..map.xsize[, as a proposed isometric numbering scheme doesn't have
  that property.
  When all code is converted the whole of the freeciv server can be
  adjusted to use a flat map, an isometric map, a torus map or maybe
  even a hex map, all by changing a very limited amount of code in
  the right places.
  Note that the AI in various places do not adjust tiles properly even
  for the current numbering scheme.
  It vould also be nice to get rid of the void_tile kludge.
  Note that the conversion is backwards compatible, so it can be done in
  small steps. No mega-patches please.

- Stop the server from sending text to the clients. Instead it should
  send an enum and some values, which the client converted to a message
  to show to the user. This will give the client more knowledge of the
  content of the messages, needed for fx a client side AI. It will also
  mean that the messages are automatically correctly localized.
  Note that these new messages will have to sometimes contain city names.
  A possibility of sending text should still exist, to avoid
  compatability breakage when changing the server.

- Create a new "ocean" variable in the tile struct, similar to the
  "continent" variable. It needs assisiated functions to be kept up to date
  in both the server and the client. It should also have an associated
  function is_oceans_connected(ocean1, ocean2, player) that returns if
  a city exists that connects the two oceans for that player.

- Document/cleanup AI code. Rename variables to more saying names than these:
  int a, c, d, e, i, a0, b0, f, g, fprime;
  int j, k, l, m, q;
  (taken from ai/advmilitary.c:process_attacker_want())
  I would especially like to have the use of the amortize() function in
  server/settlers.c documented.
  I will apply patches even if they just rename a single variable.

- Unkluge the worst AI kludges. The ones I know of are:
  - precalculated amortize() calls mostly in server/settlers.c
  - on the goto map the move cost of units with F_IGTER is multiplied with 3
  - the goto map of ships overlap one field onto land

- Replace the use of the value 255 in relation to the warmap with the
  MAXCOST constant.

- Make the server warmap use short instead of char, and raise MAXCOST from
  255 to the maxvalue of a signed short. (also see prev. item)

- Make the AI building evaluation code use the new buildings.ruleset.

- Create a function that gives a statistically excact value for a units
  chance of winning a battle.  [Now done.  What about expected number
  of hit points remaing, or the variance?  Can we come up with clever
  ways for the ai to use this information?]

- Make a function that can generate a warmap for airplanes.

- Convert the ai_manage_diplomat() function to use the warmap.

- Make the AI use the new automated ferryboat code. (note that the new
  ferryboat code is not yet in CVS...)

- Make the AI respect FoW. (They don't get much bigger than this...)

- Make the goto on the server side (optionally?) respect FoW

- Teach the AI to Fortify units in non-city strategic positions. Also, it
  needs to not idle all it's units every turn, breaking 2 turn fortify.

- Teach the AI to leave units alone in a turn to regain hit points. (it
  seems to have no concept of this at all!)

- Stop the AI from trying to buy capitalization...

- Fix the AI valuation of supermarked. (It currently never builds it).
  See farmland_food() and ai_eval_buildings() in advdomestic.c

- Teach the AI to coordinate the units in an attack (ok, this one is a bit
  big...)

- Teach the AI to use ferryboats to transport explorers to unexplored land.
  See ai_manage_explorer() and ai_manage_ferryboat().

Client goto related:
- Make connect command find the connect route in the client and send it
  to the server. Draw a line when chosing the connect route.
- Find the goto route of an airplane in the client, and send it to
  the server. Make the client draw the goto line. Note that you cannot
  make a client_goto_map for airplanes with fuel. It may be fine to go
  from p to q, and there may be a valid route from r to s via p, but
  the route p->s is then not always usable without running out of fuel.
  This makes the vectors in the client_goto_map unusable.
  A solution would be a client_goto_map which held a lot more info per
  tile, but that would not be nice I think. A better solution is
  calculating the last part of the route dynamically as the mouse moves.
  (maintain a list of the move costs to the refuel points to quickly
  know if more than the last part needs recalculating)
- Store the goto route in the client too. Keep it up to date as the unit
  moves. Make middle-clicking the unit display the route by drawing the
  line.
- Perhaps make a check on all units on goto each turn to see if you could
  find a better route than the current one. This would require the goto
  route to be kept up to date in the client.
  Note that this is not as simple as it seems, because a route A to B
  with a waypoint C is often chosen not to be the fastest way from A to
  B, but the route is still as it should be.

FURTHER INFORMATION:
====================

Information on other projects, and the Freeciv development
"roadmap", are available at the Freeciv website:

        http://www.freeciv.org/
