!

Sorry there was no post yesterday, without warning! But uh, here's your warning! I'll also be out for the rest of the week for various reasons. Sorry about that, stuff came up that can't be avoided (And I'm really good at avoiding things), see you Monday!

Java: Texas Hold Em (11)

Ugh, late post, sorry! I spent the better part of 2 days asleep, and I don't even know why, so doing this wasn't exactly a priority! Still, today we get to continue with our Hand Evaluator! Let's see, we had just finished finding straights and flushes, so let's continue that thread of thought and grab a method to find duplicates (encompassing single/double pairs, triples and four-of-a-kinds, thanks Mr. Stigter, for more efficiency!), and then something to calculate the high card in the hand to further calculate the hand's value.

Here's what I got (Yes, I did basically just use Stigter's code, but understanding it took time!):

Java: Texas Hold Em (10)

Hi hi, this is the last post for the week, because I'm lazy and went down to only 5 posts a week, remember. Going to be continuing with our HandEvaluator, which is fairly big, as far as what we've seen goes, and it'll be made longer by me messing around and looking for better ways to do what Stigter did! At least, for my own uses.

Now, we want our evaluator to work straight off, on being created, without calling any special methods on the object, which means our constructor is actually going to need to make use of methods we declare in the class. For this reason, it's probably best that we don't work on the constructor until we finish our methods! Here's what I got so far:

Java: Texas Hold Em (9)

Happy Thanksgiving to all the Yanks in the audience. Today we're moving onto the evaluation part of the program. This one's a little big, so it'll be more than 1 post dedicated to it! To keep things concise (or at the very least, available in small chunks), I'll keep posts to 2 screenshots worth of code per day, as I've been more or less doing for a while, anyway.

Fixing things in previous posts won't count, unless its a ridiculous amount! Speaking of which...

Java: Texas Hold Em (8)

To comments: Yeah, going to work on base functionality before everything else, then add in the visual and actual user interactivity. Also, thanks for info on the blinds!

So today I wanted to start on the HandEvaluation, since it is a rather big class. Complex, kind of, but mostly just big (As far as I know, which revolved entirely around guesswork), but the enumeration to hold the types of hand values is probably better off in its own class. It's similar to the Action we had yesterday, take a look:

Java: Texas Hold Em (7)

In response to a question from yesterday's post: I don't think the evaluation will be the toughest part, since the player clients all need to come together, or the GUI itself, using actual graphics might be a pain in the ass. We'll see, though.

For today: Action class! I'm gonna follow the example program for this one, since it looks simple, and much easier than what I was planning to do with it, but since the example program isn't fully functional (because I'm stupid and take inspiration from all the wrong places), it may need some tweaking later on.

Java: Texas Hold Em (6)

Short one today, I wanted to make a Player class, but realized I'd probably need a Client class to handle the, well, client for the player(s), so I'm putting that off.

I could work on the Client, but who wants to think on a Monday? I could work on the Table that the players "sit" at, but that requires players, and I'll be damned if I'm working on the GUI before a huge chunk (all?) of the functionality is complete. This leaves very few things for me to look at. From what I can think of, something to handle the evaluation of the hands, to determine who wins, and the actual Actions a player can take.


It seems like the Action class will be the shortest, since it'll just be an enumeration with a couple of parameters, so I'll get on that tomorrow. Honestly, thinking of what required what and how I'd go about it (though I have a feeling I'm wrong about a lot) took longer than it appears given the paragraph and a half above :P Quite enough time out of my busy schedule for today!

See you tomorrow!

Java: Texas Hold Em (5)

Uh, so it's now Friday. I have no idea what happened. I apparently passed out or something, and had been down and out for a full day. I am a bastion of physical health, I know. So after a while at the doctor it looks like the verdict is "Man up, bitch", so to celebrate, I'm going to write more code. And also mention here that I'll be dropping my posts to 5/week instead of 6!

So we were on the Hand class, and here`s how the rest of that goes:

Break!

No new material today, sorry, folks! Coming down with another migraine, and if I don't do something about it right the hell now it's liable to spiral out of control and incapacitate me for a while!

Java: Texas Hold Em (4)

Today (Almost tomorrow >_>) is gonna be short, mostly because its so late! We're gonna start off with the Hand class! Over the next day or two we'll finish it up, and then we can move on to something else! Hand Value, or Player or Table, I dunno, we'll see. Let's get this show on the road:

Java: Texas Hold Em (3)

Hi, today, we're going to (I think) finish off the Deck class, for happy fun times. Might need to change the toString() of Card since it looks kinda ugly, BUT it does work, as does the shuffling., so yeah. It's okay, though, I suppose, since the end result will hopefully be graphically represented.

Here's the Deck beyond the constructor:

Java: Texas Hold Em (2)

I COULD find a fully working game that's open source (probably), but that would be too easy! I did, however, decide to add the comparison method to Card, since that means we can compare them to decide which hand is worth more (if they're both the same hand. Triples or something), which we definitely need!

An important thing to note is the order in which I did the enumerations yesterday. I wrote them out in order from lowest to highest, both for Rank and Suit. The suit one was frankly luck, but apparently the ranking of those from bottom to top is:

Java: Texas Hold Em (1)

Welp, let's do this. I'm basically looking at someone else's source code, which is incomplete. So I hope to get my framework from this other person's work, while being forced to do the actual building myself! I should mention that since I don't have a working copy, if I fuck up, there'll be a lot of going back to find things. Programming isn't very good as a linear progression, unless you're beyond amazing at it. There'll always be small errors that you missed, or that require some odd fix that doesn't seem to make sense.

Having said that, we should get going!

Java: Screw the Network Application

O hi, there! Last night I realized that holy shit, this teaches me NOTHING, so I'm moving our day of bullshit up one! Like, seriously, it was useless, and I didn't read more than 1 day ahead, so I only realized this yesterday. Bah, waste of time. I suppose it was a little more practice with Threads and stuff, but eh. So instead, today I'm looking at Texas Hold Em and what classes would be required to get it.

So while I'm doing that, I'm peppering my time with random bouts of LoL and Minecraft (Which I only just got), and I'm more or less addicted to creative mode. Not even got the hang of the circuitry bullshit, I just build mazes galore. Good stuff.
I did try survival mode, but after trying to be a nomad from the spawn area (too many people around) like....8 times, and getting killed each time, I thought fuckit, and made a hovel in the ground. Then went back to creative :D

Anyway, see ya tomorrow for the first of Texas Hold Em (Y) I do think that the graphics will be the more annoying part of it, though.

Java: A Network Application (4)

Aah, had a migraine last night and now I don't. Best feeling ever. So I can happily move on to the NodeListener today, as promised! Meaning tomorrow we have the actual faux-application, then we're done. One day of bullshitting and stuff, then onto actual game stuff.

This is actually a very short class, and it's not ideal, since it uses the Application itself, before it's been created. I just fixed the errors popping up using the automatic stuff Netbeans does. Just created an empty class and method as a placeholder until I actually get around to making the application later tonight.

Java: A Network Application (3)

Somehow, I didn't get enough sleep, still. Oh well, time for more postin'! Today, we're continuing right off the network node from Saturday, and we'll be done with that. Tomorrow, we go to the node listener, then Wednesday we write the actual application. I'll give you until then to throw out any questions or requests about anything before we move on to those (in all probability, shitty) games!

So, diving into it:

Java: A Network Application (2)

Today's an early one, but also short, since I've had no sleep yet! Let's start at...well, the start. We'll want the lowest level of objects first, which is the NetworkNode itself, so we can have a Listener listen for it, and then the application to interact with it. This should be the only class I'm doing in 2 parts, the others look short, at a glance.

We're going to be using Random, which is in the Java libraries. I don't think we've used it yet, but it's fairly straightforward. Create a random object, then use the next...() method, you'll see below:

Java: More Multithreading: A Network Application (1)

This is the last example in the book, and I sure hope it helps me understand multithreading better than the other ones... Also while I remember: Texas Hold 'Em might be easier than I at first imagined, since, like 21 sticks (which I also realized is normally played with 1-4 sticks...oops!), it's (sort of) turn based. Nothing needs to happen simultaneously, so yay!

For now though, one more example on multithreading: A Network Application. From the text:
"The main purpose of this section is not to solve any particular problem but to show what an event is,

Java: Let's All Go On A Tangent!

Man, someone mentioned how often I used the word simple yesterday, but I only meant to use it for very select, small parts. The bigger picture is still....not. Don't worry, I'm as lost as you! Or more so, because I'm forced to write code despite not knowing quite what half of it does.


EDIT: Holy crap I use that word a lot, especially given how little I understand. Fuck. I guess if I 
say it enough I hope it'll come true?

I am frankly sick of multithreading at this point, so, lets relax for today. I looked up someone's 21 sticks game, then modified it to make it prettier. 21 sticks is a game with 2 players, where, oddly enough, there are 21 sticks. Each player then takes turns removing either 1 or 2 sticks from the pile until none are left. The player to take the last stick(s) is the loser.

Java: Shared Queue 4: Complete Test + Source Code

Gah, late thread, sorry! This one's a bit of a doozy, so bear with me! I'll start off with a brief overview:

Step 1: We need to actually create the thread-safe queue to use.
Step 2: Set up all the producers (don't run them yet, we don't want threads to start running before all are in place)
Step 3: Set up all the consumers. We can start them running now, since both producers and consumers are ready. Since the queues are as of yet, empty, this isn't an issue. Seeing an empty queue, the consumers will yield.
Step 4: Start the producers.
Step 5: Wait for the producers to finish. Once they are, no new values are going to be added to the queue.

Java: Shared Queue's 3: Testing Classes

Apparently, no one did shit, so I guess discussing that is outta the question :P So straight onto how I tested it! I'll put both the consumer and producer classes into an umbrella class just so its all together. I'll leave the actual running of the tests to tomorrow, since I'm a bum (or a tortoise?) and haven't actually like, got there yet. I mean, for your benefit, so we aren't moving too fast. Clearly.

I do have the actual classes to be used in the testing though, and here they are: