War card game program c

War is what is known as a simple accumulating-type card game. The objective of the game is to acquire win from the opponent all the cards in a standard card Anglo-American playing card deck. In War, each card generally has one of thirteen possible predetermined values — Two deuce through Ace. There are many variations of War. For this simulation, I choose the most basic 2-player variation of the game.

Here are the rules:. This simulation is constructed as a simple Windows Forms Application, built in C 3. In addition, there are a series of classes that contains the games logic.

My primary focus was on the accuracy of the simulation, construction of the code, and extraction of data, not creating a visually rich GUI. The simulation allows the game to be played in two different modes, manual and automatic.

You can choose to play the game manually, conducting each battle one at a time and seeing the results. Alternately, you can choose to have the program conduct all battles until a winner is determined. Add a comment. Active Oldest Votes. Instead of writing two times almost the same code Also, you could omit to cast the result of malloc and use the variable name into sizeof instead of using the type. Now you just have to alternatively deal card from this array to player and computer and after, as you do, set non-existent cards from both hands, to null.

End words Also, as you can see, I introduced assertion in the last code, paradoxically to the length of this post, i found code pretty well writes. I wrote this few days ago, but didn't take time to add it before.

Hope it will help. Cards Actually in your code, you compare cards with ranks, and then if equals, with suits. So, what's cards values? Deck s Just think two second about this game in your program and in real life. Each player have card from the same deck, right? The deck is just split into halves to players. Let's try to set that idea into practice!

Virtually splits our deck at the middle. Let's call this position "separator" Each player take cards from this separator until their sides. When a player won a card, it come in his side of the separator and so became a part of his sub-deck. When a player reach the last card of his part of the deck, he continues taking the card right before the separator, i. In real life, before picking this card, his part of the deck is shuffled. Let's assume that we can do the same, that will add a bit randomization.

Finally, when he don't have card from his side of separator, he have lost. Final End words As stated in comments, the player who have to top deck card is his sub-deck automatically win. If you want, I can try to come back in few days with a example of implementation. Improve this answer. Calak Calak 2, 8 8 silver badges 19 19 bronze badges. About pSuit , pRank and the computer equivalent, I thought it'd be shorter and the line of code where they are used wouldn't be extremely long.

But for the card creation logic, I assume you meant Show 3 more comments. Cris Luengo Cris Luengo 3, 7 7 silver badges 29 29 bronze badges. Use stdbool. Employ const When a function parameter points to unchanged data, make it const.

Technical undefined behavior UB toupper ch is valid for int values in the unsigned char range and EOF. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name.

Email Required, but never shown. The Overflow Blog. Stack Gives Back Safety in numbers: crowdsourcing data on nefarious IP addresses. Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually. Related 6. Hot Network Questions. Question feed.

Finally, we need to handle the GetShortName method. So we need a method to assign this short name to each card, like so:. With the card, player, and "deck" in place, we can finally create the last and most complex object in our model: the game itself.

In this modeling practice, like several of the others, the game itself is represented by an object. The properties of this object are the things required to play a game. In real life, what we would need to play a game is simple: two players, and a deck of cards. However, we also need to end games if they become infinite, so we need to keep track of the number of turns elapsed. Remember that our model makes the deck a property of the Player object, and so it will not be declared in the Game object.

Now we need to think about the steps involved in playing a turn in War. Here's what I came up with. The end-of-game step is also relatively easy, so that's next. In the real world, end-of-game happens whenever a player is out of cards.

Decision Point : In Part 1, we discussed the possibility of infinite games of War. In our model, we want to avoid said infinite games, and so we'll forcibly end the game after turns have elapsed the reasoning for this particular number will be in Part 3 of this series. Playing a turn in War would be simple, if it weren't for the whole War mechanic.

Flip two cards, higher card gets both. This sounds simple, but the War mechanic makes this more difficult than it sounds. Decision Point : In Part 1, I mentioned that the "official" rules of War do not say what happens if a player runs out of cards during a War.

In this model, I am making that scenario an immediate end-of-game, as it simplifies the system as a whole. There's one trick we're going to employ: for the face-down cards during a War, we're going to put them in a common pool.

At that point, it doesn't matter who placed them, it just matters that they go to the winner of the War. Decision Point : In Part 1, we discussed that War in real-life is not deterministic, meaning that the outcome cannot be known after the cards are shuffled because they will be added to players decks in random order.

Our model, almost by accident, has made War deterministic; cards are always added to player decks in a known order.

Therefore, if we wanted to, we could "know" after dealing which player will win. It's up to you, dear readers, to decide what to do with this information. Guess what? We now have a simple C application that can play games of War! But we're not done yet. In the final part of this series, we'll run this system thousands of times, to see whether or not we accidentally biased it and how we might improve.