September 4, 2013 11:20 PM | John Polson
"Lodestar is kind of an example of how not to be smart about Ludum Dare."
[Last month's Screenshot Daily looked at larger game projects. This week, I'm going to look at how developers tackle art in games made in tight schedules. Today's game is browser-based tower defense Lodestar made for Ludum Dare 27 by Folmer Kelly.]
So how did the game jam go?
I usually work with pixel art, which goes fast and is something I know. So when LD started and I sketched out my concept, I didn't think about it, I just started pushing pixels.
But it wasn't working, at all. I tried different approaches, color palettes ("ok, let's try the Gameboy palette! Nope! NES? No. Um... C64? 1bit??"), browsed screenshotsaturday.com to see if anything jumped out at me... nothing. Out of pure frustration I said fuck it and drew a non-pixel art island in this kind of faux low poly 3D style that i've had a love/hate relationship with for the longest time. Love because it looks awesome, hate because I don't do 3D so I'll never make any myself. But now I was doing it! In a way. Sort of.
Surprisingly enough it actually worked really well for the game I had in mind, which was a Plants Vs Zombies type tower defense thing (#LDTD represent) set on an island with a lighthouse. But if I'm honest, the only reason I stuck with the style was because I had wasted too much precious time already. I mean, on paper, Lodestar's art style was a horrible idea. Translating a very specific 3D style into 2D, which is also a thing you've never done before, for a game jam? That's dumb as heck.
But it went ok once I committed to the style and started working from my design document. From that point I found the flow I needed: Island, lighthouse, creeps, turrets. You take the basics to a prototype and then you get excited about what you have so the secondary stuff goes pretty fast; backgrounds, projectiles, explosions, and animations were done in a flash, just because I wanted to see them in the game. Some things had to get cut (I had more turrets and more creeps planned, and originally the lighthouse was supposed to attract boats instead of dolphins, which would make way more sense. It was supposed to be that different styles of boats would allow the player to grab different types of turrets). The lighthouse beacon shining a rainbow instead of a normal beam of light was a happy accident- I clicked on the wrong gradient. That actually inspired the dolphins-instead-of-boats thing, come to think of it.
As far as programming goes, I know my limitations so when I brainstormed mechanics I made sure to operate within those limitations, otherwise I'd just get frustrated and probably end up losing tons of time googling fixes and demotivating myself in the process. Aside from a brief scare where all my collisions stopped working, none of that happened.
That said, I did end up having to switch from the compo (48 hours) to the jam (72 hours) and sacrificed a night of sleep to be able to finish the game. So when I finally submitted it, I was just happy that I got it done. At the time I really didn't want to think about it anymore. But right after I released it, someone told me they "felt like they were there in the game" which to me is just an amazing thing to hear, so I went from exhausted to hyped in a snap.
How do you approach designing for a game jam versus a large project?
Compared to larger projects, the most noticeable difference for me is that there's no time to reiterate; once an art asset is finished it either goes in the game or it goes unused, but I'll never try something out and then redraw it if it doesn't work for the game the first time around. There's no time to waste on maybes.
The other thing is keeping a very close eye on your design document (or design scrap, or whatever you're working with) and making sure your art assets stay aligned with it. It's very easy for an artist to get sidetracked, which can lead to great things, but not when there's a deadline looming.
Any rules of thumb for how much love to give art in a jam entry?
Personally I don't believe there are any hard rules when it comes to deciding how much attention you should give to art when doing jams, but I can say this: if you're going to be flying solo, switching back and forth between art and code and everything else is death. It's a start-and-stop thing and it slows you down way more than you realize at the time. I usually try and get all the art done the first day, code the second, and audio the second evening. Another thing to keep in mind (though as an artist it pains me to say it) is that people enjoy playing good games with bad art WAY MORE than they enjoy playing bad games with good art. If making video game art isn't your strength, don't let that stop you from jamming.
What entries caught your eye?
Gas and Air!
The thing about Gas and Air! is that it looks great... but the style was decided on because it wasn't time intensive for the artist. As far as making art for jam games goes, that's the holy grail.
Stylized, colorful, abstract, awesome. It's a lot of functionality stuffed into very limited parameters, which can be a good way to go for people who aren't artists, or those who don't have time to make detailed art.
A game that looks more polished than a jam game should. Why? Because the artist is comfortable working in this style, and it shows. A great example of working to your strengths.