Menu
▾
▴
rails-devel
|
From: brett l. <bre...@gm...> - 2011-07-18 21:54:56
|
Erik - Looking over my commit history, I don't see a call to setNote() in any of the diffs. I see where I moved GameInfo into rails.common.parser. GameInfo still has the setNote() method, but I can't locate any calls to it. ---Brett. On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> wrote: > Hrm... I'd swear I moved that call into the new constructor. It was > working when I last tested it. > > I'll check it out and see what went wrong. > > ---Brett. > > > > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: >> Brett, >> >> I think this is caused by your refactoring of game info parsing. >> GameInfo.setNote() is no longer called, so all notes stay at the default >> value "Notes". You seem to have overlooked <Note> in your new parser. >> >> Erik. >> >>> -----Original Message----- >>> From: Phil Davies [mailto:de...@gm...] >>> Sent: Monday, July 18, 2011 1:51 PM >>> To: Development list for Rails: an 18xx game >>> Subject: Re: [Rails-devel] Git repository is now available. >>> >>> Something strange in the version checked out from Git. On the available >>> games dialogue at startup, each game just ahs the word 'Notes' next to it, >>> rather than the previous designation of 'playable, unplayable' etc. >>> >> >> >> ------------------------------------------------------------------------------ >> Storage Efficiency Calculator >> This modeling tool is based on patent-pending intellectual property that >> has been used successfully in hundreds of IBM storage optimization engage- >> ments, worldwide. Store less, Store more with what you own, Move data to >> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > |
|
From: Erik V. <eri...@xs...> - 2011-07-19 19:20:49
|
I think it is all explained by the fact that your GameInfoParser does not parse <Note>. Erik. > -----Original Message----- > From: brett lentz [mailto:bre...@gm...] > Sent: Monday, July 18, 2011 11:54 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Game Notes (was: Git repository is now available.) > > Erik - > > Looking over my commit history, I don't see a call to setNote() in any of the > diffs. > > I see where I moved GameInfo into rails.common.parser. GameInfo still has > the setNote() method, but I can't locate any calls to it. > > ---Brett. > > > > On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> > wrote: > > Hrm... I'd swear I moved that call into the new constructor. It was > > working when I last tested it. > > > > I'll check it out and see what went wrong. > > > > ---Brett. > > > > > > > > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: > >> Brett, > >> > >> I think this is caused by your refactoring of game info parsing. > >> GameInfo.setNote() is no longer called, so all notes stay at the > >> default value "Notes". You seem to have overlooked <Note> in your new > parser. > >> > >> Erik. > >> > >>> -----Original Message----- > >>> From: Phil Davies [mailto:de...@gm...] > >>> Sent: Monday, July 18, 2011 1:51 PM > >>> To: Development list for Rails: an 18xx game > >>> Subject: Re: [Rails-devel] Git repository is now available. > >>> > >>> Something strange in the version checked out from Git. On the > >>> available games dialogue at startup, each game just ahs the word > >>> 'Notes' next to it, rather than the previous designation of 'playable, > unplayable' etc. > >>> > >> > >> > >> --------------------------------------------------------------------- > >> --------- > >> Storage Efficiency Calculator > >> This modeling tool is based on patent-pending intellectual property > >> that has been used successfully in hundreds of IBM storage > >> optimization engage- ments, worldwide. Store less, Store more with > >> what you own, Move data to the right place. Try It Now! > >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that has > been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-07-19 20:28:58
|
Ah. Now I see where it was lost. Apologies for the oversight. The fix has been committed. ---Brett. On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: > I think it is all explained by the fact that your GameInfoParser does not parse <Note>. > Erik. > >> -----Original Message----- >> From: brett lentz [mailto:bre...@gm...] >> Sent: Monday, July 18, 2011 11:54 PM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is now available.) >> >> Erik - >> >> Looking over my commit history, I don't see a call to setNote() in any of the >> diffs. >> >> I see where I moved GameInfo into rails.common.parser. GameInfo still has >> the setNote() method, but I can't locate any calls to it. >> >> ---Brett. >> >> >> >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> >> wrote: >> > Hrm... I'd swear I moved that call into the new constructor. It was >> > working when I last tested it. >> > >> > I'll check it out and see what went wrong. >> > >> > ---Brett. >> > >> > >> > >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: >> >> Brett, >> >> >> >> I think this is caused by your refactoring of game info parsing. >> >> GameInfo.setNote() is no longer called, so all notes stay at the >> >> default value "Notes". You seem to have overlooked <Note> in your new >> parser. >> >> >> >> Erik. >> >> >> >>> -----Original Message----- >> >>> From: Phil Davies [mailto:de...@gm...] >> >>> Sent: Monday, July 18, 2011 1:51 PM >> >>> To: Development list for Rails: an 18xx game >> >>> Subject: Re: [Rails-devel] Git repository is now available. >> >>> >> >>> Something strange in the version checked out from Git. On the >> >>> available games dialogue at startup, each game just ahs the word >> >>> 'Notes' next to it, rather than the previous designation of 'playable, >> unplayable' etc. >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> --------- >> >> Storage Efficiency Calculator >> >> This modeling tool is based on patent-pending intellectual property >> >> that has been used successfully in hundreds of IBM storage >> >> optimization engage- ments, worldwide. Store less, Store more with >> >> what you own, Move data to the right place. Try It Now! >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >> _______________________________________________ >> >> Rails-devel mailing list >> >> Rai...@li... >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> > >> >> ------------------------------------------------------------------------------ >> Storage Efficiency Calculator >> This modeling tool is based on patent-pending intellectual property that has >> been used successfully in hundreds of IBM storage optimization engage- >> ments, worldwide. Store less, Store more with what you own, Move data to >> the right place. Try It Now! >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Magic Quadrant for Content-Aware Data Loss Prevention > Research study explores the data loss prevention market. Includes in-depth > analysis on the changes within the DLP market, and the criteria used to > evaluate the strengths and weaknesses of these DLP solutions. > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2011-07-21 04:41:41
|
Brett, back to Rails issues: * The game notes show up again, but new game still stops with NullPointerException errors. It occurs only if the option pane is expanded. 18xx log reports that the options are not set correctly. * The automated game tests work again but only for the first. The second and following runs fail automatically with Java exceptions, as the static class variables inside Token are not initialized again (this is especially true for TokenMap). Do you still intend to fix that or do you prefer to let me have a look at this as you already have to cope with my mistakes with git? Fixing the automated tests has a high priority on my todo list. Stefan On Tuesday, July 19, 2011 10:28:28 pm brett lentz wrote: > Ah. Now I see where it was lost. > > Apologies for the oversight. The fix has been committed. > > ---Brett. > > On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: > > I think it is all explained by the fact that your GameInfoParser does not > > parse <Note>. Erik. > > > >> -----Original Message----- > >> From: brett lentz [mailto:bre...@gm...] > >> Sent: Monday, July 18, 2011 11:54 PM > >> To: Development list for Rails: an 18xx game > >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is now > >> available.) > >> > >> Erik - > >> > >> Looking over my commit history, I don't see a call to setNote() in any > >> of the diffs. > >> > >> I see where I moved GameInfo into rails.common.parser. GameInfo still > >> has the setNote() method, but I can't locate any calls to it. > >> > >> ---Brett. > >> > >> > >> > >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> > >> > >> wrote: > >> > Hrm... I'd swear I moved that call into the new constructor. It was > >> > working when I last tested it. > >> > > >> > I'll check it out and see what went wrong. > >> > > >> > ---Brett. > >> > > >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: > >> >> Brett, > >> >> > >> >> I think this is caused by your refactoring of game info parsing. > >> >> GameInfo.setNote() is no longer called, so all notes stay at the > >> >> default value "Notes". You seem to have overlooked <Note> in your > >> >> new > >> > >> parser. > >> > >> >> Erik. > >> >> > >> >>> -----Original Message----- > >> >>> From: Phil Davies [mailto:de...@gm...] > >> >>> Sent: Monday, July 18, 2011 1:51 PM > >> >>> To: Development list for Rails: an 18xx game > >> >>> Subject: Re: [Rails-devel] Git repository is now available. > >> >>> > >> >>> Something strange in the version checked out from Git. On the > >> >>> available games dialogue at startup, each game just ahs the word > >> >>> 'Notes' next to it, rather than the previous designation of > >> >>> 'playable, > >> > >> unplayable' etc. > >> > >> >> --------------------------------------------------------------------- > >> >> --------- > >> >> Storage Efficiency Calculator > >> >> This modeling tool is based on patent-pending intellectual property > >> >> that has been used successfully in hundreds of IBM storage > >> >> optimization engage- ments, worldwide. Store less, Store more with > >> >> what you own, Move data to the right place. Try It Now! > >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> >> _______________________________________________ > >> >> Rails-devel mailing list > >> >> Rai...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > >> ------------------------------------------------------------------------ > >> ------ Storage Efficiency Calculator > >> This modeling tool is based on patent-pending intellectual property that > >> has been used successfully in hundreds of IBM storage optimization > >> engage- ments, worldwide. Store less, Store more with what you own, > >> Move data to the right place. Try It Now! > >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------- > > ----- Magic Quadrant for Content-Aware Data Loss Prevention > > Research study explores the data loss prevention market. Includes > > in-depth analysis on the changes within the DLP market, and the criteria > > used to evaluate the strengths and weaknesses of these DLP solutions. > > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > --------------------------------------------------------------------------- > --- Magic Quadrant for Content-Aware Data Loss Prevention > Research study explores the data loss prevention market. Includes in-depth > analysis on the changes within the DLP market, and the criteria used to > evaluate the strengths and weaknesses of these DLP solutions. > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-07-21 04:46:32
|
That's progress! :-) If you've got time, feel free to fix the issues. It sounds like you'll be able to get to it before I do. I don't want to force you to wait for me if these issues are hindering you from moving forward I think I've got most of the basic ideas implemented (albeit imperfectly) for this stage. So, bugfix away. ---Brett. On Wed, Jul 20, 2011 at 9:43 PM, Stefan Frey <ste...@we...> wrote: > Brett, > back to Rails issues: > > * The game notes show up again, but new game still stops with > NullPointerException errors. It occurs only if the option pane is expanded. > 18xx log reports that the options are not set correctly. > > * The automated game tests work again but only for the first. The second and > following runs fail automatically with Java exceptions, as the static class > variables inside Token are not initialized again (this is especially true for > TokenMap). > Do you still intend to fix that or do you prefer to let me have a look at this > as you already have to cope with my mistakes with git? Fixing the automated > tests has a high priority on my todo list. > > Stefan > > On Tuesday, July 19, 2011 10:28:28 pm brett lentz wrote: >> Ah. Now I see where it was lost. >> >> Apologies for the oversight. The fix has been committed. >> >> ---Brett. >> >> On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: >> > I think it is all explained by the fact that your GameInfoParser does not >> > parse <Note>. Erik. >> > >> >> -----Original Message----- >> >> From: brett lentz [mailto:bre...@gm...] >> >> Sent: Monday, July 18, 2011 11:54 PM >> >> To: Development list for Rails: an 18xx game >> >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is now >> >> available.) >> >> >> >> Erik - >> >> >> >> Looking over my commit history, I don't see a call to setNote() in any >> >> of the diffs. >> >> >> >> I see where I moved GameInfo into rails.common.parser. GameInfo still >> >> has the setNote() method, but I can't locate any calls to it. >> >> >> >> ---Brett. >> >> >> >> >> >> >> >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> >> >> >> >> wrote: >> >> > Hrm... I'd swear I moved that call into the new constructor. It was >> >> > working when I last tested it. >> >> > >> >> > I'll check it out and see what went wrong. >> >> > >> >> > ---Brett. >> >> > >> >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: >> >> >> Brett, >> >> >> >> >> >> I think this is caused by your refactoring of game info parsing. >> >> >> GameInfo.setNote() is no longer called, so all notes stay at the >> >> >> default value "Notes". You seem to have overlooked <Note> in your >> >> >> new >> >> >> >> parser. >> >> >> >> >> Erik. >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Phil Davies [mailto:de...@gm...] >> >> >>> Sent: Monday, July 18, 2011 1:51 PM >> >> >>> To: Development list for Rails: an 18xx game >> >> >>> Subject: Re: [Rails-devel] Git repository is now available. >> >> >>> >> >> >>> Something strange in the version checked out from Git. On the >> >> >>> available games dialogue at startup, each game just ahs the word >> >> >>> 'Notes' next to it, rather than the previous designation of >> >> >>> 'playable, >> >> >> >> unplayable' etc. >> >> >> >> >> --------------------------------------------------------------------- >> >> >> --------- >> >> >> Storage Efficiency Calculator >> >> >> This modeling tool is based on patent-pending intellectual property >> >> >> that has been used successfully in hundreds of IBM storage >> >> >> optimization engage- ments, worldwide. Store less, Store more with >> >> >> what you own, Move data to the right place. Try It Now! >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >> >> _______________________________________________ >> >> >> Rails-devel mailing list >> >> >> Rai...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> >> ------------------------------------------------------------------------ >> >> ------ Storage Efficiency Calculator >> >> This modeling tool is based on patent-pending intellectual property that >> >> has been used successfully in hundreds of IBM storage optimization >> >> engage- ments, worldwide. Store less, Store more with what you own, >> >> Move data to the right place. Try It Now! >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >> _______________________________________________ >> >> Rails-devel mailing list >> >> Rai...@li... >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > >> > ------------------------------------------------------------------------- >> > ----- Magic Quadrant for Content-Aware Data Loss Prevention >> > Research study explores the data loss prevention market. Includes >> > in-depth analysis on the changes within the DLP market, and the criteria >> > used to evaluate the strengths and weaknesses of these DLP solutions. >> > http://www.accelacomm.com/jaw/sfnl/114/51385063/ >> > _______________________________________________ >> > Rails-devel mailing list >> > Rai...@li... >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> --------------------------------------------------------------------------- >> --- Magic Quadrant for Content-Aware Data Loss Prevention >> Research study explores the data loss prevention market. Includes in-depth >> analysis on the changes within the DLP market, and the criteria used to >> evaluate the strengths and weaknesses of these DLP solutions. >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------------ > 5 Ways to Improve & Secure Unified Communications > Unified Communications promises greater efficiencies for business. UC can > improve internal communications as well as offer faster, more efficient ways > to interact with customers and streamline customer service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2011-07-21 05:18:06
|
step by step ;-) OK: I will fix the initialization issues on my own (most likely by introducing TokenManager and SpecialPropertyManager that store the previously static class variables) . Stefan On Thursday, July 21, 2011 06:46:05 am brett lentz wrote: > That's progress! :-) > > If you've got time, feel free to fix the issues. It sounds like you'll > be able to get to it before I do. I don't want to force you to wait > for me if these issues are hindering you from moving forward > > I think I've got most of the basic ideas implemented (albeit > imperfectly) for this stage. So, bugfix away. > > ---Brett. > > On Wed, Jul 20, 2011 at 9:43 PM, Stefan Frey <ste...@we...> wrote: > > Brett, > > back to Rails issues: > > > > * The game notes show up again, but new game still stops with > > NullPointerException errors. It occurs only if the option pane is > > expanded. 18xx log reports that the options are not set correctly. > > > > * The automated game tests work again but only for the first. The second > > and following runs fail automatically with Java exceptions, as the > > static class variables inside Token are not initialized again (this is > > especially true for TokenMap). > > Do you still intend to fix that or do you prefer to let me have a look at > > this as you already have to cope with my mistakes with git? Fixing the > > automated tests has a high priority on my todo list. > > > > Stefan > > > > On Tuesday, July 19, 2011 10:28:28 pm brett lentz wrote: > >> Ah. Now I see where it was lost. > >> > >> Apologies for the oversight. The fix has been committed. > >> > >> ---Brett. > >> > >> On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: > >> > I think it is all explained by the fact that your GameInfoParser does > >> > not parse <Note>. Erik. > >> > > >> >> -----Original Message----- > >> >> From: brett lentz [mailto:bre...@gm...] > >> >> Sent: Monday, July 18, 2011 11:54 PM > >> >> To: Development list for Rails: an 18xx game > >> >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is now > >> >> available.) > >> >> > >> >> Erik - > >> >> > >> >> Looking over my commit history, I don't see a call to setNote() in > >> >> any of the diffs. > >> >> > >> >> I see where I moved GameInfo into rails.common.parser. GameInfo still > >> >> has the setNote() method, but I can't locate any calls to it. > >> >> > >> >> ---Brett. > >> >> > >> >> > >> >> > >> >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> > >> >> > >> >> wrote: > >> >> > Hrm... I'd swear I moved that call into the new constructor. It was > >> >> > working when I last tested it. > >> >> > > >> >> > I'll check it out and see what went wrong. > >> >> > > >> >> > ---Brett. > >> >> > > >> >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> wrote: > >> >> >> Brett, > >> >> >> > >> >> >> I think this is caused by your refactoring of game info parsing. > >> >> >> GameInfo.setNote() is no longer called, so all notes stay at the > >> >> >> default value "Notes". You seem to have overlooked <Note> in your > >> >> >> new > >> >> > >> >> parser. > >> >> > >> >> >> Erik. > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: Phil Davies [mailto:de...@gm...] > >> >> >>> Sent: Monday, July 18, 2011 1:51 PM > >> >> >>> To: Development list for Rails: an 18xx game > >> >> >>> Subject: Re: [Rails-devel] Git repository is now available. > >> >> >>> > >> >> >>> Something strange in the version checked out from Git. On the > >> >> >>> available games dialogue at startup, each game just ahs the word > >> >> >>> 'Notes' next to it, rather than the previous designation of > >> >> >>> 'playable, > >> >> > >> >> unplayable' etc. > >> >> > >> >> >> ------------------------------------------------------------------ > >> >> >> --- --------- > >> >> >> Storage Efficiency Calculator > >> >> >> This modeling tool is based on patent-pending intellectual > >> >> >> property that has been used successfully in hundreds of IBM > >> >> >> storage optimization engage- ments, worldwide. Store less, Store > >> >> >> more with what you own, Move data to the right place. Try It Now! > >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> >> >> _______________________________________________ > >> >> >> Rails-devel mailing list > >> >> >> Rai...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> >> > >> >> --------------------------------------------------------------------- > >> >> --- ------ Storage Efficiency Calculator > >> >> This modeling tool is based on patent-pending intellectual property > >> >> that has been used successfully in hundreds of IBM storage > >> >> optimization engage- ments, worldwide. Store less, Store more with > >> >> what you own, Move data to the right place. Try It Now! > >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> >> _______________________________________________ > >> >> Rails-devel mailing list > >> >> Rai...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > >> > ---------------------------------------------------------------------- > >> > --- ----- Magic Quadrant for Content-Aware Data Loss Prevention > >> > Research study explores the data loss prevention market. Includes > >> > in-depth analysis on the changes within the DLP market, and the > >> > criteria used to evaluate the strengths and weaknesses of these DLP > >> > solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >> > _______________________________________________ > >> > Rails-devel mailing list > >> > Rai...@li... > >> > https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > >> ------------------------------------------------------------------------ > >> --- --- Magic Quadrant for Content-Aware Data Loss Prevention > >> Research study explores the data loss prevention market. Includes > >> in-depth analysis on the changes within the DLP market, and the > >> criteria used to evaluate the strengths and weaknesses of these DLP > >> solutions. > >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------- > > ----- 5 Ways to Improve & Secure Unified Communications > > Unified Communications promises greater efficiencies for business. UC can > > improve internal communications as well as offer faster, more efficient > > ways to interact with customers and streamline customer service. Learn > > more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > --------------------------------------------------------------------------- > --- 5 Ways to Improve & Secure Unified Communications > Unified Communications promises greater efficiencies for business. UC can > improve internal communications as well as offer faster, more efficient > ways to interact with customers and streamline customer service. Learn > more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-07-21 06:09:58
|
Yup, that sounds like it might be necessary if one of the existing *Managers isn't a good fit. I'm trying to look ahead to our dream of client/server separation where I expect the server will handle all the XML reading and pass it's authoritative information to the client. In this case, the client side will need to be able to instantiate objects without calling the ConfigureFromXML() methods in each of the *Managers. So, if your implementation of new *Managers involves new ConfigureFromXML() methods, I'd like to suggest this may be the time to work on an alternative initialization methodology. It seems that GameInfoParser might be part of the solution, but I'm not certain. Unravelling the current game init code is taking me more time than I like. ---Brett. On Wed, Jul 20, 2011 at 10:20 PM, Stefan Frey <ste...@we...> wrote: > step by step ;-) > > OK: I will fix the initialization issues on my own (most likely by introducing > TokenManager and SpecialPropertyManager that store the previously static class > variables) . > Stefan > > On Thursday, July 21, 2011 06:46:05 am brett lentz wrote: >> That's progress! :-) >> >> If you've got time, feel free to fix the issues. It sounds like you'll >> be able to get to it before I do. I don't want to force you to wait >> for me if these issues are hindering you from moving forward >> >> I think I've got most of the basic ideas implemented (albeit >> imperfectly) for this stage. So, bugfix away. >> >> ---Brett. >> >> On Wed, Jul 20, 2011 at 9:43 PM, Stefan Frey <ste...@we...> wrote: >> > Brett, >> > back to Rails issues: >> > >> > * The game notes show up again, but new game still stops with >> > NullPointerException errors. It occurs only if the option pane is >> > expanded. 18xx log reports that the options are not set correctly. >> > >> > * The automated game tests work again but only for the first. The second >> > and following runs fail automatically with Java exceptions, as the >> > static class variables inside Token are not initialized again (this is >> > especially true for TokenMap). >> > Do you still intend to fix that or do you prefer to let me have a look at >> > this as you already have to cope with my mistakes with git? Fixing the >> > automated tests has a high priority on my todo list. >> > >> > Stefan >> > >> > On Tuesday, July 19, 2011 10:28:28 pm brett lentz wrote: >> >> Ah. Now I see where it was lost. >> >> >> >> Apologies for the oversight. The fix has been committed. >> >> >> >> ---Brett. >> >> >> >> On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: >> >> > I think it is all explained by the fact that your GameInfoParser does >> >> > not parse <Note>. Erik. >> >> > >> >> >> -----Original Message----- >> >> >> From: brett lentz [mailto:bre...@gm...] >> >> >> Sent: Monday, July 18, 2011 11:54 PM >> >> >> To: Development list for Rails: an 18xx game >> >> >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is now >> >> >> available.) >> >> >> >> >> >> Erik - >> >> >> >> >> >> Looking over my commit history, I don't see a call to setNote() in >> >> >> any of the diffs. >> >> >> >> >> >> I see where I moved GameInfo into rails.common.parser. GameInfo still >> >> >> has the setNote() method, but I can't locate any calls to it. >> >> >> >> >> >> ---Brett. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz <bre...@gm...> >> >> >> >> >> >> wrote: >> >> >> > Hrm... I'd swear I moved that call into the new constructor. It was >> >> >> > working when I last tested it. >> >> >> > >> >> >> > I'll check it out and see what went wrong. >> >> >> > >> >> >> > ---Brett. >> >> >> > >> >> >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos <eri...@xs...> > wrote: >> >> >> >> Brett, >> >> >> >> >> >> >> >> I think this is caused by your refactoring of game info parsing. >> >> >> >> GameInfo.setNote() is no longer called, so all notes stay at the >> >> >> >> default value "Notes". You seem to have overlooked <Note> in your >> >> >> >> new >> >> >> >> >> >> parser. >> >> >> >> >> >> >> Erik. >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >> >>> From: Phil Davies [mailto:de...@gm...] >> >> >> >>> Sent: Monday, July 18, 2011 1:51 PM >> >> >> >>> To: Development list for Rails: an 18xx game >> >> >> >>> Subject: Re: [Rails-devel] Git repository is now available. >> >> >> >>> >> >> >> >>> Something strange in the version checked out from Git. On the >> >> >> >>> available games dialogue at startup, each game just ahs the word >> >> >> >>> 'Notes' next to it, rather than the previous designation of >> >> >> >>> 'playable, >> >> >> >> >> >> unplayable' etc. >> >> >> >> >> >> >> ------------------------------------------------------------------ >> >> >> >> --- --------- >> >> >> >> Storage Efficiency Calculator >> >> >> >> This modeling tool is based on patent-pending intellectual >> >> >> >> property that has been used successfully in hundreds of IBM >> >> >> >> storage optimization engage- ments, worldwide. Store less, Store >> >> >> >> more with what you own, Move data to the right place. Try It Now! >> >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >> >> >> _______________________________________________ >> >> >> >> Rails-devel mailing list >> >> >> >> Rai...@li... >> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> --- ------ Storage Efficiency Calculator >> >> >> This modeling tool is based on patent-pending intellectual property >> >> >> that has been used successfully in hundreds of IBM storage >> >> >> optimization engage- ments, worldwide. Store less, Store more with >> >> >> what you own, Move data to the right place. Try It Now! >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >> >> _______________________________________________ >> >> >> Rails-devel mailing list >> >> >> Rai...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > >> >> > ---------------------------------------------------------------------- >> >> > --- ----- Magic Quadrant for Content-Aware Data Loss Prevention >> >> > Research study explores the data loss prevention market. Includes >> >> > in-depth analysis on the changes within the DLP market, and the >> >> > criteria used to evaluate the strengths and weaknesses of these DLP >> >> > solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ >> >> > _______________________________________________ >> >> > Rails-devel mailing list >> >> > Rai...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> >> ------------------------------------------------------------------------ >> >> --- --- Magic Quadrant for Content-Aware Data Loss Prevention >> >> Research study explores the data loss prevention market. Includes >> >> in-depth analysis on the changes within the DLP market, and the >> >> criteria used to evaluate the strengths and weaknesses of these DLP >> >> solutions. >> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ >> >> _______________________________________________ >> >> Rails-devel mailing list >> >> Rai...@li... >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > >> > ------------------------------------------------------------------------- >> > ----- 5 Ways to Improve & Secure Unified Communications >> > Unified Communications promises greater efficiencies for business. UC can >> > improve internal communications as well as offer faster, more efficient >> > ways to interact with customers and streamline customer service. Learn >> > more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ >> > _______________________________________________ >> > Rails-devel mailing list >> > Rai...@li... >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> --------------------------------------------------------------------------- >> --- 5 Ways to Improve & Secure Unified Communications >> Unified Communications promises greater efficiencies for business. UC can >> improve internal communications as well as offer faster, more efficient >> ways to interact with customers and streamline customer service. Learn >> more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------------ > 5 Ways to Improve & Secure Unified Communications > Unified Communications promises greater efficiencies for business. UC can > improve internal communications as well as offer faster, more efficient ways > to interact with customers and streamline customer service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-07-21 08:34:24
|
For what it's worth: My idea about client/server was that both sides would parse the XML and thus would have access to all static (as opposed to dynamic) objects. Only the dynamic (state) info would be in the server only. Parsing at the client would been initiated by much simpler (and probably less) managers, probably not really worth that name. But I haven't really thought this through yet. BTW I was recently approached by a Dutch guy (Ruud Poutsma) who is developing a server game engine (for Settlers of Catan) that he thinks could be used generally. He had found the Rails site and insists that it could be useful to us. He is looking for assistance. All his mails were in Dutch, so it's no use to forward these. I have told him that I do not want to work on his project personally, and that he should write it up in English so I could forward it to the group. He has not done that yet. Anyway, here is the link to his code: https://github.com/generateui/OpenSettlers/tree/master/src/java/soc/common/server Erik. > -----Original Message----- > From: brett lentz [mailto:bre...@gm...] > Sent: Thursday, July 21, 2011 8:09 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Game Notes (was: Git repository is now available.) > > Yup, that sounds like it might be necessary if one of the existing *Managers > isn't a good fit. > > I'm trying to look ahead to our dream of client/server separation where I > expect the server will handle all the XML reading and pass it's authoritative > information to the client. In this case, the client side will need to be able to > instantiate objects without calling the > ConfigureFromXML() methods in each of the *Managers. > > So, if your implementation of new *Managers involves new > ConfigureFromXML() methods, I'd like to suggest this may be the time to > work on an alternative initialization methodology. It seems that > GameInfoParser might be part of the solution, but I'm not certain. > > Unravelling the current game init code is taking me more time than I like. > > ---Brett. > > On Wed, Jul 20, 2011 at 10:20 PM, Stefan Frey <ste...@we...> wrote: > > step by step ;-) > > > > OK: I will fix the initialization issues on my own (most likely by > > introducing TokenManager and SpecialPropertyManager that store the > > previously static class > > variables) . > > Stefan > > > > On Thursday, July 21, 2011 06:46:05 am brett lentz wrote: > >> That's progress! :-) > >> > >> If you've got time, feel free to fix the issues. It sounds like > >> you'll be able to get to it before I do. I don't want to force you to > >> wait for me if these issues are hindering you from moving forward > >> > >> I think I've got most of the basic ideas implemented (albeit > >> imperfectly) for this stage. So, bugfix away. > >> > >> ---Brett. > >> > >> On Wed, Jul 20, 2011 at 9:43 PM, Stefan Frey <ste...@we...> > wrote: > >> > Brett, > >> > back to Rails issues: > >> > > >> > * The game notes show up again, but new game still stops with > >> > NullPointerException errors. It occurs only if the option pane is > >> > expanded. 18xx log reports that the options are not set correctly. > >> > > >> > * The automated game tests work again but only for the first. The > >> > second and following runs fail automatically with Java exceptions, > >> > as the static class variables inside Token are not initialized > >> > again (this is especially true for TokenMap). > >> > Do you still intend to fix that or do you prefer to let me have a > >> > look at this as you already have to cope with my mistakes with git? > >> > Fixing the automated tests has a high priority on my todo list. > >> > > >> > Stefan > >> > > >> > On Tuesday, July 19, 2011 10:28:28 pm brett lentz wrote: > >> >> Ah. Now I see where it was lost. > >> >> > >> >> Apologies for the oversight. The fix has been committed. > >> >> > >> >> ---Brett. > >> >> > >> >> On Tue, Jul 19, 2011 at 12:20 PM, Erik Vos <eri...@xs...> wrote: > >> >> > I think it is all explained by the fact that your GameInfoParser > >> >> > does not parse <Note>. Erik. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: brett lentz [mailto:bre...@gm...] > >> >> >> Sent: Monday, July 18, 2011 11:54 PM > >> >> >> To: Development list for Rails: an 18xx game > >> >> >> Subject: Re: [Rails-devel] Game Notes (was: Git repository is > >> >> >> now > >> >> >> available.) > >> >> >> > >> >> >> Erik - > >> >> >> > >> >> >> Looking over my commit history, I don't see a call to setNote() > >> >> >> in any of the diffs. > >> >> >> > >> >> >> I see where I moved GameInfo into rails.common.parser. > GameInfo > >> >> >> still has the setNote() method, but I can't locate any calls to it. > >> >> >> > >> >> >> ---Brett. > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Mon, Jul 18, 2011 at 12:03 PM, brett lentz > >> >> >> <bre...@gm...> > >> >> >> > >> >> >> wrote: > >> >> >> > Hrm... I'd swear I moved that call into the new constructor. > >> >> >> > It was working when I last tested it. > >> >> >> > > >> >> >> > I'll check it out and see what went wrong. > >> >> >> > > >> >> >> > ---Brett. > >> >> >> > > >> >> >> > On Mon, Jul 18, 2011 at 11:50 AM, Erik Vos > >> >> >> > <eri...@xs...> > > wrote: > >> >> >> >> Brett, > >> >> >> >> > >> >> >> >> I think this is caused by your refactoring of game info parsing. > >> >> >> >> GameInfo.setNote() is no longer called, so all notes stay at > >> >> >> >> the default value "Notes". You seem to have overlooked > >> >> >> >> <Note> in your new > >> >> >> > >> >> >> parser. > >> >> >> > >> >> >> >> Erik. > >> >> >> >> > >> >> >> >>> -----Original Message----- > >> >> >> >>> From: Phil Davies [mailto:de...@gm...] > >> >> >> >>> Sent: Monday, July 18, 2011 1:51 PM > >> >> >> >>> To: Development list for Rails: an 18xx game > >> >> >> >>> Subject: Re: [Rails-devel] Git repository is now available. > >> >> >> >>> > >> >> >> >>> Something strange in the version checked out from Git. On > >> >> >> >>> the available games dialogue at startup, each game just ahs > >> >> >> >>> the word 'Notes' next to it, rather than the previous > >> >> >> >>> designation of 'playable, > >> >> >> > >> >> >> unplayable' etc. > >> >> >> > >> >> >> >> ------------------------------------------------------------ > >> >> >> >> ------ > >> >> >> >> --- --------- > >> >> >> >> Storage Efficiency Calculator This modeling tool is based on > >> >> >> >> patent-pending intellectual property that has been used > >> >> >> >> successfully in hundreds of IBM storage optimization engage- > >> >> >> >> ments, worldwide. Store less, Store more with what you own, > >> >> >> >> Move data to the right place. Try It Now! > >> >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> >> >> >> _______________________________________________ > >> >> >> >> Rails-devel mailing list > >> >> >> >> Rai...@li... > >> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> >> >> > >> >> >> --------------------------------------------------------------- > >> >> >> ------ > >> >> >> --- ------ Storage Efficiency Calculator This modeling tool is > >> >> >> based on patent-pending intellectual property that has been > >> >> >> used successfully in hundreds of IBM storage optimization > >> >> >> engage- ments, worldwide. Store less, Store more with what you > >> >> >> own, Move data to the right place. Try It Now! > >> >> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ > >> >> >> _______________________________________________ > >> >> >> Rails-devel mailing list > >> >> >> Rai...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> >> > > >> >> > ---------------------------------------------------------------- > >> >> > ------ > >> >> > --- ----- Magic Quadrant for Content-Aware Data Loss Prevention > >> >> > Research study explores the data loss prevention market. > >> >> > Includes in-depth analysis on the changes within the DLP market, > >> >> > and the criteria used to evaluate the strengths and weaknesses > >> >> > of these DLP solutions. > >> >> > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >> >> > _______________________________________________ > >> >> > Rails-devel mailing list > >> >> > Rai...@li... > >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel > >> >> > >> >> ------------------------------------------------------------------ > >> >> ------ > >> >> --- --- Magic Quadrant for Content-Aware Data Loss Prevention > >> >> Research study explores the data loss prevention market. Includes > >> >> in-depth analysis on the changes within the DLP market, and the > >> >> criteria used to evaluate the strengths and weaknesses of these > >> >> DLP solutions. > >> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ > >> >> _______________________________________________ > >> >> Rails-devel mailing list > >> >> Rai...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > >> > ------------------------------------------------------------------- > >> > ------ > >> > ----- 5 Ways to Improve & Secure Unified Communications Unified > >> > Communications promises greater efficiencies for business. UC can > >> > improve internal communications as well as offer faster, more > >> > efficient ways to interact with customers and streamline customer > >> > service. Learn more! > >> > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > >> > _______________________________________________ > >> > Rails-devel mailing list > >> > Rai...@li... > >> > https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > >> --------------------------------------------------------------------- > >> ------ > >> --- 5 Ways to Improve & Secure Unified Communications Unified > >> Communications promises greater efficiencies for business. UC can > >> improve internal communications as well as offer faster, more > >> efficient ways to interact with customers and streamline customer > >> service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ---------------------------------------------------------------------- > > -------- > > 5 Ways to Improve & Secure Unified Communications Unified > > Communications promises greater efficiencies for business. UC can > > improve internal communications as well as offer faster, more > > efficient ways to interact with customers and streamline customer service. > Learn more! > > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > 5 Ways to Improve & Secure Unified Communications Unified > Communications promises greater efficiencies for business. UC can improve > internal communications as well as offer faster, more efficient ways to > interact with customers and streamline customer service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Stefan F. <ste...@we...> - 2011-07-23 08:51:46
|
With respect to Brett wishes below I decided to not add further Managers, but
instead added a storage possibility to the GameManager.
However I tried to make this a general storage for all kind of objects instead
of adding two specific storages.
Due to the fact that Token stores ids as Strings ("Token_#") with indices
starting at zero and SpecialProperties as Integer starting at one, there is
some legacy support code which potentially could be remove when
we decide to break save file compatibility.
I have to admit that do not fully understand what Brett's concerns are: In my
understanding it will either be a fat client/lean server (means that each
instance has a full game model behind and the server component only broker
messages) or a lean client/fat sever (means that the client only shows a view
of game model on the server) and in that case the client would have none of
the current Manager which are configured by xml.
Remark: To work with my IMAP based e-mail client the search using git ids only
works if they are added to the subject efficiently.
On Thursday, July 21, 2011 08:09:28 am brett lentz wrote:
> Yup, that sounds like it might be necessary if one of the existing
> *Managers isn't a good fit.
>
> I'm trying to look ahead to our dream of client/server separation
> where I expect the server will handle all the XML reading and pass
> it's authoritative information to the client. In this case, the client
> side will need to be able to instantiate objects without calling the
> ConfigureFromXML() methods in each of the *Managers.
>
> So, if your implementation of new *Managers involves new
> ConfigureFromXML() methods, I'd like to suggest this may be the time
> to work on an alternative initialization methodology. It seems that
> GameInfoParser might be part of the solution, but I'm not certain.
>
> Unravelling the current game init code is taking me more time than I like.
>
> ---Brett.
>
|
|
From: Erik V. <eri...@xs...> - 2011-07-23 14:47:45
|
> -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > I have to admit that do not fully understand what Brett's concerns are: In my > understanding it will either be a fat client/lean server (means that each > instance has a full game model behind and the server component only > broker > messages) or a lean client/fat sever (means that the client only shows a view > of game model on the server) and in that case the client would have none of > the current Manager which are configured by xml. The current exchange of action objects is based on (what I think amounts to) yet another concept, that I mentioned a few days ago in the Game Notes thread: > -----Original Message----- > From: Erik Vos [mailto:eri...@xs...] > For what it's worth: > > My idea about client/server was that both sides would parse the XML and > thus would have access to all static (as opposed to dynamic) objects. > Only the dynamic (state) info would be in the server only. Parsing at the > client would been initiated by much simpler (and probably less) managers, > probably not really worth that name. > > But I haven't really thought this through yet. The current communication between GUI and engine mainly consists of the action objects. After a client/server split, the action objects would be exchanged in some serialized form, and only contain the unique IDs of the relevant objects, not these objects themselves (which are declared transient). So the unique IDs have to be identical at both sides. I consider that a main design consideration for the client/server split. It may put constraints on the parsing sequence at both sides. Erik. |
|
From: brett l. <bre...@gm...> - 2011-07-23 15:36:49
|
On Sat, Jul 23, 2011 at 7:47 AM, Erik Vos <eri...@xs...> wrote: >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] > >> I have to admit that do not fully understand what Brett's concerns are: In > my >> understanding it will either be a fat client/lean server (means that each >> instance has a full game model behind and the server component only >> broker >> messages) or a lean client/fat sever (means that the client only shows a > view >> of game model on the server) and in that case the client would have none > of >> the current Manager which are configured by xml. > > The current exchange of action objects is based on (what I think amounts to) > yet another concept, that I mentioned a few days ago in the Game Notes > thread: > To be clear, the thing I was trying to recommend against is *just* the configureFromXML() method that we typically use to initialize the *Manager classes. That's the biggest point where a client/server model will differ. We'll need to instantiate the various *Manager classes, but those classes will need to be instantiated using normal constructors that can then be configured, probably by getters and setters to allow the method of obtaining the information to be either local or remote, and the "game engine" won't care which. So, my main point is that I'd like us to be conscious of which classes have awareness of lower-level information (like XML parsing) and ensure that knowledge is appropriately abstracted away from the game logic in the same way that we try to separate the game logic from the display/view logic. ---Brett. >> -----Original Message----- >> From: Erik Vos [mailto:eri...@xs...] >> For what it's worth: >> >> My idea about client/server was that both sides would parse the XML and >> thus would have access to all static (as opposed to dynamic) objects. >> Only the dynamic (state) info would be in the server only. Parsing at the >> client would been initiated by much simpler (and probably less) managers, >> probably not really worth that name. >> >> But I haven't really thought this through yet. > > The current communication between GUI and engine mainly consists of the > action objects. After a client/server split, the action objects would be > exchanged in some serialized form, and only contain the unique IDs of the > relevant objects, not these objects themselves (which are declared > transient). > So the unique IDs have to be identical at both sides. I consider that a main > design consideration for the client/server split. It may put constraints on > the parsing sequence at both sides. > > Erik. > > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-07-23 15:56:20
|
> -----Original Message----- > From: brett lentz [mailto:bre...@gm...] > Sent: Saturday, July 23, 2011 5:36 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8) > To be clear, the thing I was trying to recommend against is *just* the > configureFromXML() method that we typically use to initialize the *Manager > classes. > > That's the biggest point where a client/server model will differ. Why? The client won't have the same managers, but why can't whatever will replace the managers call the same configureFromXML() methods of the objects that they need to know about? > We'll need to instantiate the various *Manager classes, but those classes will > need to be instantiated using normal constructors that can then be > configured, probably by getters and setters to allow the method of obtaining > the information to be either local or remote, and the "game engine" won't > care which. Always local, in my concept. Static info does not need to squeezed through the client/server interface. Unless you want to make the client really dumb, of course. And slower. Erik. > So, my main point is that I'd like us to be conscious of which classes have > awareness of lower-level information (like XML parsing) and ensure that > knowledge is appropriately abstracted away from the game logic in the same > way that we try to separate the game logic from the display/view logic. > > ---Brett. |
|
From: Stefan F. <ste...@we...> - 2011-07-23 17:40:03
|
Erik & Brett, it seems to me it depends on what you the suggested client/server split looks like. From what I understood from previous discussions is that Erik prefers the fat client approach, where "clients" all have a full game back-end running and only pass around actions between them. The server merely acts as a message broker. Another possibility is a client/server split between the game backend as the server and the clients only consisting of the GUI as defined by the swing classes of Rails. However it requires passing along the updates between the server and all connected clients. It seems to me that Brett thinks of the latter separation, however I still do not understand why the configureFromXML method matters here as all Managers using configureFromXML belong to the server part. So I might be wrong and Brett has other ideas. From my point of view I think that Erik's approach is the easiest to implement and has some advantages in UI responsiveness. It might also be better suited for a migration to mobile devices like Android tablets, which I think should be the longer-term goal, which are restricted in bandwidth and latency, but have enough computing power to run the game backend. Stefan On Saturday, July 23, 2011 05:56:20 pm Erik Vos wrote: > > -----Original Message----- > > From: brett lentz [mailto:bre...@gm...] > > Sent: Saturday, July 23, 2011 5:36 PM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Removal of static class variables (git: > > 8b9df8) To be clear, the thing I was trying to recommend against is > > *just* the configureFromXML() method that we typically use to initialize > > the *Manager classes. > > > > That's the biggest point where a client/server model will differ. > > Why? > The client won't have the same managers, but why can't whatever will > replace the managers call the same configureFromXML() methods of the > objects that they need to know about? > > > We'll need to instantiate the various *Manager classes, but those classes > > will need to be instantiated using normal constructors that can then be > > configured, probably by getters and setters to allow the method of > > obtaining the information to be either local or remote, and the "game > > engine" won't care which. > > Always local, in my concept. Static info does not need to squeezed through > the client/server interface. Unless you want to make the client really > dumb, of course. And slower. > > Erik. > > > So, my main point is that I'd like us to be conscious of which classes > > have awareness of lower-level information (like XML parsing) and ensure > > that knowledge is appropriately abstracted away from the game logic in > > the same way that we try to separate the game logic from the > > display/view logic. > > > > ---Brett. > > --------------------------------------------------------------------------- > --- Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-07-23 19:01:07
|
Stefan - I'm definitely identifying a different point of separation, but not strictly the "dumb" client that you describe. The thing that needs communicating is two things: the action and the data. Consider the possibility that the server-side is a Web server with a REST interface. (I select this example, because it could support a variety of clients, from the current Swing interface, to a mobile app, to a browser-based interface.) To buy a share, clients could connect to the server, authenticate, and then issue a GET to "/stockmarket/company/3/buy" and receive a response. The response can be a variety of things, depending on how "thick" or "thin" the client is. 1. It could be a simple "success/failure" response. 2. It could be success/failure, with an updated client Wallet value. 3. It could be success/failure, with the current state of every player's holdings, the whole stock market, or even whole game. We can even always provide a "thin" client response that "thicker" clients take and only use pieces of and discard the rest. It's inefficient, but a conceivable implementation. However, during client startup there is going to be a decision point of "how do I get the current state of the game?" We need to be able to initialize a GameManager and then tell it "you are at this phase of the game", and provide it with enough information that it can initialize the BankManager and other bits of the game. With client/server play, the presumption that all clients are starting at the beginning of the game does not need to be true. Servers can (and should) be long-running services that maintain the state of all games they are moderating. When returning to an in-progress game, (this is the important part) there is no need to reread most of the XML files. The server's already running and should know the state of the game. The clients simply need to retrieve the game state and take the next turn, if applicable. Now... to be clear... I'm not saying that clients won't read *any* XML, I'm saying that decoupling game engine from how we read configuration data will allow more flexibility in how we read that config data. That flexibility is a pre-requisite for client/server implementation because while we may still load the tile manifest from XML, we'll likely be transmitting the state of the map over the wire because we will only care about the current state, not the beginning state of the map. ---Brett. On Sat, Jul 23, 2011 at 10:42 AM, Stefan Frey <ste...@we...> wrote: > Erik & Brett, > it seems to me it depends on what you the suggested client/server split looks > like. > > >From what I understood from previous discussions is that Erik prefers > the fat client approach, where "clients" all have a full game back-end running > and only pass around actions between them. The server merely acts as a message > broker. > > Another possibility is a client/server split between the game backend as the > server and the clients only consisting of the GUI as defined by the swing > classes of Rails. However it requires passing along the updates between the > server and all connected clients. > > It seems to me that Brett thinks of the latter separation, however I still do > not understand why the configureFromXML method matters here as all Managers > using configureFromXML belong to the server part. So I might be wrong and > Brett has other ideas. > > >From my point of view I think that Erik's approach is the easiest to implement > and has some advantages in UI responsiveness. It might also be better suited > for a migration to mobile devices like Android tablets, which I think should > be the longer-term goal, which are restricted in bandwidth and latency, but > have enough computing power to run the game backend. > > Stefan > > > On Saturday, July 23, 2011 05:56:20 pm Erik Vos wrote: >> > -----Original Message----- >> > From: brett lentz [mailto:bre...@gm...] >> > Sent: Saturday, July 23, 2011 5:36 PM >> > To: Development list for Rails: an 18xx game >> > Subject: Re: [Rails-devel] Removal of static class variables (git: >> > 8b9df8) To be clear, the thing I was trying to recommend against is >> > *just* the configureFromXML() method that we typically use to initialize >> > the *Manager classes. >> > >> > That's the biggest point where a client/server model will differ. >> >> Why? >> The client won't have the same managers, but why can't whatever will >> replace the managers call the same configureFromXML() methods of the >> objects that they need to know about? >> >> > We'll need to instantiate the various *Manager classes, but those classes >> > will need to be instantiated using normal constructors that can then be >> > configured, probably by getters and setters to allow the method of >> > obtaining the information to be either local or remote, and the "game >> > engine" won't care which. >> >> Always local, in my concept. Static info does not need to squeezed through >> the client/server interface. Unless you want to make the client really >> dumb, of course. And slower. >> >> Erik. >> >> > So, my main point is that I'd like us to be conscious of which classes >> > have awareness of lower-level information (like XML parsing) and ensure >> > that knowledge is appropriately abstracted away from the game logic in >> > the same way that we try to separate the game logic from the >> > display/view logic. >> > >> > ---Brett. >> >> --------------------------------------------------------------------------- >> --- Storage Efficiency Calculator >> This modeling tool is based on patent-pending intellectual property that >> has been used successfully in hundreds of IBM storage optimization engage- >> ments, worldwide. Store less, Store more with what you own, Move data to >> the right place. Try It Now! >> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <bre...@gm...> - 2011-07-23 18:40:05
|
On Sat, Jul 23, 2011 at 8:56 AM, Erik Vos <eri...@xs...> wrote: > > >> -----Original Message----- >> From: brett lentz [mailto:bre...@gm...] >> Sent: Saturday, July 23, 2011 5:36 PM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8) >> To be clear, the thing I was trying to recommend against is *just* the >> configureFromXML() method that we typically use to initialize the *Manager >> classes. >> >> That's the biggest point where a client/server model will differ. > > Why? > The client won't have the same managers, but why can't whatever will replace the managers call the same configureFromXML() methods of the objects that they need to know about? > Because the clients should take the "authoritative" values for things given to it by the server, not whatever arbitrary values somebody decides to put into their own local XML files. Trusting the client to do the right thing on its own makes exploitation far too easy. >> We'll need to instantiate the various *Manager classes, but those classes will >> need to be instantiated using normal constructors that can then be >> configured, probably by getters and setters to allow the method of obtaining >> the information to be either local or remote, and the "game engine" won't >> care which. > > Always local, in my concept. Static info does not need to squeezed through the client/server interface. > Unless you want to make the client really dumb, of course. And slower. > Over-use of static info also makes supporting multiple threads more problematic; it increases the likelihood of race conditions and other difficult-to-debug issues. In general, most of the stuff that's currently static doesn't really _need_ to be static. > Erik. > >> So, my main point is that I'd like us to be conscious of which classes have >> awareness of lower-level information (like XML parsing) and ensure that >> knowledge is appropriately abstracted away from the game logic in the same >> way that we try to separate the game logic from the display/view logic. >> >> ---Brett. > ---Brett. |
|
From: Erik V. <eri...@xs...> - 2011-07-23 19:54:32
|
See below. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > >From what I understood from previous discussions is that Erik prefers > the fat client approach, where "clients" all have a full game back-end running > and only pass around actions between them. The server merely acts as a > message broker. No. As I explained, I take an intermediate position, let's call it the "medium" client. It knows about all the game objects, but nothing about the game state, except what info it receives from the server - mainly screen updates (to all clients) and allowed actions (to the client having the turn). > -----Original Message----- > From: brett lentz [mailto:bre...@gm...] > Because the clients should take the "authoritative" values for things given to > it by the server, not whatever arbitrary values somebody decides to put into > their own local XML files. Trusting the client to do the right thing on its own > makes exploitation far too easy. That's a good point, but if we go that way, it should occur only once, at the start of the game. > > Always local, in my concept. Static info does not need to squeezed through > the client/server interface. > > Unless you want to make the client really dumb, of course. And slower. > > > > Over-use of static info also makes supporting multiple threads more > problematic; it increases the likelihood of race conditions and other difficult- > to-debug issues. In general, most of the stuff that's currently static doesn't > really _need_ to be static. Apologies, I should *again* have said: "static (as opposed to dynamic)", i.e. never changing. I'm as much against "static (as opposed to instance)" as you are. > The response can be a variety of things, depending on how "thick" or "thin" > the client is. > > 1. It could be a simple "success/failure" response. > 2. It could be success/failure, with an updated client Wallet value. > 3. It could be success/failure, with the current state of every player's > holdings, the whole stock market, or even whole game. OK. To be more precise, I think we must distinguish three types of server->client info: 1. The response: what only the previously acting player client gets (success/failure, error message). 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI updates and other state-like info). 3. The prompt (or whatever): what only the next active player gets (i.e. the list of allowed actions). Or will we allow all players to enter any move, as someone suggested? Erik. |
|
From: brett l. <bre...@gm...> - 2011-07-23 20:07:29
|
On Sat, Jul 23, 2011 at 12:54 PM, Erik Vos <eri...@xs...> wrote: > See below. > > > -----Original Message----- >> From: brett lentz [mailto:bre...@gm...] > > > Because the clients should take the "authoritative" values for things > given to >> it by the server, not whatever arbitrary values somebody decides to put > into >> their own local XML files. Trusting the client to do the right thing on > its own >> makes exploitation far too easy. > > That's a good point, but if we go that way, it should occur only once, at > the start of the game. > Yup. I think we agree on the basic idea. >> > Always local, in my concept. Static info does not need to squeezed > through >> the client/server interface. >> > Unless you want to make the client really dumb, of course. And slower. >> > >> >> Over-use of static info also makes supporting multiple threads more >> problematic; it increases the likelihood of race conditions and other > difficult- >> to-debug issues. In general, most of the stuff that's currently static > doesn't >> really _need_ to be static. > > Apologies, I should *again* have said: "static (as opposed to dynamic)", > i.e. never changing. > I'm as much against "static (as opposed to instance)" as you are. > Sounds like we're in violent agreement. ;-) IMO, unchanging info should be marked "final". So, it'll be "static final" and guaranteed never to change after startup. The thing I want to begin reducing is the number of non-final static declarations. >> The response can be a variety of things, depending on how "thick" or > "thin" >> the client is. >> >> 1. It could be a simple "success/failure" response. >> 2. It could be success/failure, with an updated client Wallet value. >> 3. It could be success/failure, with the current state of every player's >> holdings, the whole stock market, or even whole game. > > OK. To be more precise, I think we must distinguish three types of > server->client info: > 1. The response: what only the previously acting player client gets > (success/failure, error message). > 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI > updates and other state-like info). > 3. The prompt (or whatever): what only the next active player gets (i.e. the > list of allowed actions). Or will we allow all players to enter any move, > as someone suggested? No. You'll note that I included authentication as a part of client-server communication in my previous description. We need to be able to identify that each player only makes _their_ moves (except for administrative overrides). However, that shouldn't preclude someone from logging in when it's not their own turn and just reviewing the current (read-only) state of the game; this is, after all, the exact same use case as playing a "live" network game where someone is disconnected for whatever reason and reconnects, then waits for their turn. > > Erik. > > ---Brett. |
|
From: Stefan F. <ste...@we...> - 2011-07-24 07:35:18
|
Brett & Erik, I like the discussion, however sometimes for me it is on a too general level. I think to decide on how to proceed with the coding it depends on what information will have to be exchanged between clients and server and what the server will actually do. And I have to admit that I currently have only vague ideas what the your actual proposals are. But to change my coding behavior you should provide a more concrete plan. I will try to give my idea shortly below. From my point of view the most realistic way is similar to what VASSAL does, which how I understand it, is mainly exchanging messages and each client has a complete model of the game. There are two candidates what to put into those messages: Either the actions (like in the save files) or moves (like for the undo/redo stack). Both allow to replay the whole game, moves also allow to move backward. Thus on each client a complete Rails game runs (with additional code that restricts only entering move for one player) and sends messages to all other clients. If this is actually done peer by peer, or one client serving as a message relay or a centralized sever in-between does not matter much. All other separations imo require much more efforts in both restructuring old code and writing new code. But most likely the chosen method will depend on the views of the person who volunteers to undertake that task. Stefan On Saturday, July 23, 2011 10:07:02 pm brett lentz wrote: > On Sat, Jul 23, 2011 at 12:54 PM, Erik Vos <eri...@xs...> wrote: > > See below. > > > > > -----Original Message----- > > > >> From: brett lentz [mailto:bre...@gm...] > > > > > Because the clients should take the "authoritative" values for things > > given to > > > >> it by the server, not whatever arbitrary values somebody decides to put > > > > into > > > >> their own local XML files. Trusting the client to do the right thing on > > > > its own > > > >> makes exploitation far too easy. > > > > That's a good point, but if we go that way, it should occur only once, at > > the start of the game. > > Yup. I think we agree on the basic idea. > > >> > Always local, in my concept. Static info does not need to squeezed > > > > through > > > >> the client/server interface. > >> > >> > Unless you want to make the client really dumb, of course. And > >> > slower. > >> > >> Over-use of static info also makes supporting multiple threads more > >> problematic; it increases the likelihood of race conditions and other > > > > difficult- > > > >> to-debug issues. In general, most of the stuff that's currently static > > > > doesn't > > > >> really _need_ to be static. > > > > Apologies, I should *again* have said: "static (as opposed to dynamic)", > > i.e. never changing. > > I'm as much against "static (as opposed to instance)" as you are. > > Sounds like we're in violent agreement. ;-) > > IMO, unchanging info should be marked "final". So, it'll be "static > final" and guaranteed never to change after startup. > > The thing I want to begin reducing is the number of non-final static > declarations. > > >> The response can be a variety of things, depending on how "thick" or > > > > "thin" > > > >> the client is. > >> > >> 1. It could be a simple "success/failure" response. > >> 2. It could be success/failure, with an updated client Wallet value. > >> 3. It could be success/failure, with the current state of every player's > >> holdings, the whole stock market, or even whole game. > > > > OK. To be more precise, I think we must distinguish three types of > > server->client info: > > 1. The response: what only the previously acting player client gets > > (success/failure, error message). > > 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI > > updates and other state-like info). > > 3. The prompt (or whatever): what only the next active player gets (i.e. > > the list of allowed actions). Or will we allow all players to enter any > > move, as someone suggested? > > No. You'll note that I included authentication as a part of > client-server communication in my previous description. We need to be > able to identify that each player only makes _their_ moves (except for > administrative overrides). > > However, that shouldn't preclude someone from logging in when it's not > their own turn and just reviewing the current (read-only) state of the > game; this is, after all, the exact same use case as playing a "live" > network game where someone is disconnected for whatever reason and > reconnects, then waits for their turn. > > > Erik. > > ---Brett. > > --------------------------------------------------------------------------- > --- Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2011-07-24 12:09:58
|
See below. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Sunday, July 24, 2011 9:38 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8) > > Brett & Erik, > I like the discussion, however sometimes for me it is on a too general level. > > I think to decide on how to proceed with the coding it depends on what > information will have to be exchanged between clients and server and what > the server will actually do. And I have to admit that I currently have only > vague ideas what the your actual proposals are. But to change my coding > behavior you should provide a more concrete plan. I will try to give my idea > shortly below. > > >From my point of view the most realistic way is similar to what VASSAL > >does, > which how I understand it, is mainly exchanging messages and each client has > a complete model of the game. > There are two candidates what to put into those messages: Either the actions > (like in the save files) or moves (like for the undo/redo stack). Both allow to > replay the whole game, moves also allow to move backward. Thus on each > client a complete Rails game runs (with additional code that restricts only > entering move for one player) and sends messages to all other clients. If this > is actually done peer by peer, or one client serving as a message relay or a > centralized sever in-between does not matter much. > > All other separations imo require much more efforts in both restructuring old > code and writing new code. Exactly. In a way, the AutoSave/Load feature already brings us pretty close to your action-exchange model, except that it's now exchanging complete action stacks (saved files) instead of single actions. My own approach to accomplish a real client/server split would be to work bottom-up. First I would refactor all GUI<->engine interchanges to objects that are passed between the GameManager and the GameUIManager. We already do this with the action objects, and implementing the action object exchange was in fact my first step in this approach. However, that work is dormant now (other wishes and needs have prevailed). If it ever would be completed, the main thing that remains to be done is to serialize these objects and build a comms interface in between these managers to transfer the serialized objects (and yes, we have initialization issues too). Brett prefers and has started to work on a top-down approach. I don't know where he currently is on that path, and I hope Brett doesn't mind that I'm a bit sceptical about his approach, because I believe that he will have to deal with the same low-level issues that I have been working on, and that those can better be addressed first. But equally well, it could turn out to be a nice fit when we meet each other somewhere in the middle... > But most likely the chosen method will depend on the views of the person > who volunteers to undertake that task. That's real life, indeed. Erik. > Stefan |
|
From: brett l. <bre...@gm...> - 2011-07-24 16:11:23
|
On Sun, Jul 24, 2011 at 5:10 AM, Erik Vos <eri...@xs...> wrote: > See below. > >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] >> Sent: Sunday, July 24, 2011 9:38 AM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8) >> >> Brett & Erik, >> I like the discussion, however sometimes for me it is on a too general > level. >> >> I think to decide on how to proceed with the coding it depends on what >> information will have to be exchanged between clients and server and what >> the server will actually do. And I have to admit that I currently have > only >> vague ideas what the your actual proposals are. But to change my coding >> behavior you should provide a more concrete plan. I will try to give my > idea >> shortly below. >> >> >From my point of view the most realistic way is similar to what VASSAL >> >does, >> which how I understand it, is mainly exchanging messages and each client > has >> a complete model of the game. >> There are two candidates what to put into those messages: Either the > actions >> (like in the save files) or moves (like for the undo/redo stack). Both > allow to >> replay the whole game, moves also allow to move backward. Thus on each >> client a complete Rails game runs (with additional code that restricts > only >> entering move for one player) and sends messages to all other clients. If > this >> is actually done peer by peer, or one client serving as a message relay or > a >> centralized sever in-between does not matter much. >> >> All other separations imo require much more efforts in both restructuring > old >> code and writing new code. > > Exactly. In a way, the AutoSave/Load feature already brings us pretty close > to your action-exchange model, except that it's now exchanging complete > action stacks (saved files) instead of single actions. > > My own approach to accomplish a real client/server split would be to work > bottom-up. First I would refactor all GUI<->engine interchanges to objects > that are passed between the GameManager and the GameUIManager. We already > do this with the action objects, and implementing the action object exchange > was in fact my first step in this approach. However, that work is dormant > now (other wishes and needs have prevailed). If it ever would be completed, > the main thing that remains to be done is to serialize these objects and > build a comms interface in between these managers to transfer the serialized > objects (and yes, we have initialization issues too). > > Brett prefers and has started to work on a top-down approach. > I don't know where he currently is on that path, and I hope Brett doesn't > mind that I'm a bit sceptical about his approach, because I believe that he > will have to deal with the same low-level issues that I have been working > on, and that those can better be addressed first. > But equally well, it could turn out to be a nice fit when we meet each other > somewhere in the middle... > >> But most likely the chosen method will depend on the views of the person >> who volunteers to undertake that task. > > That's real life, indeed. > > Erik. > >> Stefan > I don't think the approaches necessarily conflict. With Erik's approach, we'll get one method of network play (probably earlier than with my approach) and all of that same work is necessary for what I want to do. None of it is lost work. For me, I'd like to *also* have the ability of the server-side to hold the state of the game to allow for asynchronous play. This would allow a wider range of play possibilities. Historically, I think Erik and I have always preferred to work on differing sections of the code. ;-) ---Brett. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X