Well, this is going to be my first time entering the Ludum Dare, and, naturally, I’m quite excited for it. I have no idea if I’m up to the challenge, since I haven’t really done too much in the way of content generation in the past, but I suppose there’s not too much need to generate the best content ever for this. I certainly am not the most experienced game developer ever (since I’m only 15, I’ll bet some of you other people have more experience than I have living years) – I’ve always had problems with commitment to a project, but hopefully I won’t suddenly decide that I want to write something completely different in the middle of the competition. I’ll *probably* be using the following tools for the competition, but it might change:

Language: Most likely C++ (Java could happen)

IDE: Code::Blocks

Libraries: SFML, OpenGL

Graphics: GIMP

Audio: sfxr

And, of course, good luck to everyone participating.

Now all I need to do is think of an idea, program it, create graphics, create audio, upload it, and perhaps blog ’bout it.

It’s dangerous to go alone.  Take this duct tape. – Platformer-Puzzle ’bout creating duct tape bridges to get to the finish.

It’s dangerous to go alone. Take this clock. – Zombie-related game. Everything is related to the time. Perhaps you’re a ninja or something. They needed clocks, right?
It’s dangerous to go alone. Take this mirror – Laser puzzle or something.

It’s dangerous to go alone. Take this spaceship – Self explanatory, I’d assume. Space is quite dangerous.

It’s dangerous to go alone. Take this acid (not that acid. The one with the low pH) – Platformer-Puzzle about burning holes in things.

It’s dangerous to go alone. Take this box – Who knows? BOXES ARE AWESOME. There’s so much you can do with a box! You can step on it, you can put stuff in them, you can do BOTH at the same thing, you can build a fort out of them…

My movement algorithm seems to be a bit… wrong. Its collision resolution code SHOULD put my little ugly character on TOP of the line, but, clearly, it is doing the wrong thing:
Math is usually so nice to me! Somehow, I forgot all my trig, all my algebra, and everything else when the theme was announced.

EDIT: Oh, you two-faced square root function! Giving me the root that hangs Mr. Smiley-yellow-1-minute-in-GIMP from his head.

I spent about 2 hours working on some movement code for my game. It’s totally wrong. I blame math again. I guess I better fix it. At least I have some code to save.

So, my concept has been to have the item you’re given be an acid spewing thing! It’d be a puzzle-ish game where you try to kill some evil thing that is quite dangerous by using your acid to melt enemies and walls!

While developing this game, I’ve just been constantly running in to problems with movement; I didn’t think ahead far enough, and decided to use lines, which, considering that I neither had any base code for that, and have never written code to move stuff along lines affected by gravity, has proven to be a huge pain. Of course, being a person who really loves continuous systems, it’s not surprising that I missed the discrete alternative. I don’t think I’ll be able to write the code for enemies that move in the time, and I’ll definitely have to keep the bugs of the system I implemented in mind while I’m designing levels so that players won’t think to do something that will cause weird movement (hehe… good practice there. Of course, as previously mentioned, I have no idea what I’m doing, so those bugs aren’t gonna get fixed in 48 hours, so it’s better than nothing). These technical limitations are certainly gonna show in the final product, because it really limits the amount of stuff I can do with my concept.

Other than that, it’s going better than I expected for my first time, considering I’ve never really finished an original game before due to my ambitious goals (See: Above). I’ll probably get something out, if not for the compo, I’ll probably be able to get it ready for the Jam. Also, I screwed up my timelapse, somehow. I am the image of competence, aren’t I?

Well, I finally got a *functional* movement system. Mostly. Except for a little. Or a lot. In any case, I’ve wasted FAR too much time on the movement. I mean, look at what the graphics are:

Pretty bad. I also have to create maps for this, which is gonna be pretty annoying. More content to generate. Ugh… I really should have put more effort into thinking before I developed, because I don’t think I chose my best idea, in terms of a game. Then, I chose to have a system based on lines. I did not realize that I could just do a discrete grid, and that would be equally good. In fact, that would’ve been BETTER because I could have done work on things that weren’t movement. Oh well. It’s better to have this than nothing. Well, I gotta get back to writing code so that I can actually have a product, however bad.

I ironed out some MORE bugs in the movement system (that thing is killing me – I think it’s pretty good right now though. Still, I think, something in the area of 100% of the bugs that I’ve had to kill have come from the movement system!), and wrote a little utility to make levels for my game. Now, I really just have to slap a façade on it, and I’ll have… a thing. Oh, and I need to make more levels, and more interesting levels. I’ve got *plenty* of time though. I guess.

Found a bug where, for some reason, the character fails to spawn. Unfortunately, I can’t replicate it, because the program rarely does this (although sometimes, it does it the first 2 or 3 times after a build, which is odd, because it outputs no files), and is receiving identical input when it does do this, and when it doesn’t, and I can’t predict if it will happen or know if it is happening until it’s too late to debug it, so *hopefully* it will just go away in the final build…

Unfortunately, at this point, I don’t think I’ll have time to add audio. I do hope that the interface is intuitive enough to let people not fail at even playing. I mean, I just need them to read one sentence, and they should get it – but knowing how people play games, this might be too much! Also, I removed 2 more major bugs from the movement  code.

Well, at least I’ve left myself loads of room for improvement next time (because I’m definitely coming back for LD #21).

Finally got all the stuff I need for maps (because my game is level-based), and can start making some cool ones. It’s playable, but the graphics and audio (or lack thereof) are pretty bad. I think it will be pretty fun when I’m done. Yay!

Well, I submitted it. It’s still awfully buggy, terribly ugly, and annoyingly silent, but I did create a game in 48 hours. In any case, I’ll definitely be writing a reflection on this some time in the future, and will certainly return for LD #21 with a little more experience and a little less of the thought “Must… DEBUG… MOVEMENT CODE! BLARGH!” and more of the thought of making a more… polished game and one with a better game design. Today, I have a raw game. Next time, who knows what I’ll create.
I’m quite amazed at what everyone else did, but I suppose with my level of experience (which is writing about 2 games before this), I’m not too surprised at the results. I’d say that this was a pretty good end to my first Ludum Dare, and I’m quite satisfied with both my product and the process to get there. Overall, I thoroughly enjoyed this weekend (including the soccer game in the middle – a weekend where you can get sunburned AND create a game is a pretty dang good weekend).

You can view the game here

Product
Overall, I think my product was very good for a first try. While it might not have been polished, it was fairly fun. I was quite critical of myself throughout the entire process – looking at everyone else’s blogs, I noted how much better their graphics were than mine, but I didn’t think quite long enough about that to realize that that didn’t tell me anything about gameplay. I doubt I’ve created a winner, but I think, at the least, I’ve been able to bring a little joy to the people who play my game, which is a good first step. Certainly, it was very gratifying to receive the first few comments, at which point, I knew I’d done something far better than my own views on it (maybe it’s less fun when you’ve played it for hours on end, trying to debug it). The Ludum Dare is certainly more difficult to complete than one would imagine, and it was pretty much intense coding for 48 hours even to get what I got.

Process: Write Once, Debug Forever
On Friday, at 10:00 EST, the theme was announced. Bet you didn’t see that coming. I thought of ideas for about 30 minutes, and then I generated a list of ideas that I had thought of. Really, my two favorites were having the item be duct tape (because who doesn’t love duct tape?) or acid. At the time, I envisioned both being played on a world made of lines (this thought proved to be perhaps the worst thought I had in the entire contest), so the technical challenges of each were very similar. However, I assumed that duct tape would be a fairly popular idea, since if you ask anyone sensible what the single most useful item to have is, they would say duct tape. Also, I think that the acid idea had more potential, although I wasn’t sure.
I spent from then until midnight working on getting circle-line intersections done well. I probably used a bit more wolfram alpha than was necessary, because solving for x in x^2 + (mx+b)^2 = r^2 is not the hardest thing in the world. I also failed to realize that that equation existed originally, and tried using trigonometry to get the answer, to no avail. Looking back, though, I definitely could have done it with trig, so that was a bit of time wasted. I think I also created my character sprites that day. You can really tell that they took me more than 10 seconds to complete.
The next day I worked almost entirely on getting the movement system working. As a programmer, this actually turned out to be my first encounter with numerical stability (or lack thereof). Since everything had to be working on a line, all x-velocities had to be multiplied by m to get the y-velocity, and all y-velocities had to be divided by m to get the x-velocity, and there was some sort of weighting that had to happen so that gravity on a nearly flat line wouldn’t accelerate you 1 m/s downwards, and 100000 m/s to the right. Dividing by m proved to be very troublesome, because it sometimes caused massive numbers to result, and that wasn’t good. I still have such a step in my current implementation, but I also have special cases for everything that could go wrong (almost everything). Once I had finally gotten that working, I had to write the collision code. The code’s algorithm was basically to make the smallest move possible (which would mean that if you crashed into the bottom of a line, you didn’t come out on top – which was a bug that I had frequently very early on) that didn’t upset any other constraints (specifically, it rechecked every other collision box each time a collision moved you, and it made sure that if you were already on a line, and weren’t transferring to the new line, it kept you on the line). This was surprisingly difficult, although I eventually got it with some more math. I also added all the graphics and UI that were used in the game, excluding the title screen & introduction cinematic.
As is evident from the blog, this code DID NOT WORK. It worked sometimes. Not much though. I spent so much time debugging it – it’s a miracle I was using Xcode instead of Code::Blocks, because I really needed a good interface to the debugger. I deleted the code that handled moving around lines twice, and the code that checked collisions once. While it might not seem too bad, each line of code you delete is time wasted. It becomes the LD47, then LD46, and pretty soon, you’re out of time to kill. Also, I had difficulty with OpenGL & SFML, because I couldn’t figure out how to make a texture that had transparent places in it.
The next day, I worked on MORE debugging (let’s face it: the movement code was full of murderous bugs), and added the red line feature. I think that this was a very good decision, because it made the game interesting. It gave the game an obstacle – time. If you don’t destroy the floor quickly, the red stuff will fall, and you’ll die and fail. I also created my level creation tool, which I didn’t release because it’s buggy and unintuitive. I also implemented the system that let me show pictures before a level started (e.g. the instructions presented to you before the first two levels) and let you go to the next level. Most of the day was spent debugging, and I ironed out about 3 major bugs in the movement system (ARGHHHH!!!), and created the system for the title screen & introduction cinematic (which makes it relevant to the contest! XD). Those went without any trouble. I created all 5 levels that day as well. I compiled it on my Windows machine that day as well, and submitted it.

Good Things (Do More of These)

• I stayed motivated throughout the 48 hours. Often I hit an obstacle that seemed insurmountable (See: Movement), and thought about giving up, but I could never put down my computer for more than a minute before I thought to myself, How awesome would it be to succeed on my first Ludum Dare? (Answer: Really awesome)
• Even though I am a very algorithmic programmer, I gave a lot of thought to graphics and audio. Of course, thought doesn’t make it happen, but if I were making a game with a bigger time constraint, they would have gotten done.
• My code was moderately neat! I didn’t really get to use the OOP I love so much beyond having it as syntax sugar (storing two variables, xPos & yPos is uglier than storing 1 variable, pos with pos.x & pos.y), but I got my code roughly organized in a tree, with no cyclic dependencies.
• Stayed focused. It’s so tempting to try being on a forum, twitter, and what have you, while still coding. During these 48 hours, I was either programming, creating content, eating, playing soccer, sleeping, or blogging about programming (okay, I tweeted about blogging about programming a few times as well). I programmed for long stretches of time with no interruptions, and never was doing more than one thing.
• I created a game. Rather than taking my good ideas, and arduously journeying 90% of the way up a mountain, being confronted by an obstacle, and dumping them into a pit of doom, I took a decent idea, and reached the summit.

Bad Things (Do Less of These)

• I chose to use a complex system instead of a simple one. While I could have used a system based on blocks to create my worlds, I chose to use a system based on lines instead. I use the word “chose” lightly, though. I didn’t realize that I could use the simpler system, because it never occurred to me. I need to think more next time.
• I screwed up my timelapse. Yes, it takes a special kind of idiot to do that. Idiot, thy name is Milo Brandt! Oh well.
• I had no audio. This was mostly a time constraint, considering that I was coding up until the moment that I had to stop.
• My graphics were slightly ugly. This probably was also mostly a time constraint issue, but it also stems from my relative unfamiliarity with OpenGL. My relationship with OpenGL is… complicated. I keep dumping it, only to realize that I love it, and to come crawling back.

The Future
Certainly, I stole a lot of experience from the Ludum Dare, as discussed above, but I think that I generated some very interesting concepts during the contest that might be worth pursuing in the future. While the acid idea would probably, at most, yield me a pretty cool flash game (if I ever bothered getting good with flash), I think that the duct tape idea could create a very interesting game, and could also be extended to be a 3D puzzle game, like Portal. While I definitely have ideas I want to pursue more at the moment, I would certainly be interested to see how such a game would turn out. Also, I look forwards to future Ludum Dares! Bring it on!

I’m in. I probably won’t make it in time for the contest (since vacationing with my family is a full time job), but I’ll try to get it in for the Jam.

Tools (assuming that I make a 2D game, which is probable considering that meshes are time consuming; if I do make a 3D game, it’ll be in Unity):
IDE: Xcode
Library: SFML
Graphics: GIMP
Audio: cfxr, Garage Band

(And hopefully, unlike last time, I will not screw up my timelapse)

Tags: sfml, unity

My ideas so far (direct from the recesses of my mind):
1. Some sort of racing game with something chasing you that you have to escape
2. Escape from the wild. Some sort of RPG-ish thing.
3. Escape from the army. Maybe like a platformer. Could have interesting mechanics in both having to fight off the enemy (or not? ally the enemy?) and avoid detection by your nation.
4. Use sepia-tone graphics somehow…
5. Mash the escape button. Not sure how this turns into a game…
6. Something where you don’t know what you’re escaping from, and the goal is to find out.
7. Escape the internet/technology. Something about destroying infrastructure related to the internet (because let’s be honest, how else would you escape it?).
8. Escape stress/time pressure. ???
9. Something where “Escape” doesn’t come first in the sentence…
10. Escape daily life. Something about getting away from routines. Could be set in some sort of dictatorship that enforces routines.

So, my idea has been something based around escaping the army. So there will be lots of shooting. Also, there needs to be maps too, so here’s a picture of some procedurally generated terrain that I have started on. It’s supposed to be nice an’ simple. I’ll probably have several types of terrain in the future, but this will by my “urban” environment (without, you know, the buildings and snipers).

In any case, here’s an image to give the illusion of progress (these are basically the final graphics, except without the… uhh… parallax background, sepia tone, buildings, character, etc.)

(Also, I’m unusually tired tonight. Hopefully I will be able to stay up to, at least, when I usually go to bed tomorrow…)

EDIT: I decided that this idea was terrible, and needed to die. So this is unrelated to my final product.

Well, I haven’t had much time to work on my project today (which is why I’m trying for the Jam), but that might be a good thing because I have thoroughly convinced myself that my old idea was not actually worth working on and that it didn’t actually integrate the theme into the game mechanic. Thus, I have come up with a new, better idea (and one that might actually get done in time)!

The idea is basically that you are some sort of city official that is trying to evacuate a city. The player would be able to mark streets as 1-way

So, I managed to get my game logic finished last night, and now since the site is back up, here’s a demo (without so much

milo.grotonma.net/uploads/LD21.zip

It contains no instructions, so I’ll give a brief rundown:
1) Each weird redish-thing is a building. If you click on it, cars spew out. Red Building = Not evacuating, Green Building = Evacuating, Gray Building = Empty.
2) Cars always take the shortest path to the exit (which is any road leaving the left side of the screen). This usually causes gridlock.
3) There is a deadly wave bearing down on the cars. Evacuate the buildings before it’s too late (or don’t; it’s your choice).
4) Clicking on roads makes them into 1-way roads. Cars will obey these UNLESS there is no path to the exit.

Okay. That’s where I am now. Also, that’s an entire game. That means that tomorrow is left for assets, tweaking, and making menus and stuff. Which is AWESOME because, last time I did the Ludum Dare, I was working on the game logic until up to the deadline! Also, my timelapse is working this time! Things are really going up my way this time.

Of course, I have to say that if I had been a fool like last time and tried writing a fairly elaborate physics engine, I would be failing again (Read: All the blog posts I wrote last time about HOW ANNOYING that code was. Debugging it took up, probably, 90% of the entire time I was working on that). Also, every system in this game is discrete, so I didn’t waste time on difficult math (I love doing that math though). I think that, even though I only intended to do the Jam this time around, I’ll be able to make the competition, which is pretty sweet (although, I don’t have any windows computers nearby, so they’ll have to compile for themselves; shouldn’t be too hard though, since its only dependency is SFML).

I’m quite pleased with this game, especially considering that the theme completely caught me off guard (what were you thinking, people who voted for “Escape”?) and that I didn’t really have any good ideas (~first 16 seconds of my timelapse = creating a game below my quality standards) until about 8 hours ago. I’ll have to think about whether I want to keep working on this game after the dare (it needs more spicing up though).

So, throughout this entire dare, I’ve been having to deal with my program randomly segfaulting and crashing due to reasons that were unknown to me, and somehow related to the std::list class. To fix this, I rewrote the class, and it runs perfectly now (or, so I think. It’ll probably crash when I go back to test more). Also, I’ve got my title page and credits page done, and am making good progress towards finishing!

Here’s a screen of the title screen, for your enjoyment (and it gives the name of the game!):

Congratulations!

You are the proud new traffic controller of this doomed city! Why anyone would be so insane as to WANT that position beats me, but you got it, and there is a giant wave coming in from the East. The situation is quite bleak, and it is up to you to prevent as many deaths as possible. This city has a high-tech system that lets you control the evacuation in great detail. When you begin, you will be brought to a screen that looks like this:

On the bottom of this screen, you can see the number of cars that you’ve rescued, and the number of cars that are still alive, but have not yet been rescued. To the right side of the screen, you can see a blue sliver, which is the progress of the wave – it kills any car that it touches. It will grow bigger as time goes on. In the middle of the screen, there are a lot of red-ish blocks. These represent buildings. If you click on one, it will turn green, and start allowing cars to exit from it:

Each car will take the shortest legal route that it can find to the exit. Because of this, cars will often try to take the same route, and it will cause gridlock. Now, in my experience, gridlock and deadly waves do not mix will, so, to combat gridlock, you have another control: You can make streets 1-way only by clicking on them:

1-way roads are marked by the little carrots. Cars will always obey these unless you block off their only exit, in which case, they will act eratically. A good goal is to try to keep all of the exits to the city full of cars at all time. This image also has buildings that are gray – gray buildings have been fully evacuated, or, at least, cannot be evacuated further (that is, all of their occupants drowned because of your ineptitude).

After all the citizens are either dead or safe, you will be evaluated. The following criteria are evaluated:

1. How many people you rescued.
2. How many people you did not rescue.
3. How many people were killed before they escaped a building.
4. How many people were killed while trying to leave the city.
5. How many buildings were completely evacuated.