From: <wak...@ea...> - 2005-02-24 22:32:49
|
> It seems the files arrived with CR+LF line endings, > so they showed up double-spaced in Eclipse. Ah, yep. That's likely due to my using Eclipse under Windows XP. I'll see if I can't find a setting in Eclipse to tweak that. Failing that, Eclipse does have a source formatter that, once you define how you like your code formatted, you can have it sweep through and reformat everything. I don't expect everyone to use my coding style, or to even like it. I figure, as soon as we have a significant enough amount of code, we should layout some sort of formal rules about what style we're going to keep the code in. However, for now, any patches you have, I'll do the reformatting before I commit it to CVS if I feel it's necessary. >I"m reasonably proficient in Java, so maybe I can help, > although we"ll have to see how things develop. Great! I'm happy to have you aboard. >My main question for now is: what kind of animal you have in mind for > a first working prototype? A servlet? Applet? What kind of user interface? I expect to write a stand-alone app, and probably employ Java Web Start at some point to aid with running the app over the web. I'm taking many cues from both Vassal and Colossus, as they seem to have trod this path already. The UI is probably the biggest thing I'm looking for suggestions on. I'm definitely interested in making the app look and feel similar to the old 1830 PC game. If you haven't seen/played it, you can find it on many abandonware sites around the web. While the 1830 UI wasn't perfect, it did have a lot of things I really like that, in the long-term, I'd like to attempt to clone, such as how they handled the stock rounds and the purchasing of little companies. However, one of the areas I definitely want to diverge from that old UI is to attempt to keep as much relevant game information on a single screen as possible. One of my bigger complaints about the 1830 PC game was that there were separate screens for just about everything. To me, this seems a bit clumsy, and probably has more to do with the limitations of developing a DOS-based game than anything else. 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. ---Brett. |
From: Erik V. <eri...@hc...> - 2005-02-25 19:14:15
|
> >My main question for now is: what kind of animal you have in mind for > > a first working prototype? A servlet? Applet? What kind of > user interface? > > I expect to write a stand-alone app, and probably employ Java > Web Start at some point to aid with running the app over the > web. I'm taking many cues from both Vassal and Colossus, as > they seem to have trod this path already. > > The UI is probably the biggest thing I'm looking for suggestions on. 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). > I'm definitely interested in making the app look and feel > similar to the old 1830 PC game. If you haven't seen/played > it, you can find it on many abandonware sites around the web. > While the 1830 UI wasn't perfect, it did have a lot of things > I really like that, in the long-term, I'd like to attempt to > clone, such as how they handled the stock rounds and the > purchasing of little companies. However, one of the areas I > definitely want to diverge from that old UI is to attempt to > keep as much relevant game information on a single screen as possible. Yes, I have 1830PC and I agree with your view. > One of my bigger complaints about the 1830 PC game was that > there were separate screens for just about everything. To me, > this seems a bit clumsy, and probably has more to do with the > limitations of developing a DOS-based game than anything else. And the low resolution it was apparently designed for. > 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. 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? Erik. |
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. |
From: Randy S. <ran...@gm...> - 2005-02-26 02:17:58
|
On Fri, 25 Feb 2005 18:10:13 -0800, Brett Lentz <wak...@ea...> wrote: > 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 ---------- My PHP app essentially has this functionality already, although, self-taught as I am, I have no idea how OO it really is. There are objects for players, the bank, and a game object that tracks other stuff like the corporations. It's not specifically related to the Rails project, but I'd love it if any team members with PHP expertise would look at my code and tell me whether I'm on the right track. Randy... |