Stranded

I’m back again with another game jam game that I put together.

This project was not as successful as I wanted it to be, but I still learned some good stuff.

This game is called Stranded, and it was created for the Indie Mix Tape 3 on the IndieDev Subreddit. This was a two and a half week game jam that I worked on alone.

Stranded Title Screen

The concept behind this indie mix tape was to make a game that involved procedural generation. One of my first thoughts was to create a survival game, and to procedurally generate an island that the game could take place on. Even though I didn’t love this idea, I decided to go with it, and see what happened.

This was an interesting project to work on because I’ve never really done anything of this scale before. On top of that, this was the first time I ever tried to generate content procedurally. While some elements were successful, such as generating the island, and making a basic time of day/lighting system, I really underestimated what I was getting into. So to look at where this project went, and how it turned out, let’s start at the beginning.

Since the focus of the project was on procedural generation, I decided to start there, and immediately set about trying to generate an island for the game. The system I decided to use was very simple. First, it would go through an array of blank squares and create an oval island in the center. Then, after the full island was generated, it would do another pass where it determined whether each tile on the island should be a beach tile, a grass tile, or a forest tile, depending on how far it was from the center of the island, or  how close it was to water. After that it would go through all of the tiles again, and start generating various other objects like bushes, trees, rocks, and so on. The goal here was to create a very basic island, with items on it that I could turn into resources later(trees could be mined for wood, rocks for ore, etc). You can see some examples of what this system might spit out below:

Some Island Examples

Dark blue tiles represent deep water, light blue are beach water, dark green are forest,m and light green are just grass.

Even though this system was working very well, I got obsessed with trying to make the island generation better, and lost focus on some of the more important aspects that would turn it into an actual game. So even after it was working I started worrying about how often trees were spawning, how large beaches were, how big the islands were, and how varied the shapes were. All of these things mattered, but many of them could easily be classified as polish, and could have been sorted out later when I had more actual gameplay done. Despite this, I ended up spending more than half of my time on this one element of the game, and the deadline was quickly approaching.

I was still unhappy with this system, but I pushed forward with the game anyway, and got to work on the rest of the game elements. From there I started working on Player movement, enemies, combat, inventory, day/night cycles, and many other things. To put it simply, I was trying to do everything at once.

Eventually the deadline for the game jam hit, and I was nowhere near finishing. While I did complete some of my goals, such as completing player movement, having an explorable map with a fog of war element on the map screen, creating a day/night cycle and a lighting system to go with it, and even had some basic enemy AI, I didn’t have anything near a full game. Below you can see some examples of what the game looked like at the end of the jam.

Screen2 Screen3

After the game jam ended, I decided to continue working on the game to see what I could do to complete it. Once again though, I got bogged down with the island generation because I had an “epiphany” about how to generate the island faster with more variety. Just like before, that ended up being the only element I really worked on for a week or so, and the game didn’t get much better overall.

Finally, after June ended, I was forced to stop working on the game because I had other commitments. Despite all the time I put into it, the only thing that really got close to the point I wanted was the random generation of islands. Everything else was lackluster and incomplete.

This game didn’t turn out very well, but it was an interesting project , and it did help me learn one important lesson about prioritization. While I easily had the time to make the basic gameplay I wanted, I spent almost all of that time trying to make a really powerful island generation system. When I should have been focusing on what would make the game fun, I focused on making a system that could create rivers, and unique island shapes, and which would create just the right amount of trees and rocks, and everything else. In the end, I was, funnily enough, unable to see the forest for the trees, and spent a lot of time making sure the forests were just right.

This project also taught me a good lesson about scale. Survival games are interesting to look at because many of the systems at play are often very simple. Movement is very simple. Mining for resources, at its heart, is very simple. Even combat can be very simple. Together though, these systems are very complex, and create a very large game. By underestimating the amoutn of time it would take me to combine all of these elements into a single piece, I underestimated the game as a whole, and failed to appreciate the task I was taking on.In the future I will definitely keep this in mind, and try to look more at the project as a whole, and how elements interact with each other, rather than just taking each element as a single piece.

While I definitely won’t be trying to make a project of this scale again any time soon, it was a good learning experience, and it was fun to tackle procedural generation from a programming perspective.

If yoiu want to check out the final version that i did post, you can find it on itch.io.

Game Jam Rush!

It’s been a while since I posted, but I thought I’d come back with another project I just finished up.

Game Jam Rush title screen

Game Jam Rush title screen

This project is called Game Jam Rush! and it was developed for the Composer Quest Game Jam. This was a ten day game jam, with the goal being to connect developers and composers. The game was co-designed  by  Tim Brandl  and myself. I completed all of the code and pixel art, and Tim completed all of the music and sound effects.

The theme of this Game Jam was “I barely survived this game jam”, which was already pretty on-the-nose. Tim and I decided to take it very literally, and make the game about someone who needed to quickly complete a game for a game jam, because they had slacked-off and not gotten much done in the beginning of the jam.

During this jam I was actually very busy with work, so we wanted a game concept that was relatively easy to execute and polish. With that in-mind, we created a side-scroller where the player was literally running from a clock trying to collect game assets and power-ups that would improve their final product. The game assets the player could collect included Art, Code, and Music, which each got graded by the game jam’s judges, based on how much you collected before the jam ended.

Game Jam Rush screenshot

Aside from the game assets themselves, the game also included power-ups and debuffs that the player could collect. The power-ups we included were Coffee, Red Bull, Food and Extra team Members, which each did different things. These effects included speeding up your character, slowing down the clock, increasing your overall time, and so on. The debuffs we had were power-outages, which made the entire screen black and made it hard to see, pillows, which caused you to fall asleep and lose time, and computer failures, which temporarily stop completely

To develop the project, we had a very quick dev cycle where I would prototype, Tim would test, and then we would have a Skype meeting to discuss what should happen next, or how the current version could be improved. This worked out very well, and allowed us to usually keep our ideas within reason. It also helped that Tim and I got along very well, and were generally in-sync about what we thoguht was best for the project.

This was a pretty fun project to work on, and it really drove home how important scope can be to completing a project. When you’re working on such a tight deadline, it’s very easy to over-estimate, and assume you have the skills to accomplish more than you do.  On multiple occasions, Tim and I had ideas about how the game could work, or what we wanted to do, that would have really stretched our ability to complete the project in the time we had. By not letting the scope expand too far beyond our initial ideas, and choosing a simple game type, we were able to create something that thoroughly executed our vision.

If you’d like to play the game, you can check out the final version on itch.io.

Global Game Jam 2015 – After Quest

Another day, another blog post. As I said I’d be yesterday, I’m here today to talk about my GGJ 2015 entry, After Quest. Please download it from the GGJ website.

After Quest Promo Image

After Quest is a 2D action game in the style of old-school Zelda games. The plot begins moments after our main character has defeated the game’s final boss. Instead of the game ending when this occurs though, the main character is left standing around waiting for something to happen. Eventually the main character is sent to the credits screen for the game they just completed, and somehow ends up back at the very beginning of the game. After walking around town and talking to some of the villagers he realizes something is not right, and the game world is falling apart at the seams. Now the main character must fight his way through the game itself, and hopefully find a way out of the game world before it collapses with him inside.

I developed After Quest with a team of four other people, and I acted as the Programmer, and Co-Designer for the project.

My Team, with me in the middle.

Conception

The theme of GGJ 2015 was “What do we do now?” This lead to a lot of obvious jokes from people in the crowd, and was overall a more challenging theme to work with. My team went through at least 10 different ideas before we settled on this one, and most of them revolved around the central conceit that the player would be forced into a situation where they didn’t know what they were doing, or where the player had to deal with the aftermath of some event. My favorite un-used idea was one where the player wakes up in a room with a dead body and has to try and hide the body before the police arrive.

After Quest started the same way as many of our other ideas and was originally going to be a text adventure about what the main character does after the final quest is finished. We eventually decided it would be more interesting if the game itself started collapsing because it hadn’t been programmed well enough to support the player after the final quest occurs. What would happen if the player was somehow forced back to the beginning area but none of the other characters realized he had already finished the quest?

Development

The dev process on the game was a pretty straight-forward one. We took a lot of time before pitching the game to the group to really flesh out the story-line, the characters, what the gameplay would be like, what assets we would need, etc. By the time we actually had our team our game design doc, which was really just two large pieces of poster paper, was basically finished and we had a strong vision of not only what the game would be, but also why it would be that way. This gave us a huge advantage when we sat down with our final team and allowed us to quickly make a paper prototype, and move on to computer development in almost no time at all.

We were also helped by the fact that our game was relatively simple from a gameplay perspective. Even by the time it was finished, the game was basically just a top-down action game where the player could do a basic attack. We even took advantage of our concept and the fact that the main character would theoretically already have the best weapons and be at “max level”. This allowed us to give all of the enemies simplistic AI, not have to worry about them doing the player any significant damage, and even make the player super powerful, because it all fit perfectly into the world we had designed. By the end of the first 12 hours, we already had 85% of the gameplay implemented in it’s final form, and by the end of the first day, almost all the work we were doing was purely level design and iteration.

The whole process went incredibly smoothly. Even with all the work we completed on the first day though, we were still working on the game up to the last minute trying to cram in just a few more features and ideas.

Final Thoughts

This was probably the most successful game I’ve ever worked on for a game jam. Not only did we complete 99% of our goals for the final product, we also created a game that achieved our original vision and conveyed everything or almost everything we set out to do without having to compromise due to time restraints. It’s very rare that you end a game jam thinking you made the best game you could, and it’s even rarer that the game you end up with accomplishes all of your goals, but I can honestly say I walked away feeling both of those things after this jam.

I also think that this was one of the best teams I’ve ever worked with on a game jam before. Everyone on the team was very realistic about what they could and couldn’t do, and no one really over-estimated their skill or what they could accomplish in 48 hours. On top of that, everyone I worked with was great at what they chose to do.

Overall I’m walking away from this jam with a true sense of accomplishment and I can only hope that my next game jam is even half as successful as this one was.

Pixel Poker Update 8 – Back-end Changes

Where does the time go? I meant to make this post earlier this month, but I kept putting it off for one reason or another, and before I knew it, February was around the corner. I decided I didn’t want to wait another month before posting though, so even though I don’t have as much to show at this exact moment, it’d be a good time to get it out of the way.

The last month and a half on Pixel Poker have been a bit of a roller coaster of emotions. On the one hand, I am actively working on getting AI working well, but on the other hand, right now it’s basically complete crap. My primary work this past month has been in a few UI updates, and work on improving the back-end of the game to adapt it for my current AI goals.

AI Progress

The situation I’m in now is that unless I want to start working towards making the AI mimic actual players, and actual thought processes perfectly, I need to take better advantage of the way computers work. Since creating poker AI which mimics actual player thought processes was never my goal, I’ve determined that having players evaluate their hands the same way as real players is not always an ideal because it forces me to create complex if statements and handle many specific scenarios before I can even get close to that. Instead I should be striving to evaluate them in a more statistical way, which computers can do more effectively on the fly than a person can . The best way I can find to do this is simply to have the AI players evaluate their hand against hundreds of random hands, and record how often they win. Then, after looking at the probability they will win they can use other information such as how much they have to bet, their position, and even their rank in the game as a whole, to determine whether betting is worthwhile. From there I could start doing things to mimic aspects of a real player such as confidence, and skill level to adjust the exact scenarios in which they would be willing to play.

While this method is very simple on paper, it was not what I was expecting to do to begin with, and thus it brought many problems to my existing systems. The first and foremost problem is simply speed of the algorithms I’m currently using. At the beginning of this month, the algorithm I was using to do the base evaluation of a hand, to determine what type of hand the player has, was very inefficient. I’ve done a lot of work to improve it, but in all honesty, it could still be even better, so I’m still working on that. The next problem is in the way all of the systems work together. Simply put, the web of systems I’ve been using to determine the final value of the hand, and what cards are in the hand is very complex. Because of how interconnected certain systems are with each other, disconnecting them enough that I can even run the test without creating thousands of new objects on the fly is problematic to say the least.

So after all that, it comes down to this, the systems I have in place are not well-enough designed and right now my primary goal has been to restructure them to increase efficiency and work more effectively with my new AI goals. I’ve already done some major work in this area, but it seems like I will have to do even more to disconnect these systems and make them more independent to create powerful and efficient AI. Part of the reason I put off this update for so long was because I didn’t know what to do about this, and I was trying to find a solution before posting. As usual though, just typing this out is helping me consider new ideas, and even if most of my days are frustrating, I know that I am getting closer. After all, ruling out a bad solution just brings you one step closer to finding a good one.

Small UI Changes

I think that the UI is mostly unchanged, however I did modify the Call/Check buttons. Since they have very similar functions, and since they are never active at the same time, I decided to reconcile them to two smaller buttons which take up the same space as a single button. I think it makes the most sense, and it feels a bit better than it did before in my opinion. I considered making them one button which adjusts based on the situation, but I liked this better.  This change also gave me a lot of extra room to increase the “bet” area on the UI and make the Call text much larger and clearer. Finally, you’ll notice that there are now a red and black line on the Bet Slider. The Red line represents the minimum bet it would take to call, and the black one is the minimum you can raise by.

NewBettingMenu

 

While I think this is a major improvement over the previous version of the menu, I still plan on playing around with it a bit more. Eventually I’d like to remove the bet slider entirely and switch to a system which allows the player to click on images of chips and have the chips represented on the table, but that’s going to come later on since I’m pretty sure there are still some flaws in how I calculate minimum bets in uncommon situations or in situations where one player is going all-in.

Aside from the bet menu, the UI is completely the same.

Bug Fixes

This update was also a major one for general bug fixing. Shortly after my last update I found a much more efficient way to test, and it allowed me to see many more games to completion. This lead to me finding a number of different errors that had previously gone completely unseen. While many of these errors have been dealt with, I’m still working on some of them. For now I’ve decided to spend all my time getting past the AI hurdles I outlined above, and then move on to tackling the bugs. I’m doing it this way because the changes due to the AI adjustments will be fairly large and I ‘d hate to spend days working on improving a system that ends up getting completely overhauled during the AI changes anyway.

That’s all the info I’ve got for Pixel Poker today, however I’ll be updating the blog again tomorrow to discuss my Global Game Jam 2015 entry. See you all tomorrow!

Pixel Poker Update 7 – Visual Changes and Usability

It’s been a few weeks since I did the mini-update showing off the card-dealing system, and I felt it was finally time I sat down and did a full update again. This update brings a lot of visual changes for the game, and is a pretty exciting one in my opinion.

Visual Updates and UI

Since this update is mostly a visual one, it’s probably best to start off with a screenshot of the game in it’s current state:PP12-14

 

The smallest, but most obvious changes were to the shape of the poker table, and the card images. The new poker table shape came about because I wanted to make it slightly bigger. In doing so I decided I wanted a more angular shape for the table, and I settled on this. The new card images on the other hand, were something I wanted to do for a while, but simply kept putting off. While the old ones were good, they felt very same-y, and I always disliked that all of the different card values were indistinguishable other than with the number itself. With the new images, I have a much more realistic representation of playing cards, and it makes the game as a whole feel better. I still haven’t made images for the face cards which have characters on them, but I am working on it on the back-burner. You can see all of the new cards below.

NewCards

With this update I also put a large focus on working towards the final UI for the game, or at least moving further from the temporary one. To do this I eliminated all of the plain black text that was being used to display information about the players, and moved all of the information either onto the player’s portrait, or onto the poker table. I also moved the cards so that they sit on the poker table, rather than in the corner of the player portraits. These changes helped to make the game feel more “real” and finalize the look.

The other changes I made to the UI are related to the betting menu. The betting menu is now slightly thinner to accommodate the wider table, and it displays what cards the player has with large images. This was a feature I wanted to implement for a while, and had always left space for, but seeing it in action I’m not as happy with it as I expected I’d be. At a later date I plan on playing around with it a bit more and seeing if there is a slightly better use for that space such as information about the status of the game, or an options menu of some kind. I’ve also seen features like an “auto-check” in other poker games that I could put in.

The UI still has some work left to go, but this update brought a lot of positive changes. The next thing I’ll be tackling will be the UI related to the Dealer, and possibly more stuff related to the poker table.

Marking Winning Hands

The next big thing I worked on for this update was to make it so that when a game ended, the cards used in the winning hand would get highlighted. In the screenshot below you can see what this looks like:

CardMarking

 

As you can see, the cards that weren’t used, and the cards of the losing players were grayed out so that the wining hand itself could be highlighted. This system is still somewhat imperfect since it is somewhat unclear who used which cards when there is a tie, but I am working on possible solutions to that which would make the winning hands for multiple players clearer. i’m also going to make it so that the hand types are named so in this case I’d like there to be something which says that this player had a Two Pair, for example.

I also implemented this same solution when the dealer cards are being drawn to make it even clearer who has the winning dealer card.

Character Art

The character design phase is moving along a bit slower than I would have liked due to the artist I’m working with having some health issues, but there’s still good progress being made, and I have some concept art for two of the characters already. I’d like to wait a bit longer to premiere the character art, but rest assured that it is coming along very well.

Well that’s all I have for this update, but I should be back again before January 1st with another update on Pixel Poker, and a Year-in-Review post to tell you about some of the other stuff I’ve done this year at my day-job.

Pixel Poker Update 5 – UI and Character Selection

Once again I have come with another update on my Pixel Poker progress.

These past two weeks I haven’t had quite as much time to myself as I was hoping so I decided to focus this update primarily on visuals while I continue working on AI in the background. Most of the work I did for this update was visual upgrades to achieve a look that’s closer to what I’d like in the final game, but I did make two gameplay/usability improvements.

The first thing I did was fix a small issue I had been having with the various settings sliders I use throughout the game. In the previous version the sliders were only able to go to 99% of their max value, but that issue has now been dealt with.

The second gameplay change I made was giving the player the ability to select which characters will be playing. If you take a look at the new settings screen below you can see that the settings sliders have shifted to the left side of the screen, and now the right-side is taken up by what will eventually be character portraits that allow you to select who you want in the game.

NewSettings

 

Changing the value of the Number of Players slider also adjusts the number of active characters you can choose. Currently the largest game size that’s supported is eight players with six as the default. I also have nine different characters that I’m planning to include. While I’m not going to get into too much detail about the characters in this post, here’s a list of the characters I’m currently working on.

  • Clint – A wise-cracking Toucan with a bit too much confidence.
  • Roxy – A succubus who uses men like playing cards and isn’t afraid to get rid of them when another hand comes along.
  • Tom – A helpless loser who is somewhat infatuated with Roxy.
  • Bernard – A dog who’s quite the experienced player, and isn’t afraid to play dirty if it will net him a few more bones.
  • Yuri – A girl straight out of an anime.
  • Turbo – A turtle who’s looking to make some money and spend some time away from his owner.
  • Babs – A sweet old lady, and Turbo’s owner.
  • Stan – An older poker player who’s clearly past his prime.
  • Bot 2000 – A Poker Playing robot that may need to work on its programming.

I’m hoping to do another post soon with some character sketches and a bit more information on each character, so stay tuned for that.

Along with the added feature of being able to select the characters you want, you should notice a few more changes in the image above. First and foremost, I’m using a new font. I’m not sure this is the font I’ll use in the final game, but it’s definitely much closer to my intended look and works very well for now.

You’ll also notice that the Start Game button looks fairly different. One of the big changes I made was to come up with a strong visual direction for the game, and specifically the UI. I really wanted the UI to resemble the look of a high-quality poker table at a casino. Having spent a decent amount of time playing table games in casinos, I always loved the look of the tables and how they had these intricate, brightly-colored, graphics printed on them. My goal was to try and make the buttons, and many of the other UI elements, feel similar to those graphics. Below you can see a basic overview of the different button states. First you have a disabled button, then an enabled button which isn’t being used, and finally an enabled button which the user is hover-over or clicking.

ButtonStates

 

My biggest issue with the buttons right now is really with their “visibility”. I may change the background colors for the menu to make the buttons a bit easier to read, or I may make some adjustments to the colors I use. At this time I’m still toying with different combinations so it could go through another major overhaul.

The next big change I made also relates to the UI but this time it deals with the actual game screen.

PokerRoom

 

As you can see, the “betting menu” has a much more finalized layout now than it did before. In the end I’m going to make larger card graphics to put in the white spots so it’s always immediately obvious what your hand is, even at a quick glance. In this example it’s a bit more obvious why I’d like to work on the buttons more, but even in this early state they do a decent job, and they definitely convey the feel I was looking for.

The final change I made in this update is the look of the Alerts that I added in the previous update. Below is a gif of what one of the new alerts looks-like:

NewAlert

 

As you can see, they’re a bit more interesting now then they were before, and they work much better with the overall look I’ve settled on for the game.

As I’ve said, the design is still a work in progress, but it definitely feels more interesting now than it did in the previous version, and the game as a whole is coming together very well.

Now that I can actually choose my characters, it should be much easier for me to start testing the AI and character work I’ve been doing. My next update should have a lot of info on the different characters and their playing styles, and hopefully we will finally get to see some of the AI in action.

Pixel Poker Update 4

It’s been a bit longer than I was hoping it would be since my last update, but I got a lot done since then. I’m not quite as far along as I’d like to be, but at this point, I’ve finally begun doing some basic AI development, and I’m getting a bit closer to having something you could actually call a game. Most of my AI work up to this point has been conceptual, but I’ve put a lot of thought into the characters, and I’m starting to think more about how they behave as players, and not just how a player would behave. In any case, let’s look at the game in its current state.

One of the biggest changes since the previous version is the addition of a “Settings Menu” that the player can look at and modify before starting their actual game. The menu is currently very minimal, but it gives the player the ability to set the starting cash for each player, the minimum starting bet, and the number of players in the game. If you look below you can see an image of both what the menu currently looks like, and what the game looks like with different numbers of players.
SettingsMenuPlayerLayouts

 

From these images above you may also notice one of the other changes I implemented. While I haven’t implemented any major AI changes yet, I wanted to do a proof-of-concept to make sure that I could create multiple player types that were ‘children’ of the standard player. As you can see the top-center player has a different player image than any of the others. This is because that player is actually a child-object of the original Player Object I created. At this time it inherits all behavior from the standard player, but as I start implementing AI I will give it some custom behaviors and reactions. As I start making more player types, I plan to add a section to the starting menu that allows the player to choose who they play as, and who their opponents will be. Potentially I will also make multiple difficulty levels for each opponent, but I’m not sure yet if that’s something I want to implement, or what different difficulties would affect on the AI of any given player.

On top of that, you should also notice that I’ve started to implement some basic menus/dialog-boxes into this version. The menus are still very early in development, but it’s progressing well.

The final change you can see in the image above is the “Starting Dealer” dialog-box. For this update I realized that the dealer chip was always starting with the player character, so I created a system that allows the dealer to be randomly selected. After the player hits the “Find Dealer” button it deals every player a random card, and finds the player with the high-card to determine the dealer. In cases of a tie, new cards are dealt to only the players involved in the tie until a single high-card is found. You can see some examples of this in the gif below.

ChoosingStartingPlayer

Another improvement I implemented in this version, is the ability to track the “hand value” of the dealer cards. As I begin implementing AI into the game, this means that the player will be able to directly compare their hand to the overall value of the cards the dealer has revealed, and see how their cards stack up. This will allow me to do direct comparisons of the players’ hands to what the dealer has and quickly let them make decisions about folding, calling, checking, and betting.

The next visual improvement I made, was to create a basic alert system that tells the player what actions their opponents are taking. If you view the gif below, you’ll notice that after each player takes their action, a message spawns on their character portrait saying whether they checked, called, folded, or bet. At this time, since the AI players never bet or fold on their own, you can only see the check and call actions, but in the next update this system will be a bit more robust to account for more complex AI.

ActionAlerts

 

The next change I made was related to the progression of the game. In a game of poker, the minimum bet will increase over time to force more-cautious players to start taking risks, and to prevent the game from becoming stagnant. In this update I implemented a basic system to do this every time the dealer chip returns to its initial position. In the gif below you can see a game with just two players. If you watch the bet sizes, you’ll notice that they first increase from 10 to 20, and then from 20 to 40. In this system the bet always multiplies by 2, but I plan to eventually add another option to the settings menu that allows you to determine how much the bet increases each time, and how often the increases occur. While you can’t see it in this gif, this system also accounts for when the original dealer has been eliminated and continues to increment the bet size accordingly.

IncreasingBet

 

The final change I made was a non-visual one. During my testing I noticed that it was very annoying that after a round was over, the cards would automatically be removed after a certain amount of time. This was particularly frustrating because whenever I was doing multi-round debugging it forced me to increase the amount of time by a very large factor so I would be able to make sure wins were being determined correctly, and I would inevitably have to wait around rounds to end after I had finished checking things. To improve usability for the player, and for me while debugging, I made it so rounds no longer end until you hit the Deal Cards button another time. This gives me as much time as I need to evaluate the outcome of the hand, and it effectively pauses the game until the player is ready to start the next hand.

That’s everything I accomplished between the last update and now. In the next update I plan to implement some basic AI and create all of the player objects, fix a few errors I’m currently having with my custom sliders, create some character art to accompany my character objects, and give the player the ability to choose what players come into a game. I’d also like to do a bit more UI work before I update again, but I’ll see if I get to it. Hopefully I’ll be back soon with my next update, and thanks for visiting.

Pixel Poker Update 2

It’s been a few weeks since I put out my last update on Pixel Poker, or anything else I’m working on so I thought it was high-time I returned to show what I’ve been doing.

Pixel Poker Update 2

While I still haven’t gotten to the point where I am designing AI for my the game, I’ve made a lot of positive progress on Pixel Poker.

PixelPokerScreen1

Probably the biggest difference is the game layout as a whole. As you can see in the image above, I’ve successfully created a poker table layout for the players. The cool thing about this is that all of the player positions, and the positions of the elements that are “attached” to them like the cards, and the dealer chip, are dynamic based on items which I can move around as I please within the environment. So if I find I need to make a major change to the layout later on and redesign the poker table, or the positioning, it will be a very easy fix to get everything displaying in the correct positions again. Along with this change, you’ll also notice that I’ve started keeping track of how much money each player has, who the dealer is, and just generally laying the foundations of the actual game of poker beyond the cards.

NoShuffle2

After I got the basic layout working, I also set out to create a realistic dealing system where the dealer receives cards last, and dealing begins to their left. In the gif above, I have turned off shuffling and made every players’ cards visible so that you can see what order the cards are being dealt. In this case the first card that’s dealt is the 2 of Clubs and it is dealt to the player directly to the left of the dealer. If you then continue around the circle you’ll see that the cards are being dealt in a consistent order every time with. As the dealer chip moves around the table, the order of the cards never changes, but the position of each hand does in accordance with the position of the dealer chip. This shows that the dealing system works and the dealer position moves around the table with the chip as it should.

PlayersOut

The next gif shows what happens when players run out of money. Right now, since I haven’t implemented a betting system, if a player wins, they receive $10 for each of the remaining players, and if they lose, they lose $10. In the above gif I have set everyone’s starting cash at $50 so very quickly you will see a number of players lose. After they are removed from the game you’ll see that they are no longer dealt to, and that the dealer chip only moves between the remaining players.

FullRound

The last little thing I want to point out is the discard pile which actually increases in size as the game progresses based on the number of cards that have been discarded. Whenever a player folds, or a card is burned to reveal the next turned card, the discard pile increases accordingly. You can see this in action in the last gif which I’ve placed above. This gif shows a full round of eight hands being played.

The next thing I plan to do on the Poker game is implement incredibly simple AI so that I can start developing the betting system, and the game’s UI. From there I will start making the AI more advanced and developing some of the menus and other screens. I’ve also been working on another smaller project for a friend while working on this one, and will be putting up an update about that project in an hour or so.

Pixel Poker Update 1

I know it’s only been a few days since I initially posted about Pixel Poker, but I think the next few iterations I go through will require some big changes, so I thought it was important to show what I have so far before the game starts to look very different.

Over the past few days I’ve made some very important progress. The first thing that I did was implement win detection so that the game can determine which player is currently winning or wins when a round is completed. If you watch the gif below you’ll see this in action:

WinDetection

If you have any experience with poker than you should be able to follow most of these hands, but I quickly want to explain how the win detection works. The easiest way to determine a winner is obviously to assign a value to all of the hands. My initial idea was simply to add up the cards in the hand, and then multiply the resulting value or increase it by some constant based on what type of hand it was. This worked in some cases, but it created a number of situations where the system could easily assign the wrong player as a winner when two players had similarly ranked hands. For example, if two players both have  two pairs, then the winner is the person with the highest pair, not the person with the highest average value between their pairs. This means that if Player 1 has a pair of Aces, and a pair of Threes, and Player 2 has a pair of Kings, and a pair of Queens, then Player 1 should win. Even though both of Player 2′s pairs outrank the 3s that Player 1 has, his Aces win out over everything. If I had used my original system then the value of Player 1′s hand would have been Ace+3, or 14+3 = 17, and the value of Player 2′s hand would have been King+Queen or 13+12 = 25. No matter how I modified these values, Player 2 would always come up as the winner, even though that’s not how the game works.

Depending on what hand type a player has, there are a number of ways that a tie can be evaluated, but in the end a tie will never be evaluated by more than three comparisons. Below you can see how hand comparisons work in poker for each hand type:

  • High-Card – Player has no poker hands of any kind, just one card that is high value.
    • Highest card wins
  • Pair – Player has one pair in their hand.
    • Highest pair wins
    • Then high-card wins
  • Two-Pair – Player has two pairs in their hand.
    • Highest pair wins
    • Then next highest pair wins
    • Then high-card wins
  • Three-of-a-kind – Player has three cards with the same value in their hand.
    • Highest three-of-a-kind wins
    • Then high-card wins.
  • Straight – Player has five cards in an unbroken sequence of values. Cards don’t need to be the same suit.
    • Straight with the highest card wins
  • Flush – Player has five cards all of the same suit. Cards do not have to be connected based on value.
    • Flush with the highest card wins
  • Full House – Player has a three-of-a-kind and a pair simultaneously.
    • The highest three-of-a-kind wins
    • Then the highest pair wins
  • Four-of-a-kind – Player has four cards with the same value in their hand.
    • The best four-of-a-kind wins.
    • Then high-card wins.
  • Straight Flush – Player has a straight where every card is of the same suit.
    • The straight flush with the highest card wins.

As you can see, there are only a few cases where a secondary or even a tertiary comparison needs to be made, but when it does happen it is an important distinction to determine the winner. Because of this, I created three hand values for the player. The first is always the combination of the value of the hand type, and the value of the highest card or sub-hand-type that makes it up. So if a player has a pair of 5s, their hand value is PairValue+5 or 200+5=205, since I valued pairs as 200. The second value is whatever the next aspect of their hand would be, without any modifier. So if a player had Two-Pair with Aces and Threes, their secondary hand value would be 3. Finally, the third value is whatever the third comparison would be. With the comparisons I show above, a Two-Pair is the only one that would ever get that far, so the third value for that would simply be their remaining high-card. In a situation where a poker hand only has one or two comparisons, I simply leave the remaining values as 0.

The other things I added since the last post were the ability for a player to Fold, and the ability for a player to be removed from the game entirely. In the first gif below you can see what happens when a player has folded:

FoldedPlayer

As you can see, when a player folds they are only removed from the game until the round ends. On top of that, if the currently winning player folds, the system automatically readjusts to find the next best player.

In this next gif you can see what happens when a player runs out of money and is removed from the game entirely. Removing a player from the game entirely required me to introduce Money into the game. Since I haven’t added a betting system yet, I also haven’t made the money a player has visible, since it will always be either greater than 0, or equal to 0:

OutPlayer

As you can see, once the player is removed from the game, the game continues on and they are never dealt any more cards.

The next thing I want to do with the game is introduce a betting system and start keeping track of money. While I don’t technically have to start turning it into an actual game yet, and I could continue working in this abstract state for a little while longer, I think this is a good time since I will need to start considering how rounds/turns will progress, how AI players will make bets, and how the game will actually play out. Because of this, my next step will probably be to rough-out the UI and the look of the game as a whole. I already have a few ideas about how the game will look when you’re playing, but I haven’t yet decided what would be most interesting, or give the player the best ability to see/understand their AI opponents. There are also a few more things I want the AI players to be able to keep track of that I haven’t implemented yet, so I’ll probably do that soon as well.

My next post about the game will probably deal with the possible interfaces and UIs that I’m looking at and may just be sketches, but I’ll see how much I get done in the coming days. I also plan on doing some research on Texas Hold’em strategies soon to give me inspiration for how the AIs might work, and I’ll probably download and play some similar games like Poker Night at the Inventory by TellTale games, or even some games which are designed to help you become a better poker player. This should give me a good understanding of what I like about similar games in the genre, and help show me what works and what doesn’t. In any case, I’ll be back again soon with another update, so I hope to see you then.

Pixel Poker

Oh how time flies. I’ve been meaning to start posting again for a while now, but ever since Ludum dare 28 I’ve been a pretty busy guy. I could spend a whole bunch of time talking about why I’ve been busy but I’ve tried writing that post about 10 times already and found it pretty boring every single time. As a quick summary, I took a 2 week trip to Israel in February as part of the Taglit-Birthright program, I helped create a 3-session course on Game Design for the East Brunswick Public Library, and I made some pretty good progress on learning Game Maker Studio.

I’ll probably post more in the next few days about the course that I developed for the library and what I learned from it, but for now I really wanted to make a post about a project I’m working on which I’m calling Pixel Poker. For the past few months, my friends and I have been playing a lot of Texas Hold’em. At first it started as a one time thing, but before long we had played 7 weeks in a row and were showing no signs of stopping. This got me thinking about how you would make a Poker/Texas Hold’em video game. I thought about it for a while, and I began to think it would be really fun to try and build complex and interesting AI players to play against.

I decided to run with the project and use it as another great vehicle to learn Game Maker Studio with. So far I would estimate I’ve put about 7-10 hours into the game, and I’ve been working on it since the middle of April. At this point in time I am pulling cards from a randomly shuffled deck, I’m able to accurately detect what poker hands each player has, and I’m able to detect whether it’s possible for a player to get a straight or a flush based on what cards they have, and what’s been revealed. If you look at the gifs below you can see some of the aspects of the game in action. The first gif shows me shuffling the deck multiple times:

DeckShuffler

 As you can see, the deck starts off  ”in order”, and every time I hit shuffle the cards are shuffled randomly.

This next gif shows the cards being dealt for an actual game of Texas Hold’em. As you can see, below each player is a listing of the poker hands they currently have. You’ll notice that the High Card value always shows the highest value card that’s not linked to some other poker hand, not just the highest card value available to the player. On top of that, if the player were to somehow have three pairs available, or two triplets available, the system only keeps track of the best two pairs, or the best triplets. Look at the gif below to see this in action:

DealingHands

The most recent thing I implemented is the ability for players to determine whether its possible for them to get a Straight or a Flush with the current cards.

StraightFlushTest

Eventually I plan on extending this to give them the ability to see if they could get a four of a kind, or a full house, and to determine the likelihood of other players getting high value hands based on the cards the dealer has flipped.

Once I finish giving the players the ability to determine what hands other players may have, and what they may get, I will implement a betting and turn system. From there I will have to make an automated betting system that allows thew size of a players’ bet to be influenced by their hand.

Finally, I want to eventually try and make a system that allows the AI players to evaluate the actions of other players and determine if they are bluffing, or how likely they are to bluff. I’m not 100% sure how I will detect when players were bluffing and when they legitimately thought they would win, but I think it will come down to comparing their final hand with the winning hand, and the best hand that could have been played. The real challenge with this will be taking into account the fact that a player may have had a very good hand when the initial three cards were turned, and bet high because of it, but then been beaten by the fourth or fifth revealed card.

Once I have these systems in place I will try and implement character portraits and a basic animation system so that the player will be able to evaluate the actions of the AI, but that is very far down the line at this point.

For now that’s all I’ve got, but I should be posting again soon about other things I worked on the past few months, and any progress I make on this project.