Ludum Dare 35 was a huge learning experience for me, so I thought I’d write up a postmortem or whatever!
1. Making a puzzle-platformer for a game jam, and you
The first thing I did was write down a bunch of ideas that came to mind with the theme, and settled on this one. I immediately came up with a few good ideas for puzzles I could do with the gimmick, but I wish I came up with more as the last puzzle in the game is embarrassingly easy! I had this big puzzle involving moving from the one side of the screen to the other planned out, but ran out of time and submitted it as-is.
Using polymorphism for the blocks saved me a TON of time. The player and the blocks all inherit from the same class, and the “floaty thing” object has a variable for which one it’s currently controlling. I’m very glad I happened to brush up on this before the jam.
By the last day of the jam, I more or less had everything implemented coding-wise, and ran into a level design panic. Many things that I wrote down on paper didn’t get put in the game, despite the code being there. One puzzle desperately needed a ceiling, another needed a door that closes behind you, a conveyer belt needed to be just a bit longer, a certain flagpole didn’t have to be there. The “unpossessable” enemies also needed some kind of indicator on the overworld that they couldn’t be possessed, besides not having a “core” when you try to take control. All of these things I actually had written down, but just never got around to doing them!
At first I thought that the solution to this would be coming up with 100% of the game within the first 8 hours and spending the rest of the jam making that game. I soon realized that this would make the game just feel… stale, and drew connections between this and the lesson on keyframing in “The Animator’s Survival Kit”. What I just described is similar to the “pose-to-pose” method of animating, drawing out each keyframe, and then adding inbetweens until it’s smooth enough. This gets an animation done on time, but where’s the fun in it? Another method of animating is the “straight-ahead” method, which is the way that you would animate in a flipbook. The problem with this animation method is that it might not stay consistent throughout, so you might not end up with something nice at the end. Finally, the “combination of pose-to-pose and straight ahead” method is usually the best way to animate. You draw out your keyframes, then animate straight-ahead between them. You know what needs to go between these keyframes, but have the freedom to do them however you want.
The same lesson can be applied to making jam games, just replace “keyframes” with “game systems”! That said, any method is fine for doing a game jam, just know what you’re getting into with each one. I mostly planned out my systems, but just wasn’t very good at coming up with additional puzzles under pressure, tbh.
2. Take 5 minutes to give yourself cheat codes
Honestly I must have lost hours to this. Every time I wanted to test out a later puzzle, I’d have to manually drag the player character there, collecting the “floaty thing” along the way. It would have taken me 5 minutes to write code that disables collision, lets me fly, and increases my speed by 10. So… do this, especially if you’re making a puzzle game where everything is in one scene!
On this note, I soon after found a plugin for unity that keeps objects locked to the grid, without holding down command. This would have saved me a lot of time if I had it. Editor cheat codes!
3. Polish is important, but playability is more important.
Some polish can be needed to make a game playable, as I cover below when I talk about floaty controls. What I’m talking about here is that if you’re running out of time and you still need levels designed and tested, mayyybe you shouldn’t spend 2 hours trying to get particles working?
I desperately wanted the player to have dust particles when they walked and landed, but ran into some problems with shuriken, Unity’s particle system, that I’ve never had before. I’m not sure what caused it, but hopefully I can get that working in a post-jam version.
This was my first time using Unity’s surface effectors, and they’re really weird! I lost an hour or two trying to get those conveyor belts feeling good, and discovered it’s /kinda/ impossible.
4. What makes controls, “floaty”?
This was something I spent a lot of time after the jam thinking about, and asked some friends for their opinions on this. (Thanks, Managore!) It’s sort of a weird topic, since even in the post-jam build I’m working on right now, I /still/ haven’t gotten the player feeling exactly like I want, but the problem seems to be more about horizontal movement, rather than vertical.
Increasing the gravity actually didn’t do too much, just shortened the amount of time the player stays in the air. Having a jump last from 0.3s to 1s seems to be a good range, but in my game, the jump already lasted 0.8s!
Faster acceleration and higher max speed so far seem to be the biggest contribution factor to removing that “floaty” feeling. Acceleration especially helped, making the player come to a quick stop after walking made it feel much snappier. That said, I think giving the player /less/ control of their velocity midair might also help! In Super Mario Bros, if you make a jump at full speed, then try to reverse that mid-air, it’s possible but takes a lot to do it! In my game you could just glide wherever, and it feels bad.
Another big contributor are things that one might consider polish, but turned out to be essential for making a jump be more satisfying:
Jump cancelling. At first, I had this implemented, but removed it due to a bug with the “jump on enemy multiple times” puzzle. After the jam, I was able to fix this in about 10 minutes, and it made the jumping feel much snappier.
Dust upon landing. As I mentioned above, I just couldn’t get shuriken working in time for the jam. But adding a small effect like this to a jump can make it feel way better! You want it to feel like the player slammed into the ground, not like they decided to stop falling for some reason.
Audio! Adding walking sounds would have made the character feel more like they were really there, and absolutely not gliding. The player also had a jump sound, but no landing sound. This stacks with what I said with dust upon landing.
Different jump sprite for going up & coming down. This could have been as little as moving the character’s pupils, but it would have “sold” the jump more if the player looked up while jumping up, and looked down only when falling.
Toss in some cheap sprite scaling. I could go on even more about animation, but pretty much just look up “squash & stretch” and “anticipation”. (Those are just the first two principles of animation, but brushing up on all of them will be helpful!) You can mess around with sprite scaling during jump animations, which can usually get the job done in selling a jump.
5. Be nice to your artists
Without Rev, my game wouldn’t look anything like it currently does, and I would have surely ran out of time. My main character was still just a hexagon at the start of day 3! I’d like to take this time to promo him:
When you’re getting assets from an artist, come up with a list of exactly what you need to be done, and what kind of feeling you’re going for. And let them know early! And be nice to them!! Jeez!!! Also, the conveyor belt graphic in the game was still my temp-art, and we ran out of time to swap it out with something better.
Making games is cool, you learn a lot!! Make sure to write down what you learn, so you can… learn from it.
The game needed more ways to explore the main mechanic, and better ways to introduce it to the player.
I’ll probably post an updated version of the game after judging. I’ve already done some control tweaks, mechanics tweaks, fixed problems with puzzles, and worked on fixing the floatiness mentioned above. Updating that right now wouldn’t be fair, so I’ll be waiting til after to consider posting that.
Thanks for reading!