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:


 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:


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.


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.

Project Spark and more Zombie Mall…

Okay, so I haven’t gotten as many opportunities to work on my zombie game this week as I originally hoped, but I was still able to make some improvements since I posted the Post Mortem. Here are the additions I’ve made in this version:

  • Added a rudimentary “lighting system”.
    • It’s not really a lighting system, but it severely limits the area the player can see clearly. On top of that, it doesn’t make the rest of the game pitch-black, but it does make it very dark, and thus zombies can more easily take you be surprise. I’m going to keep working on it and am already working on a true lighting system, I just wanted this uploaded for now.
  • Fixed an issue where your ammo would not reset when you started a second or third game.
    • Previously, any ammo you used or gained in a previous concurrent session would still be used or gained when you started a new game. I’ve fixed it so that the ammo variables reset correctly each game now.

As usual, click the image below to go to the game:


The other thing I wanted to mention in this post is that I was able to get a Project Spark beta key yesterday. I will be downloading the game soon and hope to start playing with it tonight or tomorrow. I’m going to see what I think of it overall, and depending on how I feel about it, I may try and use Project Spark to build my game for the Global Game Jam. I’m not sure if it will work out since I don’t really know how I’ll feel about the game yet, but I am tentatively excited about it. In any case, I’ll have some thoughts on the game posted soon, so be on the lookout for those.

Ludum Dare 28 Post Mortem…

Okay so I guess I’m a few days late in putting up a Post Mortem for LD 28, but life gets in the way sometimes, so better late than never.

Before I start talking about my game and what I learned, you can click the image below to play the version I ended up submitting.

My LD 28 Game - Zombie Mall

While you’re at it, you should also check out my game’s page on the LD website, where you can see the feedback I’ve received.

I’m going to start off by saying that I’m mostly happy with my game. By no means did the game turn out perfectly, but to say that I failed would be inaccurate as well. I think for a first attempt at a solo game jam, I did a pretty good job. Most of the feedback I’ve gotten up to this point has been pretty positive about the gameplay, and has otherwise been directed towards the lack of polish/animations, and towards little things that could be changed or improved. Despite what I considered to be a lack-luster idea, many people seemed to like my game and thought I did it in a unique way. So before I get into the nitty-gritty, let’s talk about what my game was, and what it was trying to be.

The Concept

If you read through my previous 5 posts you should have a pretty good idea of the game’s concept, but just in case, here is an overview. The theme of Ludum Dare 28 was You Only Get One. I used this theme in a couple of ways.

The game itself was a pretty standard survival-horror/zombie game done from a top-down perspective. To integrate the theme I first used the obvious idea that if you are hit once by a zombie, you lose. On top of that though, I wanted to add an extra stress/horror element to the gameplay to make it challenging. To do this I made it so that the player could only perform one action at a time. For example, the player cannot run while they are shooting or reloading. If I had gotten the chance to implement it, the player also wouldn’t have been able to have their gun out while moving objects and constructing barriers.

The idea here was to make the game challenging and stressful by forcing the player to always be considering their next move, and to be very wary of the environment they are in when doing things. I also wanted to make the game somewhat realistic with this. If you concede to the fact that my character is not a trained marksman or combat specialist, it’s unlikely he would be an accurate shot when standing still, let alone when moving around with enemies coming from all sides. To that end, I also played with the way reloading works. In most games you reload your guns based on the clip. So if your gun’s clip size is 50, you reload up to 50 all at once. I wanted it to feel more stressful so I decided that instead you would reload bullets one at a time, or they would reload over time. This has been done in some other games, and I thought it would add a nice effect to do it here.

Beyond these ideas, there wasn’t much more to the game. My personal opinion is that wile the game did fit the theme, and was fun to work on, competitions like this are the most fun or the most interesting when they explore a concept you would be unlikely to sell to a larger publisher, or which would not at first glance seem like it could be a financially successful game. In that respect I do think I failed, simply because the concept itself is not incredibly unique or revolutionary. With that said though, not every idea can spark a revolution, so you gotta go with what you have.


Overall, the gameplay felt the way I envisioned it when I first started. Even I felt the stress of having to worry about how much ammo I had, where I needed to go next, and whether I was ‘aggro’ing the zombies in the area. I also know based on feedback I received that other players felt similarly, and did get the experience I was trying to create. Despite this I received a few comments about the movement, specifically that the way the player locks to the direction they are moving felt unnatural and was annoying. The idea here was to make it feel like your character was stressed and was flat out running away without looking back, but it ended up just making the game feel strange when the direction would change in an instant.

While many of the gameplay elements I did include were successful, I wish I had the time to include a few more. I really wanted to give the player the ability to lay down traps for the zombies, and I wanted the player to be able to move large items that would affect the zombie pathing, and allow the player to construct barriers. These features didn’t come to fruition for a few reasons. First, I didn’t have the time due to poor planning. The trap system would have been easy, since I’ve built similar things before, but I didn’t plan my schedule well enough and kept putting it off because bigger things came up. Second, I didn’t plan the barrier movement idea well enough. I tried a couple different methods, and it simply didn’t work the way I wanted it to. If I had put a little more time into how it would work before starting on some earlier systems, I might have been able to get it in, but I didn’t want to risk breaking what I had to implement something that I wasn’t sure I could even use effectively. The game itself ended up being fairly short, modifying or expanding the level to make the system useful probably would have taken more time than I had, and I didn’t want to take that risk.

The lack of these features also caused another issue. Initially I had envisioned the player being able to move items, but didn’t want them to be able to unless they were unarmed. Because of this, I gave the player an unarmed state. When I failed to integrate this feature, I never thought to remove the unarmed state for the player. This player state ended up being mentioned in about half the comments I received on the game, between all the places I posted it, so I definitely think it detracted from the game that I left it in.

The other feature that received a lot of attention was the reloading. Many people seemed to like the way the reloading worked, but I did realize that my instructions themselves were actually unclear. In the game you use the ‘R’ key to reload. Each gun reloads at a different speed, and if you hold down the key the gun will continue reloading until the clip is full. In the instructions I failed to mention that you could hold the key down, and a lot of people thought you had to manually press the button for each bullet. While this is fine for guns like the pistol and shotgun which each take less than 10 rounds in a clip, the machine gun and flamethrower would end up being a pain to use since they take 60 and 150 rounds respectively.

Level Design


In the end I think the level itself turned out very well. I didn’t have the time to make sprites for most of the in-game objects/props, but the level layout seemed mostly successful, and received very few comments.

One comment I received about the level was positive, and mentioned that the player liked how the extra ammo was mostly in corners, and it forced them to take risks to receive the bonus. I also received a comment from a player who didn’t think the goal was clear enough. That was the biggest fault with the level design. While the level does a great job of giving the player an environment to explore and mess around in, it doesn’t do a good job of guiding the player to their destination. On top of that, unless you read the instructions, you probably won’t know where to go. So in the end, the level layout works, but the scenario design could definitely be improved.


The graphics for the game turned out better than I expected. The sprites I made may not have been masterpieces, but they came out better than I expected.


The biggest comments I received about the art were that I needed animation, and it didn’t fit the style of the game, and I honestly can’t argue with either of those points. I went with a sprite look because I love classic games and thought it would be fun to try my hand at it, even if it didn’t turn out well. While the sprites themselves aren’t bad, many people commented on the fact they thought the art could be darker, or that the art was too bright. Considering I was attempting to make a zombie game, they thought I should have put more effort into creating a mood with the art. As for animation, I simply didn’t budget my time well enough. I actually had animated a walk cycle for the main character, but I had a lot of trouble getting to work . Eventually, since I couldn’t solve the problem, I decided to move-on and use non-animated sprites. I didn’t realize what I was doing wrong until a few hours after the competition ended, and promptly kicked myself because I was making a mistake that seemed simple in retrospect.

Thinking back I wish I had spent more time practicing striping beforehand since I had a strong feeling I’d be using it in the game. On top of that, I wish I had looked into how to simulate lighting with Construct 2, since that would make a huge difference in the game’s feel.

What I Took Away From LD 28

With all this in mind, I learned a few lessons from this competition:

  • Just because an idea doesn’t interest you, doesn’t mean it can’t be good – While I didn’t love my idea to begin with, I ended up enjoying making it, and a lot of people reacted positively to it. When the competition first started I spent 3 hours trying to think of a better idea, and lost some precious time because of it. Next time I participate in an event like this I definitely won’t dismiss ideas as quickly simply because I don’t feel as positive about them initially.
  • Budgeting time in advance is very important – Early on I made some assumptions about how long things would take, and assumed I would have certain amount completed by certain points. Despite this, I never sat down and actually wrote out how much time I was giving myself for each thing I wanted to do. This often caused me to go “over-budget” and spend more time on some tasks than I should have, especially ones which ended up failing. If I had set time limits on each task early, I may have been able to attempt more features or given up on failed ones quicker.
  • Focus on one thing at a time – Especially towards the end of the competition, I found I would often start one task, and then without realizing it jump to another that was tangentially related. This would leave me with a number of incomplete items that I would forget about and then need to return to later. In the last 12 hours of the competition I finally started keeping better track of the tasks I had, and worked much harder to focus on a single task at a time, no matter what else I thought of Those hours ended up being some of my most productive.
  • Quicker is not always better, even when the clock is ticking – One important element of the game was the zombie behaviors. Early on I used a very simple system to get the zombies following the player and it seemed to work. Eventually I wanted to make the zombies more complex, and found that because of the simplicity of my initial system, it would be very challenging to implement these new features. This forced me to switch to a more complex, but more versatile system later on and I ended up scrapping most of the old one. If I had taken more time to consider the pros and cons of each option early, I may have been able to use that time for better purposes and make the zombies more “intelligent”.
  • Keep track of how much time is left – Towards the end of the competition I was under the assumption that it was ending at 9:00 pm my time, when in fact it ended at 10:00 pm my time. Because of this I rushed to complete a few features, and spent time exporting and “finishing” my project so it could be submitted. I then saw on the site that I had an extra hour and rushed to complete/polish a few more things. While this mistake was good in the end, I still ended up exporting my project multiple times, and wasted time thinking I didn’t have the time to do anything else. If I had kept better track of the time I had, I might have been able to accomplish one more small task.
  • Do more outside playtesting – Due to time constraints and other factors, I didn’t do too much outside testing, and most of the testing was done by me. If I had brought over some friends to test for me, it would have shown me a few small bugs sooner, and it would have made it clear that some information wasn’t being conveyed correctly. Next time I will definitely plan to have people test for me at certain points to prevent this issue from happening again.

What’s Next?

While the competition is over, I did really enjoy working on this game, and it sparked a few interesting game concepts in my mind. My goal right now is to keep working on my project from Ludum Dare and to see if I can improve it based on the feedback I’ve received.  I’ve already started to do this, and if you want you can try the most recent version of my game by clicking the image below.


So far I’ve made a couple of different improvements:

  • I removed the unarmed state as a separate state the player can be in, and made it so that instead they can either have their gun out, or have it holstered. Now the player always has a gun equipped, it’s just a matter of whether it has been holstered or not. By holding the right-mouse button down you can take out the gun to fire, and reload. This preserves my intent to add movable objects which can only be manipulated while the gun is away, and makes it more realistic in some ways.
  • I added a message that tells the player he needs to reload or switch weapons because he has no ammo.
  • I changed the movement speed.
  • I added an aiming reticle for the player when they are firing.

On top of that, I am currently working on getting a lighting system in. I would like to use ray-casting, but it seems like that may not be possible in the engine I’m using. I’m currently looking into other alternatives, but depending on how hard or convoluted they end up being, I may just move to a new engine and restart development at some point. I am enjoying working with Construct 2, but I do constantly feel the limitations of the engine. My decision to switch will depend entirely on how the lighting ends up working out, and how serious I become about this project.

In the end, despite my failings, I still feel good about this project as a whole, and I took away some good lessons that will likely do me well in the Global Game Jam next month.

Ludum Dare Progress Post 5

Well, things have definitely gotten interesting since my last post.

In the time since the previous post I’ve done a lot.

  • I laid out, the entire level.
  • I came up with a full scenario for the game
  • I created a comprehensive list of assets I’m going to need.
  • I got the level into the game with basic functionality.

I wish I had gotten more done in the past few hours but I got distracted by a few things, and lost an hour or more of work because my computer insisted on crashing twice, and then Construct 2 decided to follow suit. Eventually the problems let up and I’ve been working consistently for the past hour or so.

The scenario I ended up going with for my level is a pretty classic one when it comes to zombie apocalypses, you are trying to get out of a mall.In this case the main character is stuck in a mall which has been locked down. It’s your goal to get to the security room and deactivate the gates so that you can leave. Obviously if you get bitten you lose.

Below is an image of the map I put together.


The gray areas, except where noted on the next image, are playable areas, but are gray because they have “fog of war” when youa re not inside of them. In my original plan I wanted to have a fake lighting system that would make it so that you could only see a certain distance, but that seemed too ambitious earlier today so I decided to go with something simpler. Currently you can still see what’s happening in a dark area, but it make it harder. I plan on eventually making it so that the dark ares light up when you are in them, and then slowly fade to dark again after you leave them to represent the information changing. I also plan on making it so that when a room is entirely dark, zombies are not visible to the player. Finally, I chose to make the main hallway visible at all times since it is the area the player will spend the largest amount of time in, and is visible from almost every room in the game.

Next is an image of the map as I designed it, and what every area is supposed to represent. You’ll also notice I’ve labeled where different pickups will go. Originally I was considering doing something like Left 4 Dead where the pickups are random, and you aren’t always in the same place, but right now I am going with a pre-designed arrangement.


Finally I have an image of the map labeled based on the frequency of zombies in the area. Yellow  has the lowest frequency of zombies, Orange has a mid-range, and Red has the highest frequency. This map does come from in-game, but I haven’t yet modified spawning so that it adheres to these rules, that’s just my plan going forward. I’ve already set it up so that the zombies only spawn in playable areas, I just have to start playing with the spawning system to see what I can do with it. even if I can’t get spawning to work this way though, I want to make it so that the zombies prioritize these areas based on the color, so they are more likely to go to a random destination they choose if it is in a red zone, than a yellow one. This would work well for gameplay since it would mean that the player would mostly be in high occupancy areas and would have to be very careful most of the game.


Well, that’s all I’ve got for this update. from here, I’m going to focus on making the scenario and things I mentioned above work. Then I’m going to add music, and sound effects. Finally, I’m going to work on the art. I wish I had the time to really put into the art, because I know I’ll enjoy it and be stressing about it later, but I think it’s important I get to the other elements first since at this stage they will have a bigger impact. Most likely I won’t be taking any more breaks beyond 10 minutes at this point. Luckily I still have almost half the time left.

Ludum Dare Progress Post 4

Things are coming along pretty nicely. In the last four hours I’ve done a couple of things:

  • I added a stamina bar which keeps prevents the player from running everywhere.
  • I redid the zombie movement with a better pathfinding system so that I can more easily change up the level configuration.
  • I re-evaluated the zombie pursuit AI and set it so that they pursue longer and see the player from a greater distance.
  • I set it up so that zombies will not longer spawn on the same screen as the player.
  • I created ammo pickups which can be randomly generated to be any type of ammo.
  • I changed the weapon switching system to use the mouse wheel,
  • And,I  fiddled around with player movement a bit.

At this point I am going to start fleshing out my level idea, and then I am going to implement it. I am also going to attempt to implement a mechanic which allows the player to move objects and create barriers for zombies. So conceivably they would be able to block doorways, or maybe even set traps for zombies. Since this would obviously affect level design I will do this before I start designing the level.

I also just posted a screen capture of a minute or two of gameplay on screenr.com The video doesn’t seem to want to embed in my blog for some reason, so just click the picture below and you can go straight to it.


At this point I’m going to take a short break and see if I can shovel a bit of snow since it’s been snowing all day here. but hopefully I’ll be back soon to add more functionality and get a basic level in place.

Ludum Dare Progress Post 3

Okay, I think it’s been almost 4 hours since my last post so it’s time for another.

Since I woke up I’ve been focusing primarily on enemy AI. Right now I have some decent slow-moving zombies which will alternate between wandering around the game area, and standing still doing nothing until the player comes within their field of view. Once the Player is in their field of view, or the player bumps into them, they will become alert and start chasing the player. as long as the player stays in their field of view, they will continue chasing him, but once he leaves their field of view they will only attempt to chase him for 4 seconds, and then they will return to their wandering behaviors. I originally had this set to 5 seconds, but decreased it after some testing. I’ll probably end up playing with those numbers a lot tomorrow, but for now I like them.


I don’t currently have anything in place that causes zombies to notice each other, and I also have yet to make any obstacles for them to walk around. I’ll probably integrate obstacles next, but I’m still not sure what I want to do for zombies noticing each other. I’ll probably deal with that once I integrate the second zombie type since it’ll become much more important at that point. If I had more time I might try and do some flocking behavior, but for now I’m going to stick with what’s working and try and get more features in.

The other thing I want to work on with zombies is setting it up so that they don’t spawn on the same screen as the player. Hopefully this won’t be too hard, but I have already thought of one or two issues that could come up.

On top of the zombies I also created a game over screen, and I gave each weapon a unique reload time so that they would feel more distinct.


After I finish the zombies I will move on to designing a basic level for the player to run around in, and will integrate some sounds to help make the game feel more interesting.

Obviously I’m still using a lot of temporary art. I currently plan to spend the majority of the second 24 hours working on art and animations, assuming that I don’t encounter any major hurdles completing the rest of the gameplay.

Finally, I also spent the last half hour preparing one of my upcoming meals in a slow cooker. It won’t be ready until about 9 pm, at the halfway point, but it should be a good way to relax at the middle of the jam. I also hope to upload the current version of the game here to my site around that point, but I’ll see where it’s at.

Anyway, that’s all I have to say for now so I’ll see you back here in a few hours…

Ludum Dare Progress Post 2

In my previous post I said I would be waiting till 7 to make my next post, but I’m starting to feel the lack of sleep so i figured I would post now instead and would take my first nap earlier than originally expected.

At this point I have given each gun a unique firing system, and I’ve created basic zombies. The zombies don’t currently have any working AI, but they do die when I shoot them enough.

Here is a screenshot of what it looks like when I use the flamethrower.


And this is what it looks like when I fire the shotgun.


Now that I actually have the zombies in game and dying, the next thing I do will be to add AI. I’d like to make it so that the zombies spawn randomly(right now there are just a bunch placed in random positions by hand), wander around randomly and in random intervals, and move towards the player when he is within a given range. I also want to make it possible for zombies to “hear” you when you are within a certain range, even if they cannot actually see you. If possible I’m also going to make a second type of zombie which will actively seek out the player or wander with more intent. I’ll see what time permits though.

In any case, I guess I’ll take a 2-3 hour nap, and then hit the ground running when I awake.

Ludum Dare Progress Post 1

Okay so Ludum dare has been going about 5 hours. while I wish I had gotten off to a faster start, I think I’m doing okay right now.

So far, I’ve set up some basic movement for the player, I’ve done some planning for what I want to have in my game, and I’ve started working on the weapon system. Currently I’m planning on having 4 weapons with 5 states the player can be in, Unarmed, Pistol, Shotgun, Uzi/Machine Gun, and Flamethrower. Most likely I will either add a melee weapon, change unarmed to be fists or a melee weapon, or switch the flamethrower for a melee weapon.

At this point I’m only planning on having two enemies, Slow Zombies and Fast Zombies, but I may add some others if I come up with more ideas.

Anyway, here are two progress shots. they look lostly the same except for the weapon that’s equipped, and even that isn’t represented on the player yet.

Shotgun UnarmedAs you should be able to tell, I am still using entirely temp graphics. I wanted to make sure that the gameplay was working before I started actually working on graphics.

Right now I have a pretty simple weapon system which allows the player to fire their weapons and reload( not at the same time though). I haven’t setup the firing system yet for the Uzi or the Flamethrower since they don’t work the same way as the pistol and shotgun, but that’s what I plan on doing next. From there I will most likely make some basic zombies to walk around and fight/avoid, and add ammo to be picked-up. Finally, after I have the basic interactive elements down, I plan on designing the level.

I’ll probably do my next update sometime around 7:00. See you then :)

Finally have an idea…

So it took me a while, but I finally settled on an idea for Ludum Dare.

I am going to make an top-down shooter which is a zombie game where you can only do one ting at a time. It’s not the most original game idea in the world, but I think it’ll be fun to work on, and it will allow me to make a horror type game and an overhead shooter at the same time.

Some of the things I want the player to be able to do include scavenge for items, shoot with various types of guns, lock doors, and build barriers. Also, the player will obviously die after 1 hit. There are a lot of ideas here that I’ve never done before, but even if I fail, it’ll be worth it to try and make something new.

Anyway, here are my tools.

Engine: Construct 2

Art: Photoshop

Sound: sfxr

Well, I guess that’s everything. I’ll try to have an update soon on my progress.


Post-Mortem: Match-3 Tutorial Series

The final article on the site

The day has finally come, after months of work I have officially published the last article in my series about building a Match-3 game in Construct 2. Having finished the series a few weeks ago I’ve now had some time to consider the series from more of an outsider’s perspective and I thought this would be a good place to share my thoughts on it. You can play the final version of the game here and I’ll be including links to all the articles I wrote at the end of the series, but for now, continue reading for an in-depth look at how long it took me to make this series, and what I’ve come away with.

Continue reading