Interface | Description |
---|---|
BattleCritter | |
Caretaker.ChangeListener |
Callback interface for listening to changes to the numbers.
|
Class | Description |
---|---|
Battle |
An ongoing battle.
|
BattleStrike | |
BattleUnit |
Class BattleUnit represents a Creature in a specific Battle.
|
Caretaker |
The caretaker tracks the number of creatures still available and those dead.
|
Creature |
A particular creature in a game.
|
Dice |
Class Dice handles die-rolling
|
Engagement |
Holds the basic data for an engagement.
|
Game |
An ongoing game in Colossus.
|
Legion | |
MarkerComparator |
Compare markers.
|
Movement | |
MovementClientSide |
Class MovementClientSide contains the client-side masterboard move logic.
|
MovementServerSide |
Class MovementServerSide contains the server-side masterboard move logic
which has earlier been part of Game(ServerSide).
|
Player |
A player in a game.
|
Proposal |
Class Proposal holds the results of a settlement attempt.
|
RecruitGraph |
Implementation of a graph dedicated to the Recruit "Tree" (it's a directed
graph, not a tree, as we can have cycle in theory).
|
RecruitGraph.RecruitEdge |
The edge of the Recruit Graph
|
RecruitGraph.RecruitOption |
Models a recruit option for a given creature.
|
RecruitGraph.RecruitVertex |
The vertex of the Recruit Graph
|
SummonInfo |
Little helper class to store information about a summoning:
The target legion, the donor legion, and the summoned
creature(type) (creature as String, for now).
|
Enum | Description |
---|---|
BattlePhase | |
EntrySide |
The entry side for a battle.
|
Phase |
TODO this should probably start numbering with zero as does the BattlePhase and
as does any other Java enum -- currently SPLIT is serialized as "1"
TODO instead: now that I added an artificial phase "INIT" (needed during start
of the game, otherwise updateStatusScreen tries to do toString on null),
- are then the fromInt/toInit still needed?
|
PlayerColor |
Models the notion of a color a player can pick.
|
Information about an ongoing game in Colossus.
Currently this package has not yet been fully established. It is meant to hold all code relevant to model the state of an ongoing game. This package is meant to be used both by server and client code, with no dependencies into either of them. Note that server and client should not share instances, since that would allow information to leak from the server into the clients. The server and each client should have their own instances of the classes in this package containing the information as known to each of them.