Tag: Ludum Dare

Ludum Dare 29 results

Voting results for Ludum Dare #29 were announced earlier tonight. My Jam entry, Alamagordo, fared pretty well, considering:

Rank (of 1004) Category Score (of 5)
Coolness 100%
#69 Humor(Jam) 3.60
#110 Theme(Jam) 3.70
#424 Mood(Jam) 2.97
#546 Audio(Jam) 2.53
#581 Graphics(Jam) 2.80
#592 Innovation(Jam) 2.52
#648 Fun(Jam) 2.33
#662 Overall(Jam) 2.58

The 69 and 110 rankings are the best that I’ve done so far in a Ludum Dare judging, narrowly edging the #70 ranking I received for Humor in my LD25 game, Bad Puppy.

Considering that Alamogordo was a last minute entry that I threw together in about 10 hours development time, and was intended as more of a joke entry than a game with ambition, I’m pretty pleased at how it was received, overall. I was going for humor and theme, and the other categories weren’t as important for me — I only cared about making the game look, sound, and feel like an Atari 2600 game, and I’m reasonably pleased with my work in that regard. It’s admittedly not very fun to play, nor innovative, nor very good overall, so I feel like my scores are pretty fair overall. I was also very pleased by the fact that I was able to build the game very quickly, with no false starts, rework, or getting stuck in debugging. In my previous LD games, I often found that I’d get stuck on a technical problem that should have been easier to solve than it turned out to be, I think mainly due to self-imposed pressure. This time, I felt mentally unhurried, confident that I was capable of doing what I had set out to do, that I knew how to do what I was doing, and didn’t have to spend any amount of time experimenting and figuring it out, and that helped me to build a clean, well-organized project. Although the game isn’t much, I’m pleased with the code that I wrote for it.

Alamogordo: Post-mortem

I almost didn’t submit a game this time around. For some reason, I couldn’t get my creativity going. I thought that Beneath the Surface was such an excellent theme, too, with great potential. When they announced it, I started trying to think of a game that would happen underground, or under water. But all I could think of was the setting, not what you’d do there. My brain was being an enemy to me.

So I stayed up until about 6 AM Saturday morning, and still hadn’t thought of any good ideas. My best idea of the night came to me when the Neil Young song, “The Needle and the Damage Done” popped into my head, and I briefly considered making a game about heroin use and damaging the skin beneath the surface. If I wanted to do that right, I needed to make a chiptune cover of the song, and I still can’t do music properly. One day…

So, I put that idea aside, and then nothing else came to me. I slept in until around 11:30, and spent most of the afternoon sitting around, waiting for inspiration to hit me, but nothing happened.

I dicked around on the internet, reading stuff, and started reading all these articles about the New Mexico landfill dig, where they were trying to determine if the legends of massive amounts of unsold Atari merchandise being buried in the desert were really true.

Turns out, they were true!

I found the story fascinating, because why would people still care  that much that they’d dig around in a land fill trying to find that stuff. It’s not as though E.T. was a rare and valuable game. To me, the story wasn’t fascinating, it was people’s fascination with the story that was fascinating. It seemed to be getting a lot of coverage in the media.

I still didn’t have any ideas for what would be a good game, and by around 5 or 6, I had given up and resigned myself to not producing anything this time around, and felt pretty down about my failure to come up with any good ideas. I had a relaxing Saturday evening, went to bed, had a pretty normal Sunday, and then, around 7pm it occurred to me that the land fill dig was happening beneath the surface of New Mexico. Beneath the surface…

Beneath the surface…

Beneath the surface…

Beneath the surface…

neath the surface…

the surface…




And I got this visual in my head of the pits in the E.T. video game, and connected that to the landfill, and immediately realized that there was a potential game in there.

Digging in the Alamogordo, New Mexico landfill, in a pit from the E.T. video game, searching for the secret stash of E.T. videogames. I knew exactly what I wanted it to be, not really a challenging game, just an idle time waster that paid homage to the legend and the events of the weekend. I had less than 2 hours before Compo deadline, and knew I’d never make it, but this would need to be a Jam entry anyway, as I wanted to use graphics and audio sampled from the E.T. video game.

Unfortunately I was already on my way to spend the evening with friends, and I didn’t get home until close to 11pm. By 11:30, I had just gotten started, and I worked through the night until 6:30am, and which I had most of the level laid out and working. Movement and collisions were very buggy, but the game was basically playable by this point.

I took a power nap, worked Monday, and then cranked out bugfixes until I got everything working right. All told, the game took about 10 hours to build. My fastest development time ever. Howard Scott Warshaw took 5 weeks to make E.T., his fastest development time ever.

I used that time rather well, struggling only a little bit with the bug fixes, and all I really needed to fix those bugs was to step away from the project and return to it fresh — once I did that, it was fairly easy to redesign the code that handled movement and fix the problems I’d been having in the wee hours of the morning earlier in the day. Throughout the project there was very little re-work, almost nothing thrown away, and everything that I built was done in such a way that it doesn’t feel like a mess. The project code is actually pretty decent. Almost every LD48 that I’ve done so far, I’ve struggled with some stupid error in a feature that should be very basic and easy to do, and ends up sucking a lot of my time away from the project, but this time, I worked effectively from start to end. Only, I had just about 10 hours of work put into the project over the entire weekend.

The game itself, well there’s nothing much to it, but it does feel somewhat like one of those terrible shovelware titles that caused the Great Crash of ’83.

So, there it is, an homage to terrible games. Since that’s what it is, it somewhat excuses it from itself being a fairly terrible game. At least the programming is fairly decent, …beneath the surface.

Well, play it and see what you think.


Ludum Dare 29

I didn’t complete an entry for Ludum Dare 29, and am a bit disappointed in myself. Although the theme “Beneath the surface” is an excellent theme suitable to all kinds of ideas, I struggled to come up with a concept that fit well with the theme. I thought about under ground, under water, and digging a bit, and I thought about skin, and metaphorical ideas, but these didn’t inspire a core play mechanic or goal, so I never really got to a playable game concept.

I need to figure out how to get myself into a creative mind on demand.


Around 7pm, inspiration struck. I made a game after all. I made it in only about 6 hours, so it is not a very good game, but the idea was a fitting one, and I knew that I would be able to build it in under a day.

Alamogordo, my entry for the LD29 Jam, is based on the legend of the buried E.T. cartridges in Alamogordo, New Mexico, that were dug up over the weekend.

Game review: Javel-ein by Daniel Linssen

I loved Javel-ein when it was first released as a Ludum Dare 28 Jam entry. It’s been expanded into a “Full Game” — I put this in quotes because, other than perhaps a lack of background music, there wasn’t anything about the Jam entry that felt incomplete or less than “full” to me. TL;DR: it’s a great game, it’s free, and if you run Windows, you can play it.

Get Javel-ein.

Game Play

You’re a guy armed with a Javelin, jumping and running through a 2D platform world of caves and lava pits. There are dangerous creatures, which you’ll need to kill with your Javelin. Once all the creatures are destroyed, you need to find the door to take you to the next level. The twist is that you only get one Javelin, and you have to retrieve it each time you throw it, leaving you temporarily defenseless. (more…)

Updated Javel-ein released

One of my favorite games to come out of Ludum Dare 28, Javel-ein, has been developed into a full game by its creator, Daniel Linssen. I was amazed with how polished and balanced the original version of the game was, so this expanded version should be a real treat to play.

I’ll probably post an update with a full review once I’ve had a chance to play it. Review here.

Gearing up for Ludum Dare 28

I’m getting myself ready for LD48-28, deciding my general approach to take to this project. I like to do this ahead of time so I can get certain design considerations of the way, impose creative constraints, and focus on a particular goal within the scope of my project, independent of the theme.



GameMaker Studio

As usual, I’ll be making use of GameMaker Studio for my development, and probably only targeting Windows .exe build for the initial release, with a possible HTML5 build eventually if feasible.

I don’t have any particular aim this time around to use any specific features of GameMaker, we’ll leave that up to the theme and game concept to drive those decisions this time.


Paint.NET, and Pickle

I’ve given the new Pickle 2.0 a try and while it’s no longer free/donationware, I do think that I at least like it for its onion skin feature that enables easier animations. I can see a lot of potential improvement for Pickle, and to that end I’ve written up a number of feature requests and enhancements and sent them along to the developer. I’ll be really excited if any of them get picked up and implemented.

I am going to use my pixel art minimalism technique, and also I intend to use a tightly constrained color palette. Not sure yet how few colors I want, but maybe a 4-color monochrome palette a la classic GameBoy would be fun. In any case, I’ll be making an effort to use only the smallest number of colors necessary, and paying close attention to how color works in the graphics I develop. I am going to see if Paletton can help me make better palette selections, and if I can apply what I learned from this coloring tutorial that I recently came across thanks to Joe Peacock’s recommendation.



Bfxr, of course, for sound effects. Maybe also some recorded audio samples for stuff that I can’t do well in bfxr.

Famitracker (maybe)

It’s probably still ambitious for me to try to pick up and learn Famitracker in a weekend and use it to good effect. I’ve been putting off learning it, though, and I want to have some kind of bgm in my game. Whether I end up using it or not in my LD project, I’ll be making an effort over the next few months to figure it out and put together some compositions with it.

Ludum Dare 25 Rankings

I was pretty pleased with how Bad Puppy turned out, so I hoped that my placement in the rankings would be higher this time than my previous entries. I did see a modest improvement in my scores overall.

Bad Puppy LD25 Ratings

Ranking Category Score (out of 5)
Coolness 100%
#70 Humor 3.55
#274 Fun 3.04
#312 Audio 2.57
#426 Innovation 2.71
#450 Theme 3.00
#490 Overall 2.76
#526 Mood 2.47
#636 Graphics 2.18

The 70th place (out of 902 Compo entries) in Humor is the best ranking I’ve had in any category in an LD compo game so far. So hey, that’s something. I’m in the top 10% in the Humor category.

Comparing to my previous LD games, here’s how I did:

Category LD23 LD24 LD25
Coolness 56% 100% 100%
Overall 2.76 2.82 2.76
Innovation 3.41 2.58 2.71
Fun 2.62 2.58 3.04
Theme 3.34 3.20 3.00
Graphics 2.75 2.22 2.18
Audio 2.07 2.60 2.57
Humor 2.07 1.86 3.55
Mood 2.68 2.70 2.47

I’m a little surprised that I didn’t do better in the Graphics category this time around, since I actually had animated sprites in this game for the first time. And they were pretty cute, I thought, if primitive. But I am pleased to see marked improvement in Humor and Fun, which were the things I focused on when I made Bad Puppy.

Bad Puppy Design Analysis: The Bad

Recently, I wrote up a design analysis of my game for Ludum Dare 25, Bad Puppy. Mostly, I had positive things to say about what worked about the game design. Having continued to develop the game since then, and having played many more hours in testing and for fun, I’ve noticed some flaws in the design, too, so I feel like talking about them.

Difficulty depends on display size

I did all of my game development on a 1680×1050 screen. When I developed the game, I wanted it to play in fullscreen mode, with the room scaling up or down to fill the display. I coded a routine that dynamically sized the “room” to the exact size of the display. But, although the room changes size, the player and enemies do not. Since they do not scale up or down, this means that on a larger screen, the player has much more room to run around and avoid the enemies, which makes the game much easier; conversely, on a smaller display, the game is much more difficult. I felt like the game was about “just right” at 1680×1050, which means that above that size it’s probably too easy, and below, too hard.

This also means that high scores are not directly comparable on different systems. I will have to keep this in mind when I eventually implement the online highscore system. Either I’ll have to standardize the room size, which involves its own trade-offs, or I’ll have to create different scoring categories for each screen resolution, and then do some order-by stuff with the query that displays the rankings, which fragments the player community.

Another shortcoming, on the Instructions screen, the text cuts off at the bottom if the resolution is smaller than 1680×1050. I need to fix this, but haven’t gotten around to it yet.

Safe Spots

Safe spots are places in a game where it is impossible or dramatically harder to get hurt. Many games, particularly in the NES era, featured “safe spots” as a kind of strategic place where you could safely attack certain enemies, especially bosses. Safe spots can ruin gameplay if they make the game too easy. The worst offenders are games where you can just sit in one place, and hold down the attack button, and win. There is no difficulty to such a game, beyond finding the safe spot in the first place. Many games have temporary safe spots, which are better, because they give the player a short-term advantage that they can exploit, but they still have to remain actively engaged in order to prevail, and usually learn a pattern, or a behavioral trick that they can use to manipulate the AI to make the enemy do something stupid, like get stuck or attack in a way that always misses.

Bad Puppy does not have a static safe spot where you are always safe, but it does have a certain amount of exploitable AI behavior that gives rise to a dynamic safe spot. Because of the way I constructed the hitbox for the AI petters, if you walk upward you can avoid taking “damage” most of the time, as long as you can avoid walking into the bottom of a petter who is above you. The AI will continuously home in on you, so you always have to keep moving, but if you can run around the crowd of petters, they get herded into a bunch, and if you then stay above them, escaping through the top of the room when necessary, it’s pretty easy to avoid petting.

A skillful player should be able to discover effective tactics and use them in order to play for a better score. As a designer, I do want there to be ways to play that the players can discover through trial and error that will lead to improved scores. Ideally, though, the gameplay should be rich enough that there are a variety of valid approaches, and not one dominant strategy that breaks the game.

One of the weaknesses of Bad Puppy is that the gameplay is a bit shallow in this regard. I noticed this early on, so my very first post-compo improvement was to add a bonus pickup system. In retrospect, it was a pretty glaring omission from the original design. I wanted a retro style, and bonus pickups are a very common trope in retro arcade style games. Even though picking up the bonus items is completely optional, it still seems to dramatically change the way people play the game. People want to grab the bonuses, and are willing to take risks to get them, even though all they get is points, and even though it is safer to just concentrate on avoiding people and herding them.

Still, a frequent suggestion that I’ve received from players is to add additional mechanics to the game. They want the puppy to bite, or pee, or do something else besides just running and barking. So while the bonus pickups definitely added some depth, I’m not sure that they are enough by themselves.

What next?

All the other post-compo features that I’ve added so far have been cosmetic enhancements — adding a female petter, varying the skin color and clothes colors. They help make the game less visually monotonous and add flavor. I haven’t added any new gameplay features since adding the bonus system because I’m not yet sure from a gameplay standpoint what the game needs. The game feels a bit one-dimensional, but, aside from that, what’s there feels pretty balanced and fun, so I’m not sure what I should add next, or how it could integrate to the whole that is there already.

One of my goals with the You Are The Villain theme was to create a harmless villain, because I just couldn’t stomach making a game about a being a villain on the same day of the Sandy Hook shooting. And my original concept was to make the puppy a reincarnation of Hitler, who was weak and powerless, all bark and no bite. I liked the idea of a powerless Hitler. I didn’t want to make the puppy so bad that he could actually hurt people, and I’m not clear how either a pee or a bite mechanic would add depth to gameplay. The existing gameplay, while shallow, is pretty solid, and new features should not feel “tacked on” or ruin the balance of existing play mechanics.

When adding gameplay features, I think it’s important to be gameplay-centric in your thinking. The suggestions I’ve received, I think, have been character-centric; the feedback feels like it came from asking the question “What else do bad puppies do?” In my opinion, merely adding features to the puppy to give it more attributes of a real-life puppy would not be good for gameplay. Better, in my opinion would be to make observations like, “I’m running away all the time. I find myself wishing I could get the upper hand.”

One thing that could lead to deeper gameplay would be a mechanism that resulted in some sense of advancement. It would need to be necessary — something the player has to do in order to keep playing, and that gives the player a secondary goal and sets up internal conflict between barking/running and whatever the secondary goal is. I plan to explore this idea and see what I can come up with.