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 – Quick Update – Dealing Animation

So the past week and a half I got a bit distracted from AI. Since I first started working on Pixel Poker, and got the basics of players and hands implemented, one of the things I’ve wanted to implement was a nice card dealing animation. I always hated that the cards would just appear in front of the players without any “explanation” and knew that if I could make a good animation for the card dealing it would make the game feel much less like a quickly put together program, and more like a real game.

Well, this past week, I finally thought of a solution to this problem that I not only felt comfortable implementing, but I was also reasonably confident would work. Implementing the solution required me to re-work a couple more of the back-end systems in my game, but it was definitely worth it. Below you can see how the animation looks so far:

DealingGif

There are still a couple more improvements I’d like to make to this system, but overall it does exactly what I wanted it to do. The biggest change I plan to make from here is to make the deck look like more than just a stack of black, and add some basic color variation. On top of that, I may modify some of the dealing speeds. Other than those two issues though, I’m very happy with the system, and with the changes I made to the back-end components which allowed me to make it work.

Pixel Poker Update 6 – UI, AI, and Back-End Improvements

It’s definitely been longer than I intended since my last update, but I’m going to be putting up my next update in the next day or so to try and make up for that mistake. The first update will be this one, talking about the AI I’ve implemented, and a number of other changes which have improved the game as a whole. The second update will be a character update and will talk entirely about the characters in the game. That update will have more information about the characters themselves, and who they are. Without further ado, here’s how the game’s looking:

PPScreen

If you looked at the last update, the game should look pretty similar to what it was before. Sadly I didn’t get to do too many visual improvements since the last version. I’ve made a few small changes to the colors in the UI in certain places, but the general look of the game is basically the same. Most of the UI changes are more obvious during specific moments within the game.

High Card

The first change I made was related to the high card deal that occurs at the beginning of the game. I was having a lot of trouble telling who had won the high card deal so I decided to make it more obvious by highlighting the character who has the high-card, and creating a text object above them that says “High Card”. This occurs for the winner, and also highlights every player involved in a tie if multiple players have the same high card. I also turned off the system that automatically starts the game after the high card has been determined, and gave the player the ability to choose when the game would start. These two changes together were a substantial improvement and made the whole high card process much clearer. Below you can see an image of what the player looks like when they have the high card, and what a tie looks like.

HighCardScreen

HighCardScreen2

Improving Alerts

The next UI improvement I made was related to the alert system I developed for the last update. Previously the alerts would disappear after a certain amount of time. This meant that if the player got distracted, or wasn’t paying close attention, they might miss what action the opponent took, and not know what was going on when they went to take their move. To prevent this issue, I made it so that the alerts stick around until the end of a round of betting, or until they are no longer valid. So if a player raises, all of the Called and Checked alerts disappear, but none of the Folded, and Out alerts disappear until the round has ended. Below you can see what the current alerts look like.

AlertRaise AlertChecked AlertFoldedAlertCalled

You can also watch this gif to see the alerts in action, and what happens when a player raises.

AlertGif

I also wanted to make re-raises clearer to the player. In a real game of Texas Hold’em, it’s not uncommon for multiple players to raise in the same round of betting, or for one player to re-raise another to try and force them out. With my previous system, only the most recent raise would be visible, so if the player looked away or got distracted, they may not know how the Pot got from where it was before to where it is now. To solve this problem, I made it so that when a re-raise occurs all of the existing raises get “demoted” and are moved physically downward out of the alert area, and grayed-out. This shows they are not the current raise, but are still relevant. This allows the player to step away from the game for a minute and come back still come back in without any confusion.

ReRaiseGif

The final small change I made to the alerts was the Winner alert that pops up at the end of a round to show who won. Previously this screen only showed who the winner was, but didn’t say how much they had won. I fixed this so that the win screen would a bit more informative, and below you can see what it looks like. Eventually I’m going to make it so that the win screen will also highlight what cards that were used in the winning hand, or say what type of hand the winner used.

WinnerAlert

I also added a Pause screen to the game for obvious reasons. Right now it doesn’t have any options, but I thought I should add it in now and get it out of the way. You can see what it looks like below.

Pause Menu

Implementing AI

By far the biggest things I added to the game for this update were the AI improvements. In previous versions of the game the AI was very simple and would basically just call in all scenarios. Obviously this didn’t make for a very interesting game. I finally set about solving this by implementing the AI I had been planning. With this update I implemented what I’m referring to as the first draft of the AI that’s used on the initial deal, before the flop is dealt, and I created an accurate system for Out detection. To gain a better understanding of exactly what I did with this update there are a couple poker concepts/strategies you should know about.

Chen Formula

The first concept I implemented is referred to as the Chen Formula. The Chen Formula is a simple formula that a poker player can use to determine whether the hand they’ve been dealt is really worth playing and betting on. Below you can see the Chen formula rules. Take the highest card in your hand and use these rules to determine your hand’s score:

  • Ace = 10 points
  • King = 8 points
  • Queen = 7 points
  • Jack = 6 points
  • 10 through 2 = half of face value (i.e. 10 = 5, 9 = 4.5)
  • Pairs, multiply score by 2 (i.e. KK = 16), minimum score for a pair is 5 (so pairs of 2 through 4 get a 5 score)
  • Suited cards, add two points to highest card score
  • Connectors add 1 point (i.e. KQ)
  • One gap, subtract 1 point (i.e. T8)
  • Two gap, subtract 2 points (i.e. AJ)
  • Three gap, subtract 4 points (i.e. J7)
  • Four or more gap, subtract 5 points (i.e. A4)

The examples used here come from SimplyHoldem.com

Once you have the score for your hand you can then determine whether a hand is worth playing by looking at your position in play(how early or late in the betting are you), and the actions of the previous betters. The later you are in the play, the lower a Chen value you can risk going in with. With this update I not only gave players the ability to check what their position in play is, I also gave them the ability to calculate their Chen value. Then, I took the standard betting principles/rules with the Chen formula and modified them based on the style or skill-level I wanted to model a given character after. So a fairly good player is going to consider their position and their Chen value when deciding whether to play. Less skilled players place more value on things like having a pair, even if it’s not a great one, having a high card, even if it’s not connected to or the same suit as your other card, and even use a flawed form of Chen evaluation. The really poor players also don’t consider their position since that’s something most players don’t do when they first start out.

By combining the basic principles of the Chen formula and thinking back to how I and my friends played when we weren’t as good, I was able build AI that could represent the different players in different ways. While I’m still tweaking how each player reacts, and what Chen values they will go in on, I have at least a good starting place for each of their pre-flop AIs. Below you can see a gif of a few different deals and how the players don’t always behave the same way. Right now Bernard and Yuri have particularly conservative play patterns so sadly they didn’t come in on any of these games, but you can still see pretty varied behavior among the other three non-player characters Roxy, Turbo, and Tom.

PreFlopBetting

Outs

The other major AI system I implemented is the ability for a player to determine how many Outs they have. In Hold’em, an Out is a single card which could be dealt that would make your hand the winning hand. Here’s an example: If you have an Ace of Diamonds, and a 9 of Clubs, and the flop is a 5 of Hearts, 7 of Diamonds, and King of Diamonds, then you could have the winning hand by getting any of the remaining Aces. That means you have three outs, since there are four total Aces in the deck and you have one of them.  Your hand could become better by getting a 9 as well, but those wouldn’t be Outs because you have to assume one of the other players has the King-pair and that would beat your 9. You also have 10 more potential Outs from the 10 remaining Diamonds in the deck which could give you a Flush. The problem with these Outs is that you’d need two Diamonds to make the flush, so no individual diamond could give you the winning hand at this point. Some people would consider those Half-Outs, but it’s a matter of opinion whether they should be considered.

This was a particularly challenging thing implement because of the difference in the way computers process information and how humans do. Thankfully, after some hard work I was able to make an accurate system to count how many Outs a player has. While I haven’t taken this system to the next step and started using it when determining actions and potential moves, I am well on my way to having the AI for post-flop play implemented.

Back-End and Debug Systems

Along with all the user and gameplay-centric updates I did, I also went through some of my old code and improved a number of things. I even eliminated a small memory leak I noticed. Doing this not only made the game function more smoothly, it also allowed me to create a debug mode where I can change the cards player have at will. Previously, because of the way the cards were handled, I couldn’t easily change the cards mid-game and testing certain scenarios was a huge pain. With the improvements I made to this version I was then able to make a very simple menu which I can use to change a card at any time and see the results almost immediately. At one point I was trying to track down an issue related to the way Straights are detected, and without this new menu and debug system in place it would have been a gigantic pain to find and resolve.

Art Progress

The final thing I want to mention in this update is the art progress. Sadly the art has not progressed much. While I’d like to think I’m an okay artist, character art is not really my specialty. With this in mind I decided it was better to simply contract out the character art and move forward with the parts of the game I am good at. I reached out to a friend who is an artist and we came to an initial agreement about me contracting her for art duties. While I’m still in the process of sending her information regarding what I’ll need for each character, what sort of style I want, etc, I should have the first sample image before the next update after the initial Character one. From there I can take the next step and either actually contract her, or start looking for another artist. I still plan on doing the environment and UI art if I can, but I will have to see where the game takes me and whether it is feasible as I get closer to finishing certain parts. Likely whoever I end up hiring to do the character art will do basic layouts for the environments and give input on the UI, but I’m still not sure whether I will ask them to do the full art for that as well.

Stay tuned for my other update this week, which will give all the details on the poker players available in the game.

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 3

So I’m back with another update to Pixel Poker. This time around I’ve made some pretty substantial progress, and set some goals. First, let’s take a look at the current layout for the game.

CurrentLayout

While things haven’t changed too much since the previous iteration, you will notice that I’m now going at full 720p resolution. On top of that, while the UI is still incredibly rudimentary, I have implemented a basic UI which allows the player to fully control their betting. Speaking of betting, as of this update I am all but done with the actual gameplay elements. At this point the only thing I have left is to implement a game over/win screen.  Beyond that, all of the actual gameplay elements work perfectly and you can successfully play through a round of poker. If you watch the gif below you will see me play a few hands against 7 AI players.

MultipleHands

Right now the AI players aren’t very good and only consider the value of their hands in the most concrete terms. They do not yet consider the quality of their hand relative to the cards shown on the field, or the potential quality of their hands. On top of that, the AI players also can’t vary their bet size at all. While the AI is very simple though, the functionality is all in place and at this point it is simply a matter of me developing the actual scripts for their AI. I’m also pretty proud because I was able to successfully get the characters to wait before taking actions. When betting they currently only wait a uniform amount of time, but once I start programming the AI it shouldn’t be too hard to setup pseudo-random lengths of time for the players to wait based on the quality of their hands, their nervousness/confidence, and the amount of money they have relative to other players.

At this point I am attempting to complete the game this month so that I can enter it into to 2014 Indie Game Maker Contest. Sadly the contest was only announced a few weeks ago and I had already made some unbreakable plans which will prevent me from working on the game for around 4-5 days in the middle of the month. Despite that though, I’m using the competition as motivation and doing everything I can to achieve the goal. I think the biggest obstacles are the AI and the character animations. Since poker is as much about body language as it is about the actions someone performs, it’s very important that I create good character images/animations which are representative of what the AI players are feeling or doing, and give the real player enough visual cues to see when the AI are bluffing. Thankfully I may have a friend who can take some of the burden off my shoulders. I cannot say how much that will help, or if it will allow me to complete the game on time though since their role would not fill one of the primary needs of the project and would only potentially save me time if I can reach some of the stretch goals. Either way, I will continue working hard and making progress to achieve the goal.

From here I am going to track down the last bug or two I have related to gameplay, start working on the final UI, and begin developing the menu system. I will also begin doing all of the planning work for my AI characters. While I would like to focus on AI entirely, I often leave things like menus for the end and get distracted by other concerns. This ends up causing me to rush menus at the very last minute and cobble them together hastily. While the AI is very important, I know the menus, and a few other small features I’m looking to implement, will be easy so I want to get them out of the way now. Doing it this way will allow me to spend as much time as possible during the last few days of crunch focused on getting the AI as perfect as it can be, without any other distractions.

That’s all I’ve got for this update. Check back again this time next week, and I will have some major UI/menu updates along with the first few stages of AI character development.