Life-cycle of an Order

[tsev]

I PM'd Oceanmachine about this and he suggested we start a thread about it.

As work on more of the corse UI stuff commences, we need to think about how Orders get routed through the different modules. Most orders will be created (by human users) through interaction with the UI. For example, "Move Ship A from System X to System Y". For a given turn, I think we need to keep an OrderSet object containing all actions a player wants to perform that turn. When the user clicks END_TURN, we pass those orders on to wherever they need to go. Oceanmachine suggested that the Empire objects take care of the Orders...which then get passed on to the server.

Also, we need to provide a means of validating Orders immediately. If a player wants to try something that isn't possible, the UI needs to either not allow the order, or to tell the user that the action cannot be performed. So, whichever module does the order processing client-side, will also need to provide a function like :

Code: Select all

bool ValidateOrder(const Order&);

I leave the matter open to discussion......go

[jbarcz1]

The UI can create orders and pass them on to the client core, but I think the checking of orders should be done in clientCore rather than in UI. We want the UI to be de-coupled from the game logic as much as possible so it's easy to change.

On the client side, there's no need to store orders in the Empires since there will only be one orderset per client. Server-side, it might be convenient to store them there. I dont know who should be responsible for sanity-checking the orders on the server side, I had originally thought GameCore would do it, but Empire could probably do most of it as well.

JB

[tzlaine]

The UI can create orders and pass them on to the client core, but I think the checking of orders should be done in clientCore rather than in UI. We want the UI to be de-coupled from the game logic as much as possible so it's easy to change.

I disagree with this part completely. The user should not be allowed to make illegal moves, only to be told "you can't do that". Instead, the illegal moves should be made impossible to do in the first place. Conditionally disabled controls are a good example of a way to do this. I do not believe that it is either possible or desirable to de-couple the logic of your application from its UI.

On the client side, there's no need to store orders in the Empires since there will only be one orderset per client. Server-side, it might be convenient to store them there. I dont know who should be responsible for sanity-checking the orders on the server side, I had originally thought GameCore would do it, but Empire could probably do most of it as well.

JB

This I do agree with.

[tsev]

I disagree with this part completely. The user should not be allowed to make illegal moves, only to be told "you can't do that". Instead, the illegal moves should be made impossible to do in the first place. Conditionally disabled controls are a good example of a way to do this. I do not believe that it is either possible or desirable to de-couple the logic of your application from its UI.

I agree with Zach on this, but which module should do the verifying? Should the UI call a validation function somewhere in, say, the Empire object? Should the UI perform Order validation by itself?

Also, how will the server handle Orders? Will the server assume that all orders it gets are legal, or will it perform its own verification to protect against hacking? If it does verify, can the verification code be in a module that is visible to both Client and Server so that it can be used to validate Orders as the user attempts to make them?

[jbarcz1]

What I meant was that the UI will take the user's input, pass it on to some other place to get the command validated, then cancel the order if the command is invalidated.

So instead of checking a movement order in HandleClick(), you'd want to have a CheckOrder() method somewhere that is called by HandleClick() before adding the order to the orderset. If CheckOrder() indicates that the order is bad, you'd throw up a messagebox or beep or do some such thing.

I dont know if Empire is the correct place to put it. Order checking will require access to universe data which Empire wouldn't have unless it were passed in. This is why I suggested the client core, because it has all of the universe and empire data readily available.

JB

[tzlaine]

Also, how will the server handle Orders? Will the server assume that all orders it gets are legal, or will it perform its own verification to protect against hacking? If it does verify, can the verification code be in a module that is visible to both Client and Server so that it can be used to validate Orders as the user attempts to make them?

I think the consensus is that the server will have to certify all Orders as legal before processing them. It seems very resonable to have a validator that can be separated from the reset of the server, that we could use in the client as well.

[tzlaine]

What I meant was that the UI will take the user's input, pass it on to some other place to get the command validated, then cancel the order if the command is invalidated.

I know; this is what I disagree with. It is backwards. The UI itself should contain visual cues that certain actions would be illegal, and not let you perform those actions. The purpose of a graphical UI is to convey information about the interface to the user immediately and visually. That information should include both what is, and what is not, possible for the user to do.

So instead of checking a movement order in HandleClick(), you'd want to have a CheckOrder() method somewhere that is called by HandleClick() before adding the order to the orderset. If CheckOrder() indicates that the order is bad, you'd throw up a messagebox or beep or do some such thing.

After-the-fact feedback such as message boxes are necessary in certain places, such as indicating that a user-supplied filename is invalid, etc. However, it should not be used whenever it can be avoided. It is extremely frustrating to see a choice that you think you can make, make it, and then be told that it's not actually in your power to make the choice after all. It is far better to indicate through the UI the user's current options and their limits.

All of this requires a fairly tight coupling between the UI and the underlying logic. This is the nature of a graphical app.

[tsev]

Also, how will the server handle Orders? Will the server assume that all orders it gets are legal, or will it perform its own verification to protect against hacking? If it does verify, can the verification code be in a module that is visible to both Client and Server so that it can be used to validate Orders as the user attempts to make them?

I think the consensus is that the server will have to certify all Orders as legal before processing them. It seems very resonable to have a validator that can be separated from the reset of the server, that we could use in the client as well.

So which module gets the validator?

Suppose a user can click on a fleet, which highlights it. What if he then moved the mouse around to other systems...when the mouse was over another system, a dashed line appeared along with a little text box saying "Move to <system>, 12 turns". Suppose he moved over a system that was out of range...I'd like to dynamically call a function that takes a move order and returns true or false. When the function returns false, the line becomes a flashing red one and the text box changes to "System out of range.".....this is just an example of where the UI won't be able to provide a visual cue without the help of the external function.

[jbarcz1]

Also, how will the server handle Orders? Will the server assume that all orders it gets are legal, or will it perform its own verification to protect against hacking? If it does verify, can the verification code be in a module that is visible to both Client and Server so that it can be used to validate Orders as the user attempts to make them?

I think the consensus is that the server will have to certify all Orders as legal before processing them. It seems very resonable to have a validator that can be separated from the reset of the server, that we could use in the client as well.

So which module gets the validator?

Suppose a user can click on a fleet, which highlights it. What if he then moved the mouse around to other systems...when the mouse was over another system, a dashed line appeared along with a little text box saying "Move to <system>, 12 turns". Suppose he moved over a system that was out of range...I'd like to dynamically call a function that takes a move order and returns true or false. When the function returns false, the line becomes a flashing red one and the text box changes to "System out of range.".....this is just an example of where the UI won't be able to provide a visual cue without the help of the external function.

This is what I was trying to say. We'd be duplicating the validation code if we did it directly in the UI, and we'd also be creating coupling between the UI and our game logic, which, while not harmful, doesn't really have to be there.