FreeOrion

Hello!

I'd like to outline my plans for adding turn processing to FO.
I am looking for comments related to it's fit into the current design and
also to make sure I'm not duplicating work being done elsewhere.

Obviously, the guts of turn-processing is on the server. I'm proposing a new server class - called TurnManager for now ( please feel free tcomment on naming convention, if this is not suitable ).

The TurnManager will contain a vector of a structure which has an empire IDs and a OrderSet pointer. Empires are added to this vector ( let's call it the TurnSequence vector for now ) only once per game and this dictates the turn processing order. As empires are eliminated, they are removed
from the vector.

As each client posts it's turn orders to the server, the server decodes the order set from XML, and calls a method in the TrunManager which looks for the given empireID in it's TurnSequence vector and adds the OrderSet pointer to the turn sequence data.

The server then calls a method of the TurnManager which will check if all empires have posted their orders for this turn. This is simply done by looping through the TurnSequence vector and looking for non-NULL pointers for OrderSet data.

If the turn is deemed ready to execute, the ProcessTurn() method of the TurnManager is called. This method decomposes the turn into the phases as described by the HLD doc. FleetManagement, Combat and Empire Growth phases are implemented in separate private methods.

At the end of the turn, each pOrdersSet in the TurnSequence vector is freed and set to NULL for the next turn;

This is basically it. Below is a brief outline header file for the class, minus any comments, etc.

Thanks for your time!

Andrew


class TurnManager

{
private:

struct
{
int empireID;
OrderSet *pOrderSet;

} EmpireTurn;

public:

TurnManager(){} ///< default ctor
TurnManager(const GG::XMLElement& elem); //!< construct via XML for save game restore

virtual ~TurnManager()

int AddEmpire( int empireID );
void RemoveEmpire( int empireID );

void SetOrders( int empireID, OrderSet *pOrderSet );
bool AllOrdersReceived( );

void ProcessTurns( );

protected:

void ProcessFleetHandling( );
void ProcessCombat( );
void ProcessEmpireProdAndGroth( );

private:

std::vector<EmpireTurn*> m_turnSequence;
int m_currTurn; /// current turn number

};

First of all, welcome to the project

Just a quick comment. You probably already thought of this, but its not stated.

All of the orders in the orderset need to be executed before proceeding to any of the other phases of turn processing. This has to happen so that all of the fleets and planets are doing what the player thinks they're doing.

Also, some mechanism needs to be in place for detecting invalid orders. Currently, there's an exception thrown by the Execute() if the order is illegal, there's got to be a mechanism for handling this exception. I recommend we handle it by booting the client and replacing it with an AI, then notifying all players.

Other than that, looks good to me.

JB

_________________
Empire Team Lead

This looks fine to me. I'm not sure that we need this class per se, though. The vast majority of the server's function is either passing network messages about, or doing what this class does. I think that properly the server itself is the turn manager. So I think the interface you suggest here is perfect, but that the interface should be comprised of ServerApp member functions instead (ServerApp::ProcessCombat(), ServerApp::ProcessEmpireProdAndGrowth(), etc.). Also, I'm not sure that Empire IDs will be contiguous (and they certainly will not be when the first player is eliminated), so maybe we should store the OrderSets in a std::map<int, OrderSet*>, with the ints being the IDs. That way lookups are trivial, not requiring a for loop.

One other thing, and this is obviously less important, but have a look at the coding standards for naming conventions. We have been using underscore_breaks for variables, instead of capitalBreaks. The coding standard can be found at:
http://www.freeorion.org/index.php?modu ... dards.html

Thanks for your feedback guys,

Making the vector a map is an obvious improvement!

Also, I'll make the interface part of ServerApp.

I think maybe I'll remove the private methods to execute orders at each phase and just a one method which is 'execute all orders for this given phase'.

However, for this I would need a 'phase type' member of the orders class which indicates which phase the order is processed in. If this makes sense, I can do the change.

Andrew

For now all orders should be executed in exactly one of the two phases, based on type. So you should be able to execute all the FleetSplit, FleetMerge, and FleetMove orders in the movement phase, and all build orders in the prod/growth phase, etc. Later, we may have some orders that may be executed in multiple phases, but for now I think we can rely on the type of the order.

I guess what I'm suggesting is a classification type for each order so all fleet orders would be PHASE_FLEET and all growth orders would be of classification PHASE_GROWTH. In this way, at the turn processing level, I can write a generic function which executes all orders for a given phase for each empire. Othewise it's difficult to not duplicate the looping code for each phase. Also maintainance of new orders would be more defficult because every place we want to loop for a given phase we need to add the new type to be included in the if statement, instead of just giving it a phase classification.

Actually, there's no reason why you can't execute the orders all at once. It would make things easier (no need for casts), and in the future we might need all the order processing to happen first.

_________________
Empire Team Lead

Oh yeah, of course - sorry I'm still getting used to the overall design. I was getting turn processing confused with order processing, which of course is different. Thanks!

Well actually I think we might have some situations in which we need orders to be executed at different times. For instance, if we have an "attack planet" order in the future, that will probably be settled during combat, after space combat, but before producion and growth phase.

For now, though, since I'm really bent on just getting something out the door, we can just leave it at that. We'll just execute all orders all at once during movement phase.

Sound good?

Sounds great!