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.

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 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.

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.