Menu
▾
▴
Re: [Colossus-developers] The new net.sf.colossus.Player class, global lookup
|
From: <cle...@ns...> - 2008-01-12 11:50:33
|
I've been thinking instead prefixing it with C or S or ... similar like interfaces are prefixed with I. Appending the Server/CLient makes them so long. Besides, PlayerServer might omn first read confuse:=20 It reads as a server that handles players. (like a ElefantGun is a gun that shoots elefants). -Clemens >-----Original Message----- >From: col...@li...=20 >[mailto:col...@li...] On=20 >Behalf Of ext Peter Becker >Sent: 12 January, 2008 11:59 >To: col...@li... >Subject: Re: [Colossus-developers] The new=20 >net.sf.colossus.Player class,global lookup > >I made up my mind. Currently Player doesn't hold anything but=20 >the name, and as long as our requirements grow it is just one=20 >layer of too much indirection.=20 >As the saying goes: > >"There is no problem in Software Engineering that you can't=20 >solve with another layer of indirection -- except for having=20 >too many layers of indirection." > >I've removed the Player class in my copy, I'm currently=20 >testing and then I'll commit. Adding such a class again won't=20 >be hard at all, and it should work quite well without at least for now. > >How do you guys feel about adding a "..Client" and "..Server"=20 >suffix to the subclasses. Not very elegant, but very explicit=20 >and hopefully I'll get the subclasses away anyway. > > Peter > > > >On Sat, 12 Jan 2008 15:48:45 Peter Becker wrote: >> Hmmm.. not really, but it has a better feel to it that using=20 >"PlayerState" >> for the player in the game. The latter is technically=20 >somehow correct=20 >> (since it really doesn't model the player as such, but part of the=20 >> game state), but it just won't start feel right. >> >> "Gamer" sounds a bit odd as a classname to me, but that=20 >class would be=20 >> much less visible, so I suspect it might be at least an improvement. >> >> I kind of like the "Player" as the abstract entity -- you'd=20 >talk about=20 >> a "basketball player" even if someone is not currently engaged in a=20 >> game, too. But "PlayerState" just doesn't do it for me.=20 >Maybe I should=20 >> go back to the "PlayerInfo" from the client, although the "...Info"=20 >> seemed to be just part of a general pattern of=20 >distinguishing server and client classes. >> >> Just had a little inspiration: how does "Participant" sound? I'd=20 >> probably stick with the "player" in method names, though, i.e.: >> >> public Participant getActivePlayer(); >> >> in the Game class (currently still in Client). You can then call >> getPlayer() on that to get the actual player. >> >> OTOH I sometimes wonder if we really need that Player class outside=20 >> the game. One thing it does is giving identity that is not a name=20 >> (which changes), but the current PlayerState can do that. It could=20 >> store pre-game information such as the network address, but=20 >that could=20 >> be in an object "PlayerInfo" (the mathematician in me would like to=20 >> call it "ProtoPlayer", but that would be too much of an=20 >insider-joke :-) ). >> >> I feel so indecisive about this. :-( >> >> Peter >> >> On Sat, 12 Jan 2008 15:15:41 Edward Dranathi wrote: >> > We have a term here called a Gamer. A gamer is one who=20 >likes to play=20 >> > Games of all kinds. One is a Gamer even when not actively=20 >playing a=20 >> > game. Therefore, the instance of the Gamer will be reused across=20 >> > multiple games while the Gamer only is a Player for the current=20 >> > game. >> > >> > see: http://en.wikipedia.org/wiki/Gamer >> > >> > How do you like that term? >> > >> > --- Peter Becker <pe...@pe...> wrote: >> > > On Sat, 12 Jan 2008 08:32:26 Clemens Katzer wrote: >> > > > > It was never meant to stay that way -- the >> > > >> > > Client is supposed to get the >> > > >> > > > > Players in the game, then create his own >> > > >> > > PlayerInfo for each of them. >> > > >> > > > Ah, ok. I thought each client gets has the player, >> > > >> > > and gets >> > > >> > > > the playerState from there. >> > > > >> > > > Ah, no. Other way round. At least right now from >> > > >> > > PlayerState >> > > >> > > > one can get the Player. Thats probably ok. >> > > >> > > Think of Players as people around the table, potentially playing=20 >> > > different games at once. PlayerState is what makes their=20 >role in a=20 >> > > single game. >> > > >> > > The idea is that a Game is constructed using 1 Variant and N=20 >> > > Player instances. >> > > The Game class is then to create N PlayerStates and=20 >provide access=20 >> > > to these. >> > > Players are shared by the Clients, PlayerStates are not. >> > > >> > > > > Using >> > > > > the static lookup on Player is just a temporary >> > > >> > > fix since a lot of the >> > > >> > > > > old code used static calls everywhere and they >> > > >> > > can't be replaced with >> > > >> > > > > proper object graph navigation until that graph >> > > >> > > has been established. >> > > >> > > > > Also note that we are the Player objects, which >> > > >> > > transcend the games. The >> > > >> > > > > Player class currently models nothign but the >> > > >> > > name, but is intended to >> > > >> > > > > store >> > > > > other things like type (human, AI type) and >> > > >> > > location (IP address and >> > > >> > > > > similar >> > > > > data). It does not store game-specific >> > > >> > > information such as the color of >> > > >> > > > > the >> > > > > player, the legions owned or if the player is >> > > >> > > dead or alive. As such it >> > > >> > > > > should be much safer to share and even if some >> > > >> > > of these should leak I >> > > >> > > > > wouldn't be too worried -- they are small and >> > > >> > > there are only N of them >> > > >> > > > > created per game with N being the number of >> > > >> > > players in the game. That is >> > > >> > > > > unless player names get reused, in which case >> > > >> > > the Player instances will >> > > >> > > > > be reused, too. And it is meant as a temporary >> > > >> > > fix. >> > > >> > > > ok. >> > > > >> > > > > If you are still concerned we could either put >> > > >> > > that cache as instance >> > > >> > > > > onto the >> > > > > Client and somewhere in the server or we put it >> > > >> > > into a ThreadLocal: >> > >> > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html >> > >> > > > > That would mean no sharing across threads and >> > > >> > > automatic garbage >> > > >> > > > > collection. >> > > > >> > > > No, I don't think that is necessary. >> > > > >> > > > I just mixed Player with Player :) Overloading same=20 >name with a=20 >> > > > different thing is a >> > > >> > > good source >> > > >> > > > for confusion... >> > > >> > > Yes. I'm not happy with my current naming scheme either but I=20 >> > > couldn't come up with a better one yet. Happy to hear proposals. >> > > >> > > At least I'll try to track the instances where some method like=20 >> > > getPlayer() actually returns a PlayerState since that=20 >adds to the=20 >> > > confusion. >> > > >> > > Peter >> > > >> > > > -Clemens >> > > > >> > > > > Peter >> > > > > >> > > > > On Sat, 12 Jan 2008 07:06:28 Clemens Katzer >> > > >> > > wrote: >> > > > > > > I have some concerns with the global/static >> > > >> > > getPlayerByName() >> > > >> > > > > > > lookup in the new Player class. >> > > > > > > >> > > > > > > Earlier each client had it's own PlayerInfo >> > > >> > > object; they >> > > >> > > > > > > were created, modified and maintained only >> > > >> > > by that client. >> > > >> > > > > > > Now, all clients (in same JVM) will access >> > > >> > > to the same Player >> > > >> > > > > > > object (if I see it right). >> > > > > > > >> > > > > > > >> > > > > > > That's just an artificial example, but there >> > > >> > > might be others. >> > > >> > > > > > For example the "set player dead", or reaching the=20 >400 limit=20 >> > > > > > etc. >> > > > > > >> > > > > > >> > > > > > As practical approach to that, to be on safe >> > > >> > > side, I would >> > > >> > > > > > suggest that every Client (and perhaps >> > > >> > > additionally the server) >> > > >> > > > > > has a PlayerCache object. >> > > > > > That's even nice in that sense, that on >> > > >> > > disposal the client >> > > >> > > > > > gets rid of that cache and all is fine. >> > > > > > >> > > > > > Otherwise, it's pretty tricky to decide when >> > > >> > > you can delete/clean >> > > >> > > > > > the global cache, e.g. if you want to start a >> > > >> > > new game. >> > > >> > > > > > (you can't delete all entries before you are >> > > >> > > sure no client will >> > > >> > > > > > access it anymore, but must delete it before >> > > >> > > the new ones >> > > >> > > > > > are filled in - there might be one with same >> > > >> > > name). >> > > >> > > > > > Nowadays that should not be too difficult, >> > > >> > > because since my changes >> > > >> > > > > > all stuff from old game is gone and all client >> > > >> > > threads have ceased. >> > > >> > > > > > Before that, I did in fact run into >> > > >> > > interferences between old >> > > >> > > > > > and new game if there were players with same >> > > >> > > name. >> > > >> > > > > > -Clemens >> > >> >=20 >-------------------------------------------------------------------- >> > ----- >> > >> > > Check out the new SourceForge.net Marketplace. >> > > It's the best place to buy or sell services for just about=20 >> > > anything Open Source. >> > >> >=20 >>=20 >>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/mark >> >etpl >> >ac e >> > >> > > _______________________________________________ >> > > Colossus-developers mailing list >> > > Col...@li... >> > >> > https://lists.sourceforge.net/lists/listinfo/colossus-developers >> > >> > >> > >> > >> > >> >=20 >>=20 >>_____________________________________________________________________ >> >____ __ _________ Looking for last minute shopping deals? >> > Find them fast with Yahoo! Search. >> >=20 >>=20 >>http://tools.search.yahoo.com/newsearch/category.php?category=3Dshoppin= >> >g >> > >> >=20 >>=20 >>--------------------------------------------------------------------- >> >---- Check out the new SourceForge.net Marketplace. >> > It's the best place to buy or sell services for just=20 >about anything=20 >> >Open Source. >> >=20 >>=20 >>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/mark >> >etpl ac e _______________________________________________ >> > Colossus-developers mailing list >> > Col...@li... >> > https://lists.sourceforge.net/lists/listinfo/colossus-developers >> >>=20 >>-------------------------------------------------------------- >--------- >>-- Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for just about anything=20 >>Open Source. >>=20 >>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.n >et/market >>plac e _______________________________________________ >> Colossus-developers mailing list >> Col...@li... >> https://lists.sourceforge.net/lists/listinfo/colossus-developers > > > >--------------------------------------------------------------- >---------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for just about=20 >anything Open Source. >http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.ne >t/marketplace >_______________________________________________ >Colossus-developers mailing list >Col...@li... >https://lists.sourceforge.net/lists/listinfo/colossus-developers > > |
