Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
Here’s your intrepid, randomly-generated crew. With cool sunglasses. You’ll have to earn those.
This is actually my first Unity game that’s not a team game. Let’s see how badly it goes!
I made it. I was reckless, I worked on the build system for almost a full day before starting work on the game itself! Needless to say, much was cut, but I’m still pleased with the result.
It’s a damn short game, that’s what it is. Time to sleep, I’ll play your game tomorrow… but first, a post-mortem.
What went wrong: Working on a build system for almost a full day (9PM Friday to 3PM Saturday). I was in the middle of reorganizing all my game projects when Ludum Dare hit, and I really just wanted to finish the job. Game physics was a pain, as usual. Didn’t get enough sleep.
What went right: Having used P2 and Phaser separately, there were a few things that were much easier because I was using them together. For example, teleporting a physics-enabled sprite in Phaser was a bit of a pain and web searches revealed no solutions, but it became much easier when I just dived into the guts of P2. I felt like feature prioritization went fairly well once I was actually working on the game, and I didn’t dawdle polishing irrelevant bits like I sometimes do (with the exception of the build system).
I feel like this is the first compo game I’ve done where all the pieces are there, so to speak. Animations, sound effects, and levels are all there. Just not very many
To test game balance, I wrote a script to test combat between all possible shapes you can shift into. It’s basically an automatic 2v2 arena with the results summarized in a table. The first number in each cell tells you how often the monster to the left wins, and the second number tells you how often the monster at the top wins.
So you can see that the “air” monster is quite victorious, only losing fights against the mage–and even then, it still wins 22% of the time. I’m going to have to nerf that monster a lot. Or maybe I’ll just stick it at the end. The bat is also a bit overpowered.
“Unicorn” and “glip” don’t win, but they’re not really supposed to win by themselves.
I’ll have to cut my participation short this year, but by no means am I going to give up. Just going to have to make it smaller! I’m going to try and squeeze everything into 36 hours or so.
Going to use raw WebGL again, and this time I’ve got most of a proper text system. I can mess with the text in the vertex shader, and get nasty output like this. And hey–it handles kerning properly and calculates line breaks with the Knuth-Plass algorithm, because I have fun overengineering things.
Chaos Tomb is too hard. What makes it too hard? Short answer: I made the treasure too hard to reach, so players were poorly equipped to play the game. I should have made weapons and hearts easier to access, and hidden something else (gold coins, stars, collectible keychains) around the levels to challenge players. For the long answer, see the full article, complete with visualizations using D3.js.
The game does report some basic progress stats to me, and I’ve been checking up on how well you guys are doing. It’s a bit humbling, to be honest! It seems like my game is hard… even too hard… unless, like me, you were playing it and tweaking it for 72 hours straight. Not even one player from the Ludum Dare website has visited all 14 levels in the game, although a couple players have come close.
Went worse than expected
It’s not obvious what to do. To be clear, you get in, pick up weapons, and get out. You don’t need to clear the levels. The “exit” signs may be a bit ambiguous, too.
It’s not obvious that you can (sometimes) just run past the monsters. The first area with monsters also holds the first weapon. If I had put another area early on with monsters but no weapons, players would have been forced to run past the monsters without killing them, so they would realize that you don’t have to fight them. This is also a good strategy to use if you have the shield generator.
Picking up treasure—I wanted to reward exploration, but I was too miserly
The game is completely non-linear. It’s based around a hub, and players can explore as much as they wanted. But this meant that players often missed some items when they went on to play harder levels. I saw someone playing one of the later levels without picking up any extra hearts first—while certainly doable, they were having a rough time. I should have put more treasure in the player’s path early on. Especially hearts, which are more often in difficult-to-reach locations. In fact, now that I think about it, there is only one heart in the game that you can just pick up… the others require tricky jumps or other special techniques. If that one “easy” heart is hard to get because you get a bad weapon load-out, the game’s not going to get any easier.
The brick breaker—far too situational
The brick breaker is a garbage weapon. It wasn’t supposed to be quite so garbage. Unfortunately, I was unable to get it to bounce correctly off of the boundaries of the world. It could only bounce off of level tiles. Instead of putting ceilings on all of the levels, I let the brick breaker become a much too situational weapon. It also only bounces a couple times before exploding. Ideally, it should be able to bounce all over the place before hitting its target.
You can get two garbage weapons right at the start. I’m talking about the potato and the brick breaker. If you pick those two up, just go ahead and start a new game (unless you like the challenge). The game should only give you the potato once you already have a couple good weapons.
The gun—good weapon, no opportunities to use it
There’s no good opportunity to use the “ultimate weapon”, which is the gun. Once you’ve collected everything, there should be a final gauntlet to play through with all of the weapons and plenty of hearts. Instead, you just head back to the starting area and out the exit.
After We Saved the World is a tactical RPG with a twist: you start out with all of the characters, all of the best items, and all of the most powerful skills, and you must return everything back to the way it was when you lived in generic fantasy village #3. All in all, I’m counting this one as a success, but it was a rough ride.
What went wrong
Stubborn refusal to use an existing game engine. That’s right: the game is built on nothing more than WebGL and a couple random libraries like howler.js. Worse still, I came into this project with front-end development skills that were novice at best, so I had to sink a lot of time into learning how to use node.js and gulp and things like that.
Bad timing with work. I know—I’m who’s running this Mini LD, and I could have just chosen a week where I didn’t have as much of a conflict with work! But I just didn’t plan everything out well enough. A bit of stress and overwork had me on a bad sleep schedule before the project even started, but by the end of the week I managed to get some consistent good nights of sleep in.
Large scope. This is the perennial problem with Ludum Dare games, or games in general, or heck, software projects. A tactical RPG, what, was I insane? It turns out I just had barely enough time to get combat and basic game structure working before the end of the week.
What went right
Creative Commons assets. Even though I had always made my own assets for Ludum Dare in the past, I decided to go the Creative Commons route for almost everything except for music and a few odd UI elements. I managed to find some great sprites, textures, and icons on opengameart.org. Not only is it better than what I could have done by myself, but the whole thing even looks like it was supposed to fit together.
Rolling my own WebGL code. I know that this is also in the “what went wrong” column, but I’ve been doing OpenGL for long enough that my first thoughts after picking a genre were along the lines of, “ah, I know how I want to batch this data”, and “these are the shaders I need.” I even managed to simplify the pointer hit test code: rather than write a bunch of geometry code to calculate which tile the player clicked on, I just read the coordinates out of a special WebGL buffer.
Choosing a concept that is both new and fun. I love tactical games, and that enjoyment transferred well to the project. But I had never made a tactical RPG before—to be honest, I only ever played Avernum—and that meant I wasn’t rehashing a game that I had made before.
I’d post a link to my game, or a screenshot, but something is wrong with the time vortex. Check back later.
Another twelve cool games from Ludum Dare #31… Send me your game and I’ll record a video! I currently have a short backlog of requests, so if you made your request last time around, it’s on my list. But keep the games coming
The engine. I wrote the engine in C++ this time, and took notes from an article called “Programming M. C. Kids” Iz-Tavares and Chang. The platformer physics turned out rather well, and the game feels responsive but not crazy. There was even enough time for some tricky shader effects, and I’m going to show those off in a GIF:
Core gameplay. Once the gameplay concept got to its final, simplified form, I could focus on implementing it and writing levels. The level format was just ASCII text, so I could crank them out pretty quickly, and I ended up with 9 levels.
Sound effects. Just a couple hours with a microphone (and some music software) were all it took. There are 13 sounds with an average of 5 variations each, and the engine picks a variation at random each time a sound is played. The effect is rather nice, especially for the footsteps.
Dialogue This was the last piece of code implemented, but it gives crucial context to the game. The writing isn’t great, but I’m really glad it’s there.
Analytics. I keep a record of every time a level is beaten or restarted, along with a couple other things. Here’s a chart of the statistics for each of the 9 levels. You can see that about 60% of the players who start the game finish it, and players who get to level 8 restart it 2.5 times, on average.
Analytics for “Dreamless” by level
What went wrong
No tutorial. The game doesn’t exactly throw you into the deep end, but it does very little to tell you what you’re expected to do. This was painfully obvious once I watched someone else play the game. For everyone who played my game: thank you for taking the time to figure things out!
The worst part is the double jump. I was careful to make it so you could beat the game without the double jump, but there are some places where you have to restart if you don’t know about the double jump.
Slow start to the project. Looking at the commit logs, the game didn’t even respond to input until 16 hours into the contest, and jumping didn’t work until 21 hours had passed. I spent the time refactoring, messing with base code, and other things that don’t make games.
Not enough time on graphics and music. With only an hour and ten minutes left to go, I cranked out a music track and a bunch of sprites. I spent less than 10 minutes on music, and that’s including the time it took to start up the sequencer. I picked out two chords (Cm9 and Gm9), hit record, and rendered the result to disk without editing it at all. I even used the default patch you get when you start a new song!
Special thanks to Obsolete Entertainment, who put footage of gameplay for Dreamless on YouTube. In general, thanks to everyone who posts videos of the games they play!