Estimation
During the 4th semester, we had to get our hands dirty with Java — a little bit more than some desired. In short we had to create a very basic (single threaded) multiplayer game. Code-wise this means there was very little to learn when it came to the engine, plus we had to build a GUI interface so that, to me, was the main challenge. Anyways, this semester (5th semester) we had to get our hands dirty with even more Java, this time with multithreading and Java networking. This course was actually far more interesting than the game course simply because we were introduced to many very interesting new concepts — that I thought we should have covered during the game course.
Anyway, so now that I have all the tools I need to create an application we might actually like to use, I started working on Estimation! (Yes, during my finals.. couldn’t wait any longer :\)
For now I’m working on a terminal version where playing will be done through commands, and reflected through printing the current status on each players console. The client is almost finished (all the client does is send commands, so yeah, that was pretty easy) and the server threads accept connections, and creating/joining rooms, and dealing of cards. There’s a lot missing but that’s only a couple of days work so, yeah.
If anyone’s interested in joining please let me know in the comments. It’s hosted on dropbox Google Code so sharing files shouldn’t be a hassle. Anyone with basic multithreading and networking knowledge (well, and of course Java) can tag along. Well, and umm.. you kinda need to know how to play estimation as well. 
(Or at least willing to learn the basics, you don’t really have to know how to play the game really well unless you’re planning on implementing an AI robot.) If you want to work solely on the GUI, you can also work on that. If you don’t know/want to do any networking/multithreading, you can still work on the basic engine that validates/makes the changes. All and any type of contributions are welcome!
Update (Jan 7, 06:40): The project has been submitted on Google Code, here: http://goo.gl/rach
Update (Jan 7, 12:17): For those interested in joining, please use a Google-enabled account in your comment below so I could add you to the contributors list on the project.
Update (Jan 13, 11:57): For those who haven’t used SVN before please watch this playlist: http://goo.gl/8N5O (you need Eclipse as well, you can run SVN on any IDE but the screencast shows it using Eclipse) When prompted for a SVN url use: https://estimation-game.googlecode.com/svn/trunk/
Category: Personal | Tags: discussion, estimation, java, projects 20 comments »
January 6th, 2010 at 7:16 pm
Nice, update us with screenshots
January 6th, 2010 at 7:37 pm
Hmm, nice
I do have a small suggestion is to drop the dropbox idea and start using source control if you plan on adding contributing developers to your code base.
I’d go for git if I were you, and seems you are already willing to allow people in so wouldn’t mind opening the source so github.com would pretty much be your perfect choice in such case.
Now as for the project it self I’d like to join in if that’s possible.
January 6th, 2010 at 8:07 pm
COOL !
So are you planning to make it work online or just LAN ?
BTW I can port it to C# and XNA for you after you finish the main engine, and maybe make 3D graphics and animations for it
I can also help you make it not just Estimation, but all other variations (Hearts, Spades, Tarneeb) of it in the same game.
January 6th, 2010 at 8:56 pm
Great!
@Hady I didn’t really have that insight of sharing, but now that you’ve mentioned it I submitted my code via Google Code, usinv SVN. Much easier to set up especially that I already have the plugin for Eclipse so.. there! =D
Link: https://code.google.com/p/estimation-game/
@Hassan Well it should work same way our Networks project did. The only problem with working with the internet is that our IPs are dynamic so I’m not really sure how that will be taken care of.. but for now I think most the testing will be done through localhost’ing so that shouldn’t be a problem
January 6th, 2010 at 10:14 pm
Ah, peace which ever you like
I’ll co now and see what I can do.
there are quite a lot of types of testing as you are aware so pick one that you feel right at home and tell me 
Btw, tests and documentation? you’ll go for Javadocs I suppose which what I’ll personally go with.
But what about testing?
As for Hassan’s suggestion if that’s the case it’ll be a lot better if we change our model to thin client thick server and since it’ll be card games we’ll be quite fine with a rule engine on the server side.
And in that case client will only be a frontend (This later introduces better modularity options such as wrapping things in an api and offer it as a service for developers willing to do their own clients using our own multiplayer server for card games)
Plus the fact porting to different languages will be a lot easier for the client side, and for a new game it will require the introduction of new game rules in Java for the server side to use (P.S we’ll be utilizing tons of design patterns for such architecture
so it’ll be major fun 
)
I’ll send you a firecamp invitation
so we can better communicate, and most probably I’ll setup redmine(or anything you’d like, maybe trac) on my server so we can get some nice project management running, features, bugs, timeline…etc. 
We aren’t doing this in the exams time are we?!
been trying to convince myself with that but no luck 
hahah (I am not in exams, am not in exams, am not in exams!) but who cares 
January 6th, 2010 at 11:51 pm
ma testno b3d final el Theory we ne3ml kol haga
January 7th, 2010 at 6:26 am
@Hady: lol, kol da w ba3d elfinals!
I just hope I can keep up ba3d elfinals! 
Okay, as to the engine I think it was going to be that way — based on a protocol, so technically speaking whether the client is coded in Java or God-knows-what it would still work seamlessly because the basic model is to send commands and the server will respond accordingly. Once we have the server set up we can mess around with the client all we want!
Regarding testing and documentation, no clue of any testing types so you’ll have to fill the testers on that when it’s time for that
Documentation yeah, Javadocs style seems good enough yes?
But yeah, I think it’s best to keep the work for after the finals, but keep the spirit up the whole time until then!
January 7th, 2010 at 12:24 pm
Oh, and you guys please use a google-enabled email account in your comments so I could add you to the project. (If you’re not already using Gmail, you can sign up for a google account using an already existing email here)
January 7th, 2010 at 3:56 pm
Ok, here’s a comment with my Gmail account.
@Hady Enta shaklak developer gamed awy awy awy
It would have took me a lot of time to come up with this smart “thin client – thick server” idea !
January 8th, 2010 at 3:36 pm
Hady you should set up a fan page
January 8th, 2010 at 4:56 pm
http://lifehacker.com/5442682/collabtive-gives-you-local-control-over-project-management
we could use that instead of firecamp.
January 13th, 2010 at 11:36 am
I think if we’re going to use a collaboration tool we can use collabtive, seems like an easy to use solution.
Although I don’t really think we’ll need that, I don’t think anyone’s going to like being “tied” to the project especially that we’re working on it for fun. If you can work on something do it, save it, and anyone else will take over.
January 13th, 2010 at 11:44 am
gr8….ana dayes m3ak fel 7war da 3moman !
January 13th, 2010 at 11:52 am
add me i will contibute isa
January 13th, 2010 at 1:26 pm
Sakr, dude where is my comment? the one I wrote right after Salem?
Long comment with a link, hope you didn’t nuke it as spam!
January 13th, 2010 at 2:24 pm
Can’t seem to find it :\ Nothing in my spam filter from you either..
January 13th, 2010 at 2:28 pm
Ah crap! that’s sad
hell no… I ain’t rewriting everything again 
Don’t have time now got RM tom… When I see you I’ll tell you my notes.
January 13th, 2010 at 2:44 pm
lol, whatever suits you best
Good luck with RM 
January 16th, 2010 at 5:14 pm
So here are the updates:
First and for most, the commands are as follows: CONNECT [username], JOIN room-name, DC, NDC, BID your-bid, PASS, CALL your-call
For now there is very little you can do, yet most of what needs to be done. When 4 players join a room the game starts by dealing cards. When cards are dealt, the game basically starts by asking players to dash-call (or not) so that the auction can start (aka wait for dash). When the auction starts, players make bids or pass accordingly. When everyone passes and only the caller remains, he confirms his bid and the game goes into call-mode where all players call how many tricks they need. Last caller shouldn’t sum the tricks to 13, this has been taken care of.
Up until this point, everything has been implemented. Everything else apart from that, ironically, still needs to be done!
So here, a mini-report of where we’re at.
January 31st, 2010 at 10:38 pm
GREAT NEWS!
The engine is almost finished.. users can throw cards, collect tricks, and the round proceeds! Lots of cases need be taken care of but most the logic is being handled! A few bits and pieces are still missing but the vast majority is already working!
It’s been really nice working with you all so far!
Thanks so much everyone for the contributions!!
So yeah, nobody submitted anything! lol it was nice though.. seeing you all had the motive and all, really inspiring!