Tabbed Menus

Tabbed Menus

Besides my pixel Poker project, there’s a smaller side-project I’ve been working on for someone. A few weeks ago I joined a group for indie game developers who were looking to connect with each other and gain assistance on personal projects. I thought it would be a good networking opportunity, and give me the opportunity to work on more projects. I was right too because shortly after joining I agreed to help someone by making a tabbed menu system for their game.

TabbedMenu

The premise for the game is based around running a ship in a sci-fi setting.I don’t know much more than that, as the lead on the project hasn’t given me too many details yet. I was asked to build an in-game store that the player could use to buy items, weapons, ships, crew members, and many other things. The primary requests were that the menu use a tab system for navigation, and a few basic requests about how it is laid-out. The process has been going pretty well so far, and I’ve made a lot of good progress. At this point I am able to create tabs easily when creating the menu, and I am able to add as many items as I want to a given tab. Above you can see a gif of me moving through the menu, and looking at the items that are for sale.

The layout and overall look of the menu is still not finalized and many of these graphics/colors are placeholders only, as I’m sure you guessed. I think there is a good chance the layout will be modified because there are major elements such as the players’ wallet, and the actual buttons that allow you to purchase items, which would be hard to fit on the current layout. This layout is the one designed by the project lead though so until he asks me to change it, I will be continuing to work with this one. That’s all I have for this. Come back soon, and hopefully I’ll have another update on one of my many ongoing works.

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.

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:

Screen1_05

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.

Gameplay

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

CommentedMap

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.

Graphics

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.

Characters

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.

 NewScreen

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.

Map

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.

CommentedMap

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.

MapWithPopulationZones

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.

VideoPreview

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.

Post3Screen1

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.

 Post3Screen2

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.

Flamethrower

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

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.