From: Brett L. <wak...@ea...> - 2005-02-26 02:08:18
|
>I've little experience in implementing user interfaces, >most of my work has always been on the back-end side (servers etc.). >User-friendliness I can judge. But I've never done anything with Swing, >Postscript, graphical artwork etc. Just a bit of Java AWT 8 years ago, >and quite some HTML/Javascript (with Perl CGI's and Java servlets) later= on >(I'm currently doing a project in plain old C). No worries. There's still plenty of work to be done creating objects and= prototypes for the game mechanics still. Jump in where ever you feel most comfortable. >> The number one thing I can say is, if you've got an idea or a >> suggestion, voice it. The more contributions, the fast the >> project moves. > >We could put different views (map, market, company view etc.) >in different windows or panes, so that users can move and resize. > Yeah, that's the way Colossus does it. There's the main board in one= window, and a few other optional supporting windows contain other= information. I suspect that may be the best way to do it, even if it tends to be a bit= cluttered. >No grand ideas yet, sorry. I would tend to start bottom-up, >creating prototypes that show part of the functionality and >later fit things together. All using the same base classes, of course. > >For instance, I could try to work out the Stock market, building upon >some of your classes and the StockPrice I sent you yesterday, >to create a servlet that would display the stock market, >with 4 buttons per company for the market-related movements: >PayOut (right/up), Withhold (left/down), SoldOut(up), Sell(down) >to let the tokens move over the display. >Output would be HTML initially. >This would be little more than a demo, but in the background we would get >a number of classes that can be reused for the final UI machine >(which I don't envision yet), and a stockmarket definition file >(XML if we standardise on that). And then on to something else. > >Is that a reasonable approach? > This looks like the right approach to me. This method is basically building out test cases that we want the code to= eventually pass, and then writing the code to pass the basic tests. So, we can write four tests for the stock market objects: 1. Move the chit up 2. Move the chit down 3. Move the chit right/forward 4. Move the chit left/backward. Then later, we can write test cases for the stock operations that build on= the previous test cases: Selling stock will 1. add stock value from player's cash-on-hand 2. subtract the stock's value from the bank 3. add the stock to the proper pile 4. remove the stock from the player's pile 5. move the company's chit down By this method, we guarantee the app does what we want it to, and can very= easily track our progress. ---Brett. |