Ludum Dare #23 is my first Ludum Dare. Technically my first game jam of any description, really.
About Gremlin (twitter: @isaackarth)
So, minimalism turned out to be a great theme for me. I’d already been thinking about the idea of just doing a simple, fun game to relax after all of the hard work I’d been doing on my other game, so everything worked out. But not before a sidetrip through the insanity of development that was just a little bit more insane than usual.
I decided to take a well-known genre and pare it down to the core experience. Hence, a bullet-hell shooter with no shooting. The player doesn’t even have to click on anything–the click at the start is just to make sure your web browser is focused. While the art style references De Stijl, I felt that for a game the essence was in the mechanics, not the visuals, so I avoided the visual minimalism of horizontal and vertical lines in favor of an interactive minimalism of a handful of actors and the tightly defined but emergent relationship between them.
Despite everything in the game being a square, you can pretty much instantly tell how they relate to each other just but how they move and interact. I like how that turned out.
You can play the game here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=12047
What Went Wrong
Technically this didn’t go wrong so much as I knew going in that this was going to be an issue. I had a major paper due the week of Ludum Dare, so there was no way I would be able to devote the full time to the game, or even very much of it. I actually wasn’t sure if I was going to participate at all until a late evening conversation on Saturday made me realize that I had to get this idea out of my head. I always make a point of sleeping properly and not disrupting my usual routines, so even though I had deadlines about to steamroll me I ended up putting in about three hours on the game Saturday night and picking development back up at about ten or so on Sunday. In total, I probably spent about twelve to fifteen hours on the game.
I knew I wanted to get audio into the game, but a bug earlier in the day had put me behind, so I ended up with three hours to go, no audio–and no idea how to add it, because Processing.js doesn’t natively do audio. I had to learn HTML5 audio and make the sounds in three hours or less. Preferably less, because I like to leave some extra time at the end of Ludum Dare for breathing room. It worked in the end, but I’d have liked to have a bit more attention to the audio–but not to add much, because the minimalistic effects that are currently a part of the game do fit the theme. Just be glad my screeching temp sounds got replaced.
The procedural generator I wrote is fairly clever, given the time constraints. It divides the different possible features a wave can have into buckets and then uses Perlin noise to select a subset of those features to use. But it needs a bit more tuning than it has. I was the only one testing it, so I knew the ins and outs of the generator, but other people take a bit of time to figure it out and mostly die when the difficulty curve ramps up really sharply at the fifth level.
If I had been able to watch other people play the game I probably would have been able to avoid the other big problem, which is that there’s no “Game Over” screen. I didn’t need it while I was testing, and I didn’t care what my score was, so I didn’t notice that it was missing. But having one turns out to be really important for the game. Adding it in was a simple 26-line change, and the post-comp version has it, but I feel that if I had other people test it during primary development the game would have ended up even better than it is now.
What Went Right
Processing was a great platform to work with. I had to implement my own collisions, but that wasn’t a problem since I already knew how. I was able to use a lot of programming tricks that are technically feasible anywhere, like adding easing to most of the movement, but Processing’s immediate feedback let me fine-tune to get the exact feel that I wanted. And feel is a huge part of a game like this. Processing.js was easy to get working once I figured out which PVector functions weren’t implemented yet–in fact, it was so easy that I switched to make the web version of the game the primary one for the competition release.
I gave myself permission to not do everything. That is, the game wasn’t going to be the best graphics, the best sound, the most innovative concept–I was going to focus on making a game, not starting a revolution. Minimalism turned out to help with that, since it let me make a game that is deliberately about the most basic expression of a core idea.
No Feature Creep
Speaking of which, minimalism gave me an excuse for avoiding feature creep. Every time I had an awesome idea for something that would be an awesome addition to the game, I could just say, “Nope. Minimalism,” and go on my way.
Source Code Control
I took a few minutes on Sunday to set up a git repository for the game. I never ended up needing it, but it let me experiment, knowing that there was always going to be a mostly-working version of the game that I could go back to. I can, right now, jump back to the compo-version or forward to the post-comp changes with no trouble at all. If you aren’t using source code control, take a few minutes to learn how. You won’t regret it.
Keeping yourself healthy is important, even during a crazy crunch situation like this. I made a point to sleep and eat–and that really helped when I needed the energy and concentration to learn a completely new thing three hours before the deadline.
Finally, the community is a big part of why I participate. I make a point of rating a bunch of games–nowhere near all of them, but as many as I can find the time to do. I’ve already incorporated some of the suggestions I’ve received into the post-comp version I’m working on. I try to leave feedback that will help make the games better and I encourage you to do the same.
I have now built a game in 48 hours! And you can play it here! (I think I may be a little excited. And I didn’t even lose that much sleep.)
Built in Unity, with sound effects in Bxfr and some levels in Photoshop (really!).
Stuff that didn’t get in (in order): fluid simulation (spent 3 hours researching first day, didn’t really need it), pathfinding (spent 4 hours researching second day, replaced with vector steering), procedural terrain generation (turns out that the textures I had already thrown together were varied enough, you probably won’t notice it’s missing).
Features that are in:
- Terrain editing!
- A tiny world that’s sinking
- Level progression
- Sheepdogs to herd sheep
- Wolves (that eat sheep)
- Alligators (that also eat sheep)
- Sound effects!
- Horrifically messy source code provided!
- And more!
I think the game is definitely about herding sheep now.
There’s a lot of stuff that I’d have liked to have done with it, tech-wise, but right now I think I just need to concentrate on fleshing out the whole herding and flocking experience. Mechanics, not glitz.
Well, it’s still not much of a game, but it does work a lot better. The travelers (or are they sheep? or cats?) are, if anything, even more unmanageable. They like climbing hills, they don’t like swimming, and they can’t scale cliffs. And every time you get them all to the exit, you get to start again with even more of them.
Well, I got distracted trying to implement pathfinding and lost a few hours before deciding that I’d be making better use of my time just getting the tiny travelers moving. So they’re kind of dumb, and only really know how to walk in a straight line right now.