From: Erik V. <eri...@hc...> - 2005-05-04 16:16:20
|
I have implemented OperatingRound to include most of the actions that a player can do in that round. Track and token cost and train buying is still a matter of just moving cash from a company to the bank, though. Also the revenue must be entered manually, but payout and withholding work, as does buying private companies. This class and StockRound intend to become the prime interface for the UI to get the status and allowed actions, and to execute the player's actions. Direct access to lower classes will in most cases only be needed to get the display details (cash, owned certificates, etc.). Other responsibilities of these middle-layer classes are: - all validation of player actions (though many invalid actions will be impossible if the UI is set up correctly - see below). - logging messages and errors (both retrievable for UI display from the Log class). - keeping track of who has the turn (I have not used the Turn class, I think we don't need it). I have (of course) changed GameTestServlet to use these classes, have a look there if you want examples of usage. Maybe I'll publish some updated screenshots shortly. Switching rounds is not implemented yet, this should currently be done externally, simply by creating a new StockRound or OperatingRound object. Handling that will become the duty of GameManager. These classes allow marking allowed actions in the UI in detail. For instance, to check if the current Player can buy a share of a given company from the Pool you could call isCompanyBuyable (company, pool); This method does not yet include a check that the player has enough money (this is checked, though, in buyShare), but I will add such checks later. My suggestion would be to mark the background of clickable fields with a light colour (e.g. pale yellow), and those that are have been selected (or pre-selected: the player or company that has the turn) with a darker colour (e.g. green). I have not touched the XML in a while: there is a lot hardcoded now. This is high on my list to do, but I'll first try to complete the round/turn management, as this deeply affects the UI code that Brett is currently working so hard on. Erik. |
From: Brett <wak...@ea...> - 2005-05-04 18:44:22
|
On Wed, 2005-05-04 at 18:16 +0200, Erik Vos wrote: > > Other responsibilities of these middle-layer classes are: > - all validation of player actions (though many invalid actions > will be impossible if the UI is set up correctly - see below). Correct. I see this as a task for both layers. The UI ought to block invalid input from the users, and the middle-layer ought to attempt to disallow invalid input from the UI. > - keeping track of who has the turn (I have not used the Turn class, > I think we don't need it). I agree. We probably don't need it if GameManager is handling this function. Though, if used, it does provide another point of extensibility. Not that we really need that, but it's an option. > These classes allow marking allowed actions in the UI in detail. > For instance, to check if the current Player can buy a share > of a given company from the Pool you could call > isCompanyBuyable (company, pool); I've approached this slightly differently in the Swing UI. There's only two buttons: Buy and Selling. When you select a particular company and player, and press the Buy button, if the company isn't started yet, it buys the president's share, if it is started, it buys the next available share from any pool. I'm planning on making this a bit more granular once I add displays for each pool, but for now it keeps things simple and effective. > This method does not yet include a check that the player has enough > money (this is checked, though, in buyShare), but I will > add such checks later. I think conditions like these only need checking once. The tricky part is, where should the checking be? Do we want to use exception throwing to pass errors deeper in the class hierarchy up to the higher level classes for handling? > > My suggestion would be to mark the background of clickable fields > with a light colour (e.g. pale yellow), and those that are have been > selected (or pre-selected: the player or company that has the turn) > with a darker colour (e.g. green). > I don't think the selection color really matters so long as the UI only has a single item selected at any given time. Right now my Swing UI allows a single selection in each of the three status boxes, which isn't good, but is easily correctable. > I have not touched the XML in a while: there is a lot hardcoded now. > This is high on my list to do, but I'll first try to complete the > round/turn management, as this deeply affects the UI code that Brett is > currently working so hard on. Sounds good to me. I've pulled the hex code from Colossus and put it into ui/hexmap . The main reason I like their hex code is because, just like us, they need to handle what's on each side of each hex. Thankfully, for us it's just entrances and exits rather than different types of terrain. But it's a great starting point because much of the math and drawing is already coded. I'm working on getting more familiar with it so that I can work on drawing the map while you're finishing up the turn/round logic. Do we happen to have anyone on the list familiar with programming hex- maps already? ---Brett. If it doesn't smell yet, it's pretty fresh. -- Dave Johnson, on dead seagulls |
From: Erik V. <eri...@hc...> - 2005-05-04 19:47:14
|
> > These classes allow marking allowed actions in the UI in detail. > > For instance, to check if the current Player can buy a share > > of a given company from the Pool you could call > > isCompanyBuyable (company, pool); > > I've approached this slightly differently in the Swing UI. > > There's only two buttons: Buy and Selling. > > When you select a particular company and player, and press the Buy > button, if the company isn't started yet, it buys the > president's share, > if it is started, it buys the next available share from any pool. OK, that is a sensible approach (and it answers my question in the other mail). You could then still call isCompanyStartable() and/or isCompanyBuyable() afterwards to see what StockRound method to call (startCompany() or buyShare()). Or use company.hasStarted() to check this, but then you have to look up company yourself. I could change the isCompanyWhateverable methods (or any other method) to suit your approach if you would want to highlight the clickable areas (which I would recommend). > I'm planning on making this a bit more granular once I add > displays for > each pool, but for now it keeps things simple and effective. > > > This method does not yet include a check that the player has enough > > money (this is checked, though, in buyShare), but I will > > add such checks later. > > I think conditions like these only need checking once. The tricky part > is, where should the checking be? > > Do we want to use exception throwing to pass errors deeper in > the class > hierarchy up to the higher level classes for handling? As I said, I'm doing this in StockRound.buyShare(). Currently, all XxxxRound action methods return true or false indicating whether the action was valid or not (all checks included). If false, an error message is stored in Log, you can retrieve it with Log.getErrorBuffer() (the message is then cleared) and display it. I don't see a real need to use exceptions right now, unless you would find checking the return values cumbersome. My current approach is to move most of the game logic to the middle layer (i.e. the Rounds and GameManager), including all validation, and that is only one level below the UI. BTW I'm testing an initial version of GameManager, which, however, does not handle the private auction yet. That will come next. Erik. |