Which is odd, this early on. I must be getting better at this whole rapid game creation thing. The name is “Dwarven Isolation”. It is about preventing dwarves from mining into each other, which is important since dwarven handshakes cause catastrophic explosions (but I’m sure a smart reader like you knew that). The dwarves, of course, are attracted to shiny objects, like gold or treasure, and are quite good at whacking stuff and making solid rock walls go away.

More seriously, here’s my entire design document.
(more…)

In descending order of quality, the ideas I have so far are:

Idea #1: The player’s goal is to keep several people alone, and to prevent them from contacting each other. The game would take place on a maze on a grid (although, if possible, the graphics would be smooth). New people would be introduced as the game goes on, and the player would be charged with keeping them separate for as long as possible. It would likely be a turn-based type of game where there are two stages. In one, the player places obstacles and stuff, in the other, the entities move. There would be penalties for killing people.

Idea #2: Something about splinter cells or something; trying to function without knowing anything about other members of same “team”.

Idea #3: A damsel in distress self-rescues.

Maybe this time we can break 600 games (although that might not be a good thing).

My goal this time is to make a game that DOESN’T crash randomly because that’s not a good thing. That’s in addition to, you know, everything else, but this whole technical thing gets in the way of that whole fun thing.

EDIT: I wonder if I could make a programming game. I mean, this seems like a rather apt community for such a game…

Well, I have to say that compared to my last Ludum Dare, this experience was COMPLETELY different. The first difference that comes to mind is how I didn’t waste all of my time trying to create a physics/movement engine. That thing sucked up, probably, about 80% of my time and I certainly wouldn’t call it “complete” even now. Also, it was more laid back since I only got around 14 hours to work on the game, as opposed to the 24 – 30 that I had last time.

What Went Well:

• I, once again, was focused the entire time. I was so focussed, in fact, that I forgot to finish off a delicious beverage (although don’t worry – I drank it now).
• My game concept was simple enough to leave me a whole day to work on assets & the front end.
• Audio. It existed this time. I think it sounds pretty nice for, like, 30 seconds on a loop.
• I had lots of screenshots & some demos to share before the compo ended (although I don’t think I packaged the demos correctly, and the LD site was down)

What Didn’t Go So Well:

• Uploading. I wasn’t good at it. I gotta remember to include sndfile.framework & to add other frameworks to the “Copy Frameworks” step in Xcode. I actually lost $5 here because I bet my brother that I uploaded something correctly and it didn’t work.
• I didn’t test all the “pipelines” involved in my game; 1 hour before the contest ended, I realized that I didn’t know how to get audio into my game. I figured it out though.
• All my ideas at the start were basically the same; I was only considering ideas where you (singular) were trying to escape from something, which isn’t really thinking outside of the box. I was actually really displeased with all of my ideas, and wasn’t having much fun developing them until I thought of the evacuation idea.

Overall, I am once again pleased with the product that I produced, and think that it is a pretty big step above my last entry, and am looking forwards to December. I might keep working on my entry (after the ratings though; programmers = good playtesters) since I can think of a few ways to spice it up.

(If you are some sort of STRANGE ALIEN and have yet to play my game, it’s over here)

Well, I submitted my game. I have to remember how to package my submission for next time though, since it took well over an hour for me to go from “Done” to “Done and shared”. So, tips to myself and others using SFML & Mac OSX:
1) sndfile.framework needs to be included.
2) Remember to add frameworks to the “Copy Frameworks” step.

Other than that, I’m very pleased with my game. At the start of this competition, I really did not have any good ideas – or at least, I didn’t really have any ideas that I really wanted to work on until about 40% of the way into the contest (although, I hadn’t had much time to work on it prior to that, so I only lost an hour or two of work time). I actually was planning to leave the competition entirely because my ideas were all basically remakes of some other game – that is, the theme was only present in the assets that I created, not in the game mechanic itself. Also, I got the game finished faster than I thought, since I only *meant* to do the Jam.

I’ll probably get a bit more into the process later, but for now, I’m quite tired.

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.

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!):

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).

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, 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.

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.

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)

I’ve been playing and rating a lot of the games. There’s sooo many, but as far as I’ve gotten into them as of now, most of them are really quite good. Admittedly, some might be questionably related to the theme (of course, this theme was certainly quite open – take any game, and slap a cutscene in, and it’s relevant! Not that I would do anything like that… Although a lot of people who were creative seem to have interpreted the theme in cool ways). Out of the games I’ve seen, I rated 90% at least a 3 on fun, and probably have rated the majority as 4 or 5. I’ve found most the games are pretty innovative as well – I haven’t seen any repeated concepts (certainly repeated genres, but each game is quite unique) throughout the contest, and I don’t think I’ve seen any generic games where you could just take an existing game, and change the textures. Surely, more time would let people add better audio & graphics, and for level-based games, more levels, and all the other things that make a game polished, but I just want to congratulate everyone who participated in the Dare or Jam on making a game that is enjoyable to play.

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!

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

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!

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).

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…

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.

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.