This is the first LD I wasn’t able to get game play in by the deadline. This project is a long way off from being something that could even resemble fun.

Well, unless you like clicking a box with a check mark in it and knowing that underneath the scenes, it is now the next player’s turn. B-)

Here are screen shots of the project as it stands at the deadline:

As some of the IRC members noted, the attempt was still beneficial. I learned a lot this time around, and I’m better at game development for it.

Tags: fail

Win32 binary (currently unavailable): 2.4MB

Linux binary: 2MB

Ok, so this isn’t even close to a finished game, so you don’t have to play it to know that. However, I might still be able to pull a medal out of the food compo, so I’m submitting.

Tags: final

I fixed the build scripts and libraries so that it can create Win32 builds again.

It’s still not much, but if you are interested in judging it for the compo, check the link at:
GBGames Presents a Very Unfinished Game: Walled Off

I do plan on finishing this project so that it has some semblance of game play. I really liked what I was going for and feel pretty down about how little I accomplished.

Ludum Dare #15 is over, and I already wrote that the results are in. Aside from placing well in Community, which shows how much I love participating in LD48, I also saw my overall ranking come in at around the 40 percentile. I was ranked #63, which sounds good, but there were a number of ties for previous rankings. Out of 144 entries, Mineral Miner was 87th. It’s much better than coming in almost dead last in the previous Ludum Dare (and not completely last only by virtue of two other entries not getting rated at all), but I’ve done better.

Let’s look back on this project and see what happened. First, let’s go over a summary of the game. Mineral Miner turned out to be a puzzle game in which you drive around a cavern in a tank, getting out to collect minerals. You can only collect one mineral at a time, so you need to drop off collected minerals in your tank to collect more. If you are near a monster lair and not inside the safety of your tank, a monster will come out and chase you. If a monster catches you, you lose. If you collect all the minerals, you can leave the level and win.

What Went Right:

• Rapid Prototyping on Paper I took a free, online game design course at GameDesignConcepts.wordpress.com, and I was able to put use those skills to great effect. During the competition, I posted about my prototypes. With only 48 hours, it can feel painfully slow, but I iterated through the design, adding a new mechanic, trying it out, and deciding whether to keep or remove it, and then repeating until I had something I thought might be fun. Painfully slow? It took me almost no time at all. In previous LD48s, I’ve been known to add mechanics at the last minute in an attempt to make a game out of the code I was writing. This time, I knew exactly what mechanics I needed, and there were no real surprises here. The finished game ended up playing exactly how I hoped it would.
• Quick ‘n Dirty Graphics I’m not terribly familiar with art tools, such as The Gimp, and so every LD48 I find myself looking up how to use it to create what ends up being ugly art for my games anyway. I decided that this time, I wouldn’t try to make anything fancy. If I have any images that need text, I will use the basic text tool instead of the script-fu that creates cool looking logos if you tweak parameters just right. The tank? A square with a dot to let you know which way is the front. The driver? A yellow circle. Hey, it worked for Pac-man. I was able to focus more of my time on making the game because I wasn’t frustrating myself with trying to create halfway decent artwork.

  

  

• I Made Sound Effects This is my fifth Ludum Dare, and only the second time that a game I made had sound effects. Because I had a game that pretty much worked the way I expected it to, I had time for some polish. I made a list of sound effects I thought I would need, used sfxr to create the beeps and boops, and wrote the code to tie it all together. Adding sound really makes a big difference to a game, and I was glad that I could do so for this one.
• Faster Build Times and Lighter Distributables Because I had been doing some work on my Vampire Game, work that involves using TDD from the first line of code, I also did some work on my build scripts. Going from a 10 minute build time with a distributable that is already 10+MB due to including source libraries to a build that finishes in seconds and is less than 2MB is amazing for productivity, especially as it comes down to the final hour of the competition. Everything happened so much faster, keeping me focused on game development instead of getting distracted as I waited for a build to finish. Now, it isn’t as if my builds always took 10 minutes, but going from checked out source code to a complete build would. Once the libraries were built with my old system, compiling and linking would still take some time, much longer than the time it took with my new build scripts. Plus, one of the complaints I would get from previous competitions is that my game package was so large, so that’s one complaint I did not see this time around. B-)
• Simple AI Goes a Long Way I remember taking a few minutes to think about how I wanted the monsters to interact with the level. Should they obey the walls and other obstacles, like the player has to? If so, that would take a bit of AI programming. I don’t have much experience with AI, and I didn’t want to take the time to learn it for this LD48, so what did I do? I made the monster head towards the player every step, ignoring the environment. I could explain it away. It’s a monster. Maybe it climbs walls like crazy? The big surprise was how well it looked. Besides making it move towards the player, I also made the monster randomly move horizontally or vertically to do so. Combined with the sound effect when it comes out of its lair, the twitchy looking monster moving really fast at the player actually feels scary.

What Went Wrong:

• Distractions I have two cats, and both of them have been featured in previous LD48s, so I won’t focus on their antics too much. My home office wasn’t in a usable state, so I was out in the kitchen or living room. The cats love distracting me from productivity, and LD#15 was no exception. The one thing I did my hardest to control was external obligations. Anytime someone wanted to make plans with me for the weekend of LD48, I would politely tell them that I was busy. And it worked! I was able to focus almost entirely on eating, sleeping, and LD48ing…except for the Chicago Fire game.

  

  I won tickets to the Fire vs D.C. United game, which happened to be the same weekend. They were really good tickets, too, and so I made an exception. In practical terms, I lost a good chunk of Saturday. I was able to get the game finished, but having an extra hour or two would have been good for tightening up the graphics and audio. On top of knowing that, the Fire lost, so it wasn’t even as fun a game to watch from the 2nd row as it could have been.

• The Sound Effects Were Very Rough By far the biggest complaint from people playing my game is that the audio hurts. I was able to get audio in within the last hour of the competition, but I didn’t have time to adjust it. I knew that some of the sound effects were loud and obnoxious, especially the one that plays when you bump into walls, but I couldn’t dedicate the time to tweaking it. The deadline was looming, and I still had a few more programming tasks to complete.
• There’s Only One Level Right before the end, I realized that I did not have a victory condition. I had programmed a way to lose if a monster caught you and also if you tried to leave the level without collecting all of the minerals, but someone will eventually collect all of them. What then? Ideally, I would have added code to load the next level, created that level, and kept going. In fact, Level 2 is in the distributed game, although it is a copy of Level 1 and there is no code that knows about it. I was thinking about taking Level 1 and breaking it up into at least three levels, with each level introducing new puzzles and getting progressively more difficult. Three doesn’t sound much better than one, but it would have made a big difference. The player would have felt that progress was being made, and the later levels could introduce the trickier ways to deal with monster lairs.
• Level Loading Bug I could not figure it out in time for the deadline, and I still haven’t looked at it since, but every so often, the level loading code would choke on the data, bringing the game to a halt. Sometimes shutting down the game and rerunning it would work. The data came from a text file, and my code is supposed to load a single character at a time, mapping the value to a tile. Sometimes, however, it would choke because a single character variable would have a value that is two characters long. For a time, I was dedicated to fixing it, but with only 48 hours, a good chunk of which I couldn’t make use of, I decided that since it wasn’t a show-stopper, I would keep going. I really wish I could have figured out why that bug was there. Besides ruining the perceived integrity of the game, I know at least one person didn’t review it due to this crash.
• Making a Puzzle Game I didn’t set out to make a puzzle game. I didn’t want to worry about creating a lot of content. One level might not be such a problem if the level was varied and fresh each time you played. I could have created a procedural level generator, but I never built one before. I didn’t want to spend time learning how to do so, nor did I want to spend the time tweaking the algorithm to make nicer levels even if I did end up accomplishing it. Out of all of the ideas I came up with, the game I liked the most ended up being a puzzle game, which unfortunately meant I was either going to spend a lot of time making clever levels or finish a game with hardly any levels. It ended up being the latter.

What I Learned:

• Rapid Paper Prototypes Work My game design skills are sorely lacking, but I’ve been able to practice what I learned in the game design concepts course, and it really paid off with Mineral Miner. I’m not claiming that it’s a fantastic game, but it did rank #45 in the Fun category, putting it in the top 50%, and #27 in the Innovation category, which puts it in the top quarter! It feels good to know that the game design I prototyped early on before writing a single line of code came together, and the comments for my entry showed that people saw a lot of potential in my game. Everything I wanted to put into the game, I learned from minutes of drawing on paper and messing around with tokens. I didn’t need to have a game engine coded up to explore, discard, and introduce mechanics, which means I saved a lot of time that would otherwise have been wasted on code that would get thrown away and changed needlessly.
• Quick ‘n Dirty Graphics and Audio Can’t Be Permanent My art and audio work was minimal and saved me a lot of time, allowing me to work quickly at getting the game play up and running. Unfortunately, my overall rating got hurt here. I was near the bottom in the Graphics category at #104 and surprisingly a little better in the Audio category at #77. I was hoping for time near the end to replace crude art and sounds with better ones, but it didn’t happen. On that note, even if it did happen, it wouldn’t be more than marginally better since I don’t have the practice and skill with my art tools. One suggestion was to use images of my prototype work, and I agree, the drawings look much nicer.
• My Pacing Still Needs Work I felt much more confident about my entry this time around, but I still found myself finishing the game at the last minute. There’s very little time for polish when the complete game forms only an hour before the deadline! It’s especially a concern since I decided to go with quick and low-quality art in order to get the game running as quickly as possible. I probably could have set mini-deadlines for myself. 48 hours sounds like an incredibly compressed period of time to make a game, and it is, but it’s still enough time to flounder. Early on, I have two whole days to worry about everything. In the last 5 hours, I’m in crunch mode. I could stand to manage my time and prioritize my tasks much better.

If I could do LD#15 over again, I would try to manage my time better. I could have had the prototype work done much earlier on, leaving me with more time to do the actual programming and arting. I might have been able to get more levels and variety in if I didn’t waste 5 or 10 or 20 minutes at a time wondering what to do. Still, even though Mineral Miner wasn’t a winner of Ludum Dare, I felt it was a success. I designed early on paper instead of designing with hard-to-change code, and I was able to focus on making the game I felt had a chance of being fun. People said they enjoyed the game and wished there were more levels. It was a complete game, meaning that aside from the level loading bug I mentioned above, everything that happens in the game happens because I designed it that way. In 48 hours, a complete game that provided some entertainment for others is a good accomplishment.

It’s time to check out the final tallies at the MiniLD #20 page! Congratulations go to gold medalists ExciteMike for Fun, TimSwast for Game Play, and increpare for Presentation! Also, the gold medals for Coolest entries go to Breakdance McFunkypants, wyverex, and 31eee384!

I’d like to extend a big thank you to everyone who participated! It was a fun MiniLD, and I look forward to developing alongside many of you for the major LD coming up in a few weeks.

Pop-Cop

Tags: motivation

I did 5 LDs in a row, took a break, and now I'm making my comeback!

Tags: montage

It’s time to prototype some ideas! I have a chance to play with my new barrels and hearts!

But let’s take a step back and try to come up with some ideas. Assuming you play as the hero in the game, what are the various ways you could use enemies as weapons?

1) You could use the enemy’s body as a projectile. Your attack might send Enemy A flying, but when A hits B, B is hurt. Maybe A is immobile, especially if they are somehow stuck together now, as below:

2) You could force the enemy to use its own projectiles, which happen to be damaging to all entities in the game, including other enemies. Somehow, you have to provoke the enemy into attacking. In this example, you can see that the enemy throws out its spines, leaving it naked and vulnerable. It would probably need to head home to reload, and the other enemies in the vicinity were killed.

3) You could pick up the enemy, causing it to panic and flail. Until it can get itself free from your grasp, you can move it close to other enemies and let it destroy them.

4) You could use bait to lure enemies into combat with each other. When they see the steak in this example, the two enemies can’t help themselves. They love steak! Unfortunately, only one of them can have it, so they end up in a dust cloud. Only one will survive. And get steak.

5) You could take control of the enemy in various ways. First, you could attack an enemy, bring it under submission, and train it to fight for you. It’s kind of like a Pokemon or the monsters in Rune Factory, if you’ve played that one. Second, you might have the ability to control an individual enemy’s mind or take possession of it’s body. It’s kind of like the game Space Station Silicon Valley for the N64. Third, maybe the enemies all follow whoever holds a certain token or item, like a wand or staff. If you are in control, now the enemies are yours to command! Fourth, you can find a way to mount and ride an enemy. If you can do so, you can then use it to ram into other enemies.

So these are some of the ideas I have running through my head. Even though I’ve been thinking about sending enemies after an AI hero for much longer, I’m starting to like the mechanics listed here. Any thoughts?

I had some fig bars as a snack as the evening wore on.

My fantastic and amazing girlfriend made me a taco dinner, which was so delicious that my taste buds were fist-bumping each other.

I went to a party my friends were hosting so I could take a short break and get some much-needed social time, but I came back home shortly.

Looking at The Big (Cork) Board, I can see that I’m almost done with the first iteration of work.

Unfortunately, I still have 6 more big iterations to do, and a lot of it is doing AI path-finding and other AI things I’ve never done before.

And the deadline is looming.

I’m feeling pretty screwed.

Wait a minute. I think I have some Red Bull shots in my fridge…

I don’t drink caffeine usually, but desperate times call for desperate measures.

Let’s roll.

Tags: cool, foodphoto

I got to Iteration 3 by scrapping some of the art and animations I had planned for Iteration 2. Those story points go back into the backlog.

Iteration 3 was a bear. It was where a lot of the advanced AI had to be implemented. I’ve never done A*. Most of my AI was very simplistic, which went with the simplistic games I’ve done before. This game was going to be different.

Or at least I hoped it would. Entities would bumble about, get stuck, and fly off the world map even though I explicitly told them not to!

I had a quick lunch which was easy to make while I continued to work.

Unfortunately, the deadline for the main Ludum Dare compo passed when I finally figured out the A* algorithm (it turned out that there was a greater-than sign when there should have been a less-than sign, which is why the entities were moving so strangely). After the pathfinding, the entities still had to interact.

I had the Hero moving toward targets it sees nearby, although every so often I see that he gets stuck in a certain tile for some reason. Enemies seem to have trouble moving to the Hero like I expect, but they find him soon enough.

But with Iteration 4, they fight!

Do you see how the Hero’s health is down?

That’s the first time it has been like that outside of arbitrary tests being conducted. One of the dragons did that! Good job, my babies!

Since the main compo is over, the only option I have left is to continue on. I can still try to enter the Ludum Dare Jam, which gives me an extra 24 hours before the submission deadline.

For now, though, I’m going to bed. These last 48 hours have been grueling, frustrating, and exciting.

Tags: foodphoto

I missed the deadline for the main compo, but I can still submit my game to the Ludum Dare Jam. The deadline is 24 hours after the end of the compo, so I have until 9PM tonight to finish this game.

After a good night’s rest, I woke up with bug fixes. Seriously, I was lying in bed, slowly waking up, and I thought, “Oh, yeah, I implemented cooldown for the entities after they attack, but I forgot to ensure that cooldown ends.” I fixed a crash bug which also prevents the creatures from trying to leave the world map. And I improved the exploration mode of the AI so that the entities should no longer wiggle or fidget. They pick a direction and go until they reach it. I found that the reason why the hero was getting stuck in place. It was due to the fact that I was checking if he had reached a very exact location, and with his speed, he sometimes overshoots it. When he tries to go back to it, he overshoots again, forever. I enlarged the collision detection box to compensate.

When I finished Iteration 4, I found out that accidentally implemented some stories from Iteration which deal with entities attacking each other. I’ve simplified combat so if entities are not in cooldown and are touching, they’re attacking. That implementation left Iteration 5 fairly moot. In fact, I decided to skip the remaining story in Iteration 5 which dealt with some nuanced AI that I’m not even going to look at, so I’m on to Iteration 6. You can see the backlog of skipped story cards under the Iteration card.

I’m pretty excited. It’s only 10AM, and I’m on the last two iterations. Iteration 7 is basically sound effects and packaging the game up, and frankly (and sadly), sound is optional at this point. B-)

I’m at the final iteration!

Basically, the tasks I have left:

• create instructions screen
• add sound effects
• package this baby up!

In the last iteration, I was play testing and balancing as best as I could. I decided that the bat was too expensive, so I moved it down in front of the slime in terms of costs. I lowered the starting health of the Hero and gave him fewer lives. I also tweaked the level design a bit to accommodate the AI’s inability to see too far ahead. There are also victory and defeat screens now.

I finally got the AI working well enough that I realized that I wasn’t just debugging the program anymore. I was playing the game! And it’s actually not that lame! B-)

Here’s the time lapse for my 72 hours of development on Stop That Hero!

Tags: timelapse

I’ve updated my LD final entry page, but I wanted to let you know that I finally created a Stop That Hero! Windows port (2.2MB)!

Now you have no excuse not to play! Well, assuming you don’t use a Mac. Or some other OS. Then you have an excuse.

This entry was posted on Wednesday, August 25th, 2010 at 1:29 pm and is filed under LD #18 - Enemies as Weapons - 2010. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

In the final stretch, I can finally DO something in the game.

In the Move phase, I can select couriers and move them to open adjacent tiles.

In the Shove phase, I can select couriers and shove another courier, and if the shover has the package, it is passed off.

What’s left:
– moving the agents towards the package holder
– adding pedestrians
– moving pedestrians
– win condition check
– lose condition check

Can I get at least a good chunk of it done during Submission Hour? I hope so.

So 48 hours came and went, and I have no game to submit. B-(

In the last few minutes of Submission Hour, I finally had Enemy Agents who moved towards the package holder. I need to make sure multiple couriers can move at once during the move phase. The agents currently have too much of an advantage if you can only move one courier at a time.

I had to deal with a few seg faults getting to this point, but they were relatively easy to solve compared to what I’ve written about for this LD.

What’s left:
- moving the agents towards the package holder
– adding pedestrians
– moving pedestrians
– win condition check
– lose condition check
– allow multiple couriers to move during move phase

And I have 24 hours to get all of it done and submit a Jam entry.

Actually, I now have enough to submit what could technically be called a game if I can code up the win and lose conditions. They’re easy and low-hanging fruit, so I’ll tackle those first thing in the morning. It’s too bad I don’t have one more hour, and it’s too bad it took so long to start working on the actual game play. My game could have been among the nearly 300 entries if I had less to do from scratch.

The good news is that next LD, I might be able to take this project and gut out just the Hot Potato-specific parts, and I’ll be able to build a simple, LD-ready project from the moment the theme is announced. This LD showed me that I am finally starting to get a collection of boiler-plate code that’s easy to migrate from one project to another without too much hacking.

For now, I’m getting some rest. Congratulations to everyone who submitted on time, and good luck to all of the other jammers!

Tags: foodphoto

Here’s a video of my desktop through almost 72 hours of development of Hot Potato compressed into less than 2.5 minutes:

Tags: timelapse

I’m in. I haven’t decided if I am going to continue working in C++ with libSDL or if I will use Stencyl, but I’ll be participating in LD #24. It’s been too long.

So, the theme was announced, and it’s Evolution.

Now, Evolution is the theme that was the Susan Lucci of Ludum Dare themes. It always made it to the final round of theme voting and always lost out.

Until today.

And somehow, I’m unprepared for it. Out of all of this LD’s themes, Evolution was the one I hadn’t given much thought to. And I even voted for it!

I’m a little worried about this compo. This morning, I woke up with pain in my hip and back. Walking is awkward, standing is difficult, and sitting seems to make it worse. I don’t know how much time I will be able to dedicate this weekend if I can’t be in front of the computer.

But I’m sure as the weekend evolvess (see what I did there?), things will come together. I’m going to spend the first few moments just thinking about potential design approaches.

Good luck, Ludum Dare participants!

This entry was posted on Friday, August 24th, 2012 at 7:16 pm and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.