Thread: RE: [Glchess-devel] ICS support on glChess
Brought to you by:
bob27
Menu
▾
▴
glchess-devel
|
From: Michael G. <mdg...@cs...> - 2005-01-19 14:43:56
|
Originally I was planning to modify xboard and rip some code from = glchess. After talking with tim mann (xboard maintainer) I decided to modify = glchess and steal code from xboard. Anyway, I thought I'd bring some ideas from there, since you're refactoring anyway. - One thing they're currently stuck on now is the ability to have = multiple games going simultaneously. I guess this is necessary for popular chess variants like bughouse. I haven't looked at how you've refactored it in = the branch (I was able to build it, but I didn't look at the code yet), but = in the old code, you had game-specific and configuration-specific stuff in = the Game struct. To avoid this problem in the future, it might make sense = to split them into maybe a Config struct and a Game struct (there would = only be one Config, possibly many Games). - One thing I like better about their interface is that instead of the = move list down the right, they have back to beginning/back/forward/forward to = end buttons, and they would animate the moves. I think this wouldn't be = hard to implement, and makes it much easier to visualize what has happened for non-hardcore chess players like me for whom the algebraic notation = doesn't mean much. We might combine the two, letting you double click on a move = to animate the board to that point, but I'm not as fond of that option. - I've never developed with the autotools, so I'm not sure about = automake, but I do like the standard ./configure. In particular, I usually = install packages in their own --prefix. So if getting rid of automake means = getting rid of that, I say we keep it. Also, it doesn't look like it would be = too hard to put the chess program detection into some AM_PATH_GNUCHESS(...) = and AM_PATH_CRAFTY(...) macros to add --with-gnuchess=3D... and = --with-crafty=3D..., and get rid of a lot of the "input path to crafty" dialogs. We could = also then compile in the location easily, and get rid of the "input path to textures" dialogs. I don't think users are likely to make custom = textures. If I'm thinking of autoconf or something instead of automake, please = forgive my ignorance of autotools ;-) - I've not tried real hard, but I think setting up an ICS server locally = is a bit of a pain (I think the intention is to have few servers, so that = each has many players). So I think we should just add ICS as a separate game = option. I'm wondering if the current interface will work for sitting on ICS and waiting for someone to challenge you, but I think it'll do for now. I = don't know enough about it yet to suggest anything better. Anyway, just wanted to throw these ideas out there. I'll get to work on = ICS now. --Mike -----Original Message----- From: glc...@li... on behalf of Robert = Ancell Sent: Wed 1/19/2005 4:49 AM To: glc...@li... Subject: [Glchess-devel] ICS support on glChess =20 Hi Mike & all, Sorry but your first message got stuck in the filter... I've sent it out now. This list gets spammed to death so it has to be member only... Yes please start as soon as you like! ICS support would be great - I was very keen to look into it but doubted I would have the time. I hope you've been able to compile the branch version of the code... The internal APIs are still very flexible but we should be able to work on seperate modules without major problems if we need to merge later. I've implemented a generic player API. You can see examples of players in ai.c, ai_cecp.c and ui.c (human players). The basics are that each player waits for a ready_to_move() callback and then makes a move. The UI (in this case ui_new_game.c) then just picks two players and adds them to the game. I suspect in the future we will need more callbacks to make a stronger API and reduce the need for the players to access the other modules. Mike, so please if you can implement ICS using this API. Modify the glchess.glade file as necessary and . Note the network tab in the new game dialog is planned to be a super-simple LAN protocol. I'm not sure if ICS will superceed this - if it is easy to start a local ICS server then feel free to implement that too. I will be on holiday for the next week (the last holiday was rained out so I came home early :( ). So there'll be no coding from me... I'll check this list though so feel free to ask questions. There is no problem getting CVS access, just send your sourceforge.net login and I'll set it up. Happy Coding, --Robert > Hi, >=20 > After sending that last note, I read the archives, and realized that = Robert is already doing > some of the work that I had proposed. I'd obviously like to help out = with the effort. I'm going=20 > to have much more time this week to work on it than I will for a = while, so I'd like to know if > there's some part you want me to get started with? > > One of my goals that doesn't seem to be one of yours right now is ICS support, so I'll start > looking into that to avoid duplicating effort with your work. --Mike ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Glchess-devel mailing list Glc...@li... https://lists.sourceforge.net/lists/listinfo/glchess-devel |
|
From: Michael G. <mdg...@cs...> - 2005-01-19 14:51:29
|
One more thing: Is our dependence on gnome going to hurt portability, do you know? I wouldn't usually worry about it, but I think people will want to play = glChess with their win32 friends, especially if the client/server protocol is = glchess specific (this is actually my reason for wanting to add ICS support - so = I can play with my win32 friends). If we're just using gnome for gconf, = we might want to try to encapsulate that to make future porting efforts smoother. --Mike -----Original Message----- From: glc...@li... on behalf of Robert = Ancell Sent: Wed 1/19/2005 4:49 AM To: glc...@li... Subject: [Glchess-devel] ICS support on glChess =20 Hi Mike & all, Sorry but your first message got stuck in the filter... I've sent it out now. This list gets spammed to death so it has to be member only... Yes please start as soon as you like! ICS support would be great - I was very keen to look into it but doubted I would have the time. I hope you've been able to compile the branch version of the code... The internal APIs are still very flexible but we should be able to work on seperate modules without major problems if we need to merge later. I've implemented a generic player API. You can see examples of players in ai.c, ai_cecp.c and ui.c (human players). The basics are that each player waits for a ready_to_move() callback and then makes a move. The UI (in this case ui_new_game.c) then just picks two players and adds them to the game. I suspect in the future we will need more callbacks to make a stronger API and reduce the need for the players to access the other modules. Mike, so please if you can implement ICS using this API. Modify the glchess.glade file as necessary and . Note the network tab in the new game dialog is planned to be a super-simple LAN protocol. I'm not sure if ICS will superceed this - if it is easy to start a local ICS server then feel free to implement that too. I will be on holiday for the next week (the last holiday was rained out so I came home early :( ). So there'll be no coding from me... I'll check this list though so feel free to ask questions. There is no problem getting CVS access, just send your sourceforge.net login and I'll set it up. Happy Coding, --Robert > Hi, >=20 > After sending that last note, I read the archives, and realized that = Robert is already doing > some of the work that I had proposed. I'd obviously like to help out = with the effort. I'm going=20 > to have much more time this week to work on it than I will for a = while, so I'd like to know if > there's some part you want me to get started with? > > One of my goals that doesn't seem to be one of yours right now is ICS support, so I'll start > looking into that to avoid duplicating effort with your work. --Mike ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Glchess-devel mailing list Glc...@li... https://lists.sourceforge.net/lists/listinfo/glchess-devel |
|
From: Robert A. <rob...@gm...> - 2005-01-20 03:13:56
|
With the new design I don't think it will be a problem. In the refactor I have: - All the UI code is in the files ui*.c - as long as these meet the current API (hopefully nail it down later) then you could write a win32, glut, text interface. - If you write a new UI you need to make the human players again - these could be 90% copied but are UI specific I think. Note the scene module has a function for choosing board squares from pixel locations. - So the core of glChess provides - The core rules/game - AI players - Network players - A scene renderer (openGL) and feedback (selection of squares) The idea of the glChess specific network protocol is a) faster to implement than ICS (from my perspective) b) Doesn't require internet access c) Can make it super-simple to use On Wed, 19 Jan 2005 09:47:42 -0500, Michael George <mdg...@cs...> wrote: > One more thing: > > Is our dependence on gnome going to hurt portability, do you know? I > wouldn't usually worry about it, but I think people will want to play glChess > with their win32 friends, especially if the client/server protocol is glchess > specific (this is actually my reason for wanting to add ICS support - so I > can play with my win32 friends). If we're just using gnome for gconf, we > might want to try to encapsulate that to make future porting efforts > smoother. > > --Mike > > > -----Original Message----- > From: glc...@li... on behalf of Robert Ancell > Sent: Wed 1/19/2005 4:49 AM > To: glc...@li... > Subject: [Glchess-devel] ICS support on glChess > > Hi Mike & all, > > Sorry but your first message got stuck in the filter... I've sent it > out now. This list gets spammed to death so it has to be member > only... > > Yes please start as soon as you like! ICS support would be great - I > was very keen to look into it but doubted I would have the time. > > I hope you've been able to compile the branch version of the code... > The internal APIs are still very flexible but we should be able to > work on seperate modules without major problems if we need to merge > later. > > I've implemented a generic player API. You can see examples of players > in ai.c, ai_cecp.c and ui.c (human players). The basics are that each > player waits for a ready_to_move() callback and then makes a move. The > UI (in this case ui_new_game.c) then just picks two players and adds > them to the game. I suspect in the future we will need more callbacks > to make a stronger API and reduce the need for the players to access > the other modules. > > Mike, so please if you can implement ICS using this API. Modify the > glchess.glade file as necessary and . Note the network tab in the new > game dialog is planned to be a super-simple LAN protocol. I'm not sure > if ICS will superceed this - if it is easy to start a local ICS server > then feel free to implement that too. > > I will be on holiday for the next week (the last holiday was rained > out so I came home early :( ). So there'll be no coding from me... > I'll check this list though so feel free to ask questions. > > There is no problem getting CVS access, just send your sourceforge.net > login and I'll set it up. > > Happy Coding, > --Robert > > > Hi, > > > > After sending that last note, I read the archives, and realized that Robert > is already doing > > some of the work that I had proposed. I'd obviously like to help out with > the effort. I'm going > > to have much more time this week to work on it than I will for a while, so > I'd like to know if > > there's some part you want me to get started with? > > > > One of my goals that doesn't seem to be one of yours right now is ICS > support, so I'll start > > looking into that to avoid duplicating effort with your work. > > --Mike > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Glchess-devel mailing list > Glc...@li... > https://lists.sourceforge.net/lists/listinfo/glchess-devel > > > |
|
From: Robert A. <rob...@gm...> - 2005-01-20 03:24:40
|
The game is made up of two modules: a) the board module which checks the moves are valid and updates the scene. b) the game module which handles player objects and the signalling to them Currently they are not thread-safe. (I forget the CS term - they're singletons or somthing). I was thinking of putting their state into a structure (i.e. object) - then there would be no limit on the number of parallel games at once (except we would need multiple scenes as well). Not a big problem I think. No idea about "bughouse", btw I don't even play chess... Personally I don't rate ./configure. The only dependancies should be std C and the libs glChess requires. Since all the libs use pkg-config we can easily get the Makefile to check they're installed before compiling. I think the autotools just add unnecessary complexity - the only advantage I see is they help portability somehow? Explain the prefix thing? I don't think we should have compile time options for the AIs. glChess should just know about both and disable UI controls if it can't execute "crafty" or "gnuchess". These could be configurable in gconf but not have a UI control as they'll probably never need changing. (Wait for the bug report that says otherwise :)). For ICS the UI is how we write it; we just need a dialog "waiting for challenge" and only start the game after it's been accepted. --Robert On Wed, 19 Jan 2005 09:43:41 -0500, Michael George <mdg...@cs...> wrote: > > > > Originally I was planning to modify xboard and rip some code from glchess. > After talking with tim mann (xboard maintainer) I decided to modify glchess > and steal code from xboard. Anyway, I thought I'd bring some ideas from > there, since you're refactoring anyway. > > - One thing they're currently stuck on now is the ability to have multiple > games going simultaneously. I guess this is necessary for popular chess > variants like bughouse. I haven't looked at how you've refactored it in the > branch (I was able to build it, but I didn't look at the code yet), but in > the old code, you had game-specific and configuration-specific stuff in the > Game struct. To avoid this problem in the future, it might make sense to > split them into maybe a Config struct and a Game struct (there would only be > one Config, possibly many Games). > > - One thing I like better about their interface is that instead of the move > list down the right, they have back to beginning/back/forward/forward to end > buttons, and they would animate the moves. I think this wouldn't be hard to > implement, and makes it much easier to visualize what has happened for > non-hardcore chess players like me for whom the algebraic notation doesn't > mean much. We might combine the two, letting you double click on a move to > animate the board to that point, but I'm not as fond of that option. > > - I've never developed with the autotools, so I'm not sure about automake, > but I do like the standard ./configure. In particular, I usually install > packages in their own --prefix. So if getting rid of automake means getting > rid of that, I say we keep it. Also, it doesn't look like it would be too > hard to put the chess program detection into some AM_PATH_GNUCHESS(...) and > AM_PATH_CRAFTY(...) macros to add --with-gnuchess=... and --with-crafty=..., > and get rid of a lot of the "input path to crafty" dialogs. We could also > then compile in the location easily, and get rid of the "input path to > textures" dialogs. I don't think users are likely to make custom textures. > If I'm thinking of autoconf or something instead of automake, please forgive > my ignorance of autotools ;-) > > - I've not tried real hard, but I think setting up an ICS server locally is > a bit of a pain (I think the intention is to have few servers, so that each > has many players). So I think we should just add ICS as a separate game > option. I'm wondering if the current interface will work for sitting on ICS > and waiting for someone to challenge you, but I think it'll do for now. I > don't know enough about it yet to suggest anything better. > > Anyway, just wanted to throw these ideas out there. I'll get to work on ICS > now. > > --Mike > > -----Original Message----- > From: glc...@li... on behalf of Robert Ancell > Sent: Wed 1/19/2005 4:49 AM > To: glc...@li... > Subject: [Glchess-devel] ICS support on glChess > > Hi Mike & all, > > Sorry but your first message got stuck in the filter... I've sent it > out now. This list gets spammed to death so it has to be member > only... > > Yes please start as soon as you like! ICS support would be great - I > was very keen to look into it but doubted I would have the time. > > I hope you've been able to compile the branch version of the code... > The internal APIs are still very flexible but we should be able to > work on seperate modules without major problems if we need to merge > later. > > I've implemented a generic player API. You can see examples of players > in ai.c, ai_cecp.c and ui.c (human players). The basics are that each > player waits for a ready_to_move() callback and then makes a move. The > UI (in this case ui_new_game.c) then just picks two players and adds > them to the game. I suspect in the future we will need more callbacks > to make a stronger API and reduce the need for the players to access > the other modules. > > Mike, so please if you can implement ICS using this API. Modify the > glchess.glade file as necessary and . Note the network tab in the new > game dialog is planned to be a super-simple LAN protocol. I'm not sure > if ICS will superceed this - if it is easy to start a local ICS server > then feel free to implement that too. > > I will be on holiday for the next week (the last holiday was rained > out so I came home early :( ). So there'll be no coding from me... > I'll check this list though so feel free to ask questions. > > There is no problem getting CVS access, just send your sourceforge.net > login and I'll set it up. > > Happy Coding, > --Robert > > > Hi, > > > > After sending that last note, I read the archives, and realized that > Robert is already doing > > some of the work that I had proposed. I'd obviously like to help out with > the effort. I'm going > > to have much more time this week to work on it than I will for a while, so > I'd like to know if > > there's some part you want me to get started with? > > > > One of my goals that doesn't seem to be one of yours right now is ICS > support, so I'll start > > looking into that to avoid duplicating effort with your work. > > --Mike > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Glchess-devel mailing list > Glc...@li... > https://lists.sourceforge.net/lists/listinfo/glchess-devel > > > |
×
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