Posts Tagged ‘ld48_24’

Strengths and Weaknesses

Posted by
Thursday, July 5th, 2012 11:00 pm

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.

1942 Clone Screenshot

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

Pitfall: The Mayan Adventure Screenshot

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:


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.


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.


Mark’s First Ludum Dare

Posted by
Wednesday, July 4th, 2012 9:26 pm

In about 50 days, I will partake in my first Ludum Dare event.

I started making video games before I knew what a compiler was. I remember in middle school finding a book at the library that taught you to build your own games using QBASIC. I studied the lessons, and started coding my own games with pencil and paper using the syntax I learned. I didn’t actually understand what I was supposed to do with that code to make it work until high school when I took a programming class and learned all about the pieces of software that you needed to install to compile and run your code.

Since then, while I’ve dabbled with game modding, I never really completed a game worthy of any sort of attention. I was just as well enjoying the constant challenge of completing any programming project that the (revenue-generating) world would throw at me. As I honed my craft, though, I was overtaken with the fact that I wasn’t doing something right. I’ve gone through plenty of different paradigms: the procedural spaghetti code of Pascal, the Test-Driven Development-minded ideas of Inversion of Control from the ALT.NET community and C#, and the KISS of python. My work brought me from architectural overengineering in my first job out of college, to “just get it done now” in my current job as a consultant. Over time, I’ve learned lots of different possible ways to architect a solution, and am hoping to finally bring much of those lessons back to where it all began: making video games.

With 50 days out, my plan is pretty simple: work on developing the toolchain I’ll use to make my 48-hour game. While 50-days out seems like a lot, it really comes down to seven weekends of half-devoted time, plus a few days throughout the weeks after work.

These posts will detail the decisions and plans that I make in order to make this Ludum Dare successful.

[cache: storing page]