My first step in planning out this Ludum Dare is to analyze what I can do right now. The goal is that in the next 50 days, I can spend time between exploiting my strengths and working on my… less than ideals.
Major Strength: Programming
My biggest strength, IMO, is my programming ability. I’m constantly on the lookout for ways to reduce complexity in how I write my code. I’m not going to claim that I’m anywhere near where I want to be (the ideas of functional programming is something I’m pretty interested in learning, even if it just means bringing some good ideas over to my imperative code), but I believe I have enough experience in other programming pursuits to tie back into game development.
One thing I’ve enjoyed doing is writing code that doesn’t necessarily work, but succinctly describes what I want the program to do. In game parlance, I’m developing code that should only care about the logic of the game. Anything about sprite rendering, entity storage, etc, should be handled by some outside, magical framework that reads my mind, bakes me cookies, and does all of that boilerplate stuff for me. Then, I build that magical framework. Minus the cookies and telepathy.
It’s not much to look at, but it will do as a test case.
You can view the results as I go on my bitbucket page. Right now, there are two “games” in early development (a 1942 clone, and a physics-based platformer). They both are supported by the same Python framework, ffld (“Framework for Ludum Dare”) that I write during development. I’ll go more into detail of the framework in later posts. For now though, I will say this: while the name of the framework might seem to insinuate otherwise, the goal is not to cut corners. Instead, the goal is to allow for the modularity of common code for game essentials (e.g., physics, collision, graphics rendering, asset loading, game entity tracking) , leaving only for the custom logic that will make my game unique. Of course, to keep the scope creep down, I am adding some constraints; it will only support 2D games, and be based around pygame. At some point later, perhaps I’ll look into expanding to OpenGL, but pygame works will for my needs currently.
Hopefully, my development will be a large asset to rely upon. As far as strategy goes, this means that when coming up with a game idea, I will be better off sticking to an idea more interesting from an interaction point of view, as I have no worries with being able to throw together the strange code needed to cause it all to work right.
Major Weakness: Graphics
Not by me. Not in a million years.
As of today, I can’t build a grass texture to save my life. This is my biggest fear: that no matter how cool or unique of a game I can build from a game logic standpoint, the graphics will just look childish. I’m heartened by viewing some past Ludum Dare winners who eeked by on pretty cheesy graphics. I’m pretty sure one of the reasons that I never did more game development in the past was because it was so exhausting trying to find graphic assets. Sure, you could find a cool sprite sheet here and there, but not enough to make a full game. You want another sprite, similar to the one you found online, for the next level? Not with these two left hands abusing my gimp window (I guess one of my other weaknesses is taking the time to develop relationships with people who could help in this regard).
And so, one of my large goals that I have tasked myself with achieving over the next 50 days is to become better at making graphics. This does not mean that I plan on becoming a turtle-necker. My goal here is not Pitfall: The Mayan Adventure. Realistically, my hope is to get into a situation where I can develop graphics that pass as… well, whatever they are supposed to look like. Maybe just one step above “programmer art”? I feel that with some work, I could probably make some grass textures that are more than just surface.fill(GREEN) if need be.
The Other Attributes:
Music/Sound
I don’t have much experience generating sound, but a quick look over the various toolkits shows that it doesn’t appear to be that difficult (some of it can be randomly generated very easily with tools such as bfxr and sfxr. In the coming weeks I hope to play some more with these tools. I doubt I would want to concentrate too much on this, but I realize that music and sound will contribute to the overall atmosphere of a game in a way that could be very time-effective. Even spending a single hour making a quick song, and another for adding sound effects, could be the difference between a hack and a game.
Planning and Research
Well, considering I have a gameplan of things to do 50 days before the event, I’d like to think that this is all pretty good. At some point I like to think that I’ll do a full mapping of my time during the LD weekend (When will I sleep? How long should I spend on design? How long can I develop the game? When do I call it done and spend the rest of the time polishing? How much liberty would I allow myself to deviate from such a schedule?) I also plan on reading some more post-mortems and other tips around the LD site. Of course, I could very well go into this thinking I’ll just let my first Ludum Dare hit me like a ton of bricks and learn for the next one. I feel, however, a certain pleasure in the humility of watching my best laid plans get absolutely destroyed.
Writing
While I don’t have a lot of writing experience, I do like to think that if I take my time I can be a pretty decent writer. That being said, LD isn’t about taking your time. I don’t plan on using writing to much effect since it is pretty time-consuming, but that might change if I find myself with an idea that doesn’t need a lot of code to do. Perhaps in a future LD, when I feel a little more comfortable, I will try to make a story share the spotlight of one of my games.
Tags: ld48_24, Planning
