Tagged: ludum dare

I had originally planned on collaborating with a friend on the Ludum Dare 26 Jam, however, plans started to fall apart Friday morning when my sister went into labor. Long story short, the baby was born later that evening, and along with other family commitments, took up most of the weekend.

On Sunday I was finally able to sit down and start working on something. My mind kept going back to some sample code I had given a FlashPunk user in Afternet’s #flashpunkers earlier in the week. He was asking for pointers on a drag mechanic and I was able to offer a little help. This sample code was still sitting in my initial basecode project in FlashDevelop and I just started going with the seeds of a simple idea.

I wanted a game where the player had to think fast, but didn’t have multiple types of actions to perform. The Drag mechanic is simple, and everyone who uses computers should be familiar with it. I also didn’t want to have to explain the rules to the player. I wanted them to be able to discover the rules with visual and audible hints. I decided that simply moving objects into a target would be adequate to satisfy those two pieces.


So I worked on Sunday night and before long had the basic functionality down. There were some overlap issues that I had to figure out due to me forgetting that I was centering the origin, but that was probably the only thing that was a pain. After more work on Monday night, it was ready to turn in. I ended up with a progression of levels that started simple and ended up fairly frantic. I knew I was going to be dinged by some voters if I completely avoided instructions, so I put a little blurb on the webpage about discovering it as well as adding a hint to the end game screen if you didn’t make it past the first level or the first level with multiple colored targets. I hoped this would be enough to keep people from being frustrated or downvoting me because they couldn’t understand it.

(I have to say that with the Minimalism theme it is hard to balance the polish. I decided that not only is my gameplay going to stick with one basic action, but the graphics would be minimalism with simple shapes. However, I know someone is going to downgrade the graphics because there are so many more entries that are fantastic graphically. Should they be voted higher because it looks better? Or should the simple graphics games be voted higher because they are following the theme? I don’t know, there are many entries where I can’t for the life of me figure out what is being interpreted as minimal but will probably score high because they are good.)

Here is a video of myself playing the game. Reviewers have apparently done a good job scoring higher.

I think the fact I kept the gameplay simple but had something challenging and fun was great. I was focused on that without having to prepare and test other mechanics. The progression of difficulty was simple and changed things around while still keeping that simple dragging mechanic.

I would have liked a high-score option that reported to my webpage or Twitter, or at the very least kept your own personal high score offline. I didn’t get a chance to do that before the time limit. I also had to skip the sound/music toggle which would have been a nice polite addition.

I had the same thought that showed up in many LD comments: It would be fun on mobile. I would like to explore this. I think I’d have to change the underlying code for handling the dragging to support two at a time, because I know that would be intuitive on a device.

Check it out here.

The game started as an entry to the Ludum Dare competition over a month ago with the theme “You Are The Villain.” I completed a reverse-Pacman game where you controlled the ghosts in order to trap Pacman and keep him from gobbling up your pellets. There was very little AI in it. I have a couple pathfinding classes that it uses to pick the path from the ghost to the player’s cursor, so most of my time had gone into creating the pathfollowing code and trying to get that correct.

For One Game A Month, I continued to work on it. I revamped the graphics so I would not get into intellectual property trouble should I chose to sell it and renamed it LS-MAN. I refactored many parts related to the size of the cells and gameboard, rewrote the pathfollowing code, implemented a potential field to use for AI, surrounded the game with a main menu and end conditions, and generally tried to add polish.

I did a lot of this all at the same time, which was nice because I could do something else if I got bored. Unfortunately, it also made it take longer to get a playable game since I was putting things in that weren’t necessary for the minimum threshold where you can call it a game.

What Went Right

The pathfinding was a class that came from Untold Entertainment. I had used it before in some unreleased side project and it worked well, so I grabbed it again for this. It was easy to drop in and modify for my needs. There is a Node class that contains a lot of the implementation specific stuff. I ended up using the Nodes to hold most of my data for the map.

For the invader’s AI, I learned about potential fields from AIGameDev.com. It’s a method used in real-time-strategy where the goals and threats have positive and negative effect, respectively, and those values are radiated outward. This was a very CPU intensive step. I was using the Nodes from the pathfinding to hold the potential data and it was something that needed to be recreated often. If not, LS-MAN would be using stale data to decide his path and make a wrong move. It didn’t run too bad in Release mode, but the delay was noticeable every second or so and any delay would be unacceptable. There ended up being two solutions for this and they go hand in hand.

The first fix was to change how the pathfinding algorithm went about finding the nearby nodes. The pathfinding connected node function searched every node in the grid to see if it fit the requirement of being one away either horizontally or vertically. Regardless, pathfinding is really fast but we also know it’s not searching very many nodes in most cases to find a path, so this excessive connected node function wasn’t a huge deal.  However, the potential field calculation searches _every_ node which means every node’s neighbors are requested. And since there are multiple sources of the field, certain nodes could be recalculated and set multiple times. This was just not going to work.  I had made changes to the connected node function to enable the wrapping off the edge of the screen, so I felt that searching every single node to see if it was connected was not really that bad as long as we didn’t have to do it a lot. We do have an advantage–once loaded, the map doesn’t change. Therefore we could actually do the (relatively) slow calculation at map load time and store the result on the Node object. Now whenever potential field calculation or pathfinding needed to know what was nearby, it was returned quickly. This reduced the number of CPU cycles per frame a huge amount, but we still had a delay every few frames as it waited for the field calculation to complete.

The second solution was to refactor the potential field calculation so that it wasn’t doing it all at once. Since the default algorithm has you storing the to-be-calculated nodes in a queue, it was easy to add a state machine to it and iterate through that queue over multiple frames. Whereas before it was looping until the queue was over, my implementation would now also quit the loop if a certain amount of time had passed. In my case, it would only do up to 5ms per frame and then stop, letting the rest of the game continue, and pick up where it left off the next turn. Once it completed a batch, the old values were replaced by the new values, and the cycle started over again. Now when LS-MAN reached an intersection, he would look at the potential field values for each path and take the one with the highest value. This would lead him to pellets and away from the creatures trying to get him.


Debug mode screenshot showing the positive potential field of the pellets and the negative field given off by the creatures. Blue is a positive field, red is a negative field. Black is nothing. Upper left corner of each node is the actual value.

Super pellets were a different matter. In order to give LS-MAN some kind of above-minimal survival instinct, I had the pellets give off a large positive potential when LS-MAN was within a certain distance of a creature. This results in the appearance of him seeking a pellet when he knows he’s being actively chased. In order to keep the pellets around longer, I actually have them give off a negative field which should dissuade LS-MAN from choosing that path when no creatures are around and instead have him continue eating regular pellets.

In my original LD48 implementation, people said it was hard to select the ghosts. I took that critique and added keypresses that would select individual creatures, as well as adding buttons to the screen. If I eventually port to a touchscreen format, these buttons would be perfect.

I used OGMOv2 to create the levels. I really enjoy being able to rapidly create even though I only had two for the released game.

What Went Wrong

Not really wrong per-se, but it would have been nice to have had a working game earlier. I did spend the middle of the month focusing mostly on pathfollowing, even rewriting the code at one point, but I also spent a long time tracking down bugs that the game ended up ‘shipping’ with anyway. I should have noted that they were not show-stoppers much earlier and went on to finish aspects that would make it that much closer to a game.

I’m not really happy with the scoring. I knew time and the number of pellets should be the gauge, but I never had time to come up with a score based on those two values.

As time went on the code became more difficult to manage. I think it was because the board was lumped in with the main world code. They are tightly connected, which is fine, but I think pulling out the board stuff into it’s own class would have kept the code neater and probably easier to navigate.

I gave each creature different levels of ability to give them somewhat of a personality, but I’m not really happy with the level of balance. I never really got any external playtesting so I don’t know how they feel for everyone else.

Looking Forward

I would love to add high scores and new levels at some point. If I end up writing the server code to store scores, I would certainly add something that reports back.

Bonus Reading

Long after the point of no return I found this gem of a post at GameInternals.com. Since the goal of LS-MAN is different from traditional Pacman, the AI didn’t carry over much, if any, however I if I had seen it earlier I might have picked up the method of board construction and makeup for my own instead of using a static grid size for everything. I recommend reading, especially if you like simple implementations that result in the appearance of a more complicated intelligence.


It’s not perfect, and there certainly are bugs to be found (especially with the path-following code) but it’s well-done enough for me to call it a finished game. It’s a game with a beginning, a middle and an end. I think this is a great success.


Screenshot of the Classic level of LS-MAN.

LS-MAN is a reverse-Pacman game where you control the creatures in the maze and attempt to stop the invader from stealing all the treasure pellets. The object is to do in as fast a time with the least amount of pellets eaten as possible. You control the creatures with the mouse and can select them by either clicking directly on them, on their button or hitting keys 1 through 4 on the keyboard. Then you use the mouse to select their destination. The creatures all have different personalities, and as such, have different levels of focus and attention span, as well as speed of travel. You will notice that some of them will ignore further commands for a short time after being given a command, and also at some point forget where they were going and return to roaming the maze. When LS-MAN eats a special super pellet, he becomes Super LS-MAN and can, for a limited duration, neutralize your creatures and remove them from the maze. Be careful when directing a creature to the player near a super pellet.

Go check out my January game, LS-MAN!

My Ludum Dare Jam entry is Those Stupid Aliens. It’s a top-down space shooter.

The player is firing from a capital ship at the bottom of the screen. It has just gone through a battle, defeating the enemy battleship, stranding hundreds of aliens. As a result of the battle, it only has enough shields to withstand five hits. Your technicians are routing power and fixing subsystems, but they are tired. When you defeat a wave of enemies, it builds up the morale of the crew and they repair one point worth of shield. And that brings us to Those Stupid Aliens, and your job, as one of the last remaining gunners.

Using the mouse to guide the targeting reticule, and the left mouse button to fire, your goal is to shoot the alien ships that appear. They will show up in groups and express different characteristics based on the makeup of their internal properties. As the game goes on, the successful aliens will have their internal properties inserted into the gene pool, and the next waves will be created from this information. Eventually, you should see ‘smarter’ aliens which are more difficult to defeat.



The latest in the Ludum Dare 48 Hour competitions is less than a week away! Time to get out that base code and wait, right?

WRONG! There is so much for you to get ready and practice. You could be doing any of these:

  • Draw some sprites for a random animation, either directly in a bitmap editor or on paper and scan them.
  • Polish that basecode to fix that thing you found last compo that really bugged you.
  • Install GIMP or Audacity or other development related application and practice how to use it.
  • Pull out your microphone and record yourself and other sounds around the house to create a song in Audacity.
  • Create a Towlr.
  • Think of witty motivational posters.
  • Rip CDs to MP3s and create a great 48hr in-the-zone coding playlist.
  • Stock up on food for the weekend.
  • Clean and organize your desk.
  • If you are feeling adventurous, take your first steps with that new language.
  • Vote!
  • Spend some quality time with the family so they know you still love them when you ignore them over the weekend.

Whatever you do, please share it with us on Ludum Dare! And also, no matter how much or what it is that you do, you’re a winner in this pre-compo competition!

Of course, none of these things will actually be used in the LD competition since that is against the rules (except the basecode) however they can’t keep you from using the skills you just learned!

Like a broken record, my Java basecode for the Ludum Dare 48 Hour Game Programming Competition #16 is largely the same as the past two three four five competitions. I haven’t made any changes to it since the last compo, despite saying that I wanted to. Recently I have been dabbling with C++ again, though I don’t feel that I’d manage very well using it in a compo at this time.

Download it here.

Goals are pretty much repeating what I said last time:

  • Keep the same art style as last time.  I sketched things out on paper and scanned them in so I could colorize.  Keeping with bold colors and gradients is probably what I’ll do.
  • KISS – Keep It Simple, Stupid!  Making something too complex is just a recipe for a headache at 1pm on Sunday afternoon.
  • Make useful additions to the basecode that can be used in later competitions.  The screenshot stuff is an example of something I did previously that helps out a lot.
  • Finish most of the work by Saturday night so I can spend Sunday polishing.
  • Don’t run into dumb problems that eat up eight hours.

Tools in use:

  • Java 6 SDK (though last time I included a version for JDK 5)
  • Eclipse IDE
  • Photoshop, maybe some Illustrator
  • DrPetter’s sfxr for sound effects
  • Audition, if I can get it to play well with my sound card
  • HP OfficeJet 6450 All-In-One for scanning doodles
  • No Fear Energy Drink Sugar Free (Hopefully Boris Said and Carter Racing will run some Sprint Cup this year)
  • Everlasting Gobstoppers
  • mIRC for chattery
  • Killer Game Programming in Java and the base code I mentioned above.

Can’t wait to see what the theme is.  Hope it’s a fun one!

[This is a crosspost from the Ludum Dare competition blog.  You can download my entry here.]

This was probably the best Ludum Dare weekend I’ve had.  My game was more than just a tech demo or an ‘unfinished’ idea.  Of course, they never are truly complete after 48 hours time; there is always something else that can be tweaked or added.  When all was said and done, however, my entry was a playable game.


The theme was not one that I had put much thought into before it was announced so I really had zero ideas at Go time.  One thing that kept popping into my head was the Kroz series of games by Apogee software back in the late 80’s/early 90’s.  They’re all pretty much the same engine with a new collection of levels, but one was called Caverns of Kroz.  The object of the game is to take your hero through twenty or thirty levels to find or capture some relic.  Along the way you had to run, whip or out-maneuver swarms of monsters and solve puzzles.  I had always thought those games were neat, and it would be interesting to try and ‘recreate’ some of that nostaliga.  Caverns of Kroz didn’t have anything special that made it more caverny than the rest in the series, but I thought I could do better with actual graphics instead of ASCII art.

Kingdom of Kroz

Kingdom of Kroz


LoneStranger's Caverns


My basecode For LD48_13 is largely the same as the past two competitions.  I have updated it a little:

  • Classes are now organized into the package net.lonestranger.common, game and network.
  • Network isn’t really too useful yet.  The only class that exists in it is called Report.  It’s job is to take a string of data and send it via POST to a website, where it can be digested as fit.  For example, sending scores back to a central repository.
  • You can take jpg screenshots by hitting F10.  They are named based on the current date/time and dumped into the working directory. 

Here is the link to download it.

I didn’t really list my goals in my declararion post a few days ago, so I’ll do it now.

  • Keep the same art style as last time.  I sketched things out on paper and scanned them in so I could colorize.  Keeping with bold colors and gradients is probably what I’ll do.
  • KISS – Keep It Simple, Stupid!  Making something too complex is just a recipe for a headache at 1pm on Sunday afternoon.
  • Make useful additions to the basecode that can be used in later competitions.  The screenshot stuff is an example of something I did previously that helps out a lot.
  • Finish most of the work by Saturday night so I can spend Sunday polishing.

Ok, time to finish work and then I’m off to Thanksgiving, The Sequel, but I’ll check in after 8pm Pacific tonight to see the theme I need to start thinking about.  I expect everyone to be in FULL CODE MODE when I get back.  😉

The 13th Ludum Dare 48hr Game Programming competition starts this Friday, so it’s time to get the tools in order so there is less fussing when time is running short.  Also, my wife and I have been invited to Thanksgiving, The Sequel this Friday, so I won’t be home when the topic is announced.  I’ll try to check in to LD.com with my phone so I can at least start planning things out in my head.

So let’s take a look at what I’ll be using… (more…)

The next full fledged LD competition is still months away, but I was thinking the other day about concepts and ideas that I’d like to try.  If the theme is right next time, perhaps I’ll use one of these.

‘tabletop’ wargame – Something along the lines of Axis & Allies.  Simple combat and strategy.  Perhaps even as simple as the old Global War bbs game would be doable in 48 hours.  Global War was troops only, while Axis & Allies has many unit types. 

Economic/Military strategy – Like Nobunaga’s Ambition.  Might have to simplify the combat a lot in order to get it done in 48 hours.  It also would be difficult to balance and tweak the economics.

play by email game – There was a game a few years back where your Kung Fu fighter fought against another person’s Kung Fu fighter.  You would challenge them by sending them an email and then it would play the match, and send the results back to you and the main server.  After awhile you would level up.  It got kinda weird when you had multiple challenges out and leveled up after one of them, but I’m sure there is a way to work around it.

sidescroller – I’ve always sorta wanted to make one of these, but never really got around to trying it.  When I was in 3rd grade, my friends and I used to make video games–on paper–and it would be neat to actually do it.  I think I have one or two of these sheets back at my folks’ house, so next time I’m there I’ll grab them.

Driving game – I think if you break it down to the basics, and stick to simple features, you could do a driving game.  Wouldn’t want to overdo the physics.  I’m thinking a lot more like Outrun than Gran Turismo.

Sports – It would be neat to come up with some kind of new sports game that could be simple enough for a 48 hour compo… and also fun.  Combine two sports or come up with a new one. 

Any types of games you’d like to prototype if you had a chance and a compatible theme?