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.

Tags: introduction, ld48_24

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

As I discussed in my previous post, my largest perceived weakness going into an event such as Ludum Dare was my graphic-making abilities. This past weekend, I took my first step toward exercising that particular skill. Prior to this weekend, I had never created a sprite in my life (that wasn’t entirely one color). Heck, I never even doodled in my notebook in middle school.

Where to Start?

At first, I really didn’t know how I would go about improving myself. Isn’t the designing of sprites just art? Isn’t visual artistic ability just something you’re born with? My brain is so imbalanced to the left hemisphere that I’m constantly falling into traffic. What kind of fool’s errand am I going on here? However, throwing doubt to the wind, I set out to build a sprite.

The first task I gave myself was to pick a graphics tool. I tried some of the ones list in the Ludum Dare Tools section, but didn’t see anything that struck my fancy. At one point I was on Chapter Two of a PyGTK Tutorial in the hopes to build my own tool. Luckily I shut down that bit of insanity. Eventually, I decided to just work with good ole’ Gimp, which worked better than expected.

Next, I went scrounging for tutorials. I didn’t think I’d actually find anything worthwhile, but I was badly mistaken. If you’re a programmer looking to get started with Pixel Art, you MUST read Derek Yu’s Pixel Art Tutorial. It breaks things down step-by-step, which is extremely helpful. Don’t be afraid by Derek’s amazing looking image, the ideas transplanted just as easily into my practice images.

I started very simple: following the tutorial to create a dead-simple picture (a machete). It wasn’t too shabby, but it was also a pretty simple image to begin with. So I decided to go with something a little more advanced to really test myself. I already had some sprites pulled from the NES Game “1942” to use for graphics in a game I’m screwing around with, but maybe I could replace them with some sprites of my own. So, I would use the tutorial’s lessons to create my own sprite of a fighter plane.

Step One: Draw a Concept

Some Clip Art I found to use as inspiration

For me, step one was to get an idea of what I wanted to draw. For Derek, this is Part Three (yeah, I’ve purposefully renumbered the steps to make things confusing for you). First, I googled for a top-down view of a plane, and found something to use as a concept. Next, I tried to draw with pencil and paper a likeness of this plane. I’m not really sure why I decided to do this (after all, I already have some concept art in front of me) but it just felt right. Later I decided that this worked pretty well, as the image I drew was something that I knew I could at the very least draw, which gave me a boost of confidence. It also allowed me to customize the image a bit more to what I wanted. Now to be sure, my drawing abilities are very sub-par (and fortunately for you, I didn’t scan the image I drew), but by studying the original image part by part, I was able to get something decent.

Step Two: Pixel an Outline

I created a new 64×64 pixel image in Gimp, and prepared to embarrass myself. Finally, I ended up with the following:

Some things to note about this:

• Although you don’t see it in the screenshot above, when working in Gimp I made sure to enable the grids so I had lines separating pixels.
• There are some jagged lines. While I did heed the tutorial’s warning, I felt that there wasn’t much I could do about some of the jaggedness, particularly near the back of the wings. I hoped that they would come out later in the process.
• Learning how to use the various Gimp tools to draw/erase/etc in a straight line is pretty helpful. Particularly, it is faster to use this method to draw a line rather than placing every pixel with the pencil tool. Even lines that are drawn at strange angles will give you pixels to start with, and you can just fine tune the resulting line with either the pencil or erase tool
• Speaking of the erase tool, you’re obviously going to need to set it to “Hard Edge”.
• One tip is to have a second view open to see what the image looks like in it’s actual size. After you’ve opened your Gimp window and have zoomed in on the image so you can work with the pixels, click “View -> New View”, and Gimp will give you another window that you can set to a different zoom (which is probably best to keep at the default zoom)

Step Three: Add Color

The next step was to add color. I bucket-filled the areas. This was actually pretty nice, since I have always been under the impression that if you bucket-fill a sprite it’s going to look terrible, and the only way to get something decent is to color each pixel individually. You’ll also see that I decided to add a propeller blade to the front for no particular reason.

These are just three colors that I randomly picked. Some day I might actually learn about color theory and all that, but I’ll save that lesson for some other day. Already, I’m pretty darn impressed. I would be happy with this! However, there is more that can be done.

Step Four: Shading/Lighting

The next part is what really makes the image “pop”.

I’m not sure if I got it “right”, but I did get… something. Notes on this step:

• The basic idea, as explained in the tutorial, is to pretend that there is a source of light, choose the direction it’s coming from, and draw where the shadows should go. Also, lighten where the light hits directly. I sort of changed my mind up half-way through where the light was, so I might be kind of all over the place. Especially on the right side of the tail section. However, it should be pretty clear that the light is above the plane’s vertical axis, and to the left.
• Here, the dodge/burn tool is your friend. The dodge will lighten, and the burn will darken the pixel you click. Remember to set the tool to “Hard Edge” or else it will affect multiple pixels!
• Although it might be obvious to some, this wasn’t to me: if you have the default color for the pixel and you dodge (lighten) it, then decide you’d rather keep it at where it was, doing a burn (darken) will NOT get you back to your original color. You’ll need to undo, or just redraw the pixel
• I reread the tutorial after I was done, and one tip was to do the shadows (darken) first. You’ll end up drawing more shadows this way, which sounds like a good thing. Think about it: with a single point of light, you will have more areas with less light (shadows) than you will being directly hit by the light. I’ll have to keep this in mind next time.

Step Five: Selective Outlining

As you can see, the pixels that I drew for the outline back in Step Two have been dulled down to the colors that are surrounding them. This makes the image less “hard” (or using Derek’s words, “less cartoony”).

• I made use of the “Smudge” tool. As with the other tools, I made sure to set the “Hard Edge” option so that I would be affecting one pixel at a time. The way the “Smudge” tool works is you click and hold your mouse button on one area (i.e., a blueish pixel in the cockpit window ADJACENT to a black “outline” pixel in the cockpit window), and then drag the cursor INTO the black “outline” pixel. You can think of it as smudging your finger across the page, pushing some of the blue onto the black. Really, what this means is that you get some blend between the dark black and the light blue, without needing to manually pick the dark blue color. The cockpit glass is where it’s most noticeable, but I did it for the majority of the outline pixels.
• Unlike the other tools, the Smudge tool requires a bit more finesse, since you have to “drag” color from the correct source pixel into the correct destination pixel. Obviously, this can be a pretty long process for all of the outline pixels. If I knew that there would be a large group of pixels in a row that would all have the same smudge source color, then I would smudge one of them. After, I would use the Color Picker tool to select the new color that was created, and use the pencil tool to draw that color onto other pixels that would do the same thing. This was especially effective for those long, straight lines of outline pixels.
• One thing I could have concentrated on more was to do the selective outlining a bit lighter on the very outside edges of the sprite, as suggested. I played around a bit with the smudge settings, but could have gone even further by using the dodge tool to lighten up these pixels even more.

I Survived!

It’s by no means worthy of the video game hall of fame, but it’s better than stick figures. Some final thoughts on this entire process:

• In total, it probably took me a bit over an hour for this one sprite. I imagine I can cut this time down by knowing the keyboard shorcuts for gimp, which I was only partially familiar with. Another was the fact that I did this using the trackpad on my laptop. A mouse on a desktop would probably be faster.
• While Gimp has great toolage for messing around with a single image, I can imagine creating animated sprites would be difficult. On the one hand, Gimp has nothing built in to animate the sprite as you’re creating it. On the other hand, it would not be too hard to write a program that simply animates the sprite for you that you can stick into one corner of the screen while Gimp is open.

Comments/criticism welcome!

Tags: GIMP, graphics, programmer art, sprites, tutorial

So yeah, that whole “I’m going to make some libraries and learn my tools”. Never happened. Oh well.
Here’s what I’ll be using:

• Python and Pygame
• Either cx_freeze or pyinstaller to build executables
• Some home-grown libraries: (Funcompose as a rendering engine on top of pygame, Pythfinding is a pathfinding library written in pure python that has the feature of sometimes working correctly, pyinstaller_tools as a layer on top of pyinstaller if I go that way, and calcui to help with laying out user interfaces (if I start getting fancy with them).
• One of the sound effects generators in the Ludum Dare tools section.
• FL Studio for music.

I received the theme by mail on my phone while at the bowling alley with some co-workers. I promptly looked for the rest of the e-mail where it would say “Just kidding! It’s XXX”. I also checked the website. No, it really is evolution.

At a loud bowling alley, I tried to steal some moments away to think about possible game mechanics, but all I could come up with is “evolution of bowling”. Yeah, I got nothing there.

Anyway, on the ride home I decided I would start naming occupations. Just trying to do SOMETHING other than just repeating “evolution… evolution” over and over, like that would somehow help.

The first occupation I came up with was “Pilot”. I thought about a game where you are a pilot, and the course had a number of different obstacles. Some obstacles you might be better at than others, and the ones you do worse on are the ones you’ll encounter more of in the future. Of course, this being my first idea I immediately threw it out.

I also figured it likely that biological evolution would be pretty standard, as it was another idea I had. So I started trying to concentrate on other definitions of “evolution”. Really, in the end, it came down to the fact that many small changes occur that will eventually produce a large result.

Somehow, I thought about the “large result” as the “goal”, and the “small actions” as what the player does. I instantly thought about a game idea I had a year or so ago where I would create an entire town and allow the player to interact with various characters at various times. These small interactions would change the way people view other people. I went down this road for awhile:

The game makes you the “Ghost of Fate” in a town, and you have to get people interested in topics. For example, Little Frankie should grow up to become a scientist, while Suzy and Derek should fall in love.

I started to realize that there would be a TON of graphics and interactions that would need to occur for this to work. I soon just rubbished the entire idea, and tried to move on.

I eventually came back to it, though. At some point (I’m not sure how) I came up with the idea of a “Summer Camp”. Rather than an entire town, you are a lead counselor of a summer camp, and are given a goal (“win the water marathon race against the rival camp at the end of the week”, “help Derek have his first kiss”, etc.) You do this by interacting with the the campers to find out their various likes/dislikes, who their friends are, picking up rumors of love triangles, and convincing them to participate in different activities throughout the week. If you want to win the water marathon against the rival camp, you might want to get Steve to anchor your canoeing team. But Steve probably won’t want to do the canoeing activity during the week, because his friends seem to prefer swimming. If you could convince Stephanie (the girl Steven has a crush on) to join Canoeing, then we might have a different story.

I have some worries:

1.) Game Complexity. I’m mocking the entire game idea on paper, and I think if I limit the amount of interactions, the code for this shouldn’t be that hard.

2.) Graphics: It’s a game about a lot people doing a lot of activities. I suck at drawing. If I can find a good way around drawing a bunch of people, I will, but I might need to spend a lot of time just doing graphics of faces. This seems entirely ok to me, since I think I could get away with cartoony-style faces alright. The environments might be a bit different though.

Well, I got a few hours late start, but at least I have an idea. It’s not entirely fleshed out, but it’s ready for me to start coding. However, it’s 2AM, so I’ll give myself some rest, then start tomorrow.

I slept on my other idea, then promptly got to work making it after waking up.

About 45 minutes in, I was already sick of working on it. The game itself might have been an okay idea, but I figured I would need to do a lot of work just to get it playable, and that scared me.

There will be future LDs (where I will perhaps have a better plan going in), so I’m going to try to keep it a bit simpler. I’m going to make a platform/puzzle hybrid. Basically, it’s pretty simple platformer. You play the level, although finishing it is optional. Then you get to choose from one or more “positive” rule changes. Something like “your character jumps higher”. You need to be able to finish the level with this rule. Once you do, you will now need to choose from a list of “negative” rule change (like “you can only jump three times”). All the rules you have picked in the past affect the levels in the future.

First things first: get the platformer going. This should be pretty simple. Then I can build up some more rules and start implementing them one by one.

So, I’m planning on trying to throw some stuff together in HTML5. Not planning on anything fancy, just gonna’ try to FINISH something this time.

I should be continuing on my warmup stuff, but, the only thing I can really think is…

(PS: If you’re confused like me, be sure to read the stickied “Theme Voting Begins” post)

In attempting to come up with something for the theme, I scoured the internet and found this quote:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupe

Basing on this, I started thinking about a game where you needed to take things away from the game to win. I had a few different ideas, and decided on a platform/puzzle style game where you need to walk around removing the obstacles as you go.

I’m a code-first-make-horrible-art-later type, but what the heck, first screenshot..

Also, due to the magic of github, my game should be up to date as I push code…

https://github.com/markhildreth/ld26

Tags: screenshot

I’m now four hours into LD, and I have a prototype. This is farther than I got last time (at this point, I had quit :P)

The prototype has a level-loading capability so I can easily make levels using ascii art…

var levels = {
 '0' : [
 '                ',
 '   _            ',
 '                ',
 '__S_____________',
 ],
 '1' : [
 '     _          ',
 '                ',
 '   _ST___       ',
 '                ',
 '__S____S________',
 ],
 }

You can kind of make oue the ground (underscores). S is a springboard, T is a trap door. The result (level ‘1’) is on github, where there is also a link to run the prototype. Use left and right arrows to move.

Going to sleep now (well, going to bed with my notepad, but you know..). Goals tomorrow:

1.) Eat and Shower

2.) Start putting together actual levels using the prototype, including additional types of items.

3.) Once I feel comfortable with a few levels, build some graphics (including animations).

Just about to head off to lunch. I’ll leave the laptop behind and bring my notepad to do some level design and maybe come up with slightly better drawings to turn into textures for the rest of the items in the game. I might skip out on the animation stuff, and work on changing levels / ui / story / sound. If I find time by the end of tomorrow, I’ll consider putting the animations in.

Tags: screenshot

Walked into town to grab Lunch at Beuno y Sano. Definitely check it out if you’re ever in the Western MA area.

It felt nice to step away from the apartment/computer. Of course, I have a notebook by me so that I could continue designing more levels.

Tags: food

With the exception of one of the animations, I think I have all the coding done. The graphics aren’t great, but they can pass if I don’t find time to sharpen them up tomorrow. If necessary, I can put in the levels / character speeches and call it a game. Of course, tomorrow I’m going to try to add some polish:

1.) Smooth out the controls a bit.
2.) Intro / Finish Screen
3.) Sound Effects
4.) Polish the UI (rounded corners, amirite?)

If I can do all this, I’ll be happy. If I knock these things out, I can try working on…

5.) See if I can spice up the graphics some more (there’s only so much that I can do :P)
6.) Music

Tags: progress, screenshot

At first look, making a puzzle game isn’t hard. Basically…

1.) Write a bunch of simple rules that work for one level.
2.) Write 20 more levels that use the same rules (no more coding necessary!)
3.) ????
4.) Profit!

The problem is that trying to create levels that are difficult (but not impossible) is… well.. difficult.

So far, the tactic has been:

1.) Place a bunch of stuff randomly on the screen.
2.) Try to (myself) solve the puzzle I just randomly created. If it takes me a few tries before I finally get it: awesome!
3.) If I solve it right away, add some stuff to where I went to try to make it less obvious.
4.) Continue this method of tweaking things until I break the level and make it impossible to finish.
5.) Start over from scratch with a different random level.

There has to be a better way (maybe there is some higher-level math that can use graph theory to create levels that have many possible routes, but very few “winning” routes). The worst part about this ad-hoc method is that it’s very possible I’ve made a level that is impossible to beat, and I WOULDN’T KNOW IT until it beats me many times. Also, I might have already thrown away a bunch of levels that I thought were impossible, but might have been really good candidates for some of the final levels.

Part of me wants to build an AI that brute forces the level and gives me an idea of difficulty/possibility of them. If this wasn’t for a 48-hour contest, I’d consider it. For now, I’ll just keep scrapping away.

So yeah, in theory, a puzzle is pretty straightforward. On the other hand, the amount of time it will take to create levels for a puzzle game should NOT be underestimated.

This is quite possibly the WORST use of my time right now, but it was fun, so I did it.

My LD entry is a puzzle game, and I overestimated how hard it was to design puzzle levels (read my last post for more info). So, I went ahead and wrote an AI to brute-force my levels, and give me the number of success and failure paths that the user could take, with “harder” levels probably having better ratio of failure/success paths. It also means that I can put the level into the solver and actually see if the level I made really is solvable and I was just beaten by my own game

The solver is on github. In the time I wrote this I could have gotten sound effects or just plain been making more levels (as easy as they would probably end up being), but I thought the idea of writing the AI was a fun challenge so I did it anyway. I might write a post about the AI after the contest.

Though I’m not happy with the graphics/sound/music (bad, none, and none, respectively), I think I’m going to ignore those as casualties of my first LD experience.

Plan today:

* Eat more leftover pizza.
* Add the remaining device types to my solver (right now it only can “solve” levels with SOME device types from the game)
* Use the solver to help create the remaining levels
* Continue adding dialog. Maybe actually have a plot!
* Add a background texture to replace the dull “black” background.
* Add an intro screen.
* Add an intro screen for each level.

Time permitting:

* Eat more pizza

I’ve officially been working nearly non-stop for the last 12 hours. The majority of my time has been spent creating levels and adding storyline. Note so self: it takes a long time to write dialog!

I didn’t get to add a lot of polish (no music, no sound fx, etc.). However, it is a done game, and as far as I can tell, it’s fun.

I’ll probably write a longer postmortem, but I’m just exhausted. I need a shower and some food. However, I stayed on task and did what I set out to, so I’m feeling pretty good about that.