They are selected on server side by the player hosting the game (=being the "game server") during the Player Selection / Game setup, affect the game globally and cannot be changed any more once the game has started.
For the client-local options that individual players can each change on their own see the Client options documentation pages: Options on Client Side and Settings in Preferences Window.
In the bottom part are controls for Variant selection and Game startup, always visible no matter which pane is selected.
For the numbers of players wanted, set the player type appropriately, and leave (or set so if needed) the remaining one as none. For human (local) players give a name; remote players should be left to their default <By client>, and for AI players it is usually the best to leave the setting to <By color>.
As the name suggests, state of the game is saved regularly (begin of each players turn) to files in "saves" directory under the Colossus home directory. Earlier the filenames were simply snap<number>.xml, where the number is some representation of current date/time (seconds since begin of epoch, or something like that).
Since recently (August 2008) now the filename contains also information about the current turn number, active player and phase at the time of saving. If you don't like those long names, or your system cannot handle them, you can disable the "verbose autosave names" (= revert to old behavior) by putting the following line into the Colossus-server.cfg file:
Verbose\ autosave\ names=false
Hot seat mode:
This is intended to reduce the problems with the many open windows when several players sit around the same computer, all as local players (always the one who's turn it is sits down in front of computer, thus "hot seat"...)
If this mode is enabled, when one of the local players is the active player, his MasterBoard is restored to normal size, and that which was until then normal, will be iconified.
This feature does not cover the BattleBoards yet (i.e. you will still get as many as local players); and the information windows like Game Status, Inspector, Event Viewer etc. all come and go with their respective MasterBoard. This needs still some work.
Viewable legion content:
That is a popup menu box with three possible selections:
The first one is like standard Titan - you are only allowed to review the contents of your own legions; information what is in other players legions you can only know based on events where such information is publicly revealed (e.g. recruiting, teleport), and you must memorize and conclude all by yourself.
The last one is simple - you can simply look into every legion, be it yours or that of any other player.
The middle one, "Ever revealed ..." is more complex. Colossus has a feature called split-prediction; it keeps track of such revealed information, and automatically draws conclusions ("if the angel is here, then the Titan must be in that legion because it is the only other uncertain one right now"). If this option is selected, you see the result of such automatic tracking and conclusions, i.e. the same what the AI's will know.
This view shows you for other players legions all creatures which were ever revealed, or can with certainty be concluded that a certain creature is in a certain legion.
For the remaining creatures in the legion, the Split prediction has a "best guess" - like, parent before a split had Titan, some weak and some strong creatures, and Titan teleported and is known, the rest not; most likely the strong creatures are with the titan and the weak ones in the split-off - but that is not certain.
For those which are uncertain (if and only if this view mode is selected), every client (= every individual player) has in his Graphics menu (in the running game then) a option called Uncertain as blank which controls, whether for this uncertain ones shall be displayed the best guess (with a question mark over it) or rather nothing (just a question mark).
Events expire after (turns):
That is a popup menu box with numeric values. The selected value specifies for how (at maximum) long back the events are viewable in the players "EventViewer" window (now in "Window" menu). This EventViewer windows "reveals" all those events that would in an actual board game be mandatory to be revealed to other players - like: splitting, recruiting (what creature was taken, and what does he have that allows him to do so), teleport, acquired and summoned angels, and battle results (Note: the latter one are not fully implemended in the EventViewer, but there is a separate "Engagement Results" window).
In the EventViewer itself a player can select to display (beside which types of events) fewer than the number of turns set in "Events expire after (turns)" setting, but not more than those.
Those are hopefully self-explaining - the named teleport types are or are not allowed.
In regular Titan, there's never two slowing reasons together (you don't find a bramble up a slope, for instance). In Variants this is possible, so we must decide what to do: do you need 2 (only one slow) or 3 (count them both) movement points to go to an up-slope bramble (assuming you're non-native) ? Without this option, 2. With this option, 3. We don't decide, you do :-)
Always allow one hex:
This is necessary after introducing the aforementioned option Slowing is cumulative. What if a 2-skill creature wants to enter an up-slope bramble? Without this option, it's impossible. With this option, any creature can enter any non-impassible hex as its first move (it will only move one hex), so our 2-skill creature can enter our up-slope bramble if it hasn't moved yet.
If enabled, every player can take as many mulligans as he wants, in any turn (not just turn 1). In multi player game (all humans, e.g. on the Public Game Server), you might turn this on and agree beforehand, that it might be used only in Turn 1, or e.g. "only as long as it is same roll, or as it is 2 or 5" - one can see from EventViewer if a player used it nevertheless, breaching the agreement.
Need lord for battle control:
Bruce Sears came up with this idea and implemented it - it might spice up some gaming. If it is enabled, you can control the individual creatures on a battle map only, if there is at least one lord in that legion. If there isn't, the AI will do the battling. This somewhat resembles/extends the idea, that only a legion without lord can flee. ("No boss to watch them, then the subordinates do what they please" ;-)
This effects immediately, i.e. as soon as the last lord is killed, a SimpleAI takes over, but if AI summons an angel, you are in charge again.
This mode might affect your strategy, i.e. aiming to have more angels in general, having them spread over the legions instead of all in same, etc.
Currently this mode is available only for local games, not on the Public Game Server. If there is sufficient demand to support it there, controls for that can be added to the Game Server game proposal GUI.
Use non-random battle dice:
This will use always a predefined sequence of rolls (right now: 4,3,1,6,5,2) for battle dice rolling instead of random numbers. Note that this would not necessarily guarantee "more equal chances" to the players, as it might still be that the one gets e.g. 6, 5, 2, 4, next player rangestrikes (only 2) gets 3 and 1, first player again the high numbers etc. Probably only relevant for debugging purposes.
Those values control how long an AI will pause after certain actions and how long time it may maximum take for certain steps (calculating what is the best move and so on).
In the bottom of the Get Players dialog you can choose from a number of Variants, for which in this Variant README pane is then a description shown that tells what is different in this variant comparing to the standard Titan.
By default preselected variant is called Default which is corresponding to the original Titan masterboard and creatures.
The button Run web client starts the Colossus Web Client. With that client one can/could connect to some server where a Colossus Web Server is running. When connected to that server, one can propose a game or enroll to a proposed game, and when enough players have enrolled, the game can start.
We have the software ready for such a server, but we do not have access to a public server where to run it. Anyone willing to help organizing such a thing is welcome.
Created spring 2007, reflecting the state of Colossus at this time.
Last updated July 6, 2010 by CleKa